www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Getting ready for 2.061

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
We plan to start building a new release on Sunday evening. To do so 
(pursuant to the embryonic process we're putting in place), at that time 
we'll create a new branch called "staging" for each of dmd, druntime, 
and phobos.

All contributors - over the weekend please ping reviewers on what you 
believe are pull requests with a high importance*urgency product. Once 
we branch into staging, pull requests will only be merged into master.


Thanks,

Andrei
Dec 21 2012
next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Friday, 21 December 2012 at 22:12:47 UTC, Andrei Alexandrescu 
wrote:

 All contributors - over the weekend please ping reviewers on 
 what you believe are pull requests with a high 
 importance*urgency product.



I think it is urgent in the earlier thread 
(http://forum.dlang.org/post/srzxakcwamzzzvqctluz forum.dlang.org), 
but I think the issue got lost in the wake of the UDA discussion.

David
Dec 21 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, December 21, 2012 17:12:47 Andrei Alexandrescu wrote:

 We plan to start building a new release on Sunday evening. To do so
 (pursuant to the embryonic process we're putting in place), at that time
 we'll create a new branch called "staging" for each of dmd, druntime,
 and phobos.
 
 All contributors - over the weekend please ping reviewers on what you
 believe are pull requests with a high importance*urgency product. Once
 we branch into staging, pull requests will only be merged into master.


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

really should be resolved prior to 2.061, or we're going to be introducing a 
compiler flag (-di) which we're probably then going to turn around and 
deprecate (and making deprecations warn by default instead of giving you an 
error will be  _huge_ step forward in our ability to manage deprecations 
without breaking people's code).

- Jonathan M Davis
Dec 21 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 22-12-2012 06:11, Jonathan M Davis wrote:

 On Friday, December 21, 2012 17:12:47 Andrei Alexandrescu wrote:

 We plan to start building a new release on Sunday evening. To do so
 (pursuant to the embryonic process we're putting in place), at that time
 we'll create a new branch called "staging" for each of dmd, druntime,
 and phobos.

 All contributors - over the weekend please ping reviewers on what you
 believe are pull requests with a high importance*urgency product. Once
 we branch into staging, pull requests will only be merged into master.


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

 really should be resolved prior to 2.061, or we're going to be introducing a
 compiler flag (-di) which we're probably then going to turn around and
 deprecate (and making deprecations warn by default instead of giving you an
 error will be  _huge_ step forward in our ability to manage deprecations
 without breaking people's code).

 - Jonathan M Davis


+1 to this.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Dec 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, December 21, 2012 21:11:28 Jonathan M Davis wrote:

 On Friday, December 21, 2012 17:12:47 Andrei Alexandrescu wrote:

 We plan to start building a new release on Sunday evening. To do so
 (pursuant to the embryonic process we're putting in place), at that time
 we'll create a new branch called "staging" for each of dmd, druntime,
 and phobos.
 
 All contributors - over the weekend please ping reviewers on what you
 believe are pull requests with a high importance*urgency product. Once
 we branch into staging, pull requests will only be merged into master.


 
 https://github.com/D-Programming-Language/dmd/pull/1287
 
 really should be resolved prior to 2.061, or we're going to be introducing a
 compiler flag (-di) which we're probably then going to turn around and
 deprecate (and making deprecations warn by default instead of giving you an
 error will be  _huge_ step forward in our ability to manage deprecations
 without breaking people's code).


LOL. David was talking about the thing in his reply. I read it too quickly and 
thought that he was talking about the warning for the change in UDA syntax. In 
any case, I obviously agree with him. This issue needs to be resolved prior to 
the nex release.

- Jonathan M Davis
Dec 21 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
There are still 7 reported regressions unfinished according to=20

http://d.puremagic.com/issues/buglist.cgi?y_axis_field=3Dbug_severity&query=
_format=3Dreport-table&product=3DD&bug_status=3DNEW&bug_status=3DASSIGNED&b=
ug_status=3DREOPENED&bug_severity=3Dregression

and if 8774 is not fixed then DMD 2.061 will be as useless for me as
2.060. On the other hand I am a small user in a big pond so my needs
should probably be qualified as not very important.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, December 22, 2012 08:42:05 Russel Winder wrote:

 There are still 7 reported regressions unfinished according to
 
 http://d.puremagic.com/issues/buglist.cgi?y_axis_field=bug_severity&query_fo
 rmat=report-table&product=D&bug_status=NEW&bug_status=ASSIGNED&bug_status=RE
 OPENED&bug_severity=regression
 
 and if 8774 is not fixed then DMD 2.061 will be as useless for me as
 2.060. On the other hand I am a small user in a big pond so my needs
 should probably be qualified as not very important.


It sounds like no one even has a clue which project the bug is in. It's 
clearly a major problem, but unless someone can figure out what's wrong, it's 
obviously not going to be fixed.

- Jonathan M Davis
Dec 22 2012
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Sat, 2012-12-22 at 01:10 -0800, Jonathan M Davis wrote:
[=E2=80=A6]

 It sounds like no one even has a clue which project the bug is in. It's=


=20

 clearly a major problem, but unless someone can figure out what's wrong, =


it's=20

 obviously not going to be fixed.


Someone analysed this for a couple of days after the report was put in
and came up with some hypotheses, I guess the record is in the mail list
archive. There was another flurry of activity when I raised whether this
was going to be fixed a few weeks later, and Walter said put in a bug
report, but I already had. End of activity. Which is a bit strange for
such a serious regression.

LDC works fine so I just don't use DMD. Simple workaround :-)

And as I say if my example is the only one in the world that exhibits
the regression then the problem can be qualified out.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 22 2012
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 22.12.2012 11:31, schrieb Russel Winder:

 On Sat, 2012-12-22 at 01:10 -0800, Jonathan M Davis wrote:
 […]

 It sounds like no one even has a clue which project the bug is in. It's
 clearly a major problem, but unless someone can figure out what's wrong, it's
 obviously not going to be fixed.


 Someone analysed this for a couple of days after the report was put in
 and came up with some hypotheses, I guess the record is in the mail list
 archive. There was another flurry of activity when I raised whether this
 was going to be fixed a few weeks later, and Walter said put in a bug
 report, but I already had. End of activity. Which is a bit strange for
 such a serious regression.

 LDC works fine so I just don't use DMD. Simple workaround :-)


so first you need to update your bug-report - you stated that ldc is 
also not working  - thats a bug in you bug report :)
Dec 22 2012
parent reply Russel Winder <russel winder.org.uk> writes:
On Sat, 2012-12-22 at 11:36 +0100, dennis luehring wrote:
[=E2=80=A6]

 so first you need to update your bug-report - you stated that ldc is=20
 also not working  - thats a bug in you bug report :)


It turns out to be more complicated than that. There isn't a bug in the
bug report: LDC does work where DMD does not (hence my earlier email
comment), but LDC doesn't work in some cases where DMD doesn't (hence
the comment in the bug report remains correct). Interesting (or not)
side observation: LDC generally creates faster executables than DMD,
except in one or two cases that I have.

After New Year/Hogmanay, or earlier if possible, I will reinvestigate
all the factors and update the issue appropriately.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 22 2012
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 22.12.2012 13:15, schrieb Russel Winder:

 After New Year/Hogmanay, or earlier if possible, I will reinvestigate
 all the factors and update the issue appropriately.


sound for me like an bug in the dmd code generation - ldc frontend code 
should be nearly the same (or better: i don't think that the ldc guys 
fix silently frontend bugs), backend is totaly different, phobos should 
be also the same
Dec 22 2012
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 22 December 2012 at 12:15:38 UTC, Russel Winder 
wrote:

 Interesting (or not)
 side observation: LDC generally creates faster executables than 
 DMD,
 except in one or two cases that I have.


If you ever have time to do some quick profiling, could you 
please try to figure out why the LDC-generated executable is 
slower – or if the code you are working on is open source, put 
some instructions together on how to run the benchmark(s)? The 
LLVM backend really shouldn't produce slower code than DMD in 
just about any situation, so most likely we are doing something 
stupid in LDC.

I'm really interested in this, because apart from target platform 
support (druntime/ARM is still not there yet, though) and some 
very few DMD-specific bugs such as the one you seem to hit, there 
is little reason to use LDC other than for the its code 
generation.

Oh, and if you get around to doing this before the next LDC 
release, could you please try it on a Git master build, and if 
you are on a 32 bit system, ideally use LLVM 3.2+? We had to 
disable optimizations on earlier LLVM versions for x86 builds of 
druntime due to a LLVM codegen bug only fixed in 3.2, and the 
GC-to-stack-promotion pass now activated in master should catch a 
few cases where we do stupid things like allocating array 
manifest constants on every entry into function, even if they 
were only used for meta-programming.

There is still a single known issue which can drastically affect 
GC performance, though: 
https://github.com/ldc-developers/ldc/issues/233. There is an 
easy fix, but it completely breaks shared libraries (but given 
that those don't work reliably anyway, I think I'll just go with 
it for the time being…)

David
Dec 22 2012
parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2012-12-22 at 17:41 +0100, David Nadlinger wrote:
[=E2=80=A6]

 If you ever have time to do some quick profiling, could you=20
 please try to figure out why the LDC-generated executable is=20
 slower =E2=80=93 or if the code you are working on is open source, put=


=20

 some instructions together on how to run the benchmark(s)? The=20
 LLVM backend really shouldn't produce slower code than DMD in=20
 just about any situation, so most likely we are doing something=20
 stupid in LDC.


Can you point me at tools and documentation for profiling that generates
the data that would be useful to you. I am very much an LLVM n00b.  I
just compile and use LDC and compile and install LLVMPy, so all of LLVM
is under the covers for me.

The codes are all published on GitHub
https://github.com/russel/Pi_Quadrature this is an embarrasingly
parallel summation problem, approximating  =CF=80 by quadrature. This is th=
e
example David used for one of the std.parallelism examples. The codes
use SCons for compile and execution. So to compile and run pi_d_spawn.d:

	scons run_pi_d_spawn

Though you will want to use my "D tools fork" of SCons which is a
Mercurial repository at BitBucket
https://bitbucket.org/russel/scons_d_tooling No need to install SCons
can be executed from the clone by:

	python /path/to/scons-clone/bootstrap.py run_pi_d_spawn


 I'm really interested in this, because apart from target platform=20
 support (druntime/ARM is still not there yet, though) and some=20
 very few DMD-specific bugs such as the one you seem to hit, there=20
 is little reason to use LDC other than for the its code=20
 generation.


The pattern of when DMD beats LDC on my machines is weird.  However,
this is all currently just anecdotal evidence, I have not done a proper
experiment that can give any statistical significance to the claims
made.

LDC generally beats DMD by about 2%=E2=80=934%, but in some cases by
extraordinary amounts, but I think this shows failures in DMD rather
than success of LDC since the LDC time is about what it should be.

The case where I thought DMD was beating LDC may be a misobservation
(i.e. statistics needed) and that it is just that DMD is performing
unusually as well as LDC. This is the pi_d_spawn.d code.

pi_d_threadsGlobalState_array_declarative causes both DMD and LDC to
barf, with the same problem I think.

pi_d_threadsGlobalState_array_iterative.d LDC works and DMD barfs.

pi_d_threadsGlobalState_threadGroup.d DMD behaves weirdly, LDC gets
things right.

This first one of this trio is the 2.059 =E2=86=92 2.060 regression reporte=
d if
I remember correctly. Ithought I had reported this last one as well
since I am fairly sure 2.059 did not behave as 2.060 does.


 Oh, and if you get around to doing this before the next LDC=20
 release, could you please try it on a Git master build, and if=20
 you are on a 32 bit system, ideally use LLVM 3.2+? We had to=20
 disable optimizations on earlier LLVM versions for x86 builds of=20
 druntime due to a LLVM codegen bug only fixed in 3.2, and the=20
 GC-to-stack-promotion pass now activated in master should catch a=20
 few cases where we do stupid things like allocating array=20
 manifest constants on every entry into function, even if they=20
 were only used for meta-programming.


I only ever use Git master, at least until Debian package a useful
version of LDC, then I'll have to make a decision.

I am usually 64-bit Linux, I can also do 64-bit OS X. Windows exists
only in a plane of the multiverse that I never frequent. :-)


 There is still a single known issue which can drastically affect=20
 GC performance, though:=20
 https://github.com/ldc-developers/ldc/issues/233. There is an=20
 easy fix, but it completely breaks shared libraries (but given=20
 that those don't work reliably anyway, I think I'll just go with=20
 it for the time being=E2=80=A6)


:-)



--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 22 2012
prev sibling next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 21 December 2012 at 22:12:47 UTC, Andrei Alexandrescu 
wrote:

 We plan to start building a new release on Sunday evening. To 
 do so (pursuant to the embryonic process we're putting in 
 place), at that time we'll create a new branch called "staging" 
 for each of dmd, druntime, and phobos.

 All contributors - over the weekend please ping reviewers on 
 what you believe are pull requests with a high 
 importance*urgency product. Once we branch into staging, pull 
 requests will only be merged into master.


 Thanks,

 Andrei


Is this the release for 2.061 which is being placed in staging?

Pull requests which fix regressions and bugs should go into 
staging and be made against staging.
Dec 22 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/22/12 1:39 PM, Jesse Phillips wrote:

 On Friday, 21 December 2012 at 22:12:47 UTC, Andrei Alexandrescu wrote:

 We plan to start building a new release on Sunday evening. To do so
 (pursuant to the embryonic process we're putting in place), at that
 time we'll create a new branch called "staging" for each of dmd,
 druntime, and phobos.

 All contributors - over the weekend please ping reviewers on what you
 believe are pull requests with a high importance*urgency product. Once
 we branch into staging, pull requests will only be merged into master.


 Thanks,

 Andrei


 Is this the release for 2.061 which is being placed in staging?

 Pull requests which fix regressions and bugs should go into staging and
 be made against staging.


That is my understanding too.

Andrei
Dec 22 2012
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 12/22/2012 10:39 AM, Jesse Phillips wrote:

 On Friday, 21 December 2012 at 22:12:47 UTC, Andrei Alexandrescu wrote:

 We plan to start building a new release on Sunday evening. To do so (pursuant
to the embryonic process we're putting
 in place), at that time we'll create a new branch called "staging" for each of
dmd, druntime, and phobos.

 All contributors - over the weekend please ping reviewers on what you believe
are pull requests with a high
 importance*urgency product. Once we branch into staging, pull requests will
only be merged into master.


 Thanks,

 Andrei


 
 Is this the release for 2.061 which is being placed in staging?
 
 Pull requests which fix regressions and bugs should go into staging and be
made against staging.


I strongly recommend requiring that all bugs be first fixed in the development
branch and then being pushed backwards
through the version history.  Quite a few projects follow this pattern based on
the requirement that no fix can ever be
accidentally left out of a future release.  You never want someone to pick up
(using made up version numbers) 3.4.2 to
get a fix and later upgrade to 4.1.1 and find out it's not yet fixed in that
release.
Dec 22 2012
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Saturday, 22 December 2012 at 21:48:51 UTC, Brad Roberts wrote:


 I strongly recommend requiring that all bugs be first fixed in 
 the development branch and then being pushed backwards
 through the version history.  Quite a few projects follow this 
 pattern based on the requirement that no fix can ever be
 accidentally left out of a future release.  You never want 
 someone to pick up (using made up version numbers) 3.4.2 to
 get a fix and later upgrade to 4.1.1 and find out it's not yet 
 fixed in that release.


Well, to have the easy merging the change must be made against 
the oldest applicable code. The benefit of merging into staging 
first is that staging can be merged into master, while master can 
not be merged into staging.

What is nice about making a pull request against staging is that 
the reviewer knows that the fix can be applied that far (not that 
comments wouldn't do the same).
Dec 22 2012
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 12/22/2012 3:44 PM, Jesse Phillips wrote:

 On Saturday, 22 December 2012 at 21:48:51 UTC, Brad Roberts wrote:
 

 I strongly recommend requiring that all bugs be first fixed in the development
branch and then being pushed backwards
 through the version history.  Quite a few projects follow this pattern based
on the requirement that no fix can ever be
 accidentally left out of a future release.  You never want someone to pick up
(using made up version numbers) 3.4.2 to
 get a fix and later upgrade to 4.1.1 and find out it's not yet fixed in that
release.


 
 Well, to have the easy merging the change must be made against the oldest
applicable code. The benefit of merging into
 staging first is that staging can be merged into master, while master can not
be merged into staging.
 
 What is nice about making a pull request against staging is that the reviewer
knows that the fix can be applied that far
 (not that comments wouldn't do the same).


I don't believe those assertions to be true.  Merging in either direction is
possible and the difficulty lies in the
nature of the drift between the two.  Neither direction is necessarily any
easier than the other.
Dec 22 2012
parent Leandro Lucarella <luca llucax.com.ar> writes:
Brad Roberts, el 22 de December a las 17:36 me escribiste:

 On 12/22/2012 3:44 PM, Jesse Phillips wrote:

 On Saturday, 22 December 2012 at 21:48:51 UTC, Brad Roberts wrote:
 

 I strongly recommend requiring that all bugs be first fixed in the development
branch and then being pushed backwards
 through the version history.  Quite a few projects follow this pattern based
on the requirement that no fix can ever be
 accidentally left out of a future release.  You never want someone to pick up
(using made up version numbers) 3.4.2 to
 get a fix and later upgrade to 4.1.1 and find out it's not yet fixed in that
release.


 
 Well, to have the easy merging the change must be made against the oldest
applicable code. The benefit of merging into
 staging first is that staging can be merged into master, while master can not
be merged into staging.
 
 What is nice about making a pull request against staging is that the reviewer
knows that the fix can be applied that far
 (not that comments wouldn't do the same).


 
 I don't believe those assertions to be true.  Merging in either direction is
possible and the difficulty lies in the
 nature of the drift between the two.  Neither direction is necessarily any
easier than the other.


And cherry-picking is your friend. You don't really need to merge anything.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
<original> [Penis Uptime: 2days 13hrs 59mins 35secs]
<Yapa> viagra? :)
<original> yea, 20 pills
Dec 23 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, December 22, 2012 17:36:11 Brad Roberts wrote:

 On 12/22/2012 3:44 PM, Jesse Phillips wrote:

 What is nice about making a pull request against staging is that the
 reviewer knows that the fix can be applied that far (not that comments
 wouldn't do the same).


 
 I don't believe those assertions to be true.  Merging in either direction is
 possible and the difficulty lies in the nature of the drift between the
 two.  Neither direction is necessarily any easier than the other.


If you merge from the branch to master, then there's a higher risk of 
forgetting to merge fixes. If you merge from master to the branch, then there's 
a higher risk of putting changes in the branch that you don't want in the 
branch. However, as long as the changes on master aren't too large, you can 
simply cherry-pick the changes from master to the branch (or vice versa) 
without too much trouble. Overall though, I would think that the risk of 
screwing up is higher if commits go to the branch initially rather than 
master.

- Jonathan M Davis
Dec 22 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/22/2012 5:43 PM, Jonathan M Davis wrote:

 On Saturday, December 22, 2012 17:36:11 Brad Roberts wrote:

 On 12/22/2012 3:44 PM, Jesse Phillips wrote:

 What is nice about making a pull request against staging is that the
 reviewer knows that the fix can be applied that far (not that comments
 wouldn't do the same).


 I don't believe those assertions to be true.  Merging in either direction is
 possible and the difficulty lies in the nature of the drift between the
 two.  Neither direction is necessarily any easier than the other.


 If you merge from the branch to master, then there's a higher risk of
 forgetting to merge fixes. If you merge from master to the branch, then there's
 a higher risk of putting changes in the branch that you don't want in the
 branch. However, as long as the changes on master aren't too large, you can
 simply cherry-pick the changes from master to the branch (or vice versa)
 without too much trouble. Overall though, I would think that the risk of
 screwing up is higher if commits go to the branch initially rather than
 master.


It makes more sense to me to put the commits into master, and then cherry pick 
for the branch.
Dec 22 2012
parent reply Don <nospam nospam.com> writes:
On 23.12.2012 03:11, Walter Bright wrote:

 On 12/22/2012 5:43 PM, Jonathan M Davis wrote:

 On Saturday, December 22, 2012 17:36:11 Brad Roberts wrote:

 On 12/22/2012 3:44 PM, Jesse Phillips wrote:

 What is nice about making a pull request against staging is that the
 reviewer knows that the fix can be applied that far (not that comments
 wouldn't do the same).


 I don't believe those assertions to be true.  Merging in either
 direction is
 possible and the difficulty lies in the nature of the drift between the
 two.  Neither direction is necessarily any easier than the other.


 If you merge from the branch to master, then there's a higher risk of
 forgetting to merge fixes. If you merge from master to the branch,
 then there's
 a higher risk of putting changes in the branch that you don't want in the
 branch. However, as long as the changes on master aren't too large,
 you can
 simply cherry-pick the changes from master to the branch (or vice versa)
 without too much trouble. Overall though, I would think that the risk of
 screwing up is higher if commits go to the branch initially rather than
 master.


 It makes more sense to me to put the commits into master, and then
 cherry pick for the branch.


IMHO, the big issue is, and has always been, what does the autotester test?
It makes most sense to me to have all new fixes for _anything_ going 
into the development branch, and tests on the release branch to exist 
solely for regression testing "just in case".
It makes no sense to me to have pull testing against multiple branches.
Dec 23 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 23, 2012 20:06:38 Don wrote:

 IMHO, the big issue is, and has always been, what does the autotester test?
 It makes most sense to me to have all new fixes for _anything_ going
 into the development branch, and tests on the release branch to exist
 solely for regression testing "just in case".
 It makes no sense to me to have pull testing against multiple branches.


That makes it make all the more sense to merge into master first, though it 
means that staging never gets tested in all of the various environments, which 
could be a problem if commits that are in master aren't supposed to be merged 
into staging but actually (unknowingly) fix the build somehow. There's no way 
to fix that without actually running the autotester or staging as well as 
master though. No matter how you do the branching, if you're not releasing 
from your development branch, you end up needing to autotest both branches if 
you want to be safe about it.

- Jonathan M Davis
Dec 23 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-23 20:06, Don wrote:


 IMHO, the big issue is, and has always been, what does the autotester test?
 It makes most sense to me to have all new fixes for _anything_ going
 into the development branch, and tests on the release branch to exist
 solely for regression testing "just in case".
 It makes no sense to me to have pull testing against multiple branches.


Preferably we should have the autotester running on all branches. It 
would be nice if the autotester could automatically start testing new 
branches as soon as they are pushed upstream. Now I understand that we 
might not have enough computers to do that.

-- 
/Jacob Carlborg
Dec 24 2012
next sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
What kind of computers would we need to do these tests?
I have some spare resources for one or two VPS.

Perhaps others do too.
On 24 Dec 2012 12:45, "Jacob Carlborg" <doob me.com> wrote:


 On 2012-12-23 20:06, Don wrote:

  IMHO, the big issue is, and has always been, what does the autotester

 test?
 It makes most sense to me to have all new fixes for _anything_ going
 into the development branch, and tests on the release branch to exist
 solely for regression testing "just in case".
 It makes no sense to me to have pull testing against multiple branches.


 Preferably we should have the autotester running on all branches. It would
 be nice if the autotester could automatically start testing new branches as
 soon as they are pushed upstream. Now I understand that we might not have
 enough computers to do that.

 --
 /Jacob Carlborg
Dec 24 2012
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
And what is the stage of affairs? Means: Can I download 2.061?
Dec 24 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-24 13:52, Rory McGuire wrote:

 What kind of computers would we need to do these tests?
 I have some spare resources for one or two VPS.


I have no idea how many are need to run tests on all branches. Brad 
would know this better.

What usually is a problem is Mac OS X. Since you're only allowed to run 
it on Apple computers (if you want to follow the EULA) and Mac users is 
a minority here.


 Perhaps others do too.


People have already donated computers/shells to run the test suite as we 
do now.

I'm wondering if it would be a good idea to start using Travis CI. 
Currently it only supports Linux but they're working on adding Mac OS X 
and Windows.

-- 
/Jacob Carlborg
Dec 24 2012
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 24 December 2012 at 13:05:08 UTC, Jacob Carlborg wrote:

 On 2012-12-24 13:52, Rory McGuire wrote:

 What kind of computers would we need to do these tests?
 I have some spare resources for one or two VPS.


 I have no idea how many are need to run tests on all branches. 
 Brad would know this better.

 What usually is a problem is Mac OS X. Since you're only 
 allowed to run it on Apple computers (if you want to follow the 
 EULA) and Mac users is a minority here.


 Perhaps others do too.


 People have already donated computers/shells to run the test 
 suite as we do now.

 I'm wondering if it would be a good idea to start using Travis 
 CI. Currently it only supports Linux but they're working on 
 adding Mac OS X and Windows.


If people aren't fussy about the EULA (which is apparently not 
valid in the EU anyway) then I could probably set up os x on a 
machine at university that could be left on indefinitely as a 
test machine. I wouldn't be able to do anything on that until 
mid-january though.
Dec 24 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-24 22:38, John Colvin wrote:


 If people aren't fussy about the EULA (which is apparently not valid in
 the EU anyway) then I could probably set up os x on a machine at
 university that could be left on indefinitely as a test machine. I
 wouldn't be able to do anything on that until mid-january though.


I think they are. It's been talked on these newsgroups before.

-- 
/Jacob Carlborg
Dec 24 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/24/2012 1:38 PM, John Colvin wrote:

 If people aren't fussy about the EULA (which is apparently not valid in the EU
 anyway)


I'd rather we stick to the EULA, much as I don't like them.
Dec 24 2012
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 25 December 2012 at 03:09:18 UTC, Walter Bright wrote:

 On 12/24/2012 1:38 PM, John Colvin wrote:

 If people aren't fussy about the EULA (which is apparently not 
 valid in the EU
 anyway)


 I'd rather we stick to the EULA, much as I don't like them.


Ok, I guess it's worth not pissing off Apple.

If only we had some small commercial support of some sort... A 
mac mini is less than £500 new here in the UK, probably less than 
that in the US and that's not even considering second-hand...
Dec 25 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/25/2012 5:27 AM, John Colvin wrote:

 If only we had some small commercial support of some sort... A mac mini is less
 than £500 new here in the UK, probably less than that in the US and that's not
 even considering second-hand...


An old, slow, second hand one would be fine, as long as it can run the latest
OS X.
Dec 25 2012
parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Tue, 25 Dec 2012, Walter Bright wrote:

 On 12/25/2012 5:27 AM, John Colvin wrote:

 If only we had some small commercial support of some sort... A mac mini is
 less
 than ?500 new here in the UK, probably less than that in the US and that's
 not
 even considering second-hand...


 
 An old, slow, second hand one would be fine, as long as it can run the latest
 OS X.


Thats how we have osx in the pull tester.  I picked up a used mini.  I've 
accumulated quite a lot of oldish hardwareat this point.  The only other 
doner machine is Sean's osx box.  More hardware would be nice, but isnt a 
blocker for additional branch testing, software is.  Working on it over 
the holidays.
Dec 25 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-25 20:53, Brad Roberts wrote:


 More hardware would be nice, but isnt a
 blocker for additional branch testing, software is.  Working on it over
 the holidays.


Have you considered using any existing software for continues 
integration server?

We're using CruiseControl (the Ruby version) at work. It's simple and 
easy to setup and does what we need it to do.

-- 
/Jacob Carlborg
Dec 26 2012
parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Wed, 26 Dec 2012, Jacob Carlborg wrote:


 On 2012-12-25 20:53, Brad Roberts wrote:
 

 More hardware would be nice, but isnt a
 blocker for additional branch testing, software is.  Working on it over
 the holidays.


 
 Have you considered using any existing software for continues integration
 server?
 
 We're using CruiseControl (the Ruby version) at work. It's simple and easy to
 setup and does what we need it to do.


I haven't done a survey in a while, but all of the ones I've looked at 
have lacked at least one of the features I've wanted to have.

  1) multi-platform
  2) great integration with github and pull requests
  3) ability to pull multiple repositories as a coordinated whole

and likely more, those are just off the cuff.
Dec 26 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-12-27 00:09, Brad Roberts wrote:


 I haven't done a survey in a while, but all of the ones I've looked at
 have lacked at least one of the features I've wanted to have.

    1) multi-platform
    2) great integration with github and pull requests
    3) ability to pull multiple repositories as a coordinated whole

 and likely more, those are just off the cuff.


