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

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.

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';

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)

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';

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.

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';

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

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';

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/