www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Front-end release.NEXT

reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
Morning all,

It has been about 3 months since the last release of the D 
front-end implementation.  Three years experience and carrying 
out over 100 merges into GDC tells me that each time the 
development cycle starts edging towards it's fourth month, it 
makes things an absolute nightmare, in both the time consumed 
merging in the changes, and with time spent tracking down bug 
reports for unittests/testsuite cases that test backend code 
generation - with 2.060, 2.061 and 2.063 being the worst releases 
I have ever had to deal with - before 2.060 the release schedule 
(if it even qualifies as a 'schedule') was anywhere between 1-2 
months.

So I would want to give everyone on the dev team a kick and get 
the alpha/beta out the door.

Across D/Druntime/Phobos, there are currently 26 open major bugs 
since 28/05/2013.
http://bit.ly/173WrZf

18 open critical bugs.
http://bit.ly/16WkhcM

5 blockers.
http://bit.ly/18q1pkC

And 14 regressions.
http://bit.ly/15pLzVb


Regards
Iain
Aug 30 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 30 August 2013 at 13:41:35 UTC, Iain Buclaw wrote:
 ...
My main concern about upcoming 2.064 is http://d.puremagic.com/issues/show_bug.cgi?id=10150 - it is a language change, it was merged with no discussion, it has been marked by several people as potentially dangerous in comments after merging. And still it persists. While there was some disagreement on how it should behave, it is pretty clear to me that this change is not well-developed enough in its current state and can't be released like that.
Aug 30 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 August 2013 14:56, Dicebot <public dicebot.lv> wrote:
 On Friday, 30 August 2013 at 13:41:35 UTC, Iain Buclaw wrote:
 ...
My main concern about upcoming 2.064 is http://d.puremagic.com/issues/show_bug.cgi?id=10150 - it is a language change, it was merged with no discussion, it has been marked by several people as potentially dangerous in comments after merging. And still it persists. While there was some disagreement on how it should behave, it is pretty clear to me that this change is not well-developed enough in its current state and can't be released like that.
You should create a DIP to start a formal review process for this. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 30 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 30 August 2013 at 14:43:12 UTC, Iain Buclaw wrote:
 You should create a DIP to start a formal review process for 
 this.
You have forgot the part about writing pull request and providing deprecation path (emo)
Aug 30 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 August 2013 15:48, Dicebot <public dicebot.lv> wrote:
 On Friday, 30 August 2013 at 14:43:12 UTC, Iain Buclaw wrote:
 You should create a DIP to start a formal review process for this.
You have forgot the part about writing pull request and providing deprecation path (emo)
The compiler frontend implementation allowing bogus or conflicting pre/post attributes as no-ops is nothing new (bearophile has been documenting all wrong/confusing cases since 2010). So keeping what was a no-op as a no-op for the time being can't hurt too much. Haven't read all posts but am I right in assuming that the compiler will correctly warn for post attributes, but clears pre attributes silently? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 30 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 30 August 2013 at 15:00:51 UTC, Iain Buclaw wrote:
 The compiler frontend implementation allowing bogus or 
 conflicting
 pre/post attributes as no-ops is nothing new (bearophile has 
 been
 documenting all wrong/confusing cases since 2010).  So keeping 
 what
 was a no-op as a no-op for the time being can't hurt too much.

 Haven't read all posts but am I right in assuming that the 
 compiler
 will correctly warn for post attributes, but clears pre 
 attributes
 silently?
Actually looks like I have missed one release in slumber and it is already in 2.063 >_< const char* foo(); This was an error, "function xxx.foo without 'this' cannot be const/immutable". In 2.063+ it compiles silently ignoring `const` with no warnings/errors/whatever. This is especially error-prone when writing C bindings and doing 1-to-1 translation from C code. Looks like I am too late though. Crap.
Aug 30 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 August 2013 16:08, Dicebot <public dicebot.lv> wrote:
 On Friday, 30 August 2013 at 15:00:51 UTC, Iain Buclaw wrote:
 The compiler frontend implementation allowing bogus or conflicting
 pre/post attributes as no-ops is nothing new (bearophile has been
 documenting all wrong/confusing cases since 2010).  So keeping what
 was a no-op as a no-op for the time being can't hurt too much.

 Haven't read all posts but am I right in assuming that the compiler
 will correctly warn for post attributes, but clears pre attributes
 silently?
Actually looks like I have missed one release in slumber and it is already in 2.063 >_< const char* foo(); This was an error, "function xxx.foo without 'this' cannot be const/immutable". In 2.063+ it compiles silently ignoring `const` with no warnings/errors/whatever. This is especially error-prone when writing C bindings and doing 1-to-1 translation from C code. Looks like I am too late though. Crap.
:o) I think const char* foo() should mean const(char*) foo. But this needs to be discussed elsewhere. Right now, the focus is on getting the next release out the door. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 30 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 30, 2013 at 03:41:34PM +0200, Iain Buclaw wrote:
[...]
 Across D/Druntime/Phobos, there are currently 26 open major bugs
 since 28/05/2013.
 http://bit.ly/173WrZf
 
 18 open critical bugs.
 http://bit.ly/16WkhcM
 
 5 blockers.
 http://bit.ly/18q1pkC
 
 And 14 regressions.
 http://bit.ly/15pLzVb
[...] I obtained a +1 Sword of Bisection from a git this morning, and decided to go commit hunting. I found the specific commits that introduced the following regressions (see bug notes for the offending commits): 10687 - Refused cast from uint[] to array of uint-based enums at compile-time 10401 - ICE(ztc/symbol.c 1035) - inline Nullable struct with JSONValue 10425 - Link error with templates 10555 - enumerator can no longer increment beyond maximum of initializer 10617 - contract with -profile -debug is not nothrow 10630 - Structs with disabled default construction can't be used as `out` parameters I would fix them myself, except that my dmd-fu level isn't high enough to take them on yet. ;-) T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter
Aug 30 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2013 11:32 AM, H. S. Teoh wrote:
 On Fri, Aug 30, 2013 at 03:41:34PM +0200, Iain Buclaw wrote:
 [...]
 Across D/Druntime/Phobos, there are currently 26 open major bugs
 since 28/05/2013.
 http://bit.ly/173WrZf

 18 open critical bugs.
 http://bit.ly/16WkhcM

 5 blockers.
 http://bit.ly/18q1pkC

 And 14 regressions.
 http://bit.ly/15pLzVb
[...] I obtained a +1 Sword of Bisection from a git this morning, and decided to go commit hunting. I found the specific commits that introduced the following regressions (see bug notes for the offending commits): 10687 - Refused cast from uint[] to array of uint-based enums at compile-time 10401 - ICE(ztc/symbol.c 1035) - inline Nullable struct with JSONValue 10425 - Link error with templates 10555 - enumerator can no longer increment beyond maximum of initializer 10617 - contract with -profile -debug is not nothrow 10630 - Structs with disabled default construction can't be used as `out` parameters I would fix them myself, except that my dmd-fu level isn't high enough to take them on yet. ;-)
Thank you. This is great information.
Aug 30 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2013 11:32 AM, H. S. Teoh wrote:
 On Fri, Aug 30, 2013 at 03:41:34PM +0200, Iain Buclaw wrote:
 [...]
 Across D/Druntime/Phobos, there are currently 26 open major bugs
 since 28/05/2013.
 http://bit.ly/173WrZf

 18 open critical bugs.
 http://bit.ly/16WkhcM

 5 blockers.
 http://bit.ly/18q1pkC

 And 14 regressions.
 http://bit.ly/15pLzVb
[...] I obtained a +1 Sword of Bisection from a git this morning, and decided to go commit hunting. I found the specific commits that introduced the following regressions (see bug notes for the offending commits): 10687 - Refused cast from uint[] to array of uint-based enums at compile-time 10401 - ICE(ztc/symbol.c 1035) - inline Nullable struct with JSONValue 10425 - Link error with templates 10555 - enumerator can no longer increment beyond maximum of initializer 10617 - contract with -profile -debug is not nothrow 10630 - Structs with disabled default construction can't be used as `out` parameters I would fix them myself, except that my dmd-fu level isn't high enough to take them on yet. ;-)
BTW, please add this information to both the regression issues and the issues who's resolution introduced the regression.
Aug 30 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On Aug 30, 2013 7:34 PM, "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 On Fri, Aug 30, 2013 at 03:41:34PM +0200, Iain Buclaw wrote:
 [...]
 Across D/Druntime/Phobos, there are currently 26 open major bugs
 since 28/05/2013.
 http://bit.ly/173WrZf

 18 open critical bugs.
 http://bit.ly/16WkhcM

 5 blockers.
 http://bit.ly/18q1pkC

 And 14 regressions.
 http://bit.ly/15pLzVb
[...] I obtained a +1 Sword of Bisection from a git this morning, and decided to go commit hunting. I found the specific commits that introduced the following regressions (see bug notes for the offending commits): 10687 - Refused cast from uint[] to array of uint-based enums at
compile-time
 10401 - ICE(ztc/symbol.c 1035) - inline Nullable struct with JSONValue
 10425 - Link error with templates
 10555 - enumerator can no longer increment beyond maximum of initializer
 10617 - contract with -profile -debug is not nothrow
 10630 - Structs with disabled default construction can't be used as `out`
parameters
 I would fix them myself, except that my dmd-fu level isn't high enough
 to take them on yet. ;-)
Thanks, I take it you linked in the specific commits in the bug reports? I can have a look later and chime in, however bugs that don't affect me won't get reviewed. :) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 30 2013
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Fri, 30 Aug 2013 06:41:34 -0700, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 Morning all,

 It has been about 3 months since the last release of the D front-end  
 implementation.  Three years experience and carrying out over 100 merges  
 into GDC tells me that each time the development cycle starts edging  
 towards it's fourth month, it makes things an absolute nightmare, in  
 both the time consumed merging in the changes, and with time spent  
 tracking down bug reports for unittests/testsuite cases that test  
 backend code generation - with 2.060, 2.061 and 2.063 being the worst  
 releases I have ever had to deal with - before 2.060 the release  
 schedule (if it even qualifies as a 'schedule') was anywhere between 1-2  
 months.

 So I would want to give everyone on the dev team a kick and get the  
 alpha/beta out the door.

 Across D/Druntime/Phobos, there are currently 26 open major bugs since  
 28/05/2013.
 http://bit.ly/173WrZf

 18 open critical bugs.
 http://bit.ly/16WkhcM

 5 blockers.
 http://bit.ly/18q1pkC

 And 14 regressions.
 http://bit.ly/15pLzVb


 Regards
 Iain
I don't know how much action D is going to be getting next week due to Walter's attendance of GoingNative, but IIRC last year Walter was able to sneak in a commit or two... This would actually be a good opportunity for the community to have pulls fixing the Criticals/Blockers/Regressions waiting for Walter when he gets back from GoingNative. Might make getting a new release that much smoother and sooner. :-) -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Aug 30 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 30, 2013 at 12:05:12PM -0700, Adam Wilson wrote:
[...]
 I don't know how much action D is going to be getting next week due
 to Walter's attendance of GoingNative, but IIRC last year Walter was
 able to sneak in a commit or two...
Looks like Andrei is going to be a speaker there as well, so Phobos fixes might be a bit slow as well (though we have a team of other committers who could alleviate that).
 This would actually be a good opportunity for the community to have
 pulls fixing the Criticals/Blockers/Regressions waiting for Walter
 when he gets back from GoingNative. Might make getting a new release
 that much smoother and sooner. :-)
[...] And have them all green and ready to merge by the time he gets back -- the autotester appears to be experiencing load problems recently, so it would be nice to give it some time to catch up on all the pulls. It should make the next release happen sooner... but I'm not sure about smoother, though. A higher rate of code changes usually means more potential regressions with the associated chaos that follows thereafter. :) T -- Heads I win, tails you lose.
Aug 30 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 August 2013 20:19, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 On Fri, Aug 30, 2013 at 12:05:12PM -0700, Adam Wilson wrote:
 [...]
 I don't know how much action D is going to be getting next week due
 to Walter's attendance of GoingNative, but IIRC last year Walter was
 able to sneak in a commit or two...
Looks like Andrei is going to be a speaker there as well, so Phobos fixes might be a bit slow as well (though we have a team of other committers who could alleviate that).
Hopefully in a year's time, the release process for D and Phobos should have a bigger bus factor than 1 (each). The core developers surrounding both D and Phobos are certainly self supporting without too much weight being put onto two (highly distinguished) gentlemen. :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 30 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2013 12:05 PM, Adam Wilson wrote:
 I don't know how much action D is going to be getting next week due to Walter's
 attendance of GoingNative, but IIRC last year Walter was able to sneak in a
 commit or two...
The GoingNative is a great conference, and if the past is any guide, they'll be all day & evening and I'll be barely able to answer any emergency emails let alone get any work done for those days. I won't be bringing my laptop.
Aug 30 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 30, 2013 at 08:00:35PM +0100, Iain Buclaw wrote:
 On Aug 30, 2013 7:34 PM, "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 On Fri, Aug 30, 2013 at 03:41:34PM +0200, Iain Buclaw wrote:
 [...]
 Across D/Druntime/Phobos, there are currently 26 open major bugs
 since 28/05/2013.
 http://bit.ly/173WrZf

 18 open critical bugs.
 http://bit.ly/16WkhcM

 5 blockers.
 http://bit.ly/18q1pkC

 And 14 regressions.
 http://bit.ly/15pLzVb
[...] I obtained a +1 Sword of Bisection from a git this morning, and decided to go commit hunting. I found the specific commits that introduced the following regressions (see bug notes for the offending commits): 10687 - Refused cast from uint[] to array of uint-based enums at
compile-time
 10401 - ICE(ztc/symbol.c 1035) - inline Nullable struct with JSONValue
 10425 - Link error with templates
 10555 - enumerator can no longer increment beyond maximum of initializer
 10617 - contract with -profile -debug is not nothrow
 10630 - Structs with disabled default construction can't be used as `out`
parameters
 I would fix them myself, except that my dmd-fu level isn't high
 enough to take them on yet. ;-)
Thanks, I take it you linked in the specific commits in the bug reports? I can have a look later and chime in, however bugs that don't affect me won't get reviewed. :)
[...] Well, I posted the SHA hashes... I didn't think to actually link to the github URL. That's an excellent idea; I'll keep that in mind next time. In any case, it shouldn't be too hard to find the code on github with the SHA hashes. Or better yet, just git checkout <hash>. :) T -- "Life is all a great joke, but only the brave ever get the point." -- Kenneth Rexroth
Aug 30 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2013 6:41 AM, Iain Buclaw wrote:
 Morning all,

 It has been about 3 months since the last release of the D front-end
 implementation.  Three years experience and carrying out over 100 merges into
 GDC tells me that each time the development cycle starts edging towards it's
 fourth month, it makes things an absolute nightmare, in both the time consumed
 merging in the changes, and with time spent tracking down bug reports for
 unittests/testsuite cases that test backend code generation - with 2.060, 2.061
 and 2.063 being the worst releases I have ever had to deal with - before 2.060
 the release schedule (if it even qualifies as a 'schedule') was anywhere
between
 1-2 months.

 So I would want to give everyone on the dev team a kick and get the alpha/beta
 out the door.

 Across D/Druntime/Phobos, there are currently 26 open major bugs since
28/05/2013.
 http://bit.ly/173WrZf

 18 open critical bugs.
 http://bit.ly/16WkhcM

 5 blockers.
 http://bit.ly/18q1pkC

 And 14 regressions.
 http://bit.ly/15pLzVb
I think it's a good idea. The only further enhancement I really want to get in this release is DLL support for Linux.
Aug 30 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-30 21:50, Walter Bright wrote:

 I think it's a good idea.

 The only further enhancement I really want to get in this release is DLL
 support for Linux.
Do you mean loading DLL's completely at runtime, i.e. using dlopen? We have already shipped Phobos as a DLL. -- /Jacob Carlborg
Aug 31 2013
next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Saturday, 31 August 2013 at 11:24:41 UTC, Jacob Carlborg wrote:
 Do you mean loading DLL's completely at runtime, i.e. using 
 dlopen? We have already shipped Phobos as a DLL.
Yep, see https://github.com/D-Programming-Language/druntime/pull/593 and linked pull requests. David
Aug 31 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2013 4:24 AM, Jacob Carlborg wrote:
 On 2013-08-30 21:50, Walter Bright wrote:

 I think it's a good idea.

 The only further enhancement I really want to get in this release is DLL
 support for Linux.
Do you mean loading DLL's completely at runtime, i.e. using dlopen? We have already shipped Phobos as a DLL.
I mean that from a C or D program, being able to dynamically load and unload DLLs at runtime.
Aug 31 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-31 20:10, Walter Bright wrote:

 I mean that from a C or D program, being able to dynamically load and
 unload DLLs at runtime.
I see. -- /Jacob Carlborg
Aug 31 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 31, 2013 at 11:10:54AM -0700, Walter Bright wrote:
 On 8/31/2013 4:24 AM, Jacob Carlborg wrote:
On 2013-08-30 21:50, Walter Bright wrote:

I think it's a good idea.

The only further enhancement I really want to get in this release is
DLL support for Linux.
Do you mean loading DLL's completely at runtime, i.e. using dlopen? We have already shipped Phobos as a DLL.
I mean that from a C or D program, being able to dynamically load and unload DLLs at runtime.
Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be *very* nice, if it can be made to work. T -- Many open minds should be closed for repairs. -- K5 user
Aug 31 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2013 1:00 PM, H. S. Teoh wrote:
 Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be
 *very* nice, if it can be made to work.
It certainly can be made to work. Martin Nowak is close to getting it done.
Aug 31 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 31, 2013 at 01:27:09PM -0700, Walter Bright wrote:
 On 8/31/2013 1:00 PM, H. S. Teoh wrote:
Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be
*very* nice, if it can be made to work.
It certainly can be made to work. Martin Nowak is close to getting it done.
Excellent! I presume it will be type-safe and support all the usual D idioms? (I.e., none of that ugly mess with dlsym and C++, where casting void* returned by dlsym() to a func ptr is undefined behaviour according to the C++ spec). T -- The two rules of success: 1. Don't tell everything you know. -- YHL
Aug 31 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-31 23:42, H. S. Teoh wrote:

 Excellent! I presume it will be type-safe and support all the usual D
 idioms? (I.e., none of that ugly mess with dlsym and C++, where casting
 void* returned by dlsym() to a func ptr is undefined behaviour according
 to the C++ spec).
