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?


Thanks,

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

On Thursday, January 03, 2013 14:12:34 Andrei Alexandrescu wrote:
> See
> 
> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thre ad.d
> 
> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thre ad.di
> 
> Why?

Wouldn't this question belong in the Runtime list?

In any case, it's my understanding that thread.d/di is being treated the same as object_.d / object.di in that the .di files is being maintained manually.

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

+bcc dmd-internals
+d-runtime
+Sean Kelly

Any definite response on this? What is special about thread.d/di? It's the only file in that directory that has a separate header.


Thanks,

Andrei

On 1/3/13 2:40 PM, Jonathan M Davis wrote:
> On Thursday, January 03, 2013 14:12:34 Andrei Alexandrescu wrote:
>> See
>>
>> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thre
>> ad.d
>>
>> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thre
>> ad.di
>>
>> Why?
>
> Wouldn't this question belong in the Runtime list?
>
> In any case, it's my understanding that thread.d/di is being treated the same
> as object_.d / object.di in that the .di files is being maintained manually.
>
> - Jonathan M Davis
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

I think this had something to do with working towards shared library support.  thread.di used to be automatically generated.  See:

https://github.com/D-Programming-Language/druntime/pull/132

On Jan 3, 2013, at 12:12 PM, Andrei Alexandrescu <andrei@erdani.com> wrote:

> +bcc dmd-internals
> +d-runtime
> +Sean Kelly
> 
> Any definite response on this? What is special about thread.d/di? It's the only file in that directory that has a separate header.
> 
> 
> Thanks,
> 
> Andrei
> 
> On 1/3/13 2:40 PM, Jonathan M Davis wrote:
>> On Thursday, January 03, 2013 14:12:34 Andrei Alexandrescu wrote:
>>> See
>>> 
>>> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thre ad.d
>>> 
>>> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thre ad.di
>>> 
>>> Why?
>> 
>> Wouldn't this question belong in the Runtime list?
>> 
>> In any case, it's my understanding that thread.d/di is being treated the same as object_.d / object.di in that the .di files is being maintained manually.
>> 
>> - Jonathan M Davis
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals

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

Sigh, that kind of duplication is a bummer. Any bright ideas on how to avoid it? Can we try again using the automatic di generator?

Andrei

On 1/3/13 3:24 PM, Sean Kelly wrote:
> I think this had something to do with working towards shared library support.  thread.di used to be automatically generated.  See:
>
> https://github.com/D-Programming-Language/druntime/pull/132
>
> On Jan 3, 2013, at 12:12 PM, Andrei Alexandrescu<andrei@erdani.com>  wrote:
>
>> +bcc dmd-internals
>> +d-runtime
>> +Sean Kelly
>>
>> Any definite response on this? What is special about thread.d/di? It's the only file in that directory that has a separate header.
>>
>>
>> Thanks,
>>
>> Andrei
>>
>> On 1/3/13 2:40 PM, Jonathan M Davis wrote:
>>> On Thursday, January 03, 2013 14:12:34 Andrei Alexandrescu wrote:
>>>> See
>>>>
>>>> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thre
>>>> ad.d
>>>>
>>>> https://github.com/D-Programming-Language/druntime/blob/master/src/core/thre
>>>> ad.di
>>>>
>>>> Why?
>>>
>>> Wouldn't this question belong in the Runtime list?
>>>
>>> In any case, it's my understanding that thread.d/di is being treated the same
>>> as object_.d / object.di in that the .di files is being maintained manually.
>>>
>>> - Jonathan M Davis
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals@puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Thursday, January 03, 2013 16:23:42 Andrei Alexandrescu wrote:
> Sigh, that kind of duplication is a bummer. Any bright ideas on how to avoid it? Can we try again using the automatic di generator?

Unless something major has changed, the automatic di generator is pretty pointless. It strips almost nothing. There was a pull request which changed that, but I don't remember what happened with that. I don't remember it being merged (though it might have been). However, in preparation for that, I believe that the makefile was changed to just copy and rename the files instead of using the generator (since we really don't want all of those files stripped normally since it kills CTFE). Either way, we don't want thread.di being treated like all of the other .di files in druntime.

I remember getting the impression that thread.di required better control over what was and wasn't in there than the generator was likely to provide even with stripping stuff, but I'd have to go dig through archives for discussions on that. So, if the generator was updated to actually strip most stuff, then it might work, or it might not.

Martin is likely to know more, since he's the one who made the change in the first place.

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

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.
If you can come up with a better proposal to achieve this please do.

https://github.com/D-Programming-Language/druntime/pull/118 https://github.com/D-Programming-Language/druntime/pull/132

Hopefully with the new header generator from Adam, the outlook may improve there.

Andrei

On 1/9/13 9:41 AM, Martin Nowak 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.
> If you can come up with a better proposal to achieve this please do.
>
> https://github.com/D-Programming-Language/druntime/pull/118
> https://github.com/D-Programming-Language/druntime/pull/132
>
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 3 January 2013 22:57, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Thursday, January 03, 2013 16:23:42 Andrei Alexandrescu wrote:
>> Sigh, that kind of duplication is a bummer. Any bright ideas on how to avoid it? Can we try again using the automatic di generator?
>
> Unless something major has changed, the automatic di generator is pretty pointless. It strips almost nothing. There was a pull request which changed that, but I don't remember what happened with that. I don't remember it being merged (though it might have been). However, in preparation for that, I believe that the makefile was changed to just copy and rename the files instead of using the generator (since we really don't want all of those files stripped normally since it kills CTFE). Either way, we don't want thread.di being treated like all of the other .di files in druntime.
>
> I remember getting the impression that thread.di required better control over what was and wasn't in there than the generator was likely to provide even with stripping stuff, but I'd have to go dig through archives for discussions on that. So, if the generator was updated to actually strip most stuff, then it might work, or it might not.
>
> Martin is likely to know more, since he's the one who made the change in the first place.
>
> - Jonathan M Davis

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).
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 1/9/13 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.
> (Please everyone, abandon any fanciful ideas that they speed
> compilation. Anybody who thinks it does, clearly hasn't done any
> profiling).

I'm thinking about avoiding duplication, OOAO and such. Would di files help with that in this particular case?

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