Re: Munich D Meetup July 2017
On Monday, 3 July 2017 at 18:23:27 UTC, Dragos Carp wrote: Hi all, On 18 July, we will have our next Munich meetup. Mario will give a talk with the title "Avoiding the Big Ball of Mud". As usual before and after the talk we will also have good conversations with pizza and drinks. Please RSVP on: https://www.meetup.com/de-DE/Munich-D-Programmers/events/241264180/ Thanks, Dragos Is it going to be worth 11 hours by train ? If so I am there tomarrow.
Re: Munich D Meetup July 2017
On Monday, 17 July 2017 at 12:16:13 UTC, Stefan Koch wrote: On Monday, 3 July 2017 at 18:23:27 UTC, Dragos Carp wrote: Hi all, On 18 July, we will have our next Munich meetup. Mario will give a talk with the title "Avoiding the Big Ball of Mud". As usual before and after the talk we will also have good conversations with pizza and drinks. Please RSVP on: https://www.meetup.com/de-DE/Munich-D-Programmers/events/241264180/ Thanks, Dragos Is it going to be worth 11 hours by train ? If so I am there tomarrow. Wow 11 hours. No - the Meetup tomorrow is only an evening, but as Andrei mentioned we are planning a bigger event in October for which it definitely will be worth traveling to Munich (sth. like the DConf Europe idea that was discussed on the NG). We will announce more details soon.
Re: DIP 1010--Static foreach--Accepted
On 7/16/17 1:04 PM, Andrei Alexandrescu wrote: On 7/16/17 9:10 AM, Mike Parker wrote: Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei. Indeed. Kudos to Timon (and thanks Mike for driving the process). This is a well done DIP that many others could draw inspiration from. -- Andrei What is the resolution of how break statements affect static foreach/foreach? i.e. this section: "As some consider this to be potentially confusing, it has been suggested that break and continue directly inside static foreach should instead be compiler errors and require explicit labels. This DIP leaves this decision to the language authors, but recommends the above semantics." -Steve
Re: DIP 1010--Static foreach--Accepted
On 7/16/17 9:10 AM, Mike Parker wrote: Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei. I've added my summary to the Review section of the DIP, but I'll quote it here in full: "This DIP was accepted by the language authors. Both Proposal 1 and Proposal 2 were accepted. Evaluation of the suggested future improvements has been put off until some future date when sufficient experience with the implementation has been accumulated. Regarding Proposal 1, they find it integrates well with the rest of the language and falls within the spirit of D. They see it more as the removal of a limitation than the addition of a feature, and like that it reuses the syntax and semantics of existing language entities (`alias` and `enum`). They see Proposal 2 as the core of the DIP, finding that it is well-motivated and liking that it reuses elements of Proposal 1. On the whole, they believe that this DIP obeys the rule of least astonishment in that most of the examples work as expected and are easy to understand by lowering to the pre-DIP language. They also say that the examples are a good sanity check to ensure that the feature fulfills its envisioned applications, and that the DIP is exceptionally well written. This should be read as a note to future DIP authors that they will not be wrong to use this DIP as a model." https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md Awesome! Super glad and looking forward to this in 2.076? ;) -Steve
Re: DIP 1010--Static foreach--Accepted
On Monday, 17 July 2017 at 12:38:27 UTC, Steven Schveighoffer wrote: On 7/16/17 1:04 PM, Andrei Alexandrescu wrote: On 7/16/17 9:10 AM, Mike Parker wrote: Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei. Indeed. Kudos to Timon (and thanks Mike for driving the process). This is a well done DIP that many others could draw inspiration from. -- Andrei What is the resolution of how break statements affect static foreach/foreach? i.e. this section: "As some consider this to be potentially confusing, it has been suggested that break and continue directly inside static foreach should instead be compiler errors and require explicit labels. This DIP leaves this decision to the language authors, but recommends the above semantics." -Steve static break & static continue anyone?
Re: DIP 1010--Static foreach--Accepted
On Monday, 17 July 2017 at 12:38:27 UTC, Steven Schveighoffer
wrote:
On 7/16/17 1:04 PM, Andrei Alexandrescu wrote:
On 7/16/17 9:10 AM, Mike Parker wrote:
Congratulations to Timon Gehr. Not only was his "Static
foreach" DIP accepted, it picked up a good deal of praise
from Walter & Andrei.
Indeed. Kudos to Timon (and thanks Mike for driving the
process). This is a well done DIP that many others could draw
inspiration from. -- Andrei
What is the resolution of how break statements affect static
foreach/foreach?
i.e. this section:
"As some consider this to be potentially confusing, it has been
suggested that break and continue directly inside static
foreach should instead be compiler errors and require explicit
labels. This DIP leaves this decision to the language authors,
but recommends the above semantics."
-Steve
I think the only reliable way is to not use jumps (goto, break,
continue) at all.
E.g. if you want to unroll the following loop:
foreach (x; someRange)
{
if (x.isSpecial)
break;
x.writeln();
}
You would need to guard every statement/declaration:
static foreach (x; someRange)
static if (!x.isSpecial)
x.writeln();
Hence why, I believe that we need more powerful range-like
algorithms for manipulating alias sequences. Though in case this
using what's in std.meta is not much of a stretch, ultimately it
becomes repetitive and very verbose when used more heavily and
ultimately doesn't offer significant improvement over the code
above:
foreach (x; Filter!(templateNot!isSpecial, aliasSeqOf!someRange))
x.writeln();
(I'm working on a functional programming library which would
allow to use the same functions to transform ranges, alias
sequences and other reducible/iterable objects, which should make
composing alias sequence transformations a bit more easy and
scalable.)
Anyway, if you're iterating over homogeneous expression
sequences, via DIP1010 you should be able to use std.algorithm
and std.range functions directly, since the resulting range would
be automatically evaluated at CT and expanded as an expression
sequence:
static foreach (x; someRange.filter!(x => !x.isSpecial))
x.writeln();
Re: DIP 1010--Static foreach--Accepted
On Monday, 17 July 2017 at 12:50:16 UTC, Nicholas Wilson wrote: On Monday, 17 July 2017 at 12:38:27 UTC, Steven Schveighoffer wrote: On 7/16/17 1:04 PM, Andrei Alexandrescu wrote: On 7/16/17 9:10 AM, Mike Parker wrote: Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei. Indeed. Kudos to Timon (and thanks Mike for driving the process). This is a well done DIP that many others could draw inspiration from. -- Andrei What is the resolution of how break statements affect static foreach/foreach? i.e. this section: "As some consider this to be potentially confusing, it has been suggested that break and continue directly inside static foreach should instead be compiler errors and require explicit labels. This DIP leaves this decision to the language authors, but recommends the above semantics." -Steve static break & static continue anyone? break & continue are special case gotos. What would be the semantics of static goto? In C you can skip the initialization of variables via goto. Would you be able to skip declarations via static goto?
DCompute: GPGPU with Native D for OpenCL and CUDA
Nicholas Wilson has put together a blog post on his progress with DCompute, expanding on his DConf talk. I have to admit that this is one of the D projects I'm most excited about, even though I'll probably never have a need to use it. I'd love to find an excuse to do so, though! Blog: https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native-d-for-opencl-and-cuda/ Reddit: https://www.reddit.com/r/programming/comments/6nt4ba/dcompute_gpgpu_with_native_d_for_opencl_and_cuda/
Re: DIP 1010--Static foreach--Accepted
On 7/17/17 9:23 AM, Petar Kirov [ZombineDev] wrote:
On Monday, 17 July 2017 at 12:38:27 UTC, Steven Schveighoffer wrote:
On 7/16/17 1:04 PM, Andrei Alexandrescu wrote:
On 7/16/17 9:10 AM, Mike Parker wrote:
Congratulations to Timon Gehr. Not only was his "Static foreach" DIP
accepted, it picked up a good deal of praise from Walter & Andrei.
Indeed. Kudos to Timon (and thanks Mike for driving the process).
This is a well done DIP that many others could draw inspiration from.
-- Andrei
What is the resolution of how break statements affect static
foreach/foreach?
i.e. this section:
"As some consider this to be potentially confusing, it has been
suggested that break and continue directly inside static foreach
should instead be compiler errors and require explicit labels. This
DIP leaves this decision to the language authors, but recommends the
above semantics."
I think the only reliable way is to not use jumps (goto, break,
continue) at all.
E.g. if you want to unroll the following loop:
foreach (x; someRange)
{
if (x.isSpecial)
break;
x.writeln();
}
You would need to guard every statement/declaration:
static foreach (x; someRange)
static if (!x.isSpecial)
x.writeln();
My concern is that the proposal asked for break to apply to the runtime
construct that surrounds the loop. So for instance, break would apply to
the switch statement outside the static foreach.
This differs from current static looping (i.e. foreach over a tuple),
where break applies to the foreach.
I'm not concerned with breaking out of the loop. I agree that the
proposed behavior is the best choice. However, it's confusing given
existing behavior that doesn't do that.
-Steve
Re: DCompute: GPGPU with Native D for OpenCL and CUDA
On Monday, 17 July 2017 at 13:50:22 UTC, Mike Parker wrote: Nicholas Wilson has put together a blog post on his progress with DCompute Great, Nick!
static foreach is now in github master
For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Happy hacking! Andrei
Re: DCompute: GPGPU with Native D for OpenCL and CUDA
On 7/17/2017 6:50 AM, Mike Parker wrote: Blog: https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native-d-for-opencl-and-cuda/ Reddit: https://www.reddit.com/r/programming/comments/6nt4ba/dcompute_gpgpu_with_native_d_for_opencl_and_cuda/ It's now #10 on Hacker News! https://news.ycombinator.com/news
Re: New library: open multi-methods
Thinking about it, 'openmethods' would probably be a better module/package name than just 'methods'. It emphasizes the #1 feature, i.e. polymorphism outside of classes.
Re: static foreach is now in github master
On Monday, 17 July 2017 at 18:14:35 UTC, Andrei Alexandrescu wrote: For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Happy hacking! Andrei or for those using homebrew: `brew install dmd --HEAD`
Re: static foreach is now in github master
On Monday, 17 July 2017 at 18:14:35 UTC, Andrei Alexandrescu wrote: For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, Or just wait for the next nightly until tomorrow around 5AM UTC. curl -fsS https://dlang.org/install.sh | bash -s dmd-nightly the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Great news.
Re: New library: open multi-methods
On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote: Thinking about it, 'openmethods' would probably be a better module/package name than just 'methods'. It emphasizes the #1 feature, i.e. polymorphism outside of classes. Googling `multimethods` brought up more programming-related topics than `openmethods`.
Re: New library: open multi-methods
On Monday, 17 July 2017 at 21:31:20 UTC, jmh530 wrote: On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote: Thinking about it, 'openmethods' would probably be a better module/package name than just 'methods'. It emphasizes the #1 feature, i.e. polymorphism outside of classes. Googling `multimethods` brought up more programming-related topics than `openmethods`. Or you could call it omm and then just refer to open multi-methods in the documentation.
Re: DIP 1010--Static foreach--Accepted
On 7/17/17 8:38 AM, Steven Schveighoffer wrote: What is the resolution of how break statements affect static foreach/foreach? We initially allowed break and continue to refer to the enclosing statement, but upon further consideration we will make it an error. This allows us to collect more experience with the feature and leaves us the option to permit break/continue later on. I have contacted Timon about the matter. Thanks! -- Andrei
Re: New library: open multi-methods
On Monday, 17 July 2017 at 21:31:20 UTC, jmh530 wrote: On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote: Thinking about it, 'openmethods' would probably be a better module/package name than just 'methods'. It emphasizes the #1 feature, i.e. polymorphism outside of classes. Googling `multimethods` brought up more programming-related topics than `openmethods`. Yeah, I know, but I can imagine someone casually browsing the registry, coming across the module and saying "multi-methods? yeah, cool, but I don't remember ever needing such a thing". Indeed "multi" is nice, but IMO "open" is much more important. It is still much more frequent to have only one virtual argument. Take the awful Visitor pattern, for example. It can be neatly replaced with an open method taking only one virtual argument (barring other considerations). 'openmultimethods' is another option but again it emphasizes 'multi'. Anyway, if I go for just 'openmethods', there are enough mentions of 'multi-methods' in the docs. I think I will rename 'methods' to 'openmethods' for the time being, but the discussion remains open. Not renaming the repo yet. Thinking about it, I should add a Visitor replacement example... J-L
Re: New library: open multi-methods
On Monday, 17 July 2017 at 22:46:02 UTC, Jean-Louis Leroy wrote: I think I will rename 'methods' to 'openmethods' for the time being, but the discussion remains open. Not renaming the repo yet. On the other hand, when I saw methods, my first thought was R's methods, which I imagine is similar if I'm not mistaken.
Re: New library: open multi-methods
On Monday, 17 July 2017 at 22:59:03 UTC, jmh530 wrote: On Monday, 17 July 2017 at 22:46:02 UTC, Jean-Louis Leroy wrote: I think I will rename 'methods' to 'openmethods' for the time being, but the discussion remains open. Not renaming the repo yet. On the other hand, when I saw methods, my first thought was R's methods, which I imagine is similar if I'm not mistaken. I don't know R but after a trip to Wikipedia it looks like it. J-L
Re: DCompute: GPGPU with Native D for OpenCL and CUDA
On Monday, 17 July 2017 at 13:50:22 UTC, Mike Parker wrote: Nicholas Wilson has put together a blog post on his progress with DCompute, expanding on his DConf talk. I have to admit that this is one of the D projects I'm most excited about, even though I'll probably never have a need to use it. I'd love to find an excuse to do so, though! Blog: https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native-d-for-opencl-and-cuda/ Reddit: https://www.reddit.com/r/programming/comments/6nt4ba/dcompute_gpgpu_with_native_d_for_opencl_and_cuda/ Thanks for that. Oh and @JohnColvin do you like the solution for the lambdas?
Re: New library: open multi-methods
On Monday, 17 July 2017 at 21:32:13 UTC, jmh530 wrote: On Monday, 17 July 2017 at 21:31:20 UTC, jmh530 wrote: On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote: Thinking about it, 'openmethods' would probably be a better module/package name than just 'methods'. It emphasizes the #1 feature, i.e. polymorphism outside of classes. Googling `multimethods` brought up more programming-related topics than `openmethods`. Or you could call it omm and then just refer to open multi-methods in the documentation. Yeah that's what the omm in yomm11 means, but I am not too fond of acronyms. In C++ it was the library name (-lyomm11) and also the project name but no the namespace. J-L
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 00:47:04 UTC, Jean-Louis Leroy wrote:
I don't know R but after a trip to Wikipedia it looks like it.
J-L
R is listed as one of the languages with built-in support in this
wiki link. I searched for multiple dispatch because I was
familiar with the similar feature in julia, and that's how they
refer to it.
https://en.wikipedia.org/wiki/Multiple_dispatch
An excerpt statement from this wiki page is :
" dynamically dispatched based on the run-time (dynamic) type
or, in the more general case some other attribute, of more than
one of its arguments"
Based on the 'some other attribute', I wonder if the library
could conceivably be extended to dispatch based on the User
Defined Attribute info
https://dlang.org/spec/attribute.html
@('c') string s;
pragma(msg, __traits(getAttributes, s)); // prints tuple('c')
Re: New library: open multi-methods
On 07/16/2017 10:24 AM, Jean-Louis Leroy wrote: > TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md Woot! :) I'm so happy to see this project complete. Honestly, growing up with languages without this feature (C and C++), I've not even known that I needed this feature but your example (e.g. matrix multiplication) are very convincing. If there are enough differences compared to your C++ articles, perhaps you may consider following this up with a blog post. It would be nice to see some performance results as well like you have on your C++ articles. Ali
Re: static foreach is now in github master
On 2017-07-17 20:14, Andrei Alexandrescu wrote: For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Happy hacking! That was quick, and awesome :) Great work to Timon and everyone else involved. -- /Jacob Carlborg
Re: DIP 1010--Static foreach--Accepted
On 2017-07-17 14:39, Steven Schveighoffer wrote: Awesome! Super glad and looking forward to this in 2.076? ;) It's already merged [1] so..., why not :) [1] http://forum.dlang.org/post/okiuqb$1eti$1...@digitalmars.com -- /Jacob Carlborg
Re: static foreach is now in github master
On Tuesday, 18 July 2017 at 06:48:29 UTC, Jacob Carlborg wrote: On 2017-07-17 20:14, Andrei Alexandrescu wrote: For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Happy hacking! That was quick, and awesome :) Great work to Timon and everyone else involved. wow! Now, just how am I supposed to be able to work today (using C) and not play with this pure awesomeness?!