It looks like it only contains functions for loading and unloading DLL's. No functions for handling symbols. https://github.com/D-Programming-Language/druntime/pull/593 -- /Jacob Carlborg
Sep 01 2013
prev sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Saturday, 31 August 2013 at 21:44:24 UTC, H. S. Teoh wrote:
 Excellent! I presume it will be type-safe and support all the 
 usual D
 idioms? (I.e., none of that ugly mess with dlsym and C++, where 
 casting
 void* returned by dlsym() to a func ptr is undefined behaviour 
 according
 to the C++ spec).
Currently, the focus is on just getting the technical underpinnings done. As for possible APIs, Martin's DConf talk contained some related ideas. David
Sep 01 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/30/13, Walter Bright <newshound2 digitalmars.com> wrote:
 The only further enhancement I really want to get in this release is DLL
 support for Linux.
And if it's (mostly) done, we should put it in the changelog, since it's a pretty big deal!
Aug 31 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 30, 2013 at 12:43:44PM -0700, Walter Bright wrote:
 On 8/30/2013 11:32 AM, H. S. Teoh wrote:
[...]
I obtained a +1 Sword of Bisection from a git this morning, and
decided to go commit hunting. I found the specific commits that
introduced the following regressions (see bug notes for the offending
commits):

10687 - Refused cast from uint[] to array of uint-based enums at compile-time
10401 - ICE(ztc/symbol.c 1035) - inline Nullable struct with JSONValue
10425 - Link error with templates
10555 - enumerator can no longer increment beyond maximum of initializer
10617 - contract with -profile -debug is not nothrow
10630 - Structs with disabled default construction can't be used as `out`
parameters

I would fix them myself, except that my dmd-fu level isn't high
enough to take them on yet. ;-)
Thank you. This is great information.
And easily obtained with git bisect, about 5-10 minutes per bug. :) On Fri, Aug 30, 2013 at 12:45:16PM -0700, Walter Bright wrote: [...]
 BTW, please add this information to both the regression issues and
 the issues who's resolution introduced the regression.
Done. The bugs whose resolution introduced the regressions were pretty easy to find, except for 10687: I had to read up on how to work with complicated git revision ranges to isolate it. :) Turns out it's another regression from Don's epic pull: https://github.com/D-Programming-Language/dmd/pull/2136 Unfortunately, for all of its epicness, a change of such magnitude inevitably introduces/exposes other flaws, and this is one of them (already the second one noted on the pull page). One of these days I'll have to research a little more how to more easily identify the merge commit that pulled in a particular commit. Since all commits only refer to their ancestors, git has no easy way of following the chain downstream to the merge point (at least, none that I know of). If anyone knows some git-fu to do this, I'd be very much obliged. :) T -- Кто везде - тот нигде.
Aug 30 2013
parent reply Justin Whear <justin economicmodeling.com> writes:
On Fri, 30 Aug 2013 14:35:04 -0700, H. S. Teoh wrote:

 On Fri, Aug 30, 2013 at 12:43:44PM -0700, Walter Bright wrote:
 One of these days I'll have to research a little more how to more easily
 identify the merge commit that pulled in a particular commit. Since all
 commits only refer to their ancestors, git has no easy way of following
 the chain downstream to the merge point (at least, none that I know of).
 If anyone knows some git-fu to do this, I'd be very much obliged. :)
 
 
 T
I think you can find the merge which introduced the commit with something like this: git log <commit hash>..master --merges --ancestry-path Though that includes subsequent merges; I think you just want the last one.
Aug 30 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 30, 2013 at 09:51:25PM +0000, Justin Whear wrote:
 On Fri, 30 Aug 2013 14:35:04 -0700, H. S. Teoh wrote:
 
 On Fri, Aug 30, 2013 at 12:43:44PM -0700, Walter Bright wrote:
 One of these days I'll have to research a little more how to more
 easily identify the merge commit that pulled in a particular commit.
 Since all commits only refer to their ancestors, git has no easy way
 of following the chain downstream to the merge point (at least, none
 that I know of).  If anyone knows some git-fu to do this, I'd be
 very much obliged. :)
 
 
 T
