On Wednesday, January 09, 2013 19:22:43 Don Clugston wrote:
> Personally I don't think we should have any .di files in there,
> whatsoever. They just cause problems, for NO BENEFIT. We don't want
> have trade secrets we want to hide, and .di files serve no other
> purpose.
> (Please everyone, abandon any fanciful ideas that they speed
> compilation. Anybody who thinks it does, clearly hasn't done any
> profiling).

For most everything in druntime at this point, I believe that the .di files are simply copies of the .d files with a different extension, so there arguably isn't any real point to having them be .di files. But regardless, it's an improvement over stripping stuff like we were before, since using .di files really makes no sense for them. However, in the case of core.thread, it was my understanding that some sort of implementation hiding was _required_ for something (PIMPL?), but I don't know what. I haven't touched that code in ages and have no idea what work is being done on it.

- Jonathan M Davis
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 1/9/2013 10:22 AM, Don Clugston wrote:
> Personally I don't think we should have any .di files in there, whatsoever. They just cause problems, for NO BENEFIT. We don't want have trade secrets we want to hide, and .di files serve no other purpose.

One example: do we really want to recompile the garbage collector for every D program?
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Wednesday, January 09, 2013 21:08:50 Jonathan M Davis wrote:
> For most everything in druntime at this point, I believe that the .di files are simply copies of the .d files with a different extension

Actually, I just looked at druntime, and apparently, the files are just copied without their extensions being changed, so it's not mostly just .d files sitting in the import directoryy, and they're not even claiming to be .di files. That also makes it clear which files are stripped and which aren't.

- Jonathan M Davis
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Wednesday, January 09, 2013 14:21:40 Walter Bright wrote:
> On 1/9/2013 10:22 AM, Don Clugston wrote:
> > Personally I don't think we should have any .di files in there,
> > whatsoever.
> > They just cause problems, for NO BENEFIT. We don't want have trade secrets
> > we want to hide, and .di files serve no other purpose.
> 
> One example: do we really want to recompile the garbage collector for every D program?

But core.rt doesn't end up in the import directory, so that's a non-issue. There are no .di files for the GC, and it doesn't get recompiled all the time. The solution was to simply not provide the files which should be hidden.

- Jonathan M Davis
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 01/09/2013 07:10 PM, Andrei Alexandrescu wrote:
> Hopefully with the new header generator from Adam, the outlook may improve there.
>
> Andrei
>
Is it already merged?
There is a bigger issue though. Some runtime internal structures are
fields of the core.thread.Thread class and we explicitly support
deriving from Thread as part of the API. So we'd have to change those to
'void*'.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Jan 9, 2013, at 9:41 AM, Martin Nowak <code@dawg.eu> wrote:

> Am 03.01.2013 20:12, schrieb Andrei Alexandrescu:
>> See
>> 
>> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d
>> 
>> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.di
>> 
>> Why?
> To hide the implementation as thread module needs to have access to runtime internals.

It actually doesn't.  I was looking at the thread implementation yesterday and core.thread should absolutely not be importing rt.* or gc.*, and in fact the rt.* module it imports shouldn't exist at all.  I'm working on a fix, but still deliberating the best approach.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals