On 8 June 2010 22:18, Walter Bright <walter at digitalmars.com> wrote:
>
>
> Andrei Alexandrescu wrote:
>>
>> Actually I've generated std.all myself and experimented with it
>> (attached). The parse time with rdmd is larger than with individual modules,
>> but not annoying.
>>
>>
>
> The parse time will invariably grow as phobos grows. I expect std.all will become the preferred method of using D. The problems are:
>
> 1. People will come to expect std.all to have everything and the kitchen sink in it, so we're stuck.
>
> 2. People will inevitably do compile speed benchmarks with std.all. And then we'll suck.
>
> So I say "no" to std.all.

I don't think anybody really wants 'all'. You want 'the commonly-used
stuff'. Which in Phobos right now would probably be about 15 modules,
but wouldn't get much bigger no matter how big Phobos gets.
When Sean started Ares (became Tango, became druntime) we used core.d
for that purpose (instead of all.d). Of course now a different name
would be required.

I second this.  std modules are already well organized for specific categories of code.  If we look at a language that uses wildcards for package inclusion such as Java, you do something like java.io.*, not java.*.

This would be more appropriate for something like Tango where modules are created for even small functions.  It was tried there, and nobody really used it, so it was removed.

-Steve



----- Original Message ----
> From: Walter Bright <walter at digitalmars.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Tue, June 8, 2010 4:18:00 PM
> Subject: Re: [phobos] std.all
> 
> 

Andrei Alexandrescu wrote:
> Actually I've generated std.all myself and experimented with it (attached). The parse time with rdmd is larger than with individual modules, but not annoying.
> 
> 

The
> parse time will invariably grow as phobos grows. I expect std.all will become the preferred method of using D. The problems are:

1. People will come to
> expect std.all to have everything and the kitchen sink in it, so we're stuck.

2. People will inevitably do compile speed benchmarks with
> std.all. And then we'll suck.

So I say "no" to
> std.all.
_______________________________________________
phobos mailing
> list

> href="mailto:phobos at puremagic.com">phobos at puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 06/08/2010 03:18 PM, Walter Bright wrote:
>
>
> Andrei Alexandrescu wrote:
>> Actually I've generated std.all myself and experimented with it (attached). The parse time with rdmd is larger than with individual modules, but not annoying.
>>
>>
>
> The parse time will invariably grow as phobos grows. I expect std.all will become the preferred method of using D. The problems are:
>
> 1. People will come to expect std.all to have everything and the kitchen sink in it, so we're stuck.
>
> 2. People will inevitably do compile speed benchmarks with std.all. And then we'll suck.
>
> So I say "no" to std.all.

I think there's no reason to become agitated. I measured compile time with three imports and with std.all. The compile time with three imports is 0.44s, and with std.all it's 0.82s. So we're talking about a very small margin: 380ms.

Even if Phobos doubles in size (!), we're looking at meager increases in compile time.

Also, let's not do the mistake of just taking one aspect of the problem into account. std.all does have huge advantages, and the fact that we can afford it will be noted and appreciated.



Andrei

On 08/06/10 21:18, Walter Bright wrote:
>
>
> Andrei Alexandrescu wrote:
>> Actually I've generated std.all myself and experimented with it (attached). The parse time with rdmd is larger than with individual modules, but not annoying.
>>
>>
>
> The parse time will invariably grow as phobos grows. I expect std.all will become the preferred method of using D. The problems are:
>
> 1. People will come to expect std.all to have everything and the kitchen sink in it, so we're stuck.
>
> 2. People will inevitably do compile speed benchmarks with std.all. And then we'll suck.
>
> So I say "no" to std.all.

Given that it's meant as an easy way to include the commonly used functions etc, rather than all, how about a std.common along side it? Where std.common imports commonly used code by scripts etc, and std.all imports anything that isn't std.common? This way it's the best of both worlds.

On 6/8/10, Andrei Alexandrescu <andrei at erdani.com> wrote:
> I think there's no reason to become agitated. I measured compile time with three imports and with std.all. The compile time with three imports is 0.44s, and with std.all it's 0.82s.

Curious, what were the three imports? Anecdotally, I find that D2 compiles just about as fast as D1 (that is, virtually instantly), until I import std.stdio. Then, it slows down quite a bit. Still kicks the socks off any other compiler out there, but comparatively slow.

No other module seems to have as much of an impact as stdio - if this is actually true, and not just me, the speed difference between std.all, std.common, or just std.stdio itself may all be fairly negligible, so separating them for speed purposes could be futile.

> std.all does have huge advantages, and the fact that we
> can afford it will be noted and appreciated.

It is quite nice with rdmd indeed.

I'm afraid having std.common would turn into Bikeshed War III unless it included so many things that it was practically a std.all module anyhow. For example, do regexes belong?  I personally tend to prefer plain old string processing for most things and use regexes only when there's a real need.  Others tend to prefer regexes as their "default hammer".  Does std.math belong?  I write lots of math-heavy code, so I'd say yes.  People who don't write math-heavy code would probably say no.  Does std.date go in?  I never use it, but people writing more business-y, less math-y code probably use it all the time.

On Tue, Jun 8, 2010 at 4:39 PM, Robert Clipsham
<robert at octarineparrot.com>wrote:

