http://www.reddit.com/r/programming/comments/telhj/voldemort_types_in_d/

Andrei

Le 09/05/2012 16:30, Andrei Alexandrescu a écrit :
> http://www.reddit.com/r/programming/comments/telhj/voldemort_types_in_d/
>
> Andrei

I read it.

writeln(take(generator(5), 10)); => writeln(generator(5).take(10));

UFCS FTW !

Great reading BTW, and I love how ti is named.

On Wednesday, 9 May 2012 at 14:30:33 UTC, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/telhj/voldemort_types_in_d/
>
> Andrei

One drawback of Voldemort types, is that they are incompatible with the generation of .di files (option -H).

See http://d.puremagic.com/issues/show_bug.cgi?id=5461.

Nicolas

On May 9, 2012, at 8:43 AM, deadalnix wrote:
> 
> Great reading BTW, and I love how ti is named.

I'd prefer Lovecraftian types :-)  Good article though.

On Wed, 09 May 2012 08:58:56 -0700, Nicolas Sicard <dransic@gmail.com> wrote:

> On Wednesday, 9 May 2012 at 14:30:33 UTC, Andrei Alexandrescu wrote:
>> http://www.reddit.com/r/programming/comments/telhj/voldemort_types_in_d/
>>
>> Andrei
>
> One drawback of Voldemort types, is that they are incompatible with the generation of .di files (option -H).
>
> See http://d.puremagic.com/issues/show_bug.cgi?id=5461.
>
> Nicolas

This pull fixes this problem and a bunch of others: https://github.com/D-Programming-Language/dmd/pull/928. However, it currently fails to build on Linux and fails the unittests on Windows thanks to a problem with the dur template function in std.datetime. The solution used by this pull is to include the function body of the auto-function as that was needed to allow Phobos to build correctly using the DRT DI files. This is the only workable solution as DMD does not know the type of an auto-function when DI files are generated. No semantic analysis has been performed and since semantic analysis could change the layout of a module you wouldn't want it to be
performed.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Wednesday, May 09, 2012 10:05:36 Adam Wilson wrote:
> On Wed, 09 May 2012 08:58:56 -0700, Nicolas Sicard <dransic@gmail.com>
> 
> wrote:
> > On Wednesday, 9 May 2012 at 14:30:33 UTC, Andrei Alexandrescu wrote:
> >> http://www.reddit.com/r/programming/comments/telhj/voldemort_types_in_d/
> >> 
> >> Andrei
> > 
> > One drawback of Voldemort types, is that they are incompatible with the generation of .di files (option -H).
> > 
> > See http://d.puremagic.com/issues/show_bug.cgi?id=5461.
> > 
> > Nicolas
> 
> This pull fixes this problem and a bunch of others:
> https://github.com/D-Programming-Language/dmd/pull/928. However, it
> currently fails to build on Linux and fails the unittests on Windows
> thanks to a problem with the dur template function in std.datetime. The
> solution used by this pull is to include the function body of the
> auto-function as that was needed to allow Phobos to build correctly using
> the DRT DI files. This is the only workable solution as DMD does not know
> the type of an auto-function when DI files are generated. No semantic
> analysis has been performed and since semantic analysis could change the
> layout of a module you wouldn't want it to be
> performed.

Actually, dur is in core.time (which is publicly imported by std.datetime), but regardless, what's wrong with it? It's incredibly straightforward.

- Jonathan M Davis

On May 9, 2012, at 7:30 AM, Andrei Alexandrescu wrote:

> http://www.reddit.com/r/programming/comments/telhj/voldemort_types_in_d/


One thing:


"and then use g. I know what you're thinking — use typeof and declare another instance of RandomNumberGenerator:

  auto g = generator(4);
  typeof(g) h;

Sorry, that won't work, the compiler will not allow a Voldemort Type to be instantiated outside of its scope (the technical reason is it has no reference to the seed local variable)."


If the struct were made static and given a ctor that seed were passed to, I imagine it would work, yes?

