Re: dbox is a complete D2 port of the Box2D game physics library
On Tuesday, 16 June 2020 at 17:52:37 UTC, aberba wrote: On Friday, 23 May 2014 at 22:00:51 UTC, Andrej Mitrovic wrote: https://github.com/d-gamedev-team/dbox What is Box2D? == [...] This sort of investment still amazes me. This is a 6 years old post though. I'm sure there are much better graphics libraries out there by now, including D ones.
Re: LDC 1.22.0
On Tue, Jun 16, 2020 at 08:12:12PM +, kinke via Digitalmars-d-announce wrote: > Glad to announce LDC 1.22 - some highlights: [...] Awesome!! Thanks for continuing to bring us this awesome compiler! T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
Re: LDC 1.22.0
On Tuesday, 16 June 2020 at 20:12:12 UTC, kinke wrote: Glad to announce LDC 1.22 - some highlights: [...] - `pragma(inline, true)` fix when emitting multiple object files in a single cmdline. This may have a significant impact on performance (incl. druntime/Phobos) when not using LTO. i.e significant like "positive" impact ?
Re: LDC 1.22.0
On Tuesday, 16 June 2020 at 20:12:12 UTC, kinke wrote: [...] Amazing. I just love the LDC momentum.
Re: This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!
On 16.06.20 17:35, Robert M. Münch wrote: On 2020-06-15 13:01:02 +, Timon Gehr said: The talk will be on YouTube. Great. Papers: https://www.sri.inf.ethz.ch/publications/bichsel2020silq https://www.sri.inf.ethz.ch/publications/gehr2020lpsi Source code: https://github.com/eth-sri/silq https://github.com/eth-sri/psi/tree/new-types Thanks, somehow missed these. ... I think they were not online when you asked (neither were the versions in ACM DL). What's the main difference of your approach WRT something like this: http://pyro.ai/ ... Pyro is a Python library/EDSL, while PSI is a typed programming language (with some support for dependent typing). Pyro's focus is on scalable machine learning. PSI alone would not be particularly helpful there. Pyro fits a parameterized probabilistic model to data using maximum likelihood estimation while at the same time inferring a posterior distribution for the latent variables of the model. If you use a probabilistic model without parameters, Pyro can be used for plain probabilistic inference without maximum likelihood estimation. PSI currently does not do optimization, just probabilistic inference. (PSI can do symbolic inference with parameters, then they can be optimized with some other tool.) The goal is to find a distribution such that KL-divergence of the posterior and this distribution is as small as possible. PSI always finds the true posterior when it is successful (i.e. KL-divergence 0 when applicable), but will not always succeed, in particular, it might not be fast enough, or the result may not be in a useful form. Pyro produces best-effort results. You may have to use some sort of validation to make sure that results are useful. - The posterior distribution is assumed to have a specific form that can be represented symbolically and is normalized by construction. Often, the true posterior is not actually (known to be) in that family. - The KL-divergence is upper-bounded using ELBO (evidence lower bound). - The (gradient of the) ELBO is approximated by sampling from the assumed posterior with current parameters. - This approximate ELBO is approximately optimized using gradient descent. Also see: https://pyro.ai/examples/svi_part_i.html BTW: I'm located in Zug... so not far away from you guys.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote: [snip] Pretty cool, thanks for the fixups. It may make for a good documentation example, in that it may help make clear that you need to pass the module in somehow when dealing with non-member functions (AFAICT). You could include a comment about how it would be different if it were split into separate files. I have a few more questions... In your original example, is there any issue if we then make transform a templated non-member function that is generic over types like Adder (maybe there is an enum hasAddableMember that is true for Adder and false for Plus1)? Am I right that the shared static constructor in vtable means that there is one vtable for all the instances? Are there any technical issues preventing Polymorphism from accepting a class in addition to an interface?
Re: This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!
On 2020-06-15 13:01:02 +, Timon Gehr said: The talk will be on YouTube. Great. Papers: https://www.sri.inf.ethz.ch/publications/bichsel2020silq https://www.sri.inf.ethz.ch/publications/gehr2020lpsi Source code: https://github.com/eth-sri/silq https://github.com/eth-sri/psi/tree/new-types Thanks, somehow missed these. What's the main difference of your approach WRT something like this: http://pyro.ai/ BTW: I'm located in Zug... so not far away from you guys. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 12:30:24 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 11:31:14 UTC, Atila Neves wrote:
On Tuesday, 16 June 2020 at 11:24:05 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
[snip]
In the more longer-term, is the goal of the project to
implement a Typescript / Go interfaces like structural type
system in user space?
Yes. Other than allowing multiple interfaces, I think it's
already implemented.
I'm not familiar with what Typescript does, but doesn't Go
allow interfaces to be implemented by free-standing functions?
So does tardy.
Sorry, I had not realized that. I took Go's interface example
and converted it to D. Would this work with tardy?
With a few changes, yes (added missing semicolons, changed
IGeometry to Geometry in `measure`, passed the current module so
tardy can find the UFCS functions, added `@safe pure` to the UFCS
functions:
import tardy;
interface IGeometry
{
double area() @safe pure const;
double perim() @safe pure const;
}
alias Geometry = Polymorphic!IGeometry;
struct Rect {
double width, height;
}
struct Circle {
double radius;
}
double area(Rect r) @safe pure {
return r.width * r.height;
}
double perim(Rect r) @safe pure {
return 2 * r.width + 2 * r.height;
}
double area(Circle c) @safe pure {
import std.math: PI;
return PI * c.radius * c.radius;
}
double perim(Circle c) @safe pure {
import std.math: PI;
return 2 * PI * c.radius;
}
void measure(Geometry g) {
import std.stdio: writeln;
writeln(g);
writeln(g.area);
writeln(g.perim);
}
void main() {
auto r = Rect(3.0, 4.0);
auto c = Circle(5.0);
Geometry.create!__MODULE__(r).measure;
Geometry.create!__MODULE__(c).measure;
}
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 12:30:24 UTC, jmh530 wrote:
[snip]
double area(Rect r) {
return r.width * r.height
}
double perim(Rect r) {
return 2 * r.width + 2 * r.height
}
double area(Circle c) {
import std.math: PI;
return PI * c.radius * c.radius
}
double perim(Circle c) {
import std.math: PI;
return 2 * PI * c.radius
}
These should be @safe pure.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 11:31:14 UTC, Atila Neves wrote:
On Tuesday, 16 June 2020 at 11:24:05 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
[snip]
In the more longer-term, is the goal of the project to
implement a Typescript / Go interfaces like structural type
system in user space?
Yes. Other than allowing multiple interfaces, I think it's
already implemented.
I'm not familiar with what Typescript does, but doesn't Go
allow interfaces to be implemented by free-standing functions?
So does tardy.
Sorry, I had not realized that. I took Go's interface example and
converted it to D. Would this work with tardy?
```
import tardy;
interface IGeometry
{
double area() @safe pure const;
double perim() @safe pure const;
}
alias Geometry = Polymorphic!IGeometry;
struct Rect {
double width, height;
}
struct Circle {
double radius;
}
double area(Rect r) {
return r.width * r.height
}
double perim(Rect r) {
return 2 * r.width + 2 * r.height
}
double area(Circle c) {
import std.math: PI;
return PI * c.radius * c.radius
}
double perim(Circle c) {
import std.math: PI;
return 2 * PI * c.radius
}
void measure(IGeometry g) {
import std.stdio: writeln;
writeln(g);
writeln(g.area);
writeln(g.perim);
}
void main() {
auto r = Rect(3.0, 4.0);
auto c = Circle(5.0);
r.Geometry.measure;
c.Geometry.measure;
}
```
That is a little bit more similar to open methods. This
requires the type inherit from the interface and implement
member functions.
There is no inheritance anywhere, otherwise that'd defeat the
point of the library in the first place. I used interfaces
because they exist and intuively make sense, and support
classes because why not. Otherwise it could be just structs and
other values with candidate UFCS functions.
Sorry, that was me being hasty. I was just concerned about the
member functions part of it, which you said above is not a
concern.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 11:24:05 UTC, jmh530 wrote: On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote: [snip] In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space? Yes. Other than allowing multiple interfaces, I think it's already implemented. I'm not familiar with what Typescript does, but doesn't Go allow interfaces to be implemented by free-standing functions? So does tardy. That is a little bit more similar to open methods. This requires the type inherit from the interface and implement member functions. There is no inheritance anywhere, otherwise that'd defeat the point of the library in the first place. I used interfaces because they exist and intuively make sense, and support classes because why not. Otherwise it could be just structs and other values with candidate UFCS functions. I'm not that knowledgeable of Boost, but I see some similarities with Boost's type_erasure library. However, one main difference is that it is implemented with concepts, rather than the equivalent of interfaces. I would guess using interfaces has some benefits in terms of implementation since you know exactly what functions need to be called. Something like @models is very flexible, but that might be a downside. Using an interface means using familiar syntax with the added benefits of being able to write a signature like this: int* fun(int*, int) @safe @nogc pure return scope const; And then have all of those attributes and `this` modifiers used in the vtable function pointer declarations. Overloading and UFCS get dealt with naturally by usual language rules.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote: [snip] In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space? Yes. Other than allowing multiple interfaces, I think it's already implemented. I'm not familiar with what Typescript does, but doesn't Go allow interfaces to be implemented by free-standing functions? That is a little bit more similar to open methods. This requires the type inherit from the interface and implement member functions. Also how would it compare to Rust traits? Rust's traits are usually used like D's template contraints and Haskell's type classes. The only way they're relevant here are trait objects: https://doc.rust-lang.org/reference/types/trait-object.html [snip] Similar to above, aren't Rusts's trait objects defined using separate impl blocks, rather than as member functions. --- I'm not that knowledgeable of Boost, but I see some similarities with Boost's type_erasure library. However, one main difference is that it is implemented with concepts, rather than the equivalent of interfaces. I would guess using interfaces has some benefits in terms of implementation since you know exactly what functions need to be called. Something like @models is very flexible, but that might be a downside.
Re: Origins of the D Programming Language now published by ACM!
On Saturday, 13 June 2020 at 03:16:05 UTC, Walter Bright wrote: https://dl.acm.org/doi/abs/10.1145/3386323 Many, many thanks to Mike Parker and Andrei Alexandrescu for their endless hours spent fixing the mess I originally wrote. Many, thanks to you, too! Just found the time to read it (again). What I think is worth mentioning as additional milestones, is the setup of code.dlang.org (DUB >1800 packages now) and the online tutorial - Dlang Tour: tour.dlang.org with the embedded D compiler.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote: On Tuesday, 16 June 2020 at 03:56:52 UTC, Petar Kirov [ZombineDev] wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy Looks interesting, nice work! How does it compare to: https://dlang.org/phobos/std_experimental_typecons#.wrap ? For starters, that uses a class and inheritance internally and therefore has all the drawbacks of that approach as laid out in tardy's README.md. Then there's the lack of allocator support. In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space? Yes. Other than allowing multiple interfaces, I think it's already implemented. Cool! Also how would it compare to Rust traits? Rust's traits are usually used like D's template contraints and Haskell's type classes. The only way they're relevant here are trait objects: Yes I meant trait objects actually. https://doc.rust-lang.org/reference/types/trait-object.html The main difference is that tardy is supposed to give the user choices over how the dispatch is actually implemented. Allocators alone are huge. Interesting! I guess the main difference, would be that Rust enforces a nominal type system like approach, where 2 differently named traits that otherwise define the same interface are not considered interchangeable. Yes, that's also a difference.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 03:56:52 UTC, Petar Kirov [ZombineDev] wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy Looks interesting, nice work! How does it compare to: https://dlang.org/phobos/std_experimental_typecons#.wrap ? For starters, that uses a class and inheritance internally and therefore has all the drawbacks of that approach as laid out in tardy's README.md. Then there's the lack of allocator support. In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space? Yes. Other than allowing multiple interfaces, I think it's already implemented. Also how would it compare to Rust traits? Rust's traits are usually used like D's template contraints and Haskell's type classes. The only way they're relevant here are trait objects: https://doc.rust-lang.org/reference/types/trait-object.html The main difference is that tardy is supposed to give the user choices over how the dispatch is actually implemented. Allocators alone are huge. I guess the main difference, would be that Rust enforces a nominal type system like approach, where 2 differently named traits that otherwise define the same interface are not considered interchangeable. Yes, that's also a difference.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Monday, 15 June 2020 at 20:47:16 UTC, 12345swordy wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy [...] Wouldn't a top type be a better way to achieve this? -Alex How?
