www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.053 and 2.037 release

reply Walter Bright <newshound1 digitalmars.com> writes:
Probably the biggest thing is opDispatch!

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


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

Many thanks to the numerous people who contributed to this update.
Dec 04 2009
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Fri, Dec 04, 2009 at 08:05:13PM -0800, Walter Bright wrote:
 Probably the biggest thing is opDispatch!
Nay, the bug fixes! It looks like you guys solved an elusive codegen problem in this release that's been bugging me since about 2007. Not a showstopper - rearranging some statements made it go away (also why I never filed a bug report; I couldn't reproduce it reliably in any test case smaller than my 5000 line app!), but an annoyance nonetheless. I think it might have been Bugzilla 3521. Whatever, I've been unable to reproduce it again at all over the last hour and a half. I think it's dead! Yay! And WOW dmd 1 is fast. dmd 2 is fast too, but oh man, I've forgotten how blazing dmd1 really is. Anyway, thanks! So exciting.
 
 Many thanks to the numerous people who contributed to this update.
-- Adam D. Ruppe http://arsdnet.net
Dec 04 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Adam D. Ruppe wrote:
 I think it might have been Bugzilla 3521.
Yeah, that was a pretty evil bug. It has been lurking there for probably 18+ years now. It's evil because only a very, very rare set of circumstances will trip it, and even then it may not be executed or noticed. I instrumented the C++ compiler for it, and ran it through its test suite. Turns out, it did trip it, but only on a piece of code that was tested for compile only. Sigh. I was glad to get it fixed.
Dec 04 2009
prev sibling next sibling parent Max Samukha <spambox d-coding.com> writes:
On Fri, 04 Dec 2009 20:05:13 -0800, Walter Bright
<newshound1 digitalmars.com> wrote:

Probably the biggest thing is opDispatch!

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


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

Many thanks to the numerous people who contributed to this update.
This code: int[3] a = [1, 2, 3]; allocates the literal on heap and then copies it to 'a'. A call to a library function has to be made to avoid the allocation. Can we have such allocations optimized out?
Dec 05 2009
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
Walter Bright wrote:
 Probably the biggest thing is opDispatch!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.053.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.037.zip
 
 Many thanks to the numerous people who contributed to this update.
Why is opPow just override-able in classes and not in structs ? Is that intended behaviour ?
Dec 05 2009
next sibling parent reply Extrawurst <spam extrawurst.org> writes:
Extrawurst wrote:
 Walter Bright wrote:
 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
Why is opPow just override-able in classes and not in structs ? Is that intended behaviour ?
ok my bad it does work for structs, it just complains if i implement the operator using the "override" keyword: Inside of a class it say: "Error: function main.Foo.opPow does not override any function" and inside of a struct is says: "Error: function main.Foo.opPow override only applies to class member functions" Weird !
Dec 05 2009
next sibling parent Extrawurst <spam extrawurst.org> writes:
Extrawurst wrote:
 Extrawurst wrote:
 Walter Bright wrote:
 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
Why is opPow just override-able in classes and not in structs ? Is that intended behaviour ?
ok my bad it does work for structs, it just complains if i implement the operator using the "override" keyword: Inside of a class it say: "Error: function main.Foo.opPow does not override any function" and inside of a struct is says: "Error: function main.Foo.opPow override only applies to class member functions" Weird !
Ignore me, i should take a nap ;) it is all good!
Dec 05 2009
prev sibling parent Don <nospam nospam.com> writes:
Extrawurst wrote:
 Extrawurst wrote:
 Walter Bright wrote:
 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
Why is opPow just override-able in classes and not in structs ? Is that intended behaviour ?
ok my bad it does work for structs, it just complains if i implement the operator using the "override" keyword: Inside of a class it say: "Error: function main.Foo.opPow does not override any function" and inside of a struct is says: "Error: function main.Foo.opPow override only applies to class member functions" Weird !
overriding is not the same as overloading.
Dec 05 2009
prev sibling parent Don <nospam nospam.com> writes:
Extrawurst wrote:
 Walter Bright wrote:
 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
Why is opPow just override-able in classes and not in structs ? Is that intended behaviour ?
Do you have a test case? The cases I tested all worked.
Dec 05 2009
prev sibling next sibling parent Extrawurst <spam extrawurst.org> writes:
Walter Bright wrote:
 Probably the biggest thing is opDispatch!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.053.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.037.zip
 
 Many thanks to the numerous people who contributed to this update.