On Wed, 09 May 2012 10:19:08 -0700, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday, May 09, 2012 10:05:36 Adam Wilson wrote:
>> On Wed, 09 May 2012 08:58:56 -0700, Nicolas Sicard <dransic@gmail.com>
>>
>> wrote:
>> > On Wednesday, 9 May 2012 at 14:30:33 UTC, Andrei Alexandrescu wrote:
>> >>  
>> http://www.reddit.com/r/programming/comments/telhj/voldemort_types_in_d/
>> >>
>> >> Andrei
>> >
>> > One drawback of Voldemort types, is that they are incompatible with  
>> the
>> > generation of .di files (option -H).
>> >
>> > See http://d.puremagic.com/issues/show_bug.cgi?id=5461.
>> >
>> > Nicolas
>>
>> This pull fixes this problem and a bunch of others:
>> https://github.com/D-Programming-Language/dmd/pull/928. However, it
>> currently fails to build on Linux and fails the unittests on Windows
>> thanks to a problem with the dur template function in std.datetime. The
>> solution used by this pull is to include the function body of the
>> auto-function as that was needed to allow Phobos to build correctly using
>> the DRT DI files. This is the only workable solution as DMD does not know
>> the type of an auto-function when DI files are generated. No semantic
>> analysis has been performed and since semantic analysis could change the
>> layout of a module you wouldn't want it to be
>> performed.
>
> Actually, dur is in core.time (which is publicly imported by std.datetime),
> but regardless, what's wrong with it? It's incredibly straightforward.
>
> - Jonathan M Davis

All of this is a result of using the above mentioned 928 pull.

This from core.time.d:
Duration dur(string units)(long length) @safe pure nothrow
    if(units == "weeks" ||
       units == "days" ||
       units == "hours" ||
       units == "minutes" ||
       units == "seconds" ||
       units == "msecs" ||
       units == "usecs" ||
       units == "hnsecs" ||
       units == "nsecs")
{
    return Duration(convert!(units, "hnsecs")(length));
}

Gets translated to this in core.time.di:
template dur(string units) if (units == "weeks" || units == "days" || units == "hours" || units == "minutes" || units == "seconds" || units == "msecs" || units == "usecs" || units == "hnsecs" || units == "nsecs")
{
    pure nothrow @safe Duration dur(long length)
    {
        return Duration(convert!(units,"hnsecs")(length));
    }
}

Which results in this error from DMD (HEAD):
../druntime/import/core/time.di(218): Error: this cannot be interpreted at compile time, because it has no available source code
std/net/curl.d(187):        called from here: dur(2L)
make[1]: *** [generated/linux/release/32/libphobos2.a] Error 1
make: *** [release] Error 2

But DMD, there *IS* source code to read! Even if it is just a function call...

Note the above D->DI translation is the same without the patch, I checked on a vanilla DMD 2.059 install. Also, I don't know near enough about core.time to begin to guess what D is whining about here... It all looks good to me.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Wednesday, May 09, 2012 10:41:31 Adam Wilson wrote:
> On Wed, 09 May 2012 10:19:08 -0700, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > On Wednesday, May 09, 2012 10:05:36 Adam Wilson wrote:
> >> On Wed, 09 May 2012 08:58:56 -0700, Nicolas Sicard <dransic@gmail.com>
> >> 
> >> wrote:
> >> > On Wednesday, 9 May 2012 at 14:30:33 UTC, Andrei Alexandrescu wrote:
> >> http://www.reddit.com/r/programming/comments/telhj/voldemort_types_in_d/
> >> 
> >> >> Andrei
> >> > 
> >> > One drawback of Voldemort types, is that they are incompatible with
> >> 
> >> the
> >> 
> >> > generation of .di files (option -H).
> >> > 
> >> > See http://d.puremagic.com/issues/show_bug.cgi?id=5461.
> >> > 
> >> > Nicolas
> >> 
> >> This pull fixes this problem and a bunch of others:
> >> https://github.com/D-Programming-Language/dmd/pull/928. However, it
> >> currently fails to build on Linux and fails the unittests on Windows
> >> thanks to a problem with the dur template function in std.datetime. The
> >> solution used by this pull is to include the function body of the
> >> auto-function as that was needed to allow Phobos to build correctly
> >> using
> >> the DRT DI files. This is the only workable solution as DMD does not
> >> know
> >> the type of an auto-function when DI files are generated. No semantic
> >> analysis has been performed and since semantic analysis could change the
> >> layout of a module you wouldn't want it to be
> >> performed.
> > 
> > Actually, dur is in core.time (which is publicly imported by
> > std.datetime),
> > but regardless, what's wrong with it? It's incredibly straightforward.
> > 
> > - Jonathan M Davis
> 
> All of this is a result of using the above mentioned 928 pull.
> 
> This from core.time.d:
> Duration dur(string units)(long length) @safe pure nothrow
> if(units == "weeks" ||
> units == "days" ||
> units == "hours" ||
> units == "minutes" ||
> units == "seconds" ||
> units == "msecs" ||
> units == "usecs" ||
> units == "hnsecs" ||
> units == "nsecs")
> {
> return Duration(convert!(units, "hnsecs")(length));
> }
> 
> Gets translated to this in core.time.di:
> template dur(string units) if (units == "weeks" || units == "days" ||
> units == "hours" || units == "minutes" || units == "seconds" || units ==
> "msecs" || units == "usecs" || units == "hnsecs" || units == "nsecs")
> {
> pure nothrow @safe Duration dur(long length)
> {
> return Duration(convert!(units,"hnsecs")(length));
> }
> }
> 
> Which results in this error from DMD (HEAD):
> ../druntime/import/core/time.di(218): Error: this cannot be interpreted at
> compile time, because it has no available source code
> std/net/curl.d(187): called from here: dur(2L)
> make[1]: *** [generated/linux/release/32/libphobos2.a] Error 1
> make: *** [release] Error 2
> 
> But DMD, there *IS* source code to read! Even if it is just a function call...
> 
> Note the above D->DI translation is the same without the patch, I checked on a vanilla DMD 2.059 install. Also, I don't know near enough about core.time to begin to guess what D is whining about here... It all looks good to me.

Line 187 of std.net.curl is an enum:

private enum _defaultDataTimeout = dur!"minutes"(2);

So, dur!"minutes(2) will be evaluated at compile time. That means that the _full_ source of everything that's needed for dur!"minutes"(2) must be available. At minimum, that's going to be Duration's source code (including the full source for its constructor) and the source of convert.

Duration's constructor is quite straightforward, so as long as its full body is included, you should be fine. convert requires the source of hnsecsPer in addition to its own source, but hnsecsPer doesn't rely on anything else and both of those are templates, so their full source should be in the .di file anyway.

So, I would think that as long as the basic declaration for Duration is available along with the full source for Duration's constructor, std.time.convert, and std.time.hnsecsPer is available, then CTFE should be able to evaluate dur!"minutes"(2), and std.curl.net should be fine. So, if any of that source is being stripped out, then there's your problem. If it's all there, then I don't know what's wrong. Maybe there's another function in Duration that got stripped when it was needed (though I don't know what else in Duration besides the constructor would be required for dur!"minutes"(2) to be evaluated).

Personally, I think that the fact that CTFE requires the full source to work is a prime example of why .di files tend to be a very bad idea, but you can still strip at least some of it for at least stuff that wouldn't be used in CTFE.

- Jonathan M Davis

On Wed, 09 May 2012 11:00:01 -0700, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday, May 09, 2012 10:41:31 Adam Wilson wrote:
>> On Wed, 09 May 2012 10:19:08 -0700, Jonathan M Davis <jmdavisProg@gmx.com>
>>
>> wrote:
>> > On Wednesday, May 09, 2012 10:05:36 Adam Wilson wrote:
>> >> On Wed, 09 May 2012 08:58:56 -0700, Nicolas Sicard  
>> <dransic@gmail.com>
>> >>
>> >> wrote:
>> >> > On Wednesday, 9 May 2012 at 14:30:33 UTC, Andrei Alexandrescu  
>> wrote:
>> >>  
>> http://www.reddit.com/r/programming/comments/telhj/voldemort_types_in_d/
>> >>
>> >> >> Andrei
>> >> >
>> >> > One drawback of Voldemort types, is that they are incompatible with
>> >>
>> >> the
>> >>
>> >> > generation of .di files (option -H).
>> >> >
>> >> > See http://d.puremagic.com/issues/show_bug.cgi?id=5461.
>> >> >
>> >> > Nicolas
>> >>
>> >> This pull fixes this problem and a bunch of others:
>> >> https://github.com/D-Programming-Language/dmd/pull/928. However, it
>> >> currently fails to build on Linux and fails the unittests on Windows
>> >> thanks to a problem with the dur template function in std.datetime.  
>> The
>> >> solution used by this pull is to include the function body of the
>> >> auto-function as that was needed to allow Phobos to build correctly
>> >> using
>> >> the DRT DI files. This is the only workable solution as DMD does not
>> >> know
>> >> the type of an auto-function when DI files are generated. No semantic
>> >> analysis has been performed and since semantic analysis could change  
>> the
>> >> layout of a module you wouldn't want it to be
>> >> performed.
>> >
>> > Actually, dur is in core.time (which is publicly imported by
>> > std.datetime),
>> > but regardless, what's wrong with it? It's incredibly straightforward.
>> >
>> > - Jonathan M Davis
>>
>> All of this is a result of using the above mentioned 928 pull.
>>
>> This from core.time.d:
>> Duration dur(string units)(long length) @safe pure nothrow
>> if(units == "weeks" ||
>> units == "days" ||
>> units == "hours" ||
>> units == "minutes" ||
>> units == "seconds" ||
>> units == "msecs" ||
>> units == "usecs" ||
>> units == "hnsecs" ||
>> units == "nsecs")
>> {
>> return Duration(convert!(units, "hnsecs")(length));
>> }
>>
>> Gets translated to this in core.time.di:
>> template dur(string units) if (units == "weeks" || units == "days" ||
>> units == "hours" || units == "minutes" || units == "seconds" || units ==
>> "msecs" || units == "usecs" || units == "hnsecs" || units == "nsecs")
>> {
>> pure nothrow @safe Duration dur(long length)
>> {
>> return Duration(convert!(units,"hnsecs")(length));
>> }
>> }
>>
>> Which results in this error from DMD (HEAD):
>> ../druntime/import/core/time.di(218): Error: this cannot be interpreted at
>> compile time, because it has no available source code
>> std/net/curl.d(187): called from here: dur(2L)
>> make[1]: *** [generated/linux/release/32/libphobos2.a] Error 1
>> make: *** [release] Error 2
>>
>> But DMD, there *IS* source code to read! Even if it is just a function
>> call...
>>
>> Note the above D->DI translation is the same without the patch, I checked
>> on a vanilla DMD 2.059 install. Also, I don't know near enough about
>> core.time to begin to guess what D is whining about here... It all looks
>> good to me.
>
> Line 187 of std.net.curl is an enum:
>
> private enum _defaultDataTimeout = dur!"minutes"(2);
>
> So, dur!"minutes(2) will be evaluated at compile time. That means that the
> _full_ source of everything that's needed for dur!"minutes"(2) must be
> available. At minimum, that's going to be Duration's source code (including
> the full source for its constructor) and the source of convert.
>
> Duration's constructor is quite straightforward, so as long as its full body
> is included, you should be fine. convert requires the source of hnsecsPer in
> addition to its own source, but hnsecsPer doesn't rely on anything else and
> both of those are templates, so their full source should be in the .di file
> anyway.
>
> So, I would think that as long as the basic declaration for Duration is
> available along with the full source for Duration's constructor,
> std.time.convert, and std.time.hnsecsPer is available, then CTFE should be
> able to evaluate dur!"minutes"(2), and std.curl.net should be fine. So, if any
> of that source is being stripped out, then there's your problem. If it's all
> there, then I don't know what's wrong. Maybe there's another function in
> Duration that got stripped when it was needed (though I don't know what else
> in Duration besides the constructor would be required for dur!"minutes"(2) to
> be evaluated).
>
> Personally, I think that the fact that CTFE requires the full source to work
> is a prime example of why .di files tend to be a very bad idea, but you can
> still strip at least some of it for at least stuff that wouldn't be used in
> CTFE.
>
> - Jonathan M Davis

Nuts. It's CTFE. Because the implementation source is being stripped out, that was *THE* main request of DI files and they are pointless without that.

Essentially DI files and CTFE are mutually exclusive.

I would say that Phobos' usage of CTFE breaks the cardinal rule of external code, never assume that it will always be available and won't change.

I'll be posting a larger message on the main forums about this ... It's a big issue.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/