On Monday, May 14, 2012 23:03:20 Adam Wilson wrote:
> I have updated the make files so that only core.thread and core.sync.* are run through DI generation. ALL other core.* modules are copied into the import directory now.

I assume that object.di and core/thread.di are being used rather than their corresponding .d files being run through the .di generation? They already have hand-crafted .di files.

- Jonathan M Davis

On Mon, 14 May 2012 23:11:50 -0700, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Monday, May 14, 2012 23:03:20 Adam Wilson wrote:
>> I have updated the make files so that only core.thread and core.sync.* are
>> run through DI generation. ALL other core.* modules are copied into the
>> import directory now.
>
> I assume that object.di and core/thread.di are being used rather than their
> corresponding .d files being run through the .di generation? They already have
> hand-crafted .di files.
>
> - Jonathan M Davis

The funny thing is that core.thread.di was being run through the DI generator in the old make file. I had left it that way, I have posted a commit that moves it to the copy section.

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

Old days import/core/thread.di was generated from src/core/thread.d . Current import/core/thread.di is generated from src/core/thread.*di* .

Kenji Hara

2012/5/15 Jonathan M Davis <jmdavisProg@gmx.com>:
> On Monday, May 14, 2012 23:46:08 Adam Wilson wrote:
>> On Mon, 14 May 2012 23:11:50 -0700, Jonathan M Davis <jmdavisProg@gmx.com>
>>
>> wrote:
>> > On Monday, May 14, 2012 23:03:20 Adam Wilson wrote:
>> >> I have updated the make files so that only core.thread and core.sync.*
>> >> are
>> >> run through DI generation. ALL other core.* modules are copied into the
>> >> import directory now.
>> >
>> > I assume that object.di and core/thread.di are being used rather than
>> > their
>> > corresponding .d files being run through the .di generation? They
>> > already have
>> > hand-crafted .di files.
>> >
>> > - Jonathan M Davis
>>
>> The funny thing is that core.thread.di was being run through the DI generator in the old make file. I had left it that way, I have posted a commit that moves it to the copy section.
>
> Well, if that works... It's weird though, because there's no reason to have a thread.di if it's not used, and as I understand it, some work was being done that required some of Thread's internals _not_ be in the .di file, but I don't remember the details, and I don't know where that stands.
>
> - Jonathan M Davis

On Tue, 15 May 2012 02:51:44 -0700, kenji hara <k.hara.pg@gmail.com> wrote:

> Old days import/core/thread.di was generated from src/core/thread.d .
> Current import/core/thread.di is generated from src/core/thread.*di* .
>
> Kenji Hara

Well, I've updated the make file to just copy thread.di instead of running it through the generator.

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

On Tue, 15 May 2012 05:51:44 -0400, kenji hara <k.hara.pg@gmail.com> wrote:

> Old days import/core/thread.di was generated from src/core/thread.d .
> Current import/core/thread.di is generated from src/core/thread.*di* .

Huh?  Why the copy?  Just move src/core/thread.di to import/core/thread.di

object.di lives in import/core, I think it should be the same for all the hand-maintained .di files.

FWIW, I thought thread.di was being generated because of this.

Also, I agree that thread and object are the only modules that need to be .di files.  Everything else is already opaque for the most part, and the pieces that aren't are just supporting code that can be visible.

What we need to protect is the runtime implementation, so projects cannot depend on private APIs that may change.

-Steve

On 16-05-2012 14:46, Steven Schveighoffer wrote:
> On Tue, 15 May 2012 05:51:44 -0400, kenji hara <k.hara.pg@gmail.com> wrote:
>
>> Old days import/core/thread.di was generated from src/core/thread.d .
>> Current import/core/thread.di is generated from src/core/thread.*di* .
>
> Huh? Why the copy? Just move src/core/thread.di to import/core/thread.di
>
> object.di lives in import/core, I think it should be the same for all
> the hand-maintained .di files.

Good point. I wonder why we didn't do that initially.

>
> FWIW, I thought thread.di was being generated because of this.
>
> Also, I agree that thread and object are the only modules that need to
> be .di files. Everything else is already opaque for the most part, and
> the pieces that aren't are just supporting code that can be visible.
>
> What we need to protect is the runtime implementation, so projects
> cannot depend on private APIs that may change.
>
> -Steve

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Wed, 16 May 2012 05:46:44 -0700, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Tue, 15 May 2012 05:51:44 -0400, kenji hara <k.hara.pg@gmail.com> wrote:
>
>> Old days import/core/thread.di was generated from src/core/thread.d .
>> Current import/core/thread.di is generated from src/core/thread.*di* .
>
> Huh?  Why the copy?  Just move src/core/thread.di to import/core/thread.di
>
> object.di lives in import/core, I think it should be the same for all the hand-maintained .di files.