I love opDispatch ;) [CODE] struct Foo { public void opDispatch(string s) (int _v) { writefln("Foo.'%s' (%s)",s,_v); return; } } void main() { Foo f; f.fuckya(2); f.thisisaterriblelongmethodnamethatisnotevenimplementedexplicitlyinsideofmyclassFoo(2); } [/CODE] I cannot wait to use it in my lua bindings, this is a great feature.
Dec 05 2009
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
Walter Bright wrote:
 Probably the biggest thing is opDispatch!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.053.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.037.zip
 
 Many thanks to the numerous people who contributed to this update.
Can someone explain this "new feature" please ?! "Added support for op= for array.length" array.length = X; cannot be meant...
Dec 05 2009
parent Don <nospam nospam.com> writes:
Extrawurst wrote:
 Walter Bright wrote:
 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
Can someone explain this "new feature" please ?! "Added support for op= for array.length" array.length = X; cannot be meant...
int [] x = new int[30]; x.length += 5;
Dec 05 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 Probably the biggest thing is opDispatch!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.053.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.037.zip
 
 Many thanks to the numerous people who contributed to this update.
I just noticed: I don't see property in the changelog anywhere, but it's now in the spec. safe, trusted, system aren't there either.
Dec 05 2009
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:
 Walter Bright wrote:
 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
I just noticed: I don't see property in the changelog anywhere, but it's now in the spec. safe, trusted, system aren't there either.
Do safe, trusted and system actually do anything yet? It seems property now enforces the "0 or 1 parameter" constraint, but one can still use property syntax to call non- property functions. -Lars
Dec 07 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
There's a large number of changes!
I don't understand what "No more comma operators allowed between [ ]." means.

I have tried the D2 compiler a little with this code:

import std.stdio: writeln;
import std.math: pow;

struct S1 { int x; }

void main() {
    struct S2 { int x; }
    static struct S3 { int x; }
    writeln(S1.sizeof, " ", S2.sizeof, " ", S3.sizeof); // 4 4 4

    auto a = [1, 2, 3];
    writeln(a); // 1 2 3
    a.length++;

    //writeln(5 ^^ 2);
    writeln(5.2 ^^ 2); // errors
}

S2 seems to not have the hidden field, The sizeof is the same for all three
structs.

a.length++ seems to not work yet.

writeln(a); prints stupidly items separated by a space. A MUCH better print is:
[1, 2, 3]

5 ^^ 2 doesn't work yet, I guess it's not implemented yet.
But what do I have to import from math to use 5.2 ^^ 2 ?
Anyway, the need to explicitly import something to use a built-in operator like
^^ looks like a bad idea.

Bye and thank you,
bearophile
Dec 05 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hfdt87$1num$1 digitalmars.com...
 There's a large number of changes!
 I don't understand what "No more comma operators allowed between [ ]." 
 means.
I assume that means: int[1,2,3] foo; // <- formerly created an int[3], now (presumably) disallowed
Dec 05 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:
 I assume that means:
 
 int[1,2,3] foo; // <- formerly created an int[3], now (presumably) 
 disallowed 
Yes, you are right, that's probably it, thank you. Bye, bearophile
Dec 05 2009
prev sibling parent reply Max Samukha <spambox d-coding.com> writes:
On Sat, 5 Dec 2009 10:19:23 -0500, "Nick Sabalausky" <a a.a> wrote:

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hfdt87$1num$1 digitalmars.com...
 There's a large number of changes!
 I don't understand what "No more comma operators allowed between [ ]." 
 means.
I assume that means: int[1,2,3] foo; // <- formerly created an int[3], now (presumably) disallowed
Was this feature documented anywhere?
Dec 05 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Max Samukha" <spambox d-coding.com> wrote in message 
news:pkvkh5tvvhie0ga61lrpp5qmt53h5ju1t4 4ax.com...
 On Sat, 5 Dec 2009 10:19:23 -0500, "Nick Sabalausky" <a a.a> wrote:

"bearophile" <bearophileHUGS lycos.com> wrote in message
news:hfdt87$1num$1 digitalmars.com...
 There's a large number of changes!
 I don't understand what "No more comma operators allowed between [ ]."
 means.
I assume that means: int[1,2,3] foo; // <- formerly created an int[3], now (presumably) disallowed
Was this feature documented anywhere?
I don't think it was ever really a feature, it was just a consequence of the next-to-useless expression "x,y" evaluating to "y" and "int[...] foo;" taking a single value for "...".
Dec 05 2009
parent reply Max Samukha <spambox d-coding.com> writes:
On Sat, 5 Dec 2009 10:59:12 -0500, "Nick Sabalausky" <a a.a> wrote:

"Max Samukha" <spambox d-coding.com> wrote in message 
news:pkvkh5tvvhie0ga61lrpp5qmt53h5ju1t4 4ax.com...
 On Sat, 5 Dec 2009 10:19:23 -0500, "Nick Sabalausky" <a a.a> wrote:

