Re: Front-end release.NEXT
On Sep 30, 2013 7:30 AM, "Jacob Carlborg" wrote: > > 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. > And they are @safe. :) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
On 29 September 2013 18:57, Joseph Rushton Wakeling 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';
Re: Front-end release.NEXT
On 29 September 2013 20:12, Jacob Carlborg 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';
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
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?
Re: Front-end release.NEXT
On 29 September 2013 17:28, Jacob Carlborg 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';
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
On Sep 29, 2013 10:45 AM, "Dicebot" wrote: > > On Saturday, 28 September 2013 at 20:17:24 UTC, Iain Buclaw wrote: >> >> On 28 September 2013 21:02, Dicebot 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';
Re: Front-end release.NEXT
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 :(
Re: Front-end release.NEXT
On Saturday, 28 September 2013 at 20:17:24 UTC, Iain Buclaw wrote: On 28 September 2013 21:02, Dicebot 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.
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
On 28 September 2013 21:02, Dicebot 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';
Re: Front-end release.NEXT
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.
Re: Front-end release.NEXT
On 28 September 2013 20:37, Dicebot 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';
Re: Front-end release.NEXT
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?
Re: Front-end release.NEXT
On 28 September 2013 18:39, Jacob Carlborg 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';
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
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)
Re: Front-end release.NEXT
On Aug 30, 2013 2:45 PM, "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 > 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';
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
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.
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
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.
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
On 8/30/13, Walter Bright 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!
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
On Fri, Aug 30, 2013 at 09:51:25PM +, 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 ..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!
Re: Front-end release.NEXT
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 ..master --merges --ancestry-path Though that includes subsequent merges; I think you just want the last one.
Re: Front-end release.NEXT
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 -- Кто везде - тот нигде.
Re: Front-end release.NEXT
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.
Re: Front-end release.NEXT
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.
Re: Front-end release.NEXT
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.
Re: Front-end release.NEXT
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.
Re: Front-end release.NEXT
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.
Re: Front-end release.NEXT
On 30 August 2013 20:19, H. S. Teoh 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';
Re: Front-end release.NEXT
On Fri, 30 Aug 2013 06:41:34 -0700, 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 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/
Re: Front-end release.NEXT
On Fri, Aug 30, 2013 at 08:00:35PM +0100, Iain Buclaw wrote: > On Aug 30, 2013 7:34 PM, "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. ;-) > > > > 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 . :) T -- "Life is all a great joke, but only the brave ever get the point." -- Kenneth Rexroth
Re: Front-end release.NEXT
On Aug 30, 2013 7:34 PM, "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. ;-) > 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';
Re: Front-end release.NEXT
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
Re: Front-end release.NEXT
On 30 August 2013 16:08, Dicebot 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';
Re: Front-end release.NEXT
On 30 August 2013 15:48, Dicebot 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';
Re: Front-end release.NEXT
On 30 August 2013 14:56, Dicebot 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';
Re: Front-end release.NEXT
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)
Re: Front-end release.NEXT
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.
Re: Front-end release.NEXT
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.
Front-end release.NEXT
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
