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