"bearophile" <bearophileHUGS lycos.com> wrote in message
news:hfdt87$1num$1 digitalmars.com...
 There's a large number of changes!
 I don't understand what "No more comma operators allowed between [ ]."
 means.
I assume that means: int[1,2,3] foo; // <- formerly created an int[3], now (presumably) disallowed
Was this feature documented anywhere?
I don't think it was ever really a feature, it was just a consequence of the next-to-useless expression "x,y" evaluating to "y" and "int[...] foo;" taking a single value for "...".
Ah, it is simply the unfortunate comma expression evaluated to 3. Comma expressions need to go. Thanks.
Dec 06 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Max Samukha:
 Ah, it is simply the unfortunate comma expression evaluated to 3.
 Comma expressions need to go. Thanks.
There are so many design holes in the C language that's the other languages must be really bad to be worse than C :-) Designing languages is hard. Bye, bearophile
Dec 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Max Samukha:
 Ah, it is simply the unfortunate comma expression evaluated to 3. 
 Comma expressions need to go. Thanks.
There are so many design holes in the C language that's the other languages must be really bad to be worse than C :-) Designing languages is hard.
Appreciating language designs is subjective. IMHO C has a remarkably good design. It has an awkward precedence for the shift operators, an odd syntax for function declaration, a few conversions are messed up... other than that, there's a lot of good things to say about it. I think it's considerably better designed than e.g. Fortran, which is not much older. And look at Pascal - whereas on the outside it looks so clean and well-designed, it is virtually useless in its standard incarnation. Not wanting to start a language war, but to just say C has plenty of design holes and then patronize it with the comment that designing languages is hard - well, you better have a hell of an argument up your sleeve. Andrei
Dec 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Not wanting to start a language war, but to just say C has plenty of 
 design holes and then patronize it with the comment that designing 
 languages is hard - well, you better have a hell of an argument up your 
 sleeve.
C really has only one major design flaw - the conflation of arrays and pointers.
Dec 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Not wanting to start a language war, but to just say C has plenty of 
 design holes and then patronize it with the comment that designing 
 languages is hard - well, you better have a hell of an argument up 
 your sleeve.
C really has only one major design flaw - the conflation of arrays and pointers.
Great insight. Andrei
Dec 06 2009
parent reply Max Samukha <spambox d-coding.com> writes:
On Sun, 06 Dec 2009 23:43:16 -0600, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Not wanting to start a language war, but to just say C has plenty of 
 design holes and then patronize it with the comment that designing 
 languages is hard - well, you better have a hell of an argument up 
 your sleeve.
C really has only one major design flaw - the conflation of arrays and pointers.
Great insight. Andrei
I think the following real-world code is a good argument against comma operators: template <typename T> Q_INLINE_TEMPLATE void QList<T>::node_destruct(Node *from, Node *to) { if (QTypeInfo<T>::isLarge || QTypeInfo<T>::isStatic) while(from != to) --to, delete reinterpret_cast<T*>(to->v); else if (QTypeInfo<T>::isComplex) while (from != to) --to, reinterpret_cast<T*>(to)->~T(); }
Dec 07 2009
parent reply klickverbot <klickverbot gmail.com> writes:
Max Samukha wrote:
 
 I think the following real-world code is a good argument against comma
 operators:
 
 template <typename T>
 Q_INLINE_TEMPLATE void QList<T>::node_destruct(Node *from, Node *to)
 {
     if (QTypeInfo<T>::isLarge || QTypeInfo<T>::isStatic)
         while(from != to) --to, delete reinterpret_cast<T*>(to->v);
     else if (QTypeInfo<T>::isComplex)
         while (from != to) --to, reinterpret_cast<T*>(to)->~T();
 }
I have never used the comma operator in my own code, but in my opinion this particular piece of code is really easy and fluent to read. »Maintainability« is admittedly, however, a different topic.
Dec 07 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
klickverbot wrote:
 Max Samukha wrote:
 I think the following real-world code is a good argument against comma
 operators:

 template <typename T>
 Q_INLINE_TEMPLATE void QList<T>::node_destruct(Node *from, Node *to)
 {
     if (QTypeInfo<T>::isLarge || QTypeInfo<T>::isStatic)
         while(from != to) --to, delete reinterpret_cast<T*>(to->v);
     else if (QTypeInfo<T>::isComplex)
         while (from != to) --to, reinterpret_cast<T*>(to)->~T();
 }