Actually, object.di lives /import. Moving thread.di to /import/core would require a significant change to the clean targets of both makefiles since they just rm the whole /import/core directory at the moment. It's not impossible and if you guys agree that the change should be made I'd be happy to make it happen.

> FWIW, I thought thread.di was being generated because of this.
>
> Also, I agree that thread and object are the only modules that need to be .di files.  Everything else is already opaque for the most part, and the pieces that aren't are just supporting code that can be visible.
>
> What we need to protect is the runtime implementation, so projects cannot depend on private APIs that may change.
>
> -Steve

The biggest problem right now is that, while we all agree that these changes need to happen, getting them merged appears to be nigh impossible. There appears to be a bottleneck in the process caused by the lack of capable persons to verify and execute the merges, particularly for druntime. There are 11 passing merges for the druntime at last count, out of 28 total. Alexrp and dawgfoto particularly seem to have a lot of pulls that are just languishing.

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

On 16-05-2012 19:00, Adam Wilson wrote:
> On Wed, 16 May 2012 05:46:44 -0700, Steven Schveighoffer
> <schveiguy@yahoo.com> wrote:
>
>> On Tue, 15 May 2012 05:51:44 -0400, kenji hara <k.hara.pg@gmail.com>
>> wrote:
>>
>>> Old days import/core/thread.di was generated from src/core/thread.d .
>>> Current import/core/thread.di is generated from src/core/thread.*di* .
>>
>> Huh? Why the copy? Just move src/core/thread.di to import/core/thread.di
>>
>> object.di lives in import/core, I think it should be the same for all
>> the hand-maintained .di files.
>
> Actually, object.di lives /import. Moving thread.di to /import/core
> would require a significant change to the clean targets of both
> makefiles since they just rm the whole /import/core directory at the
> moment. It's not impossible and if you guys agree that the change should
> be made I'd be happy to make it happen.

I think it's a good idea.

>
>> FWIW, I thought thread.di was being generated because of this.
>>
>> Also, I agree that thread and object are the only modules that need to
>> be .di files. Everything else is already opaque for the most part, and
>> the pieces that aren't are just supporting code that can be visible.
>>
>> What we need to protect is the runtime implementation, so projects
>> cannot depend on private APIs that may change.
>>
>> -Steve
>
> The biggest problem right now is that, while we all agree that these
> changes need to happen, getting them merged appears to be nigh
> impossible. There appears to be a bottleneck in the process caused by
> the lack of capable persons to verify and execute the merges,
> particularly for druntime. There are 11 passing merges for the druntime
> at last count, out of 28 total. Alexrp and dawgfoto particularly seem to
> have a lot of pulls that are just languishing.
>

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Wednesday, May 16, 2012 10:00:24 Adam Wilson wrote:
> The biggest problem right now is that, while we all agree that these changes need to happen, getting them merged appears to be nigh impossible. There appears to be a bottleneck in the process caused by the lack of capable persons to verify and execute the merges, particularly for druntime. There are 11 passing merges for the druntime at last count, out of 28 total. Alexrp and dawgfoto particularly seem to have a lot of pulls that are just languishing.

That's just life with druntime, Phobos, and dmd. There are only so many people with commit access, and they're all busy. druntime is a bit worse than Phobos, since it often requires Sean to look at stuff, but they both have the problem. And in this particular case, since it impacts so much, it's one of the requests that Sean probabyl should look at, and I don't know how often he goes through druntime's pull requests.

- Jonathan M Davis

On Wed, 16 May 2012 14:37:46 -0700, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday, May 16, 2012 10:00:24 Adam Wilson wrote:
>> The biggest problem right now is that, while we all agree that these
>> changes need to happen, getting them merged appears to be nigh impossible.
>> There appears to be a bottleneck in the process caused by the lack of
>> capable persons to verify and execute the merges, particularly for
>> druntime. There are 11 passing merges for the druntime at last count, out
>> of 28 total. Alexrp and dawgfoto particularly seem to have a lot of pulls
>> that are just languishing.
>
> That's just life with druntime, Phobos, and dmd. There are only so many people
> with commit access, and they're all busy. druntime is a bit worse than Phobos,
> since it often requires Sean to look at stuff, but they both have the problem.
> And in this particular case, since it impacts so much, it's one of the
> requests that Sean probabyl should look at, and I don't know how often he goes
> through druntime's pull requests.
>
> - Jonathan M Davis

I absolutely agree that he should look at it. I was just kvetching about the backlog in general. There are some really good fixes that aren't getting merged. Realistically, I no longer expect for the full DI patch to make it in to 2.060; but at the same time I don't want it to get forgotten, and there are A LOT of bitrotten pulls on GitHub.

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