www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD v2.066.0-b3

reply Andrew Edwards <ridimz yahoo.com> writes:
The v2.066.0-b3 binaries are now available. The review period for beta 3 
will run until 0700 UTC (0000 PDT, 0300 EDT, 1600 JST) on 14 July 2014, 
at which time binaries for RC1 will be produced and released. Due 
diligence in identifying regressions as early as possible is requested 
and appreciated. Issue 13101, [1], is provided for identifying 
anyfixedregressions that needs to be picked and included in RC1.

B3 binaries are located here:

     ALL
     ftp.digitalmars.com/dmd.2.066.0-b3.zip

     OSX
     ftp.digitalmars.com/dmd.2.066.0-b3.dmg
     ftp.digitalmars.com/dmd.2.066.0-b3.osx.zip

     FREEBSD
     ftp.digitalmars.com/dmd.2.066.0-b3.freebsd-64.zip
     ftp.digitalmars.com/dmd.2.066.0-b3.freebsd-32.zip

     LINUX
     ftp.digitalmars.com/dmd_2.066.0~b3-0_i386.deb
     ftp.digitalmars.com/dmd_2.066.0~b3-0_amd64.deb
     ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip
     ftp.digitalmars.com/dmd-2.066.0~b3-0.openSUSE.i386.rpm
  ftp.digitalmars.com/dmd-2.066.0~b3-0.openSUSE.x86_64.rpm
     ftp.digitalmars.com/dmd-2.066.0~b3-0.fedora.i386.rpm
     ftp.digitalmars.com/dmd-2.066.0~b3-0.fedora.x86_64.rpm
     ftp.digitalmars.com/libphobos2-66_2.066.0~b3-0_i386.deb
  ftp.digitalmars.com/libphobos2-66_2.066.0~b3-0_amd64.deb

     WINDOWS
     ftp.digitalmars.com/dmd-2.066.0-b3.exe
     ftp.digitalmars.com/dmd.2.066.0-b3.windows.zip

A maintenance release is scheduled for 2.065 on September 15. Request 
assistance in identifying non-breaking changes (fixes) for inclusion in 
2.065.1 by 30 August. Issue 13036, [2], is opened for 
documenting/consolidating candidates for the point release.

Enjoy,
Andrew

[1] [Cherry-pick v2.066.0-rc1]https://issues.dlang.org/show_bug.cgi?id=13101
[2] [Cherry-pick v2.065.1-b1]https://issues.dlang.org/show_bug.cgi?id=13036
Jul 11 2014
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
For convenience, the list of unresolved issues marked as 
regressions: 
https://issues.dlang.org/buglist.cgi?bug_severity=regression&resolution=---

Seems like there is still quite a way to go until we can release 
RC1.

David
Jul 11 2014
next sibling parent reply "AfroboyX" <darkafro.edwards3 gmail.com> writes:
On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote:
 For convenience, the list of unresolved issues marked as 
 regressions: 
 https://issues.dlang.org/buglist.cgi?bug_severity=regression&resolution=---

 Seems like there is still quite a way to go until we can 
 release RC1.

 David
There is 1027 issues here... We can't even clear a list of 10 issues, what makes you think we can clear this list before the next release? On second thought this is a list of all issues ever marked as regressions. This might be what you intended: https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=47252&query_format=advanced
Jul 12 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-07-12 15:21, AfroboyX wrote:

 There is 1027 issues here... We can't even clear a list of 10
 issues, what makes you think we can clear this list before the
 next release?
The last three dashes of the URL is part of the link as well but is apparently not recognized as part of the link. If you add the three dashes you can see it's only 9 issues, the ones that are open. -- /Jacob Carlborg
Jul 12 2014
prev sibling parent reply "Andrew Edwards" <ridimz yahoo.com> writes:
On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote:
 For convenience, the list of unresolved issues marked as 
 regressions: 
 https://issues.dlang.org/buglist.cgi?bug_severity=regression&resolution=---

 Seems like there is still quite a way to go until we can 
 release RC1.

 David
David, I'm sure you are aware that list will never be empty. The last release lasted from mid November to 24 February and that list was never empty once during that entire time. The only way we will empty that list is to prevent people from submitting new regressions during a review. When I checked the list yesterday the count was at 9: right now it is at 12. And at least on of those items on the list has been there since 2011. The reality is that zero emphasis is place on regressions unless it's time for a release, and even then, only a few people pay attention to them. Everyone else just continue on in their happy world doing "what's important to them". You you cannot ask that anyone work on anything because if it's not important in their minds, they will not do it. They'd much rather sit around and biker about how you did it incorrectly. Which, in my opinion, is a huge wast of time and resource. So I have some questions: What is the magic number that will trigger the release? What happens if we never reach that number? Do we just continue waiting for it or do we make a decision at some point that it's time? If so, how long do we wait? Is there one person who makes the decision, or is it decision automatic? If there is a person, who is it?
Jul 12 2014
parent Brad Roberts via Digitalmars-d-announce writes:
On 7/12/14, 4:31 PM, Andrew Edwards via Digitalmars-d-announce wrote:
 On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote:
 For convenience, the list of unresolved issues marked as regressions:
 https://issues.dlang.org/buglist.cgi?bug_severity=regression&resolution=---

 Seems like there is still quite a way to go until we can release RC1.

 David
David, I'm sure you are aware that list will never be empty. The last release lasted from mid November to 24 February and that list was never empty once during that entire time. The only way we will empty that list is to prevent people from submitting new regressions during a review. When I checked the list yesterday the count was at 9: right now it is at 12. And at least on of those items on the list has been there since 2011. The reality is that zero emphasis is place on regressions unless it's time for a release, and even then, only a few people pay attention to them. Everyone else just continue on in their happy world doing "what's important to them". You you cannot ask that anyone work on anything because if it's not important in their minds, they will not do it. They'd much rather sit around and biker about how you did it incorrectly. Which, in my opinion, is a huge wast of time and resource. So I have some questions: What is the magic number that will trigger the release? What happens if we never reach that number? Do we just continue waiting for it or do we make a decision at some point that it's time? If so, how long do we wait? Is there one person who makes the decision, or is it decision automatic? If there is a person, who is it?
An important topic, certainly. But not for the announce newsgroup. Please continue this over on the beta list.
Jul 12 2014
prev sibling next sibling parent Brad Roberts via Digitalmars-d-announce writes:
Also available at downloads.dlang.org

On 7/11/14, 5:00 PM, Andrew Edwards via Digitalmars-d-announce wrote:
 The v2.066.0-b3 binaries are now available. The review period for beta 3 will
run until 0700 UTC
 (0000 PDT, 0300 EDT, 1600 JST) on 14 July 2014, at which time binaries for RC1
will be produced and
 released. Due diligence in identifying regressions as early as possible is
requested and
 appreciated. Issue 13101, [1], is provided for identifying anyfixedregressions
that needs to be
 picked and included in RC1.

 B3 binaries are located here:

      ALL
      ftp.digitalmars.com/dmd.2.066.0-b3.zip

      OSX
      ftp.digitalmars.com/dmd.2.066.0-b3.dmg
      ftp.digitalmars.com/dmd.2.066.0-b3.osx.zip

      FREEBSD
      ftp.digitalmars.com/dmd.2.066.0-b3.freebsd-64.zip
      ftp.digitalmars.com/dmd.2.066.0-b3.freebsd-32.zip

      LINUX
      ftp.digitalmars.com/dmd_2.066.0~b3-0_i386.deb
      ftp.digitalmars.com/dmd_2.066.0~b3-0_amd64.deb
      ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip
      ftp.digitalmars.com/dmd-2.066.0~b3-0.openSUSE.i386.rpm
   ftp.digitalmars.com/dmd-2.066.0~b3-0.openSUSE.x86_64.rpm
      ftp.digitalmars.com/dmd-2.066.0~b3-0.fedora.i386.rpm
      ftp.digitalmars.com/dmd-2.066.0~b3-0.fedora.x86_64.rpm
      ftp.digitalmars.com/libphobos2-66_2.066.0~b3-0_i386.deb
   ftp.digitalmars.com/libphobos2-66_2.066.0~b3-0_amd64.deb

      WINDOWS
      ftp.digitalmars.com/dmd-2.066.0-b3.exe
      ftp.digitalmars.com/dmd.2.066.0-b3.windows.zip

 A maintenance release is scheduled for 2.065 on September 15. Request
assistance in identifying
 non-breaking changes (fixes) for inclusion in 2.065.1 by 30 August. Issue
13036, [2], is opened for
 documenting/consolidating candidates for the point release.

 Enjoy,
 Andrew

 [1] [Cherry-pick v2.066.0-rc1]https://issues.dlang.org/show_bug.cgi?id=13101
 [2] [Cherry-pick v2.065.1-b1]https://issues.dlang.org/show_bug.cgi?id=13036
Jul 11 2014
prev sibling parent reply "Dragos Carp" <dragoscarp gmail.com> writes:
     LINUX
     ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip
I think something got wrong on building the 2.066.0-b3. The sources from dmd.2.066.0-b3.linux.zip are not the same with the tagged version 2.066.0-b3 in git (for dmd at least). For example: unzipped dmd2.066-b3/src/dmd/nogc.c:65 if (v && (v->storage_class & (STCmanifest | STCstatic)) == 0 && v->init) git v2.066.0-b3 dmd/src/nogc.c:65 if (v && !(v->storage_class & STCmanifest) && !v->isDataseg() && v->init) Maybe you should rebuild this or simply ignore -b3 and create a -b4. Because of improper tagging, testing actual binaries of -b3 makes no sense.
Jul 14 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 14 July 2014 at 11:57:33 UTC, Dragos Carp wrote:
    LINUX
    ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip
I think something got wrong on building the 2.066.0-b3. The sources from dmd.2.066.0-b3.linux.zip are not the same with the tagged version 2.066.0-b3 in git (for dmd at least). For example: unzipped dmd2.066-b3/src/dmd/nogc.c:65 if (v && (v->storage_class & (STCmanifest | STCstatic)) == 0 && v->init) git v2.066.0-b3 dmd/src/nogc.c:65 if (v && !(v->storage_class & STCmanifest) && !v->isDataseg() && v->init) Maybe you should rebuild this or simply ignore -b3 and create a -b4. Because of improper tagging, testing actual binaries of -b3 makes no sense.
http://forum.dlang.org/post/yavpusxgxwgbaepctjty forum.dlang.org
Jul 14 2014
parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
I've been running beta2, and I noticed that class debugging isn't working.
There was a discussion some time back about how class members weren't
evaluated correctly in Win64, and it was said that it was fixed in master.
I was excited and patiently awaiting the release.

Can anyone who knows about this stuff comment?


On 14 July 2014 22:00, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Monday, 14 July 2014 at 11:57:33 UTC, Dragos Carp wrote:

    LINUX
    ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip
I think something got wrong on building the 2.066.0-b3. The sources from dmd.2.066.0-b3.linux.zip are not the same with the tagged version 2.066.0-b3 in git (for dmd at least). For example: unzipped dmd2.066-b3/src/dmd/nogc.c:65 if (v && (v->storage_class & (STCmanifest | STCstatic)) == 0 && v->init) git v2.066.0-b3 dmd/src/nogc.c:65 if (v && !(v->storage_class & STCmanifest) && !v->isDataseg() && v->init) Maybe you should rebuild this or simply ignore -b3 and create a -b4. Because of improper tagging, testing actual binaries of -b3 makes no sense.
http://forum.dlang.org/post/yavpusxgxwgbaepctjty forum.dlang.org
Jul 14 2014
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 14.07.2014 16:17, Manu via Digitalmars-d-announce wrote:
 I've been running beta2, and I noticed that class debugging isn't
 working. There was a discussion some time back about how class members
 weren't evaluated correctly in Win64, and it was said that it was fixed
 in master.
 I was excited and patiently awaiting the release.

 Can anyone who knows about this stuff comment?
You have to use -gc instead of -g to enable the '.' to ' ' translation inside class names.
Jul 14 2014
parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 15 July 2014 07:37, Rainer Schuetze via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On 14.07.2014 16:17, Manu via Digitalmars-d-announce wrote:

 I've been running beta2, and I noticed that class debugging isn't
 working. There was a discussion some time back about how class members
 weren't evaluated correctly in Win64, and it was said that it was fixed
 in master.
 I was excited and patiently awaiting the release.

 Can anyone who knows about this stuff comment?
You have to use -gc instead of -g to enable the '.' to ' ' translation inside class names.
Shouldn't that be the default then? It's no good not being able to view class members... Are you sure that's the problem? If I inspect a class, it shows a grid populated with the proper number of members, but the member names are blank and the values are blank too. Occasionally, if there are many members, the first 10 or so are blank, but then the rest display properly from there down. It's very strange... you haven't experienced this? If the problem is as you say, I'm surprised that it would occasionally work past the first 10 members or so...
Jul 14 2014
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 15.07.2014 04:06, Manu via Digitalmars-d-announce wrote:
 On 15 July 2014 07:37, Rainer Schuetze via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com
 <mailto:digitalmars-d-announce puremagic.com>> wrote:



     On 14.07.2014 16:17, Manu via Digitalmars-d-announce wrote:

         I've been running beta2, and I noticed that class debugging isn't
         working. There was a discussion some time back about how class
         members
         weren't evaluated correctly in Win64, and it was said that it
         was fixed
         in master.
         I was excited and patiently awaiting the release.

         Can anyone who knows about this stuff comment?


     You have to use -gc instead of -g to enable the '.' to ' '
     translation inside class names.


 Shouldn't that be the default then? It's no good not being able to view
 class members...
Please convince Walter, I was unsuccessful. In his favor, there are debug engines that understand type names with '.', like mago. It would be strange to burden these with ' '. I guess I'll have to add some "best option for selected debug engine" to Visual D, though.
 Are you sure that's the problem? If I inspect a class, it shows a grid
 populated with the proper number of members, but the member names are
 blank and the values are blank too.
 Occasionally, if there are many members, the first 10 or so are blank,
 but then the rest display properly from there down. It's very strange...
 you haven't experienced this?
 If the problem is as you say, I'm surprised that it would occasionally
 work past the first 10 members or so...
That was exactly my experience, too, and led to the workaround (this was long before Win64 support, though). If there is a better solution, please speak up ;-)
Jul 14 2014