Does anyone have any objections to adding a std.all to Phobos, which would just publicly import all of Phobos?  This would make it much easier to write small script-style programs in D, since so much functionality that's built into languages like Python and Perl is scattered across several Phobos modules in D.  The library functions work as well as builtins after they're imported, but having to add 10 import statements to a simple 50-line program to get this functionality gets a little tedious at times.

If we add std.all, is there any easy way to automatically keep it in sync as new modules are added to Phobos, or would this have to be done manually?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100608/e906e18e/attachment-0001.html>

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.

Recently there seems to be a problem with BigInt. Trying to add std.all to the Phobos build yields the bizarre error:

std/all.d(7): Error: module bigint from file std/bigint.d conflicts with another module bigint from file std/bigint.d

Looks like a compiler bug.

Yes, generation of std.all can and must be automated. It's very easy to do so inside the makefile, which has a list of all modules. However, there's a problem with the Windows makefile which is underpowered.


Andrei

On 06/08/2010 12:02 PM, David Simcha wrote:
> Does anyone have any objections to adding a std.all to Phobos, which would just publicly import all of Phobos?  This would make it much easier to write small script-style programs in D, since so much functionality that's built into languages like Python and Perl is scattered across several Phobos modules in D.  The library functions work as well as builtins after they're imported, but having to add 10 import statements to a simple 50-line program to get this functionality gets a little tedious at times.
>
> If we add std.all, is there any easy way to automatically keep it in sync as new modules are added to Phobos, or would this have to be done manually?
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: all.d
Type: text/x-dsrc
Size: 1599 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100608/6e9a8306/attachment.d>

(don't forget to add the phobos list when replying)

On 06/08/2010 01:10 PM, David Simcha wrote:
> Ok, well I remember this discussion about 6 months ago on digitalmars.D, and I guess this answers my other implicit question, which was "Why hasn't this been done already?".  I had thought that it was just an oversight that got lost in bigger and better things.

We definitely should do it. I was unable to build Phobos with std.all, but I pasted all of its contents into a file with an empty main. Building and running the whole banana only took 0.68 seconds.

We're enjoying a tremendous compilation speed advantage, which affords us to do things that other languages can't hope to emulate reasonably. Let's use that advantage.

I just checked in linux.mak with code that generates std/all.d. For now, the code comments out std.bigint to make everything work. It does work rather beautifully.

Walter, could you look into the std.bigint issue? All you have to do is build on Linux, uncomment the import of std.bigint, and see why the error occurs.


Thanks,

Andrei

> Walter, could you look into the std.bigint issue? All you have to do is build on Linux, uncomment the import of std.bigint, and see why the error occurs.

I bet it's because std.bigint refers to std.internal.math.XXX, and all the others only import from the root directory.

On 06/08/2010 01:37 PM, Don Clugston wrote:
>> Walter, could you look into the std.bigint issue? All you have to do is build on Linux, uncomment the import of std.bigint, and see why the error occurs.
>
> I bet it's because std.bigint refers to std.internal.math.XXX, and all the others only import from the root directory.

Yah, I saw that. How can we overcome that issue?

Andrei

On 6/8/10, Andrei Alexandrescu <andrei at erdani.com> wrote:
> Recently there seems to be a problem with BigInt. Trying to add std.all to the Phobos build yields the bizarre error:
>
> std/all.d(7): Error: module bigint from file std/bigint.d conflicts with another module bigint from file std/bigint.d

I saw this error message on my code yesterday. Try changing the line:

module bigint;

To

module std.bigint;

Done.

On 8 June 2010 20:48, Adam Ruppe <destructionator at gmail.com> wrote:
> On 6/8/10, Andrei Alexandrescu <andrei at erdani.com> wrote:
>> Recently there seems to be a problem with BigInt. Trying to add std.all to the Phobos build yields the bizarre error:
>>
>> std/all.d(7): Error: module bigint from file std/bigint.d conflicts with another module bigint from file std/bigint.d
>
> I saw this error message on my code yesterday. Try changing the line:
>
> module bigint;
>
> To
>
> module std.bigint;
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

Perfect, committed the change.

Andrei

On 06/08/2010 01:48 PM, Adam Ruppe wrote:
> On 6/8/10, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>> Recently there seems to be a problem with BigInt. Trying to add std.all to the Phobos build yields the bizarre error:
>>
>> std/all.d(7): Error: module bigint from file std/bigint.d conflicts with another module bigint from file std/bigint.d
>
> I saw this error message on my code yesterday. Try changing the line:
>
> module bigint;
>
> To
>
> module std.bigint;
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Looking good. I've fixed phobos.mak as well. std.all is working smoothly now.

If we decide to keep it, we need to decide how to generate it on windows. I'd be very happy with an overhaul of win32.mak. It doesn't scale.


Andrei

On 06/08/2010 02:26 PM, Don Clugston wrote:
> Done.
>
> On 8 June 2010 20:48, Adam Ruppe<destructionator at gmail.com>  wrote:
>> On 6/8/10, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>>> Recently there seems to be a problem with BigInt. Trying to add std.all to the Phobos build yields the bizarre error:
>>>
>>> std/all.d(7): Error: module bigint from file std/bigint.d conflicts with another module bigint from file std/bigint.d
>>
>> I saw this error message on my code yesterday. Try changing the line:
>>
>> module bigint;
>>
>> To
>>
>> module std.bigint;
>> _______________________________________________
>> phobos mailing list
>> 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

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.