On Tue, 14 Jun 2011 17:47:32 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Finding weakness in a proposal is easy. The more difficult thing to do is to find ways to improve it or propose alternatives.

I think the only solid alternative is to stop trying to reinvent the wheel, and "start up our photocopiers" (copy CPAN/Gems/PECL).

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On 6/14/11 11:32 AM, Graham Fawcett wrote:
> On Tue, 14 Jun 2011 15:59:15 +0000, Adam D. Ruppe wrote:
>
>>> One other interesting aspect is that the string literal can be
>>> CTFE-constructed,
>>
>> Oh, or it could be in version {} blocks. I like that.
>>
>> I think we should actually whip up a working model. It needn't be a
>> compiler feature at this point - we can use pragma(msg, "BUILD: " ~
>> param) for now and have a helper program scan dmd's output.
>
> +1, sounds fun. :)
>
> Rather than pragma(msg), you could also use pragma(liburl), and run dmd
> with "-ignore -v". You can parse the pragma from there. (I think you'd
> need to write `pragma(liburl, "name-in-quotes", "url-in-quotes")`, a
> slight diversion from Andrei's syntax, but otherwise it would work.)
>
> Graham

I just realized that one advantage of the download being integrated in the compiler is that the compiler is the sole tool with full knowledge and control of what modules are imported. A tool could repeatedly run the compiler with -v and see what modules it couldn't load, to then download them. (Also, of course, a tool could rely on extralinguistic library management control that has its own advantages and disadvantages as we discussed.)

Andrei

On 6/14/11 11:34 AM, Vladimir Panteleev wrote:
> On Tue, 14 Jun 2011 17:47:32 +0300, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Finding weakness in a proposal is easy. The more difficult thing to do
>> is to find ways to improve it or propose alternatives.
>
> I think the only solid alternative is to stop trying to reinvent the
> wheel, and "start up our photocopiers" (copy CPAN/Gems/PECL).

Agreed. I've used CPAN in the past, and just read its basics again. I don't think the proposal is majorly diverging from it.

Andrei

Am 14.06.2011 18:35, schrieb Andrei Alexandrescu:
> On 6/14/11 11:32 AM, Graham Fawcett wrote:
>> On Tue, 14 Jun 2011 15:59:15 +0000, Adam D. Ruppe wrote:
>>
>>>> One other interesting aspect is that the string literal can be CTFE-constructed,
>>>
>>> Oh, or it could be in version {} blocks. I like that.
>>>
>>> I think we should actually whip up a working model. It needn't be a compiler feature at this point - we can use pragma(msg, "BUILD: " ~ param) for now and have a helper program scan dmd's output.
>>
>> +1, sounds fun. :)
>>
>> Rather than pragma(msg), you could also use pragma(liburl), and run dmd
>> with "-ignore -v". You can parse the pragma from there. (I think you'd
>> need to write `pragma(liburl, "name-in-quotes", "url-in-quotes")`, a
>> slight diversion from Andrei's syntax, but otherwise it would work.)
>>
>> Graham
> 
> I just realized that one advantage of the download being integrated in the compiler is that the compiler is the sole tool with full knowledge and control of what modules are imported. A tool could repeatedly run the compiler with -v and see what modules it couldn't load, to then download them. (Also, of course, a tool could rely on extralinguistic library management control that has its own advantages and disadvantages as we discussed.)
> 
> Andrei

Hmm I thought somebody (possibly Walter) mentioned adding something to the compiler that makes this more easy (probably outputting all imports or all imports that are not in Phobos or something like that). Unfortunately my memory is to vague to find the corresponding message or to even remember what exactly was done - maybe somebody else remembers it?

On 6/14/11 11:39 AM, Daniel Gibson wrote:
> Am 14.06.2011 18:35, schrieb Andrei Alexandrescu:
>> On 6/14/11 11:32 AM, Graham Fawcett wrote:
>>> On Tue, 14 Jun 2011 15:59:15 +0000, Adam D. Ruppe wrote:
>>>
>>>>> One other interesting aspect is that the string literal can be
>>>>> CTFE-constructed,
>>>>
>>>> Oh, or it could be in version {} blocks. I like that.
>>>>
>>>> I think we should actually whip up a working model. It needn't be a
>>>> compiler feature at this point - we can use pragma(msg, "BUILD: " ~
>>>> param) for now and have a helper program scan dmd's output.
>>>
>>> +1, sounds fun. :)
>>>
>>> Rather than pragma(msg), you could also use pragma(liburl), and run dmd
>>> with "-ignore -v". You can parse the pragma from there. (I think you'd
>>> need to write `pragma(liburl, "name-in-quotes", "url-in-quotes")`, a
>>> slight diversion from Andrei's syntax, but otherwise it would work.)
>>>
>>> Graham
>>
>> I just realized that one advantage of the download being integrated in
>> the compiler is that the compiler is the sole tool with full knowledge
>> and control of what modules are imported. A tool could repeatedly run
>> the compiler with -v and see what modules it couldn't load, to then
>> download them. (Also, of course, a tool could rely on extralinguistic
>> library management control that has its own advantages and disadvantages
>> as we discussed.)
>>
>> Andrei
>
> Hmm I thought somebody (possibly Walter) mentioned adding something to
> the compiler that makes this more easy (probably outputting all imports
> or all imports that are not in Phobos or something like that).
> Unfortunately my memory is to vague to find the corresponding message or
> to even remember what exactly was done - maybe somebody else remembers it?

That is actually possible only with multiple runs due to the transitivity issues. For example, module A tries to import module B and fails -> dmd outputs B. But then module B tries to import other modules, so a new run of dmd is needed etc.

This is not pernicious, but it definitely requires a nontrivial tool to handle all that.


Andrei

Andrei Alexandrescu wrote:
> A tool could repeatedly run
> the compiler with -v and see what modules it couldn't load, to
> then download them.

This is what my build.d does. <http://arsdnet.net/dcode/build.d>


There's a problem though: it's pretty slow. You always run the compiler at least twice with this setup with any libs - once to get the dependencies and build the compile line, once to actually compile.

If there's nested dependencies, it just gets worse.


Build into the compiler, and the speed ought to be improvable by several times.

On Tue, 14 Jun 2011 11:35:44 -0500, Andrei Alexandrescu wrote:

> On 6/14/11 11:32 AM, Graham Fawcett wrote:
>> On Tue, 14 Jun 2011 15:59:15 +0000, Adam D. Ruppe wrote:
>>
>>>> One other interesting aspect is that the string literal can be CTFE-constructed,
>>>
>>> Oh, or it could be in version {} blocks. I like that.
>>>
>>> I think we should actually whip up a working model. It needn't be a compiler feature at this point - we can use pragma(msg, "BUILD: " ~ param) for now and have a helper program scan dmd's output.
>>
>> +1, sounds fun. :)
>>
>> Rather than pragma(msg), you could also use pragma(liburl), and run dmd
>> with "-ignore -v". You can parse the pragma from there. (I think you'd
>> need to write `pragma(liburl, "name-in-quotes", "url-in-quotes")`, a
>> slight diversion from Andrei's syntax, but otherwise it would work.)
>>
>> Graham
> 
> I just realized that one advantage of the download being integrated in the compiler is that the compiler is the sole tool with full knowledge and control of what modules are imported. A tool could repeatedly run the compiler with -v and see what modules it couldn't load, to then download them. (Also, of course, a tool could rely on extralinguistic library management control that has its own advantages and disadvantages as we discussed.)

You could get pretty far with an external tool, as long as the pragmas were explicit in the source, and not generated by mixins at compile time. That's the point at which compiler support becomes more than nice-to-have.

Graham

On 6/14/11 11:51 AM, Adam D. Ruppe wrote:
> Andrei Alexandrescu wrote:
>> A tool could repeatedly run
>> the compiler with -v and see what modules it couldn't load, to
>> then download them.
>
> This is what my build.d does.<http://arsdnet.net/dcode/build.d>
>
>
> There's a problem though: it's pretty slow. You always run the
> compiler at least twice with this setup with any libs - once to
> get the dependencies and build the compile line, once to actually
> compile.
>
> If there's nested dependencies, it just gets worse.
>
>
> Build into the compiler, and the speed ought to be improvable by
> several times.

This is a very compelling data point. I added a mention of it to the proposal. See "Alternatives" at the end.

http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11

Andrei

Andrei:

> This is a very compelling data point. I added a mention of it to the proposal. See "Alternatives" at the end.
> 
> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11

Isn't this also an argument for the (ancient request of) inclusion of a normal build feature into the D compiler?

Bye,
bearophile

bearophile:
> Isn't this also an argument for the (ancient request of) inclusion of a normal build feature into the D compiler?

I think if the compiler is going to be downloading files, it is necessarily looking for those files... thus it'd become a bit of a smarter build tool as a side effect of this change.

It'd be silly if it said "this module is missing, and I'll download it, but I refuse to actually look at it once it's downloaded!"