digitalmars.D - Front-end release.NEXT
- Iain Buclaw (25/25) Aug 30 2013 Morning all,
- Dicebot (9/10) Aug 30 2013 My main concern about upcoming 2.064 is
- Iain Buclaw (5/16) Aug 30 2013 You should create a DIP to start a formal review process for this.
- Dicebot (3/5) Aug 30 2013 You have forgot the part about writing pull request and providing
- Iain Buclaw (11/16) Aug 30 2013 The compiler frontend implementation allowing bogus or conflicting
- Dicebot (9/21) Aug 30 2013 Actually looks like I have missed one release in slumber and it
- Iain Buclaw (8/26) Aug 30 2013 :o)
- H. S. Teoh (17/29) Aug 30 2013 [...]
- Walter Bright (2/28) Aug 30 2013 Thank you. This is great information.
- Walter Bright (3/29) Aug 30 2013 BTW, please add this information to both the regression issues and the i...
- Iain Buclaw (10/36) Aug 30 2013 parameters
- Adam Wilson (14/38) Aug 30 2013 I don't know how much action D is going to be getting next week due to
- H. S. Teoh (16/23) Aug 30 2013 Looks like Andrei is going to be a speaker there as well, so Phobos
- Iain Buclaw (9/17) Aug 30 2013 Hopefully in a year's time, the release process for D and Phobos
- Walter Bright (5/8) Aug 30 2013 The GoingNative is a great conference, and if the past is any guide, the...
- H. S. Teoh (9/48) Aug 30 2013 [...]
- Walter Bright (4/24) Aug 30 2013 I think it's a good idea.
- Jacob Carlborg (5/8) Aug 31 2013 Do you mean loading DLL's completely at runtime, i.e. using dlopen? We
- David Nadlinger (5/7) Aug 31 2013 Yep, see
- Walter Bright (3/10) Aug 31 2013 I mean that from a C or D program, being able to dynamically load and un...
- Jacob Carlborg (4/6) Aug 31 2013 I see.
- H. S. Teoh (6/20) Aug 31 2013 Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be
- Walter Bright (2/4) Aug 31 2013 It certainly can be made to work. Martin Nowak is close to getting it do...
- H. S. Teoh (8/15) Aug 31 2013 Excellent! I presume it will be type-safe and support all the usual D
- Jacob Carlborg (6/10) Sep 01 2013 It looks like it only contains functions for loading and unloading
- David Nadlinger (6/13) Sep 01 2013 Currently, the focus is on just getting the technical
- Andrej Mitrovic (3/5) Aug 31 2013 And if it's (mostly) done, we should put it in the changelog, since
- H. S. Teoh (21/40) Aug 30 2013 And easily obtained with git bisect, about 5-10 minutes per bug. :)
- Justin Whear (6/15) Aug 30 2013 I think you can find the merge which introduced the commit with somethin...
- H. S. Teoh (8/28) Aug 30 2013 Cool, that did the trick! Yeah I just want the last one... but at least
- Iain Buclaw (17/28) Sep 28 2013 implementation. Three years experience and carrying out over 100 merges
- Dicebot (8/12) Sep 28 2013 From my point of view two things that are necessary for making
- Jacob Carlborg (4/10) Sep 28 2013 --
- Iain Buclaw (10/17) Sep 28 2013 I am fine with pushing that feature as an entirely new release (eg.
- Dicebot (7/15) Sep 28 2013 I agree that it at least makes sense to make release branch to
- Iain Buclaw (5/18) Sep 28 2013 In gdc or dmd?
- Dicebot (2/8) Sep 28 2013 Both. g++ / dmd and g++ / gdc.
- Iain Buclaw (8/18) Sep 28 2013 There's no limitations really loading C/C++ libraries into D - don't
- Dicebot (5/26) Sep 29 2013 No, not loading C plugins from D, other way around ;)
- Iain Buclaw (25/53) Sep 29 2013 was rejected to be loaded because of TLS. Was curious if this is
- Jacob Carlborg (9/14) Sep 29 2013 How is exception handling tables, module infos, GC range and TLS data
- Iain Buclaw (13/21) Sep 29 2013 1. GDC uses libunwind for EH.
- Joseph Rushton Wakeling (3/4) Sep 29 2013 I don't understand why the solution wasn't (or couldn't be) designed fro...
- Jacob Carlborg (6/9) Sep 29 2013 I think Walter picked an easy solution that he know would work. I don't
- Iain Buclaw (12/19) Sep 29 2013 I've spoken to Walter about this before, he was quite open about
- David Nadlinger (9/15) Sep 29 2013 … with the most irritating aspect being that DMD doesn't
- Jacob Carlborg (6/9) Sep 29 2013 Perhaps it only matter when interfacing with C. Perhaps not that many
- Iain Buclaw (8/13) Sep 30 2013 people actually use varargs at all. I guess most people use variadic
- Iain Buclaw (6/12) Sep 29 2013 Many bad things get implemented in dmd without discussion.
- Jacob Carlborg (11/14) Sep 29 2013 It's the usual issues, which have been mentioned many times before:
- Dicebot (6/15) Sep 29 2013 Yeah, I am mostly familiar with those but though this is exactly
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
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
On 30 August 2013 14:56, Dicebot <public dicebot.lv> wrote:On Friday, 30 August 2013 at 13:41:35 UTC, Iain Buclaw wrote:You should create a DIP to start a formal review process for this. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';...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
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
On 30 August 2013 15:48, Dicebot <public dicebot.lv> wrote:On Friday, 30 August 2013 at 14:43:12 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? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';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
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
On 30 August 2013 16:08, Dicebot <public dicebot.lv> wrote:On Friday, 30 August 2013 at 15:00:51 UTC, Iain Buclaw wrote::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';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
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
On 8/30/2013 11:32 AM, H. S. Teoh wrote:On Fri, Aug 30, 2013 at 03:41:34PM +0200, Iain Buclaw wrote: [...]Thank you. This is great information.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. ;-)
Aug 30 2013
On 8/30/2013 11:32 AM, H. S. Teoh wrote:On Fri, Aug 30, 2013 at 03:41:34PM +0200, Iain Buclaw wrote: [...]BTW, please add this information to both the regression issues and the issues who's resolution introduced the regression.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. ;-)
Aug 30 2013
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: [...]compile-timeAcross 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 at10401 - 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`parametersI 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
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 IainI 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
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
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: [...]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';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).
Aug 30 2013
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
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:[...] 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 RexrothOn Fri, Aug 30, 2013 at 03:41:34PM +0200, Iain Buclaw wrote: [...]compile-timeAcross 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 at10401 - 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`parametersI 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. :)
Aug 30 2013
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/15pLzVbI 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
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
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
On 8/31/2013 4:24 AM, Jacob Carlborg wrote:On 2013-08-30 21:50, Walter Bright wrote:I mean that from a C or D program, being able to dynamically load and unload DLLs at runtime.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.
Aug 31 2013
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
On Sat, Aug 31, 2013 at 11:10:54AM -0700, Walter Bright wrote:On 8/31/2013 4:24 AM, Jacob Carlborg wrote: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 userOn 2013-08-30 21:50, Walter Bright wrote:I mean that from a C or D program, being able to dynamically load and unload DLLs at runtime.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.
Aug 31 2013
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
On Sat, Aug 31, 2013 at 01:27:09PM -0700, Walter Bright wrote:On 8/31/2013 1:00 PM, 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). T -- The two rules of success: 1. Don't tell everything you know. -- YHLOh, 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
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
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
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
On Fri, Aug 30, 2013 at 12:43:44PM -0700, Walter Bright wrote:On 8/30/2013 11:32 AM, H. S. Teoh wrote:[...]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: [...]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.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
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. :) TI 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
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: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!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. :) TI 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
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-endimplementation. 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 thealpha/beta out the door.Across D/Druntime/Phobos, there are currently 26 open major bugs since28/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/15pLzVbOne 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
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... RegardsFrom 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
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
On 28 September 2013 18:39, Jacob Carlborg <doob me.com> wrote:On 2013-09-28 18:48, Dicebot 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. 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';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.
Sep 28 2013
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
On 28 September 2013 20:37, Dicebot <public dicebot.lv> wrote:On Saturday, 28 September 2013 at 18:32:51 UTC, Iain Buclaw wrote:In gdc or dmd? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';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
On Saturday, 28 September 2013 at 19:53:16 UTC, Iain Buclaw wrote:Both. g++ / dmd and g++ / gdc.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?
Sep 28 2013
On 28 September 2013 21:02, Dicebot <public dicebot.lv> wrote:On Saturday, 28 September 2013 at 19:53:16 UTC, Iain Buclaw wrote: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';Both. g++ / dmd and g++ / gdc.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?
Sep 28 2013
On Saturday, 28 September 2013 at 20:17:24 UTC, Iain Buclaw wrote:On 28 September 2013 21:02, Dicebot <public dicebot.lv> wrote: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.On Saturday, 28 September 2013 at 19:53:16 UTC, Iain Buclaw wrote: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). ;-)Both. g++ / dmd and g++ / gdc.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?
Sep 29 2013
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:loading DOn 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 inwas 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';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 libraryThere'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). ;-)Both. g++ / dmd and g++ / gdc.plugins from C/C++ programs). Are there any fundamental issues that prevent it?In gdc or dmd?
Sep 29 2013
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
On 29 September 2013 17:28, Jacob Carlborg <doob me.com> wrote:On 2013-09-29 12:25, Iain Buclaw wrote: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';- 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?
Sep 29 2013
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
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
On 29 September 2013 20:12, Jacob Carlborg <doob me.com> wrote:On 2013-09-29 19:57, Joseph Rushton Wakeling wrote: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';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".
Sep 29 2013
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
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
On Sep 30, 2013 7:30 AM, "Jacob Carlborg" <doob me.com> wrote:On 2013-09-30 00:07, David Nadlinger wrote:people actually use varargs at all. I guess most people use variadic templates. They're easier to deal with.=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 manyAnd they are safe. :) Regards --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Sep 30 2013
On 29 September 2013 18:57, Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:On 29/09/13 12:25, Iain Buclaw wrote:Many bad things get implemented in dmd without discussion. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';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
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
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