I think you can find the merge which introduced the commit with something like this: git log <commit hash>..master --merges --ancestry-path Though that includes subsequent merges; I think you just want the last one.
Cool, that did the trick! Yeah I just want the last one... but at least it's there. It's easy to ignore the rest. :) T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Aug 30 2013
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On Aug 30, 2013 2:45 PM, "Iain Buclaw" <ibuclaw ubuntu.com> wrote:
 Morning all,

 It has been about 3 months since the last release of the D front-end
implementation. Three years experience and carrying out over 100 merges into GDC tells me that each time the development cycle starts edging towards it's fourth month, it makes things an absolute nightmare, in both the time consumed merging in the changes, and with time spent tracking down bug reports for unittests/testsuite cases that test backend code generation - with 2.060, 2.061 and 2.063 being the worst releases I have ever had to deal with - before 2.060 the release schedule (if it even qualifies as a 'schedule') was anywhere between 1-2 months.
 So I would want to give everyone on the dev team a kick and get the
alpha/beta out the door.
 Across D/Druntime/Phobos, there are currently 26 open major bugs since
28/05/2013.
 http://bit.ly/173WrZf

 18 open critical bugs.
 http://bit.ly/16WkhcM

 5 blockers.
 http://bit.ly/18q1pkC

 And 14 regressions.
 http://bit.ly/15pLzVb
One month gone and 14 of these have now been closed/fixed. Still seen no signs of moving towards a next release... Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 28 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 September 2013 at 10:48:49 UTC, Iain Buclaw wrote:
 One month gone and 14 of these have now been closed/fixed.  
 Still seen no
 signs of moving towards a next release...

 Regards
From my point of view two things that are necessary for making this release: 1) working dynamic loading of shared libraries (what is the state of this?) 2) fixing all regression caused by recent symbol emitting changes (at least vibe.d had one on master weak or two ago, did not check it after that)
Sep 28 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-28 18:48, Dicebot wrote:

  From my point of view two things that are necessary for making this
 release:

 1) working dynamic loading of shared libraries (what is the state of this?)
I would like to add: only on Linux.
 2) fixing all regression caused by recent symbol emitting changes (at
 least vibe.d had one on master weak or two ago, did not check it after
 that)
-- /Jacob Carlborg
Sep 28 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 28 September 2013 18:39, Jacob Carlborg <doob me.com> wrote:
 On 2013-09-28 18:48, Dicebot wrote:

  From my point of view two things that are necessary for making this
 release:

 1) working dynamic loading of shared libraries (what is the state of
 this?)
I would like to add: only on Linux.
I am fine with pushing that feature as an entirely new release (eg. 2.065). What I'm concerned about are that we've had 4 months of adding *other* features, bug fixing, and other changes in the D frontend that need to be sync'd up. Point two, shared library support in D is not transferable to gdc/ldc - so it's not even a beneficial feature in my eyes. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 28 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 September 2013 at 18:32:51 UTC, Iain Buclaw wrote:
 I am fine with pushing that feature as an entirely new release 
 (eg.
 2.065).  What I'm concerned about are that we've had 4 months of
 adding *other* features, bug fixing, and other changes in the D
 frontend that need to be sync'd up.
I agree that it at least makes sense to make release branch to start slowly working towards fixing regressions and stabilizing stuff.
 Point two, shared library support in D is not transferable to 
 gdc/ldc
 - so it's not even a beneficial feature in my eyes.
I thought it is a temporary limitation (I am very interested in loading D plugins from C/C++ programs). Are there any fundamental issues that prevent it?
Sep 28 2013
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 28 September 2013 20:37, Dicebot <public dicebot.lv> wrote:
 On Saturday, 28 September 2013 at 18:32:51 UTC, Iain Buclaw wrote:
 I am fine with pushing that feature as an entirely new release (eg.
 2.065).  What I'm concerned about are that we've had 4 months of
 adding *other* features, bug fixing, and other changes in the D
 frontend that need to be sync'd up.
I agree that it at least makes sense to make release branch to start slowly working towards fixing regressions and stabilizing stuff.
 Point two, shared library support in D is not transferable to gdc/ldc
 - so it's not even a beneficial feature in my eyes.
I thought it is a temporary limitation (I am very interested in loading D plugins from C/C++ programs). Are there any fundamental issues that prevent it?
In gdc or dmd? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 28 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 September 2013 at 19:53:16 UTC, Iain Buclaw wrote:
 I thought it is a temporary limitation (I am very interested 
 in loading D
 plugins from C/C++ programs). Are there any fundamental issues 
 that prevent
 it?
