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.
DMD #1287 is still pending a response by Walter. I explained why 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.
DMD #1396 fixes a compile error with Visual Studio 2012 and should be 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