Re: dmd 1.053 and 2.037 release
On Fri, Dec 11, 2009 at 9:34 PM, Don nos...@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_castint(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
Re: dmd 1.053 and 2.037 release
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_castint(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.
Re: dmd 1.053 and 2.037 release
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.
Re: dmd 1.053 and 2.037 release
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_castint(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.
Re: dmd 1.053 and 2.037 release
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? ;-)
Re: dmd 1.053 and 2.037 release
== Quote from Walter Bright (newshou...@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.
Re: dmd 1.053 and 2.037 release
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)...
Re: dmd 1.053 and 2.037 release - minor docs typo
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...
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
On Sun, 06 Dec 2009 23:43:16 -0600, Andrei Alexandrescu
seewebsiteforem...@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 QListT::node_destruct(Node *from, Node *to)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
while(from != to) --to, delete reinterpret_castT*(to-v);
else if (QTypeInfoT::isComplex)
while (from != to) --to, reinterpret_castT*(to)-~T();
}
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
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 n...@property functions. -Lars
Re: dmd 1.053 and 2.037 release
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.
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
Max Samukha wrote:
I think the following real-world code is a good argument against comma
operators:
template typename T
Q_INLINE_TEMPLATE void QListT::node_destruct(Node *from, Node *to)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
while(from != to) --to, delete reinterpret_castT*(to-v);
else if (QTypeInfoT::isComplex)
while (from != to) --to, reinterpret_castT*(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.
Re: dmd 1.053 and 2.037 release
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 QListT::node_destruct(Node *from, Node *to)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
while(from != to) --to, delete reinterpret_castT*(to-v);
else if (QTypeInfoT::isComplex)
while (from != to) --to, reinterpret_castT*(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;'.
Re: dmd 1.053 and 2.037 release
Jeremie Pelletier jerem...@gmail.com wrote in message
news:hfjbs4$v3...@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 QListT::node_destruct(Node *from, Node *to)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
while(from != to) --to, delete reinterpret_castT*(to-v);
else if (QTypeInfoT::isComplex)
while (from != to) --to, reinterpret_castT*(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.
Re: dmd 1.053 and 2.037 release
On Sat, 5 Dec 2009 10:59:12 -0500, Nick Sabalausky a...@a.a wrote: Max Samukha spam...@d-coding.com wrote in message news:pkvkh5tvvhie0ga61lrpp5qmt53h5ju...@4ax.com... On Sat, 5 Dec 2009 10:19:23 -0500, Nick Sabalausky a...@a.a wrote: bearophile bearophileh...@lycos.com wrote in message news:hfdt87$1nu...@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.
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
On Fri, 04 Dec 2009 20:05:13 -0800, Walter Bright newshou...@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?
Re: dmd 1.053 and 2.037 release
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 ?
Re: dmd 1.053 and 2.037 release
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 !
Re: dmd 1.053 and 2.037 release
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!
Re: dmd 1.053 and 2.037 release
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.
Re: dmd 1.053 and 2.037 release
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...
Re: dmd 1.053 and 2.037 release
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.
Re: dmd 1.053 and 2.037 release
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;
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
bearophile bearophileh...@lycos.com wrote in message news:hfdt87$1nu...@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
Re: dmd 1.053 and 2.037 release
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?
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
== Quote from Don (nos...@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?
Re: dmd 1.053 and 2.037 release
dsimcha wrote: == Quote from Don (nos...@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.
Re: dmd 1.053 and 2.037 release
On Sat, 05 Dec 2009 05:05:13 +0100, Walter Bright newshou...@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
Re: dmd 1.053 and 2.037 release
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?
Re: dmd 1.053 and 2.037 release
On Sun, 06 Dec 2009 03:35:42 +0100, Walter Bright newshou...@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
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
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.