In gdc or dmd?
Both. g++ / dmd and g++ / gdc.
Sep 28 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 28 September 2013 21:02, Dicebot <public dicebot.lv> wrote:
 On Saturday, 28 September 2013 at 19:53:16 UTC, Iain Buclaw wrote:
 I thought it is a temporary limitation (I am very interested in loading D
 plugins from C/C++ programs). Are there any fundamental issues that
 prevent
 it?
In gdc or dmd?
Both. g++ / dmd and g++ / gdc.
There's no limitations really loading C/C++ libraries into D - don't know about dmd... Thought you meant fundamental issues that prevent shared library support in dmd/gdc (as in D libraries). ;-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 28 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 September 2013 at 20:17:24 UTC, Iain Buclaw wrote:
 On 28 September 2013 21:02, Dicebot <public dicebot.lv> wrote:
 On Saturday, 28 September 2013 at 19:53:16 UTC, Iain Buclaw 
 wrote:
 I thought it is a temporary limitation (I am very interested 
 in loading D
 plugins from C/C++ programs). Are there any fundamental 
 issues that
 prevent
 it?
In gdc or dmd?
Both. g++ / dmd and g++ / gdc.
There's no limitations really loading C/C++ libraries into D - don't know about dmd... Thought you meant fundamental issues that prevent shared library support in dmd/gdc (as in D libraries). ;-)
No, not loading C plugins from D, other way around ;) I have tried it right now on dmd master + gcc 4.8.1 and shared library was rejected to be loaded because of TLS. Was curious if this is fundamental limitation or eventually can be worked around.
Sep 29 2013
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On Sep 29, 2013 10:45 AM, "Dicebot" <public dicebot.lv> wrote:
 On Saturday, 28 September 2013 at 20:17:24 UTC, Iain Buclaw wrote:
 On 28 September 2013 21:02, Dicebot <public dicebot.lv> wrote:
 On Saturday, 28 September 2013 at 19:53:16 UTC, Iain Buclaw wrote:
 I thought it is a temporary limitation (I am very interested in
loading D
 plugins from C/C++ programs). Are there any fundamental issues that
 prevent
 it?