I have never used the comma operator in my own code, but in my opinion this particular piece of code is really easy and fluent to read. »Maintainability« is admittedly, however, a different topic.
It is still more readable than 'while(from != to--)' or '((--to)->v)'. I myself use the comma operator in for loops and simple assignments such as 'if(something) x = a, y = b;'. The boost::assign namespace also declares operator,() overloads to ease up assignments in C++ such as 'myVector += 1,2,3,4,5;'.
Dec 07 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jeremie Pelletier" <jeremiep gmail.com> wrote in message 
news:hfjbs4$v35$1 digitalmars.com...
 klickverbot wrote:
 Max Samukha wrote:
 I think the following real-world code is a good argument against comma
 operators:

 template <typename T>
 Q_INLINE_TEMPLATE void QList<T>::node_destruct(Node *from, Node *to)
 {
     if (QTypeInfo<T>::isLarge || QTypeInfo<T>::isStatic)
         while(from != to) --to, delete reinterpret_cast<T*>(to->v);
     else if (QTypeInfo<T>::isComplex)
         while (from != to) --to, reinterpret_cast<T*>(to)->~T();
 }
I have never used the comma operator in my own code, but in my opinion this particular piece of code is really easy and fluent to read. »Maintainability« is admittedly, however, a different topic.
It is still more readable than 'while(from != to--)' or '((--to)->v)'. I myself use the comma operator in for loops and simple assignments such as 'if(something) x = a, y = b;'. The boost::assign namespace also declares operator,() overloads to ease up assignments in C++ such as 'myVector += 1,2,3,4,5;'.
I've noticed that every use I've ever seen mentioned of the comma operator has only been a half-use of it. They all seem to fall into two categories: In one group, there's things like 'for' loops and the QList and if() examples above that don't make any use whatsoever of the comma operator's return value. Then in the other group there are operator overloading uses like boost::assign above that use only the comma operator's syntax, but throw away its semantics.
Dec 07 2009
prev sibling parent Kagamin <spam here.lot> writes:
Jeremie Pelletier Wrote:

 I myself use the comma operator in for loops and simple assignments such 
 as 'if(something) x = a, y = b;'.
also: for(...) if(test) found=TRUE, break; if(found)...
Dec 08 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
bearophile wrote:
 5 ^^ 2 doesn't work yet, I guess it's not implemented yet.
 But what do I have to import from math to use 5.2 ^^ 2 ?
 Anyway, the need to explicitly import something to use a built-in operator
like ^^ looks like a bad idea.
A very bad idea indeed! The idea is to save keystrokes... Can't "import std.math : pow;" be added to the current module when this is needed?
Dec 05 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Ary Borenszweig:
 Can't "import std.math : pow;" be added to the current module when this 
 is needed?
Note that this code doesn't compile: import std.stdio: writeln; import std.math: pow; void main() { writeln(5.2 ^^ 2); } This is what the compiler shows: test.d(5): Error: undefined identifier module test.std test.d(5): Error: no property 'math' for type 'void' Error: no property 'pow' for type 'int' test.d(5): Error: function expected before (), not __error of type int Tool completed with exit code 1 Bye, bearophile
Dec 05 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Ary Borenszweig wrote:
 bearophile wrote:
 5 ^^ 2 doesn't work yet, I guess it's not implemented yet.
 But what do I have to import from math to use 5.2 ^^ 2 ?
 Anyway, the need to explicitly import something to use a built-in 
 operator like ^^ looks like a bad idea.
A very bad idea indeed! The idea is to save keystrokes... Can't "import std.math : pow;" be added to the current module when this is needed?
I'll just explain the situation here. I provided a patch to DMD for opPow, with ^^. The patch was very minimal, since I did not know if Walter would accept it. It's not worth putting a whole lot of effort into something which will just be rejected (and it has less chance of acceptance if it is complicated). In the end, he did include the patch, though without opPowAssign. I did the absolute bare minimum required to get ^^ working. In my patch, I clearly stated that the requirement to include std.math.pow is temporary. BTW, One of the nice things about ^^ is that we will finally be able to do integer powers without necessarily using floating-point. All kinds of stuff is still missing. a ^^ b won't be constant-folded, for example. It's desperately important that the language spec becomes stable before Andrei's book comes out. That leaves only a couple more releases left in D2 where features can be added. Some, like this one, will have rough edges. Don't think of it as fully implemented feature.
Dec 05 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Don (nospam nospam.com)'s article
 All kinds of stuff is still missing. a ^^ b won't be constant-folded,
 for example.
 It's desperately important that the language spec becomes stable before
 Andrei's book comes out. That leaves only a couple more releases left in
 D2 where features can be added. Some, like this one, will have rough
 edges. Don't think of it as fully implemented feature.
