digitalmars.D - Thoughts about std.experimental.all?
- Dukc (11/11) Feb 28 2019 For those who don't know, std.experintal.all is a module that,
- Arun Chandrasekaran (2/13) Feb 28 2019 I use it wherever I can, cus that's what it was designed for.
- Nick Sabalausky (Abscissa) (7/10) Feb 28 2019 Big fan of it. It's not something I'd use everywhere (there's something
- Bastiaan Veelo (10/12) Mar 01 2019 Without your description (or the docs) I would have assumed
- Seb (4/16) Mar 01 2019 It would just be `import std` ;-)
- Bastiaan Veelo (2/8) Mar 01 2019 +2 ten ;-)
For those who don't know, std.experintal.all is a module that, when imported, effectively imports almost all std modules. I have been using it for some time now, and personally I love it and wish it remains. Compile times have not been a major issue for me and faster than dub can import stuff anyway. I think the only reason to choose importing more than one or two std modules is when you're in an embedded enviroment that can't compile everthing std.experimental.all includes. But I'm interested, what are your opinions? Is std.experimental.all a success, or is it just my feeling?
Feb 28 2019
Arun Chandrasekaran <aruncxy gmail.com> On Thursday, 28 February 2019 at 10:58:39 UTC, Dukc wrote:For those who don't know, std.experintal.all is a module that, when imported, effectively imports almost all std modules. I have been using it for some time now, and personally I love it and wish it remains. Compile times have not been a major issue project, and faster than dub can import stuff anyway. I think the only reason to choose importing more than one or two std modules is when you're in an embedded enviroment that can't compile everthing std.experimental.all includes. But I'm interested, what are your opinions? Is std.experimental.all a success, or is it just my feeling?I use it wherever I can, cus that's what it was designed for.
Feb 28 2019
On 2/28/19 5:58 AM, Dukc wrote:But I'm interested, what are your opinions? Is std.experimental.all a success, or is it just my feeling?Big fan of it. It's not something I'd use everywhere (there's something to be said for not cluttering the namespace), but it's absolutely fantastic for scripts and other short programs. Heck, that's why even before std.experimental.all existed, I included a module that does pretty much the same thing into Scriptlike. (I think I got the idea from rdmd's eval feature.)
Feb 28 2019
On Thursday, 28 February 2019 at 10:58:39 UTC, Dukc wrote:For those who don't know, std.experintal.all is a module that, when imported, effectively imports almost all std modules.Without your description (or the docs) I would have assumed std.experimental.all only to import everything under std.experimental. Of all the things that have gone into std.experimental, I am unaware of anything ever coming out of it again. IMO, the concept of std.experimental is flawed without some sort of policy for how long a module can stay experimental. So if this is a poll for promotion of std.experimental.all to std.all, you have my +1.
Mar 01 2019
On Friday, 1 March 2019 at 18:15:01 UTC, Bastiaan Veelo wrote:On Thursday, 28 February 2019 at 10:58:39 UTC, Dukc wrote:It would just be `import std` ;-) That was my goal all along when I pushed for and created std.experimental.all.For those who don't know, std.experintal.all is a module that, when imported, effectively imports almost all std modules.Without your description (or the docs) I would have assumed std.experimental.all only to import everything under std.experimental. Of all the things that have gone into std.experimental, I am unaware of anything ever coming out of it again. IMO, the concept of std.experimental is flawed without some sort of policy for how long a module can stay experimental. So if this is a poll for promotion of std.experimental.all to std.all, you have my +1.
Mar 01 2019
On Friday, 1 March 2019 at 18:18:29 UTC, Seb wrote:On Friday, 1 March 2019 at 18:15:01 UTC, Bastiaan Veelo wrote:+2 ten ;-)So if this is a poll for promotion of std.experimental.all to std.all, you have my +1.It would just be `import std` ;-) That was my goal all along when I pushed for and created std.experimental.all.
Mar 01 2019
On Friday, 1 March 2019 at 18:35:26 UTC, Bastiaan Veelo wrote:On Friday, 1 March 2019 at 18:18:29 UTC, Seb wrote:FYI: Now you can show your support in this PR -> https://github.com/dlang/phobos/pull/6889On Friday, 1 March 2019 at 18:15:01 UTC, Bastiaan Veelo wrote:+2 ten ;-)So if this is a poll for promotion of std.experimental.all to std.all, you have my +1.It would just be `import std` ;-) That was my goal all along when I pushed for and created std.experimental.all.
Mar 03 2019
On Monday, 4 March 2019 at 05:43:21 UTC, Seb wrote:https://github.com/dlang/phobos/pull/6889Before we even asked :)
Mar 05 2019
On Monday, 4 March 2019 at 05:43:21 UTC, Seb wrote:On Friday, 1 March 2019 at 18:35:26 UTC, Bastiaan Veelo wrote:OK. Thanks a lot for your support! This is now in master and coming to your nearest DMD nightly and DMD 2.086: https://dlang.org/changelog/pending.html#std-allOn Friday, 1 March 2019 at 18:18:29 UTC, Seb wrote:FYI: Now you can show your support in this PR -> https://github.com/dlang/phobos/pull/6889On Friday, 1 March 2019 at 18:15:01 UTC, Bastiaan Veelo wrote:+2 ten ;-)So if this is a poll for promotion of std.experimental.all to std.all, you have my +1.It would just be `import std` ;-) That was my goal all along when I pushed for and created std.experimental.all.
Mar 21 2019
On Thursday, 21 March 2019 at 12:12:00 UTC, Seb wrote:[snip] OK. Thanks a lot for your support! This is now in master and coming to your nearest DMD nightly and DMD 2.086: https://dlang.org/changelog/pending.html#std-allNice. Where it says "The baseline cost for import std; is less than half a second (varying from system to system) and work is in progress to reduce this overhead even further." It would be interesting if there was a way to speed it up specifically for something like run.dlang.org as well.
Mar 21 2019
On Thursday, 21 March 2019 at 13:54:44 UTC, jmh530 wrote:On Thursday, 21 March 2019 at 12:12:00 UTC, Seb wrote:That's just a very negative estimate. On my machine it's less than 0.2s and the released DMD is still compiled with DMD - just imagine how fast it would be when we finally start shipping a DMD compiled with LDC.[snip] OK. Thanks a lot for your support! This is now in master and coming to your nearest DMD nightly and DMD 2.086: https://dlang.org/changelog/pending.html#std-allNice. Where it says "The baseline cost for import std; is less than half a second (varying from system to system) and work is in progress to reduce this overhead even further."It would be interesting if there was a way to speed it up specifically for something like run.dlang.org as well.- compile DMD with LDC - instantiate more modules lazily in Phobos At the moment the entire std.uni trie is loaded and parsed, because IIRC std.net.curl has a struct that somewhere uses a type which through multiple layer's of inference depends on an instantiated std.uni. Potential fixes: - make struct instantiation lazy (pretty hard as it touches a lot of DMD) - make std.uni's table lazy (building them at CTFE is still pretty expensive) Other ideas: - fully lazy imports (this can work for selective and static imports) - CTFE caching I presume that's what you were thinking about. In theory, there's no need for the compiler to re-instantiate all the Phobos if it already has done so. There was quite a bit of work by Dmitry on this one, but somehow it died: https://github.com/dlang/dmd/pull/7843 - do sth. like Vladimir's forking DMD compiler (i.e. serialize the compiler's state to disk) https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler tl;dr: for now the easiest and still low-hanging fruit is to improve the compilation time of Phobos further. Vladimir has written a great tool which helps with this: https://github.com/CyberShadow/dmdprof
Mar 22 2019