Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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.
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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!
Re: Getting ready for 2.061
Anyone knows when the new version will be available for download? An E.T.A. would be fine. Thanks! Phil
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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.
Re: Getting ready for 2.061
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.
Re: Getting ready for 2.061
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...
Re: Getting ready for 2.061
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.
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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.
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
And what is the stage of affairs? Means: Can I download 2.061?
Re: Getting ready for 2.061
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" 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 >
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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.
Re: Getting ready for 2.061
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) -- [Penis Uptime: 2days 13hrs 59mins 35secs] viagra? :) yea, 20 pills
Re: Getting ready for 2.061
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.
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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.
Re: Getting ready for 2.061
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).
Re: Getting ready for 2.061
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.
Re: Getting ready for 2.061
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 a...@lycus.org http://lycus.org
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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.
Re: Getting ready for 2.061
On Sat, 2012-12-22 at 17:41 +0100, David Nadlinger wrote: […] > 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. 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 π by quadrature. This is the 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 > 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. 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%–4%, 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 → 2.060 regression reported 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 > 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. 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 > 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…) :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
On Sat, 2012-12-22 at 11:36 +0100, dennis luehring wrote: […] > so first you need to update your bug-report - you stated that ldc is > 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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Getting ready for 2.061
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 :)
Re: Getting ready for 2.061
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 :-) 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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
There are still 7 reported regressions unfinished according to http://d.puremagic.com/issues/buglist.cgi?y_axis_field=bug_severity&query_format=report-table&product=D&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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
Re: Getting ready for 2.061
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/srzxakcwamzzzvqct...@forum.dlang.org), but I think the issue got lost in the wake of the UDA discussion. David
Getting ready for 2.061
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