Ok, I see.

-- 
/Jacob Carlborg
Dec 27 2012
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Monday, 24 December 2012 at 10:43:07 UTC, Jacob Carlborg wrote:

 Preferably we should have the autotester running on all 
 branches. It would be nice if the autotester could 
 automatically start testing new branches as soon as they are 
 pushed upstream. Now I understand that we might not have enough 
 computers to do that.


The additional load caused by this should be negligible compared 
to all the pull requests.

David
Dec 24 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-12-24 14:08, David Nadlinger wrote:


 The additional load caused by this should be negligible compared to all
 the pull requests.


Well, we want all pull request to run on all these branches as well, or 
at least the pull request made on a given branch :)

-- 
/Jacob Carlborg
Dec 24 2012
prev sibling next sibling parent Kai Nacke <kai redstar.de> writes:
On 21.12.2012 23:12, Andrei Alexandrescu wrote:

 All contributors - over the weekend please ping reviewers on what you
 believe are pull requests with a high importance*urgency product. Once
 we branch into staging, pull requests will only be merged into master.



merged.

Kai
Dec 23 2012
prev sibling parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
Anyone knows when the new version will be available for download? 
An E.T.A. would be fine.

Thanks!
Phil
Dec 26 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/26/2012 2:08 PM, Phil Lavoie wrote:

 Anyone knows when the new version will be available for download? An E.T.A.
 would be fine.


It is now. Please subscribe to the dmd-beta mailing list, where such 
notifications go.


http://ftp.digitalmars.com/dmd1beta.zip
http://ftp.digitalmars.com/dmd2beta.zip
Dec 26 2012
parent "Phil Lavoie" <maidenphil hotmail.com> writes:
On Wednesday, 26 December 2012 at 22:10:57 UTC, Walter Bright 
wrote:

 On 12/26/2012 2:08 PM, Phil Lavoie wrote:

 Anyone knows when the new version will be available for 
 download? An E.T.A.
 would be fine.


 It is now. Please subscribe to the dmd-beta mailing list, where 
 such notifications go.


 http://ftp.digitalmars.com/dmd1beta.zip
 http://ftp.digitalmars.com/dmd2beta.zip


Thanks!
Dec 26 2012