Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 13:46:24 UTC, Jean-Louis Leroy
wrote:
What if you do:
shared static this(){
mixin(registerMethods);
}
You mean in openmethods.d?
Yes. I haven't tried something like that, but it seems like a use
case for either static this or shared static this.
https://dlang.org/spec/class.html#StaticConstructor
https://dlang.org/spec/class.html#SharedStaticConstructor
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 15:56:06 UTC, Jean-Louis Leroy wrote: Among other things, the mixin introduces two functions in the module's scope: the function the user actually calls (the "dispatcher"). E.g. it creates a times(double, Matrix) when it sees a times(double, virtual!Matrix). It also declares a "discriminator" function which is used to locate which method the specializations (the @method funcs) relates to (it has to deal with overloads - there are two "times" methods). This has to be done for every module that contains method declarations (virtual!) or implementations (@method). That's why it has to be a string mixin (at least until we have static foreach) and be called in the matrix etc modules, not in module openmethods. I see what you mean. It only works per thread, not per module. What you really need is some kind of module constructor.
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 15:33:28 UTC, jmh530 wrote:
On Wednesday, 19 July 2017 at 13:46:24 UTC, Jean-Louis Leroy
wrote:
What if you do:
shared static this(){
mixin(registerMethods);
}
You mean in openmethods.d?
Yes. I haven't tried something like that, but it seems like a
use case for either static this or shared static this.
https://dlang.org/spec/class.html#StaticConstructor
https://dlang.org/spec/class.html#SharedStaticConstructor
Among other things, the mixin introduces two functions in the
module's scope: the function the user actually calls (the
"dispatcher"). E.g. it creates a times(double, Matrix) when it
sees a times(double, virtual!Matrix). It also declares a
"discriminator" function which is used to locate which method the
specializations (the @method funcs) relates to (it has to deal
with overloads - there are two "times" methods). This has to be
done for every module that contains method declarations
(virtual!) or implementations (@method). That's why it has to be
a string mixin (at least until we have static foreach) and be
called in the matrix etc modules, not in module openmethods.
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 15:33:28 UTC, jmh530 wrote: Yes. I haven't tried something like that, but it seems like a use case for either static this or shared static this. https://dlang.org/spec/class.html#StaticConstructor https://dlang.org/spec/class.html#SharedStaticConstructor Based on some of your README.md text, you may need to do static this rather than shared static this for what I suggested. I don't really know, but worth investigating. I liked Ali's suggestion for mixin updateMethods. Again, not sure if it should be static this or shared static this, but if you have static this for registerMethods, then a shared static this for updateMethods may occur before that. I'm not sure how important the order is.
Re: New library: open multi-methods
On Sunday, 16 July 2017 at 17:24:17 UTC, Jean-Louis Leroy wrote: Hello, TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md for an explanation of what open multi-methods are, if you are not familiar with the idea.You may also want to read my article on Code Project https://www.codeproject.com/Articles/635264/Open-Multi-Methods-for-Cplusplus11-Part-1 Earlier this year I attended Ali Çehreli's talk at C++ Now. He did a good job: I walked out with the desire to learn about D and see how it measures up against C++, especially in terms of meta-programming and language extensibility. The first programming language I learned is Forth and I did some Lisp programming, so as you can imagine, my expectations are high. As an experiment, I decided to try to port parts of my yomm11 library to D. The experience turned out to be pleasant and I ended up writing a full implementation, with some friendly help from Ali and others in the Learn forum. I think that what I have now is good enough to show. The git repo is here https://github.com/jll63/methods.d and I will post a package to the registry soon. If you have the inclination, feel free to review and comment. This is my very first D project and I certainly have missed some idioms and been clumsy at times. Jean-Louis Leroy Interesting. One problem I think the above approach has is adding methods after compilation. Say, a plugin adds a new derived matrix type SparseMatrix and wants to customize the addition of them. This is impossible under the current model, is it not? Would it not be possible create a sort of "externmultimethod" that mimics extern'ing a method? Basically, on the "server/host" side there is a method that can be used to add new multimethods at runtime. It takes meta data and extends the virtual table to handle dispatching it along with the other functions. The "client/plugin" side has the multimethod it wants to add to the dispatch and it does this by giving it all the needed information to do so and using the new externmultimethod method to do it.
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 18:21:21 UTC, Ali Çehreli wrote:
On 07/18/2017 11:03 AM, jmh530 wrote:
> the mixin(registerMethods); could then be adjusted so that
void
> print(virtual!Matrix m); is mixed in automatically because we
now know
> how to construct it.
That reminds me: Would the following be possible and better?
// From
void main()
{
updateMethods();
// ...
}
// To
mixin(constructMethods());
void main()
{
// ...
}
constructMethods() could return the following string:
string constructMethods() {
return q{
shared static this() { updateMethods(); }
};
}
OK, I think I may have found solutions to both problems. The
question is, is it too hacky?
1/ method registration
Replace this:
import openmethods;
mixin(registerMethods);
...with:
mixin(import(openmethoddecls));
...that does the two above. Problem is, it needs -Jpath on the
command line to work. Unless there is a workaround?
2/ updateMethods
During static construction, I could set the dispatch tables to
make all the methods call a function that does updateMethods()
then re-dispatches. The cost of the first method call would be
huge, but if it matters the user can still call updateMethods
explicitly.
Thoughts?
Re: Release D 2.075.0
On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [...] Wow, dmd builds in 12 seconds on a single linux/x64 core, can't wait to see what that time is when the backend is in D too, especially since it's taking most of the compile time now. Thanks to those involved for all the work on the release.
Re: Release D 2.075.0
On 7/19/2017 12:34 PM, Joakim wrote: when the backend is in D too The sticking point there is the base D compiler used by GDC and LDC needs to be upgraded with the -mv switch. For discussion: https://github.com/dlang/dmd/pull/6907
Release D 2.075.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Glad to announce D 2.075.0. This release comes with various phobos additions, a repackaged std.datetime, configurable Fiber stack guard pages (now also on Posix), and optional precise GC scanning for the DATA/TLS segment (static data) on Windows. http://dlang.org/download.html http://dlang.org/changelog/2.075.0.html - -Martin -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAllvfHYACgkQsnOBFhK7 GTnSzhAAoSbvYNslsKZ0yqOOlQIIGAlfhNc4SlZold83DS/SPVjMzCPRURHwQgvj T+NxivnAT8t794MBauYFv8t5JF1vEKf7e6Nyc6durr6zEDLwIuRGkjXnBzZjgC/J DrCKTxuLpWqW+EIDB0V6VNUsrK+M9bz4GFZe3vYzK8CAO+c0l1a4/g9vf8Uf4KIv 4cSZ2lxsSZf4VuPlfPKXc9bdnVDNxm3uare/BtYM94V6w0f+z4xbmf9FCa86t4P+ Z7Ll2z14n7Ps9BxgLjHGkcPMeO/IwPL/8o+gce0QVlitHirfxayTtQyv/M4HwY+9 A2IGfrrErfeyJ1JmnBHw6uwQdER7C3z3NJPKP+GCF6vIuDXxxUOE9Nu792HBsFMg Y6osvMqXqEp7dDAytTAnTKOd2R3Lg8ys7gx5xW21aBRRAhO4zBQ5bMTpvXhxEVxn AKcnq4ri3tuwkPoPPNDSXMk32lqy0t/Ere8/X8dhL/8J04CNvAuiTaVQJsQnHKdw 4tQ7q55BGdsNqWdA7DHBFGcgbHmBsNfKA7fIb1OpggVzADNT7tLEAM4H498NAnoO 4AjnKZLJw1KhIdycDRkMz13m3zgVQvV4EdOENXTOlyOoRUrPA9cQx5N01MLA8WBG 4FkbqIlsjFBUj2NHRq1KsxDAI34DbSPXFzIeX5MJTixXqDL0eWo= =HmY4 -END PGP SIGNATURE-
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 06:27:40 UTC, James Dean wrote: Interesting. One problem I think the above approach has is adding methods after compilation. Say, a plugin adds a new derived matrix type SparseMatrix and wants to customize the addition of them. This is impossible under the current model, is it not? Why? I haven't tried it yet (putting together an example is one of the TODOs before v1.0.0) but I fully expect it to work. The dispatch tables are created at compile time. Just call updateMethods after loading or unloading the DLL and it should work. It does in the C++ version.
Re: New library: open multi-methods
openmethods is now available in the dub registry: https://code.dlang.org/packages/openmethods
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 04:26:42 UTC, Ali Çehreli wrote: It would be nice to see some performance results as well like you have on your C++ articles. Lib is in the dub registry now. Do you have a working gdc compiler? If yes, could you run the benchmark and post the results? Please make sure to build in release mode.
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 13:35:40 UTC, jmh530 wrote:
On Wednesday, 19 July 2017 at 12:29:36 UTC, Jean-Louis Leroy
wrote:
...that does the two above. Problem is, it needs -Jpath on the
command line to work. Unless there is a workaround?
I prefer the original.
What if you do:
shared static this(){
mixin(registerMethods);
}
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 12:29:36 UTC, Jean-Louis Leroy wrote: ...that does the two above. Problem is, it needs -Jpath on the command line to work. Unless there is a workaround? I prefer the original.
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 13:36:55 UTC, jmh530 wrote:
On Wednesday, 19 July 2017 at 13:35:40 UTC, jmh530 wrote:
On Wednesday, 19 July 2017 at 12:29:36 UTC, Jean-Louis Leroy
wrote:
...that does the two above. Problem is, it needs -Jpath on
the command line to work. Unless there is a workaround?
I prefer the original.
What if you do:
shared static this(){
mixin(registerMethods);
}
You mean in openmethods.d?
Re: Release D 2.075.0
On 7/19/2017 8:36 AM, Martin Nowak wrote: Glad to announce D 2.075.0. This release comes with various phobos additions, a repackaged std.datetime, configurable Fiber stack guard pages (now also on Posix), and optional precise GC scanning for the DATA/TLS segment (static data) on Windows. http://dlang.org/download.html http://dlang.org/changelog/2.075.0.html Pretty dazz! Thank you!
Re: Release D 2.075.0
On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote: Glad to announce D 2.075.0. This release comes with various phobos additions, a repackaged std.datetime, configurable Fiber stack guard pages (now also on Posix), and optional precise GC scanning for the DATA/TLS segment (static data) on Windows. http://dlang.org/download.html http://dlang.org/changelog/2.075.0.html - -Martin Congratulations Martin and everyone! A snap package for DMD 2.075.0 is now available in the `edge` channel of the snap store: sudo snap install --classic --edge dmd for a fresh install, or sudo snap refresh --classic --edge dmd ... for anyone who already has an earlier version installed. Note that there's a known issue with `rdmd` in this package (which is an issue with `snapd` rather than the package itself). However, please do let me know about any other issues (or successes!).
Re: DIP 1010--Static foreach--Accepted
On 18.07.2017 00:44, Andrei Alexandrescu wrote: 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 https://github.com/dlang/DIPs/pull/87 https://github.com/dlang/dmd/pull/7009
Re: DMD library available as DUB package
On Tuesday, 18 July 2017 at 12:07:27 UTC, Jacob Carlborg wrote: During the dconf hackathon I set out to create a DUB package for DMD to be used as a library. This has finally been merged [1] and is available here [2]. It contains the lexer and the parser. Great news!! I think it was not ready yet.