If we do find bugs in it, should we still file bug reports, or is the feature still so experimental that filing these would just be noise?
Dec 05 2009
parent Don <nospam nospam.com> writes:
dsimcha wrote:
 == Quote from Don (nospam nospam.com)'s article
 All kinds of stuff is still missing. a ^^ b won't be constant-folded,
 for example.
 It's desperately important that the language spec becomes stable before
 Andrei's book comes out. That leaves only a couple more releases left in
 D2 where features can be added. Some, like this one, will have rough
 edges. Don't think of it as fully implemented feature.
If we do find bugs in it, should we still file bug reports, or is the feature still so experimental that filing these would just be noise?
I just patched the bug you reported. Putting together a test suite mightn't be a bad idea.
Dec 05 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  4 de diciembre a las 20:05 me escribiste:
 Probably the biggest thing is opDispatch!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.053.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.037.zip
 
 Many thanks to the numerous people who contributed to this update.
Great! Can you tag the new releases? (and maybe the old ones too ;) This should be enough: svn cp http://svn.dsource.org/projects/dmd/branches/dmd-1.x http://svn.dsource.org/projects/dmd/tags/dmd-1.053 svn cp http://svn.dsource.org/projects/dmd/trunk http://svn.dsource.org/projects/dmd/tags/dmd-2.037 The same should be done in the phobos and druntime repositories. Thanks! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Cuando le dije si quería bailar conmigo Se puso a hablar de Jung, de Freud y Lacan Mi idiosincracia le causaba mucha gracia Me dijo al girar la cumbiera intelectual
Dec 05 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Leandro Lucarella, el  5 de diciembre a las 13:07 me escribiste:
 Walter Bright, el  4 de diciembre a las 20:05 me escribiste:
 Probably the biggest thing is opDispatch!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.053.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.037.zip
 
 Many thanks to the numerous people who contributed to this update.
Great! Can you tag the new releases? (and maybe the old ones too ;) This should be enough: svn cp http://svn.dsource.org/projects/dmd/branches/dmd-1.x http://svn.dsource.org/projects/dmd/tags/dmd-1.053 svn cp http://svn.dsource.org/projects/dmd/trunk http://svn.dsource.org/projects/dmd/tags/dmd-2.037
Thanks for the tagging :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- If you do not change your beliefs Your life will always be like this
Dec 08 2009
prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 05 Dec 2009 05:05:13 +0100, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
I get a compile error: std\conv.d(2506): Error: undefined identifier module traits.staticIndexOf Line 2506 in std.conv should be changed from if (std.traits.staticIndexOf!(Unqual!S, uint, ulong) >= 0 && isSomeString!T) to if (std.typetuple.staticIndexOf!(Unqual!S, uint, ulong) >= 0 && isSomeString!T) -- Simen
Dec 05 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Simen kjaeraas wrote:
 I get a compile error:
   std\conv.d(2506): Error: undefined identifier module traits.staticIndexOf
 Line 2506 in std.conv should be changed from
   if (std.traits.staticIndexOf!(Unqual!S, uint, ulong) >= 0 && 
 isSomeString!T)
 to
   if (std.typetuple.staticIndexOf!(Unqual!S, uint, ulong) >= 0 && 
 isSomeString!T)
That change is already in the release. Perhaps you have an old version?
Dec 05 2009
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 06 Dec 2009 03:35:42 +0100, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Simen kjaeraas wrote:
 I get a compile error:
   std\conv.d(2506): Error: undefined identifier module  
 traits.staticIndexOf
 Line 2506 in std.conv should be changed from
   if (std.traits.staticIndexOf!(Unqual!S, uint, ulong) >= 0 &&  
 isSomeString!T)
 to
   if (std.typetuple.staticIndexOf!(Unqual!S, uint, ulong) >= 0 &&  
 isSomeString!T)
That change is already in the release. Perhaps you have an old version?
So it would indeed seem. Sorry about the noise. -- Simen
Dec 05 2009
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Walter Bright wrote:
 Probably the biggest thing is opDispatch!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.053.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.037.zip
 
 Many thanks to the numerous people who contributed to this update.
Thanks, guys! This is a pretty awesome release. :) I especially like that opPow made it in, and also the changes to std.math look very useful. I have one question regarding the latter: What exactly is supposed to happen when I run the example in the FloatingPointControl documentation? Is the program supposed to crash with some informative error message, or do I have to do something to catch the exception? Currently, nothing out of the ordinary happens when I run it on my computer -- y just becomes NaN when x is NaN. -Lars
Dec 07 2009
parent reply Don <nospam nospam.com> writes:
Lars T. Kyllingstad wrote:
 Walter Bright wrote:
 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
Thanks, guys! This is a pretty awesome release. :) I especially like that opPow made it in, and also the changes to std.math look very useful. I have one question regarding the latter: What exactly is supposed to happen when I run the example in the FloatingPointControl documentation? Is the program supposed to crash with some informative error message, or do I have to do something to catch the exception? Currently, nothing out of the ordinary happens when I run it on my computer -- y just becomes NaN when x is NaN.
Aargh, the example's wrong. DMD optimizes the assignment into a blit. Try setting y = x*2.
Dec 07 2009
parent reply Don <nospam nospam.com> writes:
Don wrote:
 Lars T. Kyllingstad wrote:
 Walter Bright wrote:
 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
Thanks, guys! This is a pretty awesome release. :) I especially like that opPow made it in, and also the changes to std.math look very useful. I have one question regarding the latter: What exactly is supposed to happen when I run the example in the FloatingPointControl documentation? Is the program supposed to crash with some informative error message, or do I have to do something to catch the exception? Currently, nothing out of the ordinary happens when I run it on my computer -- y just becomes NaN when x is NaN.
Aargh, the example's wrong. DMD optimizes the assignment into a blit. Try setting y = x*2.
I take that back. The example is correct. This code... ----- import std.math; void main() { real x; FloatingPointControl fpctrl; fpctrl.enableExceptions(FloatingPointControl.severeExceptions); double y = x*3.0; } ---- results in: object.Error: Invalid Floating Point Operation However, it seems that the compiler is no longer creating variables of type double and float as signalling NaNs. That's a bug.
Dec 07 2009
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:
 Don wrote:
 Lars T. Kyllingstad wrote:
 Walter Bright wrote:
 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
Thanks, guys! This is a pretty awesome release. :) I especially like that opPow made it in, and also the changes to std.math look very useful. I have one question regarding the latter: What exactly is supposed to happen when I run the example in the FloatingPointControl documentation? Is the program supposed to crash with some informative error message, or do I have to do something to catch the exception? Currently, nothing out of the ordinary happens when I run it on my computer -- y just becomes NaN when x is NaN.
Aargh, the example's wrong. DMD optimizes the assignment into a blit. Try setting y = x*2.
I take that back. The example is correct. This code... ----- import std.math; void main() { real x; FloatingPointControl fpctrl; fpctrl.enableExceptions(FloatingPointControl.severeExceptions); double y = x*3.0; } ---- results in: object.Error: Invalid Floating Point Operation However, it seems that the compiler is no longer creating variables of type double and float as signalling NaNs. That's a bug.
OK, thanks for explaining. :) -Lars
Dec 07 2009
parent reply Don <nospam nospam.com> writes:
Lars T. Kyllingstad wrote:
 Don wrote:
 Don wrote:
 Lars T. Kyllingstad wrote:
 Walter Bright wrote:
 Probably the biggest thing is opDispatch!

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


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

 Many thanks to the numerous people who contributed to this update.
Thanks, guys! This is a pretty awesome release. :) I especially like that opPow made it in, and also the changes to std.math look very useful. I have one question regarding the latter: What exactly is supposed to happen when I run the example in the FloatingPointControl documentation? Is the program supposed to crash with some informative error message, or do I have to do something to catch the exception? Currently, nothing out of the ordinary happens when I run it on my computer -- y just becomes NaN when x is NaN.
Aargh, the example's wrong. DMD optimizes the assignment into a blit. Try setting y = x*2.
I take that back. The example is correct. This code... ----- import std.math; void main() { real x; FloatingPointControl fpctrl; fpctrl.enableExceptions(FloatingPointControl.severeExceptions); double y = x*3.0; } ---- results in: object.Error: Invalid Floating Point Operation However, it seems that the compiler is no longer creating variables of type double and float as signalling NaNs. That's a bug.
OK, thanks for explaining. :) -Lars
I had a further look at this. The compiler *is* creating doubles and floats as signalling NaNs. Turns out, that there are slight differences between processors in the way they treat signalling NaNs, especially between Intel vs AMD. Intel Core2 triggers SNANs when loading floats & doubles, but *doesn't* trigger for 80-bit SNANs. The Pentium M that I did most of my testing on, didn't trigger for any of them. AMD's docs say that it triggers for all of them. Won't be too hard to fix.
Dec 10 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 I had a further look at this. The compiler *is* creating doubles and 
 floats as signalling NaNs. Turns out, that there are slight differences 
 between processors in the way they treat signalling NaNs, especially 
 between Intel vs AMD. Intel Core2 triggers SNANs when loading floats & 
 doubles, but *doesn't* trigger for 80-bit SNANs. The Pentium M that I 
 did most of my testing on, didn't trigger for any of them. AMD's docs 
 say that it triggers for all of them.
 Won't be too hard to fix.
How do we fix the CPU? ;-)
Dec 10 2009
next sibling parent reply Brad Roberts <braddr bellevue.puremagic.com> writes:
On Thu, 10 Dec 2009, Walter Bright wrote:

 Don wrote:
 I had a further look at this. The compiler *is* creating doubles and floats
 as signalling NaNs. Turns out, that there are slight differences between
 processors in the way they treat signalling NaNs, especially between Intel
 vs AMD. Intel Core2 triggers SNANs when loading floats & doubles, but
 *doesn't* trigger for 80-bit SNANs. The Pentium M that I did most of my
 testing on, didn't trigger for any of them. AMD's docs say that it triggers
 for all of them.
 Won't be too hard to fix.
How do we fix the CPU? ;-)
A soldering iron with a really sharp point? Or maybe a sledgehammer.
Dec 10 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 On Thu, 10 Dec 2009, Walter Bright wrote:
 
 Don wrote:
 I had a further look at this. The compiler *is* creating doubles and floats
 as signalling NaNs. Turns out, that there are slight differences between
 processors in the way they treat signalling NaNs, especially between Intel
 vs AMD. Intel Core2 triggers SNANs when loading floats & doubles, but
 *doesn't* trigger for 80-bit SNANs. The Pentium M that I did most of my
 testing on, didn't trigger for any of them. AMD's docs say that it triggers
 for all of them.
 Won't be too hard to fix.
How do we fix the CPU? ;-)
A soldering iron with a really sharp point? Or maybe a sledgehammer.
I was thinking 220VAC might help!
Dec 10 2009
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Brad Roberts wrote:
 On Thu, 10 Dec 2009, Walter Bright wrote:

 Don wrote:
 I had a further look at this. The compiler *is* creating doubles and floats
 as signalling NaNs. Turns out, that there are slight differences between
 processors in the way they treat signalling NaNs, especially between Intel
 vs AMD. Intel Core2 triggers SNANs when loading floats & doubles, but
 *doesn't* trigger for 80-bit SNANs. The Pentium M that I did most of my
 testing on, didn't trigger for any of them. AMD's docs say that it triggers
 for all of them.
 Won't be too hard to fix.
How do we fix the CPU? ;-)
A soldering iron with a really sharp point? Or maybe a sledgehammer.
I was thinking 220VAC might help!
Yep, on that voltage 10 GHz overclocks seems possible.
Dec 10 2009
prev sibling parent BCS <none anon.com> writes:
Hello Walter,

 How do we fix the CPU? ;-)
 
I was thinking 220VAC might help!
That one way to be totally sure what is wrong with your CPU.
Dec 11 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 Don wrote:
 I had a further look at this. The compiler *is* creating doubles and 
 floats as signalling NaNs. Turns out, that there are slight 
 differences between processors in the way they treat signalling NaNs, 
 especially between Intel vs AMD. Intel Core2 triggers SNANs when 
 loading floats & doubles, but *doesn't* trigger for 80-bit SNANs. The 
 Pentium M that I did most of my testing on, didn't trigger for any of 
 them. AMD's docs say that it triggers for all of them.
 Won't be too hard to fix.
How do we fix the CPU? ;-)
Yeah. Actually the CPU problem is an accepts-invalid bug. It worked on my Pentium M, but it shouldn't have. The problem is what DMD does to the "uninitialized assignments". float x; gets changed into float x = double.snan; and is implemented with fld float.snan; fstp x; The FLD is triggering the snan. They should be changed into mov EAX, reinterpret_cast<int>(float.snan); mov x, EAX; There's another reason for doing this. On Pentium 4, x87 NaNs are incredibly slow. More than 250 cycles!!! On AMD and on Pentium 4 SSE2, they are the same as any other value (about 0.5 cycles). Yet another reason to hate the P4. But still, this is such a horrific performance killer that we ought to avoid it.
Dec 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Yeah. Actually the CPU problem is an accepts-invalid bug. It worked on 
 my Pentium M, but it shouldn't have.
 The problem is what DMD does to the "uninitialized assignments".
 
 float x;
 
 gets changed into
 
 float x = double.snan;
 
 and is implemented with
 fld float.snan; fstp x;
 
 The FLD is triggering the snan. They should be changed into mov EAX, 
 reinterpret_cast<int>(float.snan); mov x, EAX;
Sounds like a good idea.
 There's another reason for doing this. On Pentium 4, x87 NaNs are 
 incredibly slow. More than 250 cycles!!! On AMD and on Pentium 4 SSE2, 
 they are the same as any other value (about 0.5 cycles). Yet another 
 reason to hate the P4. But still, this is such a horrific performance 
 killer that we ought to avoid it.
