On 9 December 2011 08:56, Jacob Carlborg <doob at me.com> wrote:
>
>
> On 09 Dec, 2011,at 08:48 AM, Walter Bright <walter at digitalmars.com> wrote:
>
>
>
> On 12/8/2011 11:43 PM, Andrej Mitrovic wrote:
>> Well yeah, it's the classic synchronized(WalterMutex) condition..
>>
>
> If you have a suggestion for speeding up the beta process, I'd like to hear it.
>
>
> Yes, create a public beta branch. When you think it's time to put out a new release, branch out to the beta branch. Only fixes for regressions (or what you/someone decides) is allowed in the beta branch. Everyone else can continue to work on the main branch, nothing gets stalled.

A minor downside of that, is it would mean that releases aren't made from the main branch. Which might make things like bisecting a bit messier.

One of the challenges is that we want to run all the tests on the
development branch, as well as on the release branch.
OTOH if we had a dedicated release branch, that was only ever used for
pushing release candidates, it could run a different set of tests. For
example, it could check that all of Diemos compiles, and also a set of
"blessed" projects, eg SciD. That would be a major step to a more
structured release process.

On 9 December 2011 04:39, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> Still fails my latest mentioned regression:
>
> inout(int[]) foo(inout(int)[] x)
> {
> ??? return x;
> }
>
>
> Error: cannot implicitly convert expression (x) of type inout(int)[] to inout(int[])
>
>
> Given that inout is relatively new to the implementation, I'm not sure how much existing code this breaks.? It certainly breaks dcollections, but I can just instruct people not to use 2.057, and I haven't done a beta release of it since I added the inout decorations.

Do we need to also fix Phobos regression 7070 "can't assign null to Variant" ? It's the only bugzilla regression relative to 2.056.

Sorry, I cannot fix the regressions correctly in short. Because it is bigger than I've thought.Sadly, I think we should revert changes for 6912 to erase regressions.This way reopens 6912.

Kenji Hara
2011/12/9 Steve Schveighoffer <schveiguy at yahoo.com>:
> Still fails my latest mentioned regression:
>
> inout(int[]) foo(inout(int)[] x)
> {
> ??? return x;
> }
>
>
> Error: cannot implicitly convert expression (x) of type inout(int)[] to inout(int[])
>
>
> Given that inout is relatively new to the implementation, I'm not sure how much existing code this breaks.? It certainly breaks dcollections, but I can just instruct people not to use 2.057, and I haven't done a beta release of it since I added the inout decorations.
>
> So it might not be horrible if this goes out.? There is a valid workaround (use a blunt cast).
>
> Again, sorry for the last-minute testing.? I've been busy with work lately.
>
> -Steve
>
>
>
> ----- Original Message -----
>> From: Walter Bright <walter at digitalmars.com>
>> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
>> Cc:
>> Sent: Thursday, December 8, 2011 9:47 PM
>> Subject: [dmd-beta] Last (really, this time I mean it!) D2 beta 2.057
>>
>> Includes Kenji's fix (thanks for the super quick response!)
>>
>> http://ftp.digitalmars.com/dmd2beta.zip
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

Posted... https://github.com/D-Programming-Language/dmd/pull/551

Kenji Hara

2011/12/9 kenji hara <k.hara.pg at gmail.com>:
> Sorry, I cannot fix the regressions correctly in short. Because it is bigger than I've thought.Sadly, I think we should revert changes for 6912 to erase regressions.This way reopens 6912.
>
> Kenji Hara
> 2011/12/9 Steve Schveighoffer <schveiguy at yahoo.com>:
>> Still fails my latest mentioned regression:
>>
>> inout(int[]) foo(inout(int)[] x)
>> {
>> ??? return x;
>> }
>>
>>
>> Error: cannot implicitly convert expression (x) of type inout(int)[] to inout(int[])
>>
>>
>> Given that inout is relatively new to the implementation, I'm not sure how much existing code this breaks.? It certainly breaks dcollections, but I can just instruct people not to use 2.057, and I haven't done a beta release of it since I added the inout decorations.
>>
>> So it might not be horrible if this goes out.? There is a valid workaround (use a blunt cast).
>>
>> Again, sorry for the last-minute testing.? I've been busy with work lately.
>>
>> -Steve
>>
>>
>>
>> ----- Original Message -----
>>> From: Walter Bright <walter at digitalmars.com>
>>> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
>>> Cc:
>>> Sent: Thursday, December 8, 2011 9:47 PM
>>> Subject: [dmd-beta] Last (really, this time I mean it!) D2 beta 2.057
>>>
>>> Includes Kenji's fix (thanks for the super quick response!)
>>>
>>> http://ftp.digitalmars.com/dmd2beta.zip
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta

The special handling of arrays always trip me up. It's strange that immutable(int)[] can initialize immutable(int[]). What's even more bizarre is that immutable(int[]) can be assigned to immutable(int)[]

Am I unique in the momentary confusion this causes? I think this property is unique to arrays. Can "alias this" cause a similar effect in other types?

Sent from my iPhone

On Dec 8, 2011, at 11:50 PM, Walter Bright <walter at digitalmars.com> wrote:

> In any case, there needs to be a bugzilla entry for it.
> 
> On 12/8/2011 7:39 PM, Steve Schveighoffer wrote:
>> Still fails my latest mentioned regression:
>> 
>> inout(int[]) foo(inout(int)[] x)
>> {
>>     return x;
>> }
>> 
>> 
>> Error: cannot implicitly convert expression (x) of type inout(int)[] to inout(int[])
>> 
>> 
>> Given that inout is relatively new to the implementation, I'm not sure how much existing code this breaks.  It certainly breaks dcollections, but I can just instruct people not to use 2.057, and I haven't done a beta release of it since I added the inout decorations.
>> 
>> So it might not be horrible if this goes out.  There is a valid workaround (use a blunt cast).
>> 
>> Again, sorry for the last-minute testing.  I've been busy with work lately.
>> 
>> -Steve
>> 
>> 
>> 
>> ----- Original Message -----
>>> From: Walter Bright<walter at digitalmars.com>
>>> To: Discuss the dmd beta releases for D<dmd-beta at puremagic.com>
>>> Cc:
>>> Sent: Thursday, December 8, 2011 9:47 PM
>>> Subject: [dmd-beta] Last (really, this time I mean it!) D2 beta 2.057
>>> 
>>> Includes Kenji's fix (thanks for the super quick response!)
>>> 
>>> http://ftp.digitalmars.com/dmd2beta.zip
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>> 
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>> 
>> 
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

No, the issue is simply that the value type part of a slice (i.e. the length and the head-immutability of the pointer) can implicitly cast to and from immutable.? This is the same as casting an immutable(int)* and a size_t to immutable(int *) and immutable(size_t) respectively.


As far as the regression, I'll test momentarily Kenji's pull request that reverses the fix for 6912 against dcollections, and if everything builds and tests properly, I'd say just reverse that for the release, put it back in, and then fix the regression in the main branch for the next cycle.

If that's agreeable, I'll file a bug.? One question, is it good to file quick-fix bugs for historical purposes?? I mean I just discovered the bug, it's not in a released version yet, and it may be fixed or nullified momentarily.


-Steve



----- Original Message -----
> From: Jason House <jason.james.house at gmail.com>
> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> Cc:
> Sent: Friday, December 9, 2011 9:08 AM
> Subject: Re: [dmd-beta] Last (really, this time I mean it!) D2 beta 2.057
> 
>T he special handling of arrays always trip me up. It's strange that
> immutable(int)[] can initialize immutable(int[]). What's even more bizarre is that immutable(int[]) can be assigned to immutable(int)[]
> 
> Am I unique in the momentary confusion this causes? I think this property is unique to arrays. Can "alias this" cause a similar effect in other types?
> 
> Sent from my iPhone
> 
> On Dec 8, 2011, at 11:50 PM, Walter Bright <walter at digitalmars.com> wrote:
> 
>>  In any case, there needs to be a bugzilla entry for it.
>> 
>>  On 12/8/2011 7:39 PM, Steve Schveighoffer wrote:
>>>  Still fails my latest mentioned regression:
>>> 
>>>  inout(int[]) foo(inout(int)[] x)
>>>  {
>>> ? ?  return x;
>>>  }
>>> 
>>> 
>>>  Error: cannot implicitly convert expression (x) of type inout(int)[] to
> inout(int[])
>>> 
>>> 
>>>  Given that inout is relatively new to the implementation, I'm not
> sure how much existing code this breaks.? It certainly breaks dcollections, but I can just instruct people not to use 2.057, and I haven't done a beta release of it since I added the inout decorations.
>>> 
>>>  So it might not be horrible if this goes out.? There is a valid
> workaround (use a blunt cast).
>>> 
>>>  Again, sorry for the last-minute testing.? I've been busy with work
> lately.
>>> 
>>>  -Steve
>>> 
>>> 
>>> 
>>>  ----- Original Message -----
>>>>  From: Walter Bright<walter at digitalmars.com>
>>>>  To: Discuss the dmd beta releases for
> D<dmd-beta at puremagic.com>
>>>>  Cc:
>>>>  Sent: Thursday, December 8, 2011 9:47 PM
>>>>  Subject: [dmd-beta] Last (really, this time I mean it!) D2 beta
> 2.057
>>>> 
>>>>  Includes Kenji's fix (thanks for the super quick response!)
>>>> 
>>>>  http://ftp.digitalmars.com/dmd2beta.zip
>>>>  _______________________________________________
>>>>  dmd-beta mailing list
>>>>  dmd-beta at puremagic.com
>>>>  http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>> 
>>>  _______________________________________________
>>>  dmd-beta mailing list
>>>  dmd-beta at puremagic.com
>>>  http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>> 
>>> 
>>  _______________________________________________
>>  dmd-beta mailing list
>>  dmd-beta at puremagic.com
>>  http://lists.puremagic.com/mailman/listinfo/dmd-beta
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> 

