View mode: basic / threaded / horizontal-split · Log in · Help
May 15, 2012
Re: Request for Review: DI Generation Improvements
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
May 15, 2012
Re: Request for Review: DI Generation Improvements
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/
May 15, 2012
Re: Request for Review: DI Generation Improvements
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
May 15, 2012
Re: Request for Review: DI Generation Improvements
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/
May 16, 2012
Re: Request for Review: DI Generation Improvements
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
May 16, 2012
Re: Request for Review: DI Generation Improvements
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
May 16, 2012
Re: Request for Review: DI Generation Improvements
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/
May 16, 2012
Re: Request for Review: DI Generation Improvements
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
May 16, 2012
Re: Request for Review: DI Generation Improvements
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
May 16, 2012
Re: Request for Review: DI Generation Improvements
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/
1 2 3
Top | Discussion index | About this forum | D home