I had no idea that was the case!
Dec 11 2009
parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 Don wrote:
 Yeah. Actually the CPU problem is an accepts-invalid bug. It worked on 
 my Pentium M, but it shouldn't have.
 The problem is what DMD does to the "uninitialized assignments".

 float x;

 gets changed into

 float x = double.snan;

 and is implemented with
 fld float.snan; fstp x;

 The FLD is triggering the snan. They should be changed into mov EAX, 
 reinterpret_cast<int>(float.snan); mov x, EAX;
Sounds like a good idea.
 There's another reason for doing this. On Pentium 4, x87 NaNs are 
 incredibly slow. More than 250 cycles!!! On AMD and on Pentium 4 SSE2, 
 they are the same as any other value (about 0.5 cycles). Yet another 
 reason to hate the P4. But still, this is such a horrific performance 
 killer that we ought to avoid it.
I had no idea that was the case!
I only just discovered it. Every documentation I've seen just said "These [cycle count] values are for normal operands. NaNs, infinities, and denormals may increase cycle counts considerably." I found a blog of someone who'd actually measured it.
Dec 11 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Dec 11, 2009 at 9:34 PM, Don <nospam nospam.com> wrote:
 Walter Bright wrote:
 Don wrote:
 Yeah. Actually the CPU problem is an accepts-invalid bug. It worked on my
 Pentium M, but it shouldn't have.
 The problem is what DMD does to the "uninitialized assignments".

 float x;

 gets changed into

 float x = double.snan;

 and is implemented with
 fld float.snan; fstp x;

 The FLD is triggering the snan. They should be changed into mov EAX,
 reinterpret_cast<int>(float.snan); mov x, EAX;
Sounds like a good idea.
 There's another reason for doing this. On Pentium 4, x87 NaNs are
 incredibly slow. More than 250 cycles!!! On AMD and on Pentium 4 SSE2, they
 are the same as any other value (about 0.5 cycles). Yet another reason to
 hate the P4. But still, this is such a horrific performance killer that we
 ought to avoid it.
I had no idea that was the case!
I only just discovered it. Every documentation I've seen just said "These [cycle count] values are for normal operands. NaNs, infinities, and denormals may increase cycle counts considerably." I found a blog of someone who'd actually measured it.
I experienced it in a fluid sim I was working on in grad school. NaNs were creeping in and performance was terrible. I thought it was two problems till I got rid of the NaNs and suddenly performance was ok too. --bb
Dec 12 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Fri, Dec 11, 2009 at 9:34 PM, Don <nospam nospam.com> wrote:
 Walter Bright wrote:
 Don wrote:
 Yeah. Actually the CPU problem is an accepts-invalid bug. It worked on my
 Pentium M, but it shouldn't have.
 The problem is what DMD does to the "uninitialized assignments".

 float x;

 gets changed into

 float x = double.snan;

 and is implemented with
 fld float.snan; fstp x;

 The FLD is triggering the snan. They should be changed into mov EAX,
 reinterpret_cast<int>(float.snan); mov x, EAX;
Sounds like a good idea.
 There's another reason for doing this. On Pentium 4, x87 NaNs are
 incredibly slow. More than 250 cycles!!! On AMD and on Pentium 4 SSE2, they
 are the same as any other value (about 0.5 cycles). Yet another reason to
 hate the P4. But still, this is such a horrific performance killer that we
 ought to avoid it.
I had no idea that was the case!
I only just discovered it. Every documentation I've seen just said "These [cycle count] values are for normal operands. NaNs, infinities, and denormals may increase cycle counts considerably." I found a blog of someone who'd actually measured it.
I experienced it in a fluid sim I was working on in grad school. NaNs were creeping in and performance was terrible. I thought it was two problems till I got rid of the NaNs and suddenly performance was ok too. --bb
Almost same here. Program was amazingly slow until I figured there were NaNs involved. It would be great if we could eliminate that behavior. Andrei
Dec 12 2009
prev sibling parent reply Nick Treleaven <nospam example.net> writes:
On Fri, 04 Dec 2009 20:05:13 -0800, Walter Bright wrote:

 Probably the biggest thing is opDispatch!
Sounds great :) But I think there's a minor typo here: http://www.digitalmars.com/d/2.0/operatoroverloading.html#Dispatch class C { void opDispatch(string s)(int i) { writefln("S.opDispatch('%s', %s)", s, i); The writefln should be C.opDispatch Apologies if already reported elsewhere...
Dec 08 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Nick Treleaven wrote:
 Apologies if already reported elsewhere...
Nope. Thanks! Fixed.
Dec 08 2009