www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.064 and 2.049 release

reply Walter Bright <newshound2 digitalmars.com> writes:
This is primarily a bug fix release.

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.064.zip

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.049.zip
Sep 16 2010
next sibling parent BCS <none anon.com> writes:
Hello Walter,


 This is primarily a bug fix release.


And that it is! Great job!

-- 
... <IXOYE><
Sep 16 2010
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i6up2t$19cp$1 digitalmars.com...

 This is primarily a bug fix release.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.064.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.049.zip


Excellent, I see the current RDMD has been included :) Now maybe we can get 
these applied ("squeak" says the wheel...):

http://d.puremagic.com/issues/show_bug.cgi?id=4672
http://d.puremagic.com/issues/show_bug.cgi?id=4683
http://d.puremagic.com/issues/show_bug.cgi?id=4684
http://d.puremagic.com/issues/show_bug.cgi?id=4688
Sep 17 2010
prev sibling next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
On Thu, 16 Sep 2010 20:58:56 -0700, Walter Bright wrote:


 This is primarily a bug fix release.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.064.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.049.zip



Looks solid, but it appears to have broken debugging info. (Linux)

Looking through the bug tracker now.
Sep 17 2010
parent reply Bernard Helyer <b.helyer gmail.com> writes:
On Fri, 17 Sep 2010 11:45:15 +0000, Bernard Helyer wrote:

 Looks solid, but it appears to have broken debugging info. (Linux)
 
 Looking through the bug tracker now.


Uhhhh disregard that, PEBKAC.   ^^;
Sep 17 2010
parent reply "Aldo Nunez" <aldoSkipallthisNunez1 gmail.com> writes:
Bernard Helyer <b.helyer gmail.com> wrote:


 On Fri, 17 Sep 2010 11:45:15 +0000, Bernard Helyer wrote:

 Looks solid, but it appears to have broken debugging info. (Linux)

 Looking through the bug tracker now.


 Uhhhh disregard that, PEBKAC.   ^^;


Actually, something went wrong in the debugging info on Windows.

It seems to be a problem with the new linker (8.00.7). Using an older one,  
like from DMD release 2.048, works well.

I filed bug report 4897.
Sep 19 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Aldo Nunez wrote:

 I filed bug report 4897.


http://ftp.digitalmars.com/link.8.00.8.zip
Sep 19 2010
parent "Aldo Nunez" <aldoSkipallthisNunez1 gmail.com> writes:
Walter Bright <newshound2 digitalmars.com> wrote:

 Aldo Nunez wrote:

 I filed bug report 4897.


 http://ftp.digitalmars.com/link.8.00.8.zip


Looks good.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Sep 20 2010
prev sibling next sibling parent reply osa <osa aso.osa> writes:
After upgrading to 2.049, trying to compile this code:
----
import std.traits;
void foo() {}
void main() {
     static assert( ! hasUnsharedAliasing!foo );
}
----
gives this error:
dmd2/linux/bin/../../src/phobos/std/traits.d(971): Error: template 
instance isAssociativeArray!(foo) does not match template declaration 
isAssociativeArray(T)
dmd2/linux/bin/../../src/phobos/std/traits.d(971): Error: expression 
isAssociativeArray!(foo) is not constant or does not evaluate to a bool

It used to work with 2.048 so it is probably caused by fixing bug 4834.

Also, error message points to the guts of std.traits and does not give 
any clue about actual instantiation of hasUnsharedAliasing which caused 
this. It was not easy to reduce the problem to the small test case.
Sep 17 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from osa (osa aso.osa)'s article

 After upgrading to 2.049, trying to compile this code:
 ----
 import std.traits;
 void foo() {}
 void main() {
      static assert( ! hasUnsharedAliasing!foo );
 }
 ----
 gives this error:
 dmd2/linux/bin/../../src/phobos/std/traits.d(971): Error: template
 instance isAssociativeArray!(foo) does not match template declaration
 isAssociativeArray(T)
 dmd2/linux/bin/../../src/phobos/std/traits.d(971): Error: expression
 isAssociativeArray!(foo) is not constant or does not evaluate to a bool
 It used to work with 2.048 so it is probably caused by fixing bug 4834.
 Also, error message points to the guts of std.traits and does not give
 any clue about actual instantiation of hasUnsharedAliasing which caused
 this. It was not easy to reduce the problem to the small test case.


I agree the error message is obtuse, but I don't think this code is supposed to
work because foo is not a type.  This code does work:

