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