On 09 Dec, 2011,at 09:41 AM, Walter Bright <walter at digitalmars.com> wrote:

>
>
> On 12/8/2011 11:56 PM, Jacob Carlborg wrote:
> >
> >
> > On 09 Dec, 2011,at 08:48 AM, Walter Bright <walter at digitalmars.com> wrote:
> >
> >>
> >>
> >> On 12/8/2011 11:43 PM, Andrej Mitrovic wrote:
> >> > Well yeah, it's the classic synchronized(WalterMutex) condition..
> >> >
> >>
> >> If you have a suggestion for speeding up the beta process, I'd like to hear it.
> >
> > Yes, create a public beta branch. When you think it's time to put out a new release, branch out to the beta branch. Only fixes for regressions (or what you/someone decides) is allowed in the beta branch. Everyone else can continue to work on the main branch, nothing gets stalled.
>
> Anyone can fork and still create pull requests.

Then what's the rush in getting the release out even if there are known regressions?

?
/Jacob Carlborg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20111209/61ea8659/attachment.html>

On Dec 9, 2011, at 3:57 AM, Don Clugston <dclugston at googlemail.com> wrote:

> On 9 December 2011 08:56, Jacob Carlborg <doob at me.com> wrote:
>> 
>> 
>> 
>> Yes, create a public beta branch. When you think it's time to put out a new release, branch out to the beta branch. Only fixes for regressions (or what you/someone decides) is allowed in the beta branch. Everyone else can continue to work on the main branch, nothing gets stalled.
> 
> A minor downside of that, is it would mean that releases aren't made from the main branch. Which might make things like bisecting a bit messier.

It really should not be that bad. It is good practice to apply patches in the release branch to the main branch as well. Even if that is not done for the "one fix per day", one merge after a release will at least allow you to discover it was one of the release candidate patches and you can do a second bisect if required.

Just tested the latest master git branch (I saw that you made some changes Walter), and dcollections compiles and passes unit tests.

And it seems like 6912 fix is still intact (code in that bug fails to compile).? So I think we're good as far as this issue is concerned.

-Steve