In gdc or dmd?
Both. g++ / dmd and g++ / gdc.
There's no limitations really loading C/C++ libraries into D - don't know about dmd... Thought you meant fundamental issues that prevent shared library support in dmd/gdc (as in D libraries). ;-)
No, not loading C plugins from D, other way around ;) I have tried it right now on dmd master + gcc 4.8.1 and shared library
was rejected to be loaded because of TLS. Was curious if this is fundamental limitation or eventually can be worked around. Run time support for shared libraries in gdc is non existent compared to incomplete, as all of Martin's patches have not been pulled in. And at this rate they never will, so will be forced to fork eventually (what I currently do is more like a spork), but hey I guess that's the point of druntime, no? Each compiler has its own version that is incompatible with the next compiler. No one cares about ABI compatibility anyway... *grin* Reasons I won't be going down the route of dmd's implementation is because. - Relies on some undocumented implementation detail of how symbols are written to object file by the compiler. - Not sure if possible to express the same in gdc; bearing in mind we emit assembly, not object code. - Though I can't be sure because I don't know what it is actually doing other than creating some custom bracketed segment (Really??? Is this truly necessary? That's about as useful as having a separate calling convention just for one language. Oh wait!!!) However, see point one on why there is uncertainty surrounding this. Not following dmd's way of doing things is nothing new however... Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 29 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-29 12:25, Iain Buclaw wrote:

 - Though I can't be sure because I don't know what it is actually doing
 other than creating some custom bracketed segment (Really??? Is this
 truly necessary? That's about as useful as having a separate calling
 convention just for one language.  Oh wait!!!)  However, see point one
 on why there is uncertainty surrounding this.
How is exception handling tables, module infos, GC range and TLS data handled now in GDC? I guess we should change druntime to use "dl_iterate_phdr" on Linux and FreeBSD instead of these bracketed segments. Or is there some better way? Mac OS X already uses "getsectbynamefromheader" and similar functions to avoid bracketed segments. -- /Jacob Carlborg
Sep 29 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 29 September 2013 17:28, Jacob Carlborg <doob me.com> wrote:
 On 2013-09-29 12:25, Iain Buclaw wrote:

 - Though I can't be sure because I don't know what it is actually doing
 other than creating some custom bracketed segment (Really??? Is this
 truly necessary? That's about as useful as having a separate calling
 convention just for one language.  Oh wait!!!)  However, see point one
 on why there is uncertainty surrounding this.
How is exception handling tables, module infos, GC range and TLS data handled now in GDC?
1. GDC uses libunwind for EH. 2. ModuleInfos are put into a linked list - this is for all platforms (which differs from dmd's runtime at last check). There's a .ctor function emitted into the module which attaches itself to _Dmodule_ref. 3. I assume when you say GC range, you mean __data_start / _end? 4. TLS data depends on the platform. Linux has a .tdata and .tbss section that is not bracketed for example... Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 29 2013
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 29/09/13 12:25, Iain Buclaw wrote:
 Not following dmd's way of doing things is nothing new however...
I don't understand why the solution wasn't (or couldn't be) designed from the start to work with all three D compilers. Can anyone offer an explanation?
Sep 29 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-29 19:57, Joseph Rushton Wakeling wrote:

 I don't understand why the solution wasn't (or couldn't be) designed
 from the start to work with all three D compilers.  Can anyone offer an
 explanation?
I think Walter picked an easy solution that he know would work. I don't think he knew about platform specific functions such as "getsectbynamefromheader" and "dl_iterate_phdr". -- /Jacob Carlborg
Sep 29 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 29 September 2013 20:12, Jacob Carlborg <doob me.com> wrote:
 On 2013-09-29 19:57, Joseph Rushton Wakeling wrote:

 I don't understand why the solution wasn't (or couldn't be) designed
 from the start to work with all three D compilers.  Can anyone offer an
 explanation?
I think Walter picked an easy solution that he know would work. I don't think he knew about platform specific functions such as "getsectbynamefromheader" and "dl_iterate_phdr".
I've spoken to Walter about this before, he was quite open about taking a "make it work, then try to make it pretty" approach to things. My biggest pet peeve is probably how dmd treats va_arg a totally inconsistent way across each platform dmd supports. In comparison gdc handles va_arg in one way, and it is identical across each platform supported (and platforms that have not yet gotten support ;) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 29 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 29 September 2013 at 19:24:40 UTC, Iain Buclaw wrote:
 My biggest pet peeve is probably how dmd treats va_arg a
 totally inconsistent way across each platform dmd supports.  In
 comparison gdc handles va_arg in one way, and it is identical 
 across
 each platform supported (and platforms that have not yet gotten
 support ;)
… with the most irritating aspect being that DMD doesn't correctly implement va_copy on x86_64 (at least it didn't last time I checked), yet nobody seems to have noticed so far. This was in fact the reason for me to put fixing the related state of affairs in LDC on the back burner, although I'd highly appreciate if somebody with DMD backend experience would aid in getting this done and over with once and for all. David
Sep 29 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-30 00:07, David Nadlinger wrote:

 … with the most irritating aspect being that DMD doesn't correctly
 implement va_copy on x86_64 (at least it didn't last time I checked),
 yet nobody seems to have noticed so far.
Perhaps it only matter when interfacing with C. Perhaps not that many people actually use varargs at all. I guess most people use variadic templates. They're easier to deal with. -- /Jacob Carlborg
Sep 29 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On Sep 30, 2013 7:30 AM, "Jacob Carlborg" <doob me.com> wrote:
 On 2013-09-30 00:07, David Nadlinger wrote:

 =85 with the most irritating aspect being that DMD doesn't correctly
 implement va_copy on x86_64 (at least it didn't last time I checked),
 yet nobody seems to have noticed so far.
Perhaps it only matter when interfacing with C. Perhaps not that many
people actually use varargs at all. I guess most people use variadic templates. They're easier to deal with.

And they are  safe.  :)

Regards
--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Sep 30 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 29 September 2013 18:57, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On 29/09/13 12:25, Iain Buclaw wrote:
 Not following dmd's way of doing things is nothing new however...
I don't understand why the solution wasn't (or couldn't be) designed from the start to work with all three D compilers. Can anyone offer an explanation?
Many bad things get implemented in dmd without discussion. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 29 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-28 21:37, Dicebot wrote:

 I thought it is a temporary limitation (I am very interested in loading
 D plugins from C/C++ programs). Are there any fundamental issues that
 prevent it?
It's the usual issues, which have been mentioned many times before: * Exception handling tables * TLS data * GC roots * Module infos * Basically anything the runtime needs to collect from the running executable/shared library. I don't know the status of these. -- /Jacob Carlborg
Sep 29 2013
parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 29 September 2013 at 09:23:16 UTC, Jacob Carlborg 
wrote:
 It's the usual issues, which have been mentioned many times 
 before:

 * Exception handling tables
 * TLS data
 * GC roots
 * Module infos
 * Basically anything the runtime needs to collect from the 
 running executable/shared library.

 I don't know the status of these.
Yeah, I am mostly familiar with those but though this is exactly what is ongoing shared lib support is about - to make this possible. Right now on master it does seem to work only for D lib + D app and C lib + D app though :(
Sep 29 2013