> On 08/06/10 21:18, Walter Bright wrote:
>
>>
>>
>> Andrei Alexandrescu wrote:
>>
>>> Actually I've generated std.all myself and experimented with it (attached). The parse time with rdmd is larger than with individual modules, but not annoying.
>>>
>>>
>>>
>> The parse time will invariably grow as phobos grows. I expect std.all will become the preferred method of using D. The problems are:
>>
>> 1. People will come to expect std.all to have everything and the kitchen sink in it, so we're stuck.
>>
>> 2. People will inevitably do compile speed benchmarks with std.all. And then we'll suck.
>>
>> So I say "no" to std.all.
>>
>
> Given that it's meant as an easy way to include the commonly used functions etc, rather than all, how about a std.common along side it? Where std.common imports commonly used code by scripts etc, and std.all imports anything that isn't std.common? This way it's the best of both worlds.
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100608/06e893ca/attachment.html>

One further aspect, which is more of a compiler limitation, but should also be taken into account, including modules without using anything from them increases executable size.  For example, compiling with the sample std.all on the newsgroup and the simple hello world program produces an executable twice the size of the same program that just imports std.stdio.

Another issue with this, I think any static constructors that are thread local will be run when you create new threads, even if you never use the module!

-Steve




----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Tue, June 8, 2010 4:34:24 PM
> Subject: Re: [phobos] std.all
> 
> On 06/08/2010 03:18 PM, Walter Bright wrote:
>
>
> Andrei Alexandrescu wrote:
>> Actually I've generated std.all myself and
> experimented with it
>> (attached). The parse time with rdmd is larger
> than with individual
>> modules, but not
> annoying.
>>
>>
>
> The parse time will invariably
> grow as phobos grows. I expect std.all
> will become the preferred method
> of using D. The problems are:
>
> 1. People will come to expect
> std.all to have everything and the kitchen
> sink in it, so we're
> stuck.
>
> 2. People will inevitably do compile speed benchmarks
> with std.all. And
> then we'll suck.
>
> So I say "no" to std.all.

I think there's no reason to become agitated. I measured compile
> time
with three imports and with std.all. The compile time with three
> imports
is 0.44s, and with std.all it's 0.82s. So we're talking about a very
> 
small margin: 380ms.

Even if Phobos doubles in size (!), we're
> looking at meager increases in
compile time.

Also, let's not do the
> mistake of just taking one aspect of the problem
into account. std.all does
> have huge advantages, and the fact that we
can afford it will be noted and
> appreciated.



Andrei
_______________________________________________
phobos
> mailing list

> href="mailto:phobos at puremagic.com">phobos at puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 06/08/2010 03:42 PM, Adam Ruppe wrote:
> On 6/8/10, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>> I think there's no reason to become agitated. I measured compile time with three imports and with std.all. The compile time with three imports is 0.44s, and with std.all it's 0.82s.
>
> Curious, what were the three imports? Anecdotally, I find that D2 compiles just about as fast as D1 (that is, virtually instantly), until I import std.stdio. Then, it slows down quite a bit. Still kicks the socks off any other compiler out there, but comparatively slow.

import std.algorithm, std.conv, std.stdio;

> No other module seems to have as much of an impact as stdio - if this is actually true, and not just me, the speed difference between std.all, std.common, or just std.stdio itself may all be fairly negligible, so separating them for speed purposes could be futile.
>
>> std.all does have huge advantages, and the fact that we
>> can afford it will be noted and appreciated.
>
> It is quite nice with rdmd indeed.

To me, given D's approach to modularization, import statements are a necessary evil. I'm all for std.all.

Andrei

Yah, the problem with "commonly used" is that everybody's commonly used subset is different.

std.all for the win!


Andrei

On 06/08/2010 03:50 PM, David Simcha wrote:
> I'm afraid having std.common would turn into Bikeshed War III unless it included so many things that it was practically a std.all module anyhow.  For example, do regexes belong?  I personally tend to prefer plain old string processing for most things and use regexes only when there's a real need.  Others tend to prefer regexes as their "default hammer".  Does std.math belong?  I write lots of math-heavy code, so I'd say yes.  People who don't write math-heavy code would probably say no. Does std.date go in?  I never use it, but people writing more business-y, less math-y code probably use it all the time.
>
> On Tue, Jun 8, 2010 at 4:39 PM, Robert Clipsham
> <robert at octarineparrot.com <mailto:robert at octarineparrot.com>> wrote:
>
>     On 08/06/10 21:18, Walter Bright wrote:
>
>
>
>         Andrei Alexandrescu wrote:
>
>             Actually I've generated std.all myself and experimented with it
>             (attached). The parse time with rdmd is larger than with
>             individual
>             modules, but not annoying.
>
>
>
>         The parse time will invariably grow as phobos grows. I expect
>         std.all
>         will become the preferred method of using D. The problems are:
>
>         1. People will come to expect std.all to have everything and the
>         kitchen
>         sink in it, so we're stuck.
>
>         2. People will inevitably do compile speed benchmarks with
>         std.all. And
>         then we'll suck.
>
>         So I say "no" to std.all.
>
>
>     Given that it's meant as an easy way to include the commonly used
>     functions etc, rather than all, how about a std.common along side
>     it? Where std.common imports commonly used code by scripts etc, and
>     std.all imports anything that isn't std.common? This way it's the
>     best of both worlds.
>
>
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On 06/08/2010 03:50 PM, Steve Schveighoffer wrote:
> One further aspect, which is more of a compiler limitation, but should also be taken into account, including modules without using anything from them increases executable size.  For example, compiling with the sample std.all on the newsgroup and the simple hello world program produces an executable twice the size of the same program that just imports std.stdio.
>
> Another issue with this, I think any static constructors that are thread local will be run when you create new threads, even if you never use the module!
>
> -Steve

Oops. Now that sucks!


Andrei