----- Original Message -----
> From: Steve Schveighoffer <schveiguy at yahoo.com>
> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> Cc:
> Sent: Friday, December 9, 2011 9:21 AM
> Subject: Re: [dmd-beta] Last (really, this time I mean it!) D2 beta 2.057
> 
> No, the issue is simply that the value type part of a slice (i.e. the length and the head-immutability of the pointer) can implicitly cast to and from immutable.? This is the same as casting an immutable(int)* and a size_t to immutable(int *) and immutable(size_t) respectively.
> 
> 
> As far as the regression, I'll test momentarily Kenji's pull request that reverses the fix for 6912 against dcollections, and if everything builds and tests properly, I'd say just reverse that for the release, put it back in, and then fix the regression in the main branch for the next cycle.
> 
> If that's agreeable, I'll file a bug.? One question, is it good to file quick-fix bugs for historical purposes?? I mean I just discovered the bug, it's not in a released version yet, and it may be fixed or nullified momentarily.
> 
> 
> -Steve
> 
> 
> 
> ----- Original Message -----
>>  From: Jason House <jason.james.house at gmail.com>
>>  To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
>>  Cc:
>>  Sent: Friday, December 9, 2011 9:08 AM
>>  Subject: Re: [dmd-beta] Last (really, this time I mean it!) D2 beta 2.057
>> 
>> T he special handling of arrays always trip me up. It's strange that
>>  immutable(int)[] can initialize immutable(int[]). What's even more
> bizarre
>>  is that immutable(int[]) can be assigned to immutable(int)[]
>> 
>>  Am I unique in the momentary confusion this causes? I think this property
> is
>>  unique to arrays. Can "alias this" cause a similar effect in
> other
>>  types?
>> 
>>  Sent from my iPhone
>> 
>>  On Dec 8, 2011, at 11:50 PM, Walter Bright <walter at digitalmars.com>
> wrote:
>> 
>>> ? In any case, there needs to be a bugzilla entry for it.
>>> 
>>> ? On 12/8/2011 7:39 PM, Steve Schveighoffer wrote:
>>>> ? Still fails my latest mentioned regression:
>>>> 
>>>> ? inout(int[]) foo(inout(int)[] x)
>>>> ? {
>>>>  ? ?? return x;
>>>> ? }
>>>> 
>>>> 
>>>> ? Error: cannot implicitly convert expression (x) of type
> inout(int)[] to
>>  inout(int[])
>>>> 
>>>> 
>>>> ? Given that inout is relatively new to the implementation, I'm
> not
>>  sure how much existing code this breaks.? It certainly breaks dcollections,
> but
>>  I can just instruct people not to use 2.057, and I haven't done a beta
>>  release of it since I added the inout decorations.
>>>> 
>>>> ? So it might not be horrible if this goes out.? There is a valid
>>  workaround (use a blunt cast).
>>>> 
>>>> ? Again, sorry for the last-minute testing.? I've been busy with
> work
>>  lately.
>>>> 
>>>> ? -Steve
>>>> 
>>>> 
>>>> 
>>>> ? ----- Original Message -----
>>>>> ? From: Walter Bright<walter at digitalmars.com>
>>>>> ? To: Discuss the dmd beta releases for
>>  D<dmd-beta at puremagic.com>
>>>>> ? Cc:
>>>>> ? Sent: Thursday, December 8, 2011 9:47 PM
>>>>> ? Subject: [dmd-beta] Last (really, this time I mean it!) D2
> beta
>>  2.057
>>>>> 
>>>>> ? Includes Kenji's fix (thanks for the super quick
> response!)
>>>>> 
>>>>> ? http://ftp.digitalmars.com/dmd2beta.zip
>>>>> ? _______________________________________________
>>>>> ? dmd-beta mailing list
>>>>> ? dmd-beta at puremagic.com
>>>>> ? http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>>> 
>>>> ? _______________________________________________
>>>> ? dmd-beta mailing list
>>>> ? dmd-beta at puremagic.com
>>>> ? http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>> 
>>>> 
>>> ? _______________________________________________
>>> ? dmd-beta mailing list
>>> ? dmd-beta at puremagic.com
>>> ? http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>  _______________________________________________
>>  dmd-beta mailing list
>>  dmd-beta at puremagic.com
>>  http://lists.puremagic.com/mailman/listinfo/dmd-beta
>> 
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> 

This *has* to be a solved problem with git, some google research is in order.? I'm thinking there should be some way to construct a branch that places the beta fixes before the development changes.? I know with something like svn, branches should be discarded once you merge them back to their source, but is git the same way?

I agree we should find a better way to avoid gumming up the development cycle with a beta cycle.


-Steve



----- Original Message -----
> From: Jason House <jason.james.house at gmail.com>
> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> Cc:
> Sent: Friday, December 9, 2011 9:36 AM
> Subject: Re: [dmd-beta] Last (really, this time I mean it!) D2 beta 2.057
> 
> On Dec 9, 2011, at 3:57 AM, Don Clugston <dclugston at googlemail.com> wrote:
> 
>>  On 9 December 2011 08:56, Jacob Carlborg <doob at me.com> wrote:
>>> 
>>> 
>>> 
>>>  Yes, create a public beta branch. When you think it's time to put
> out a new
>>>  release, branch out to the beta branch. Only fixes for regressions (or
> what
>>>  you/someone decides) is allowed in the beta branch. Everyone else can
>>>  continue to work on the main branch, nothing gets stalled.
>> 
>>  A minor downside of that, is it would mean that releases aren't made
>>  from the main branch. Which might make things like bisecting a bit
>>  messier.
> 
> It really should not be that bad. It is good practice to apply patches in the
> release branch to the main branch as well. Even if that is not done for the
> "one fix per day", one merge after a release will at least allow you
> to discover it was one of the release candidate patches and you can do a second
> bisect if required.
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>