import std.traits;
void foo() {}
void main() {
     static assert( ! hasUnsharedAliasing!(typeof(foo)) );
}
Sep 17 2010
parent reply osa <osa aso.osa> writes:
On 09/17/2010 03:22 PM, dsimcha wrote:

 I agree the error message is obtuse, but I don't think this code is supposed to
 work because foo is not a type.  This code does work:

 import std.traits;
 void foo() {}
 void main() {
       static assert( ! hasUnsharedAliasing!(typeof(foo)) );
 }


My bad. However, old code used to work with 2.048, with hasLocalAliasing.

Now the next problem. I do not think there is unshared aliasing here:
----
import std.traits;
struct Foo
{
     void function() func;
}
void main()
{
     static assert( ! hasUnsharedAliasing!Foo, "struct Foo has unshared 
aliasing" );
}
----
but it fails to compile. As far as I understand, functions (unlike 
delegates) do not have any shared aliasing but hasUnsharedAliasing 
thinks they do.
Sep 17 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from osa (osa aso.osa)'s article

 On 09/17/2010 03:22 PM, dsimcha wrote:

 I agree the error message is obtuse, but I don't think this code is supposed to
 work because foo is not a type.  This code does work:

 import std.traits;
 void foo() {}
 void main() {
       static assert( ! hasUnsharedAliasing!(typeof(foo)) );
 }


 My bad. However, old code used to work with 2.048, with hasLocalAliasing.
 Now the next problem. I do not think there is unshared aliasing here:
 ----
 import std.traits;
 struct Foo
 {
      void function() func;
 }
 void main()
 {
      static assert( ! hasUnsharedAliasing!Foo, "struct Foo has unshared
 aliasing" );
 }
 ----
 but it fails to compile. As far as I understand, functions (unlike
 delegates) do not have any shared aliasing but hasUnsharedAliasing
 thinks they do.


This is a real bug.  Please file a bug report.  I'll look into it soon.
Sep 17 2010
parent osa <osa aso.osa> writes:
On 09/17/2010 04:05 PM, dsimcha wrote:


 This is a real bug.  Please file a bug report.  I'll look into it soon.


Done: http://d.puremagic.com/issues/show_bug.cgi?id=4882
Sep 17 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 This is primarily a bug fix release.


I was away. Thank you for all the work.
For the close future I suggest to focus a bit more on fixing language/design
corner cases, instead of just on normal dmd/Phobos/druntime bugs (as done in
this release).


The Changelog of 2.049 says:
Bugzilla 4603: array(iota(1, 0)) error.
But it's not closed, here time ago I have explained why:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=115725


See also:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=117461

-----------------------

Regarding bug 3554/3957:
http://d.puremagic.com/issues/show_bug.cgi?id=3554
It doesn't seem fixed in dmd 2.049. This program:


/// Return a random number in [0, 10 $(LPAREN)
void foo() {}
void main() {}



Generates an html that doesn't show the closing left parenthesis:


...
<dd>Return a random number in [0, 10 <br><br>

</dd>
...


So if I am not mistaken I may reopen bug 3554.

Bye,
bearophile
Sep 20 2010
parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Walter Bright:
 

 This is primarily a bug fix release.


 
 I was away. Thank you for all the work.
 For the close future I suggest to focus a bit more on fixing language/design
corner cases, instead of just on normal dmd/Phobos/druntime bugs (as done in
this release).


Sorry bearophile, regressions and wrong-code bugs will ALWAYS have top 
priority. There will be no apology for fixing bugs like 3996, 4681, and 
4009. <g>.
Sep 20 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:

 Sorry bearophile, regressions and wrong-code bugs will ALWAYS have top 
 priority. There will be no apology for fixing bugs like 3996, 4681, and 
 4009. <g>.


I see. On the other hand little design bugs are important too because despite
they now look temporary, they risk becoming permanent, I have some past
experience on this. This is why I am using all the chances I have to put them
under attention. So far only two of the ones I have listed have being discussed
and only one of them was fixed (the one about a|b>c).

Unrelated: in Bugzilla I have few small Phobos patches. If no one finds time or
interest in them, then I may eventually desire to apply those patches myself.

Bye,
bearophile
Sep 20 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:


 Sorry bearophile, regressions and wrong-code bugs will ALWAYS have top 
 priority. There will be no apology for fixing bugs like 3996, 4681, and 
 4009. <g>.


Thinking quite more about it, I don't agree. Those are critical implementation
bugs, but they are bugs still. Design bugs come before critical implementation
bugs because if you don't fix them sooner, they become permanent. Among my list
of little design bugs to fix there are things more important than 3996, 4681,
and 4009, and the risk of seeing them become permanent is growing at every dmd2
release after TDPL publication.

Bye,
bearophile
Sep 28 2010