www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thoughts about std.experimental.all?

reply Dukc <ajieskola gmail.com> writes:
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 
-it still compiles faster than th
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
next sibling parent Arun Chandrasekaran <aruncxy gmail.com> writes:
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 
 for me -it still compiles faster than th
 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
prev sibling next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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
parent reply Seb <seb wilzba.ch> writes:
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:
 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.
It would just be `import std` ;-) That was my goal all along when I pushed for and created std.experimental.all.
Mar 01
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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:
 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.
+2 ten ;-)
Mar 01
parent reply Seb <seb wilzba.ch> writes:
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:
 On Friday, 1 March 2019 at 18:15:01 UTC, Bastiaan Veelo wrote:
 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.
+2 ten ;-)
FYI: Now you can show your support in this PR -> https://github.com/dlang/phobos/pull/6889
Mar 03
next sibling parent Dukc <ajieskola gmail.com> writes:
On Monday, 4 March 2019 at 05:43:21 UTC, Seb wrote:
 https://github.com/dlang/phobos/pull/6889
Before we even asked :)
Mar 05
prev sibling parent reply Seb <seb wilzba.ch> writes:
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:
 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:
 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.
+2 ten ;-)
FYI: Now you can show your support in this PR -> https://github.com/dlang/phobos/pull/6889
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-all
Mar 21
parent reply jmh530 <john.michael.hall gmail.com> writes:
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-all
Nice. 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
parent Seb <seb wilzba.ch> writes:
On Thursday, 21 March 2019 at 13:54:44 UTC, jmh530 wrote:
 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-all
Nice. 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."
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.
 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