Re: dmd 1.062 and 2.047 release
I am back.
From the v2.047 changelog:
std.conv: Added file and line information to conversion errors; added brackets
'[' and ']' around arrays and associative arrays as defaults; added emplace()
for non-class types.
This program:
import std.stdio: writeln;
import std.conv: to;
void main() {
int[] a = [1, 2, 3];
writeln(to!string(a));
writeln(a);
}
Prints:
[1 2 3]
1 2 3
But I think if they produce the same default output.
Like:
[1, 2, 3]
[1, 2, 3]
--
I have reopened bug 4109 and in the meantime Shin Fujishiro has closed it
again. He looks efficient :-)
Bye,
bearophile
Re: dmd 1.062 and 2.047 release
bearophile wrote:
I am back.
From the v2.047 changelog:
std.conv: Added file and line information to conversion errors; added brackets '['
and ']' around arrays and associative arrays as defaults; added emplace() for
non-class types.
This program:
import std.stdio: writeln;
import std.conv: to;
void main() {
int[] a = [1, 2, 3];
writeln(to!string(a));
writeln(a);
}
Prints:
[1 2 3]
1 2 3
But I think if they produce the same default output.
Like:
[1, 2, 3]
[1, 2, 3]
--
I have reopened bug 4109 and in the meantime Shin Fujishiro has closed it
again. He looks efficient :-)
Bye,
bearophile
Thank you guys. Indeed that was my intent.
Andrei
Re: dmd 1.062 and 2.047 release
Andrei Alexandrescu: Thank you guys. Indeed that was my intent. What do you mean? Bye, bearophile
Re: dmd 1.062 and 2.047 release
What do you mean? I have now understood :-)
Re: dmd 1.062 and 2.047 release
torhu Wrote:
I tried the example on page 406-407 of the book (copying stdin to stdout
using message passing). I don't mean to be a killjoy, but it doesn't
compile. :(
I'm using the latest pdf version of the book, and dmd 2.047.
I get this:
---
d:\prog\dmd\bin\..\src\phobos\std\stdio.d(1902): Error: cannot
implicitly conver
t expression (buffer) of type ubyte[] to immutable(ubyte)[]
d:\prog\dmd\bin\..\src\phobos\std\stdio.d(7): Error: template instance
std.stdio
.chunks.opApply!(int delegate(ref immutable(ubyte)[] __applyArg0)) error
instant
iating
---
stdin.byChunk uses a mutable buffer that's overwritten for each chunk so you
can't ask for an immutable ubyte[] in the foreach line. Here's the version of
that sample I used to test (13.7):
import std.algorithm, std.concurrency, std.stdio;
void main()
{
enum bufferSize = 10;
auto tid = spawn( fileWriter );
// Read loop
foreach( ubyte[] buffer; stdin.byChunk( bufferSize ) )
send( tid, buffer.idup );
}
void fileWriter()
{
// Write loop
for( ; ; )
{
auto buffer = receiveOnly!(immutable(ubyte)[])();
writeln( rx: , buffer );
}
}
Re: dmd 1.062 and 2.047 release
On 15.06.2010 00:45, Sean Kelly wrote:
stdin.byChunk uses a mutable buffer that's overwritten for each chunk so you
can't ask for an immutable ubyte[] in the foreach line. Here's the version of
that sample I used to test (13.7):
import std.algorithm, std.concurrency, std.stdio;
void main()
{
enum bufferSize = 10;
auto tid = spawn(fileWriter );
// Read loop
foreach( ubyte[] buffer; stdin.byChunk( bufferSize ) )
send( tid, buffer.idup );
}
void fileWriter()
{
// Write loop
for( ; ; )
{
auto buffer = receiveOnly!(immutable(ubyte)[])();
writeln( rx: , buffer );
}
}
Right, now where's the bugzilla for TDPL? :)
Re: [ot] D users at Google
On 06/07/2010 10:09 PM, BCS wrote: IIRC there are a few D users who work for Google (I know there is now at least one :D ) but I don't remember who. For that matter, are there other D users in the Mountain View/San Jose area? Man, I'm late to the game responding. I'm in the east bay, working in Berkeley. Does that count? =) (I work at Tippett Studio, doing movie VFX, and a coworker also was ordering TDPL, so there's two of us that at least play with D from time to time and watch its progress). -Mike
Re: Is the declaration grammar definition of 'Parameter' correct?
BCS wrote: That would be a start as well as a necessary step in getting a extractor working (to test the tools output against), but if the docs and the parser are maintained separately, the docs will be wrong sooner rather than later. I think that's very unlikely to be true. The existing errors in the grammer have formed during the long development of the language, and the grammer docs never really got much attention. Now that the language has stabilised, the grammer is not going to change rapidly enough to be major source of errors. The effort involved in making a tool to do it, probably exceeds the effort involved in just fixing it, by a factor of five or ten. There are many other things which could be done which would FAR more useful for D.
Re: Price drop for TDPL on Amazon to $41.10eom
On amazon.co.uk it costs £18.50, which is roughly $26. http://www.amazon.co.uk/D-Programming-Language-Andrei-Alexandrescu/ dp/0321635361/ref=sr_1_1?ie=UTF8s=booksqid=1276503587sr=1-1 -Lars
Re: Price drop for TDPL on Amazon to $41.10eom
Lars T. Kyllingstad wrote: On amazon.co.uk it costs £18.50, which is roughly $26. http://www.amazon.co.uk/D-Programming-Language-Andrei-Alexandrescu/ dp/0321635361/ref=sr_1_1?ie=UTF8s=booksqid=1276503587sr=1-1 -Lars Wow, 50% - that's pretty awesome. Amazon seems to be carrying an aggressive kick-off campaign to TDPL. This is a good sign; a similar campaign worked well for Modern C++ Design. By the way, UK sales are almost equal in gross volume to US sales, which means they're much higher percentage-wise. Kudos to UK hackers! Andrei
Re: Price drop for TDPL on Amazon to $41.10eom
Although the price is very good on Amazon, one needs to wait till August to get a copy of the book. I've followed the advice from some other people on the NG, cancelled my amazon order and went to Informit ($49.99 + $9 to ship to the UK). Ordered it last week Thursday and it's already shipped by now...can't wait to get my hands on it! ~ Filip
Re: Price drop for TDPL on Amazon to $41.10eom
I pre-ordered it from http://www.bookdepository.co.uk/book/9780321635365/The-D-Programming-Language, who now have it listed as dispatched within 48 hours, so hopefully won't have to wait too long :-)
Re: Price drop for TDPL on Amazon to $41.10eom
I cancelled with amazon last week and ordered with informit. Got it this morning. On Mon, 14 Jun 2010 11:21:40 +0200, filgood fi...@wuytack.net wrote: Although the price is very good on Amazon, one needs to wait till August to get a copy of the book. I've followed the advice from some other people on the NG, cancelled my amazon order and went to Informit ($49.99 + $9 to ship to the UK). Ordered it last week Thursday and it's already shipped by now...can't wait to get my hands on it! ~ Filip
Re: TDPL shipping off Amazon
On 11.6.2010 18:34, Andrei Alexandrescu wrote: Looks like Amazon has finally stocked up on TDPL and is delivering it as of today. Just received my Collector's Edition. :) O.
Re: Price drop for TDPL on Amazon to $41.10eom
On Mon, 14 Jun 2010 11:59:41 +0200, Rory McGuire rmcgu...@neonova.co.za wrote: I cancelled with amazon last week and ordered with informit. Got it this morning. On Mon, 14 Jun 2010 11:21:40 +0200, filgood fi...@wuytack.net wrote: Although the price is very good on Amazon, one needs to wait till August to get a copy of the book. I've followed the advice from some other people on the NG, cancelled my amazon order and went to Informit ($49.99 + $9 to ship to the UK). Ordered it last week Thursday and it's already shipped by now...can't wait to get my hands on it! ~ Filip PS: I'm in South Africa
Re: Is there a way to get the names of a function's parameters?
On 2010-06-14 00:56, Adam Ruppe wrote: Given: void foo(int a, string b); You can use std.traits.ParameterTypeTuple to get (int, string). Is there any method, at all, to get (a, b) out of it? I can't find one, and am considering import(mysrc.d); and finding it that way, but figured I'd ask first. The benefits of getting the names would be runtime function calls, or named arguments. Consider this: ParameterTuple!foo args; args.b = hello; foo(args); That'd be kinda cool. Here you go: http://tango.pastebin.com/M38jdhGd including calling using named arguments. -- /Jacob Carlborg
Re: TDPL shipping off Amazon
Olli Aalto wrote: On 11.6.2010 18:34, Andrei Alexandrescu wrote: Looks like Amazon has finally stocked up on TDPL and is delivering it as of today. Just received my Collector's Edition. :) O. I'm starting to sweat over here. Andrei
Re: Is there a way to get the names of a function's parameters?
Jacob Carlborg d...@me.com wrote:
Here you go: http://tango.pastebin.com/M38jdhGd including calling using
named arguments.
Does not handle function/delegate return types.
struct S {}
void function(int delegate(float)) F(string delegate(), string
function(string, string), float, double, S);
writeln(Parameters: , parameterNamesOf!F);
Gives:
Parameters: delegate(float
One needs to match parentheses from the last parentheses in the
typeof.stringof.
--
Simen
Re: Is there a way to get the names of a function's parameters?
Simen kjaeraas simen.kja...@gmail.com wrote:
One needs to match parentheses from the last parentheses in the
typeof.stringof.
string parameterNamesOf( alias fn )( ) {
string fullName = typeof(fn).stringof;
int pos = fullName.lastIndexOf( ')' );
int end = pos;
int count = 0;
do {
if ( fullName[pos] == ')' ) {
count++;
} else if ( fullName[pos] == '(' ) {
count--;
}
pos--;
} while ( count 0 );
return fullName[pos+2..end];
}
--
Simen
Re: Constrained Templates
Leandro Lucarella llu...@gmail.com wrote:
it would be nice
to have some sort of way to tell the compiler to write the template
constraints for us (the obvious ones at least, there might be other
template constraints desired besides the ones the ones the compiler can
figure out). This way, the errors can be improved without user
intervention.
How's about @optional? Marks an entire function as optional, i.e. will
not be included if it does not compile.
struct foo( T ) {
@optional
void bar( ) { // Will not exist if T cannot be flabbergasted.
T tmp;
t.flabbergast( );
}
}
--
Simen
Re: Constrained Templates
Simen kjaeraas Wrote:
Leandro Lucarella llu...@gmail.com wrote:
it would be nice
to have some sort of way to tell the compiler to write the template
constraints for us (the obvious ones at least, there might be other
template constraints desired besides the ones the ones the compiler can
figure out). This way, the errors can be improved without user
intervention.
How's about @optional? Marks an entire function as optional, i.e. will
not be included if it does not compile.
struct foo( T ) {
@optional
void bar( ) { // Will not exist if T cannot be flabbergasted.
T tmp;
t.flabbergast( );
}
}
--
Simen
Would it be a bug or a feature if bar was never included? As written, bar
should never compile...
Re: Constrained Templates
Simen kjaeraas wrote:
Leandro Lucarella llu...@gmail.com wrote:
it would be nice
to have some sort of way to tell the compiler to write the template
constraints for us (the obvious ones at least, there might be other
template constraints desired besides the ones the ones the compiler can
figure out). This way, the errors can be improved without user
intervention.
How's about @optional? Marks an entire function as optional, i.e. will
not be included if it does not compile.
struct foo( T ) {
@optional
void bar( ) { // Will not exist if T cannot be flabbergasted.
T tmp;
t.flabbergast( );
}
}
This can be trivially shown to be NP-complete.
void bar(T)()
{
static if ( big_function!T) {
T t;
t.flabbergast( );
}
}
Compiler cannot determine if T needs flabbergast(), unless it evaluates
big_function. Which can be arbitrarily complicated.
We're taking the approach of making the default error message in such
cases as helpful as possible.
Re: Constrained Templates
Don nos...@nospam.com wrote:
This can be trivially shown to be NP-complete.
void bar(T)()
{
static if ( big_function!T) {
T t;
t.flabbergast( );
}
}
Compiler cannot determine if T needs flabbergast(), unless it evaluates
big_function. Which can be arbitrarily complicated.
But how does the compiler decide whether or not to include that code
usually? Would it not then also have to evaluate big_function?
We're taking the approach of making the default error message in such
cases as helpful as possible.
Which is likely a better choice. The idea just hit me, and I decided
to probe for reactions.
--
Simen
Re: TDPL shipping off Amazon
On 6/14/2010 3:18 AM, Andrei Alexandrescu wrote: Olli Aalto wrote: On 11.6.2010 18:34, Andrei Alexandrescu wrote: Looks like Amazon has finally stocked up on TDPL and is delivering it as of today. Just received my Collector's Edition. :) O. I'm starting to sweat over here. Andrei Ok, now that's a mental image I didn't need. Ewww.
Re: Price drop for TDPL on Amazon to $41.10eom
I see Amazon has two used copies at $77.14. Why would anyone try to sell a copy at double the price of new, when the new is in stock and shipping?
Re: Price drop for TDPL on Amazon to $41.10eom
On Mon, 14 Jun 2010 13:42:20 -0400, Walter Bright newshou...@digitalmars.com wrote: I see Amazon has two used copies at $77.14. Why would anyone try to sell a copy at double the price of new, when the new is in stock and shipping? Probably the same reason the ask prices for stock go up to 100 times their value at the end of the day. Some people are dumb, and click without thinking. -Steve
D const enables multi-reader synchronization
This is a continuation of a recent thread Synchronized const methods on D.learn. Currently only one thread at a time can execute a synchronized method. But think about D's const -- it's deep, so if a method is const, it can't possibly mutate its object. So many synchronized const method calls could safely look-but-not-touch the same object at the same time. The chain of questions that stems from the above is: 1. Is letting many readers in on an object really safe? Know any multi-threading quirk that would make sh*t hit the fan? 2. If answer to 1. is yes, would there be room in the current implementation of synchronized keyword for a readers-writer lock? 3. If answer to 2. is yes, how do we tackle write-starvation? In a read-mostly scenario the mutating thread may be held up forever. More on readers-writer lock: http://en.wikipedia.org/wiki/Readers-writer_lock Tomek
Re: D const enables multi-reader synchronization
On Mon, 14 Jun 2010, Tomek Sowi?ski wrote: This is a continuation of a recent thread Synchronized const methods on D.learn. Currently only one thread at a time can execute a synchronized method. But think about D's const -- it's deep, so if a method is const, it can't possibly mutate its object. So many synchronized const method calls could safely look-but-not-touch the same object at the same time. The chain of questions that stems from the above is: 1. Is letting many readers in on an object really safe? Know any multi-threading quirk that would make sh*t hit the fan? 2. If answer to 1. is yes, would there be room in the current implementation of synchronized keyword for a readers-writer lock? 3. If answer to 2. is yes, how do we tackle write-starvation? In a read-mostly scenario the mutating thread may be held up forever. More on readers-writer lock: http://en.wikipedia.org/wiki/Readers-writer_lock Tomek Const methods only prevent mutating 'this'. You can still call functions that mutate other state (via globals or passed in arguments). Additionally, I'm also a little concerned about the implications to application performance. Add one method that's non-const and suddenly the app performs somewhat differently and it's hard to tell why. It's an interesting idea, and still worth exploring, but my inclinations are that this should be explicitly setup rather than done behind the scenes. Later, Brad
Constraints error messages [Was: Re: Constrained Templates]
Yao G.:
Something I would like to see with template constraints, is the ability to
show text messages, like when static if is used.
This is a problem I too have.
In D1 I used to write code like:
template Foo(T) {
static assert(condition1, error message1);
static assert(condition2, error message2);
...
}
Now in D2 I usually write:
template Foo(T) if (condition1 condition2) {
...
}
This D2 code is better because error compiler messages are better (at the
template instantiation point instead inside the template body), but it's worse
because I lose the error messages written by me. In simple situations the error
messages are not so important, but in some situations they are useful to
understand why the template input values are wrong.
A syntax like the following allows to add the user-defined error messages too,
but it's bad looking, so probably something quite better can be invented:
template Foo(T)
if (condition1) else pragma(msg, error message1)
if (condition2) else pragma(msg, error message2) {
}
Bye,
bearophile
Re: D const enables multi-reader synchronization
Dnia 14-06-2010 o 21:27:24 Brad Roberts bra...@slice-2.puremagic.com
napisał(a):
On Mon, 14 Jun 2010, Tomek Sowi?ski wrote:
This is a continuation of a recent thread Synchronized const methods
on
D.learn.
Currently only one thread at a time can execute a synchronized method.
But
think about D's const -- it's deep, so if a method is const, it can't
possibly
mutate its object. So many synchronized const method calls could safely
look-but-not-touch the same object at the same time.
The chain of questions that stems from the above is:
1. Is letting many readers in on an object really safe? Know any
multi-threading quirk that would make sh*t hit the fan?
2. If answer to 1. is yes, would there be room in the current
implementation
of synchronized keyword for a readers-writer lock?
3. If answer to 2. is yes, how do we tackle write-starvation? In a
read-mostly
scenario the mutating thread may be held up forever.
More on readers-writer lock:
http://en.wikipedia.org/wiki/Readers-writer_lock
Tomek
Const methods only prevent mutating 'this'. You can still call functions
that mutate other state (via globals or passed in arguments).
But synchronized on a method also protects only 'this', no?. Currently you
can have:
class A { ... }
shared class K {
synchronized void fun(A a) const {
// mutate a
}
}
If you call fun on two instances of K, each in a different thread, but
pass them the same instance of A, you'll get a data race anyway. You could
make fun's arguments const, but still there's shared globals.
Additionally, I'm also a little concerned about the implications to
application performance. Add one method that's non-const and suddenly
the
app performs somewhat differently and it's hard to tell why.
It's an interesting idea, and still worth exploring, but my inclinations
are that this should be explicitly setup rather than done behind the
scenes.
Probably. It's difficult to find info on threading in D2, so it's hard to
imagine how a library implementation could look like.
Tomek
Re: Price drop for TDPL on Amazon to $41.10eom
Steven Schveighoffer wrote: On Mon, 14 Jun 2010 13:42:20 -0400, Walter Bright newshou...@digitalmars.com wrote: I see Amazon has two used copies at $77.14. Why would anyone try to sell a copy at double the price of new, when the new is in stock and shipping? Probably the same reason the ask prices for stock go up to 100 times their value at the end of the day. Some people are dumb, and click without thinking. Did you see the copies at $444 on amazon.com and £444 on amazon.co.uk? Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Signed word lengths and indexes
I have found a Reddit discussion few days old: http://www.reddit.com/r/programming/comments/cdwz5/the_perils_of_unsigned_iteration_in_cc/ It contains this, that I quote (I have no idea if it's true), plus follow-ups: At Google using uints of all kinds for anything other than bitmasks or other inherently bit-y, non computable things is strongly discouraged. This includes things like array sizes, and the warnings for conversion of size_t to int are disabled. I think it's a good call. I have expressed similar ideas here: http://d.puremagic.com/issues/show_bug.cgi?id=3843 Unless someone explains me why I am wrong, I will keep thinking that using unsigned words to represent lengths and indexes, as D does, is wrong and unsafe, and using signed words (I think C# uses ints for that purpose) in D is a better design choice. In a language as greatly numerically unsafe as D (silly C-derived conversion rules, fixed-sized numbers used everywhere on default, no runtime numerical overflows) the usage of unsigned numbers can be justified inside bit vectors, bitwise operations, and few other similar situations only. If D wants to be a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. it must understand that numerical safety is one of the not secondary things that make those languages as Ruby and Python more productive. Bye, bearophile
Re: D const enables multi-reader synchronization
Tomek Sowiński wrote: 3. If answer to 2. is yes, how do we tackle write-starvation? In a read-mostly scenario the mutating thread may be held up forever. I'd say that as soon as someone requests the write lock, nobody can get the read lock anymore. Then when the current readers release the lock, the writer gets it. So you can have the following sequence of events: 1. R1 requests the read lock and gets it; 2. R2 requests the read lock and gets it; 3. W1 requests the write lock and waits; 4. R3 requests the read lock and waits; 5. R4 requests the read lock and waits; 6. R1 and R2 release the lock, W1 gets it; 7. W2 requests the write lock and waits; 8. W1 releases the lock, R3 and R4 get it (since they requested the lock before W2); 9. R5 requests the read lock and waits (since W2 is already waiting for the write lock); 10. R3 and R4 release the lock, W2 gets it; 11. W2 releases the lock, R5 gets it. Of course, this is not optimal: it is conceivable that R3 could have gotten the lock, done whatever it had to do and released the lock before R1 and R2. However, I believe it is the best compromise: it still allowed R1 and R2 to access the object simultaneously, while at the same time ensuring that write starvation cannot occur. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Price drop for TDPL on Amazon to $41.10eom
Am 14.06.2010 22:53, schrieb Jérôme M. Berger: Steven Schveighoffer wrote: On Mon, 14 Jun 2010 13:42:20 -0400, Walter Bright newshou...@digitalmars.com wrote: I see Amazon has two used copies at $77.14. Why would anyone try to sell a copy at double the price of new, when the new is in stock and shipping? Probably the same reason the ask prices for stock go up to 100 times their value at the end of the day. Some people are dumb, and click without thinking. Did you see the copies at $444 on amazon.com and £444 on amazon.co.uk? Jerome These must be computed prices, based on the bestseller lists, and since this book is just released and already in top 100 (currently #88) in Programming/Language and Tools (complete 24,029) ... :) greets Matthias
Re: Signed word lengths and indexes
On Mon, 14 Jun 2010 16:52:04 -0400, bearophile wrote: If D wants to be a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. it must understand that numerical safety is one of the not secondary things that make those languages as Ruby and Python more productive. Bye, bearophile Isn't this why D has foreach and foreach_reverse? -By
Re: Signed word lengths and indexes
Byron Heads: Isn't this why D has foreach and foreach_reverse? If you mean the exact problem the original article was talking about, then you are right. But foreach and foreach_reverse are not enough to solve the general safety problem caused by the widespread usage of unsigned words in a language that at the same time has C conversion rules, uses mostly fixed-sized numbers and lacks run-time integral numerical overflows. Four things that if present at the same time create an explosive mix. I am happy to see that (if that quote is right) Google C++ coding standards agree with me about this. Bye, bearophile
Re: Signed word lengths and indexes
On 14/06/2010 21:52, bearophile wrote:
I have found a Reddit discussion few days old:
http://www.reddit.com/r/programming/comments/cdwz5/the_perils_of_unsigned_iteration_in_cc/
It contains this, that I quote (I have no idea if it's true), plus
follow-ups:
At Google using uints of all kinds for anything other than bitmasks
or other inherently bit-y, non computable things is strongly
discouraged. This includes things like array sizes, and the
warnings for conversion of size_t to int are disabled. I think it's
a good call.
I have expressed similar ideas here:
http://d.puremagic.com/issues/show_bug.cgi?id=3843
Unless someone explains me why I am wrong, I will keep thinking that
using unsigned words to represent lengths and indexes, as D does, is
wrong and unsafe, and using signed words (I think C# uses ints for
that purpose) in D is a better design choice.
Well for a start, you lose half your addressable memory.
unsigned numbers are only a problem if you don't understand how they
work, but that goes for just about everything else as well.
Personally I hate the use of signed numbers as array indices; it's
moronic and demonstrates the writers lack of understanding. It's very
rare to actually want to index an array with a negative number.
Last time I did that was years ago when writing in assembler; and that
was an optimisation hack to squeeze maximum performance out of my code.
c.f.
Item getItem(int indx) {
if(indx = 0 indx _arr.length)
return _arr[indx];
throw new Error(...)
}
vs.
// cleaner no?
Item getItem(uint indx) {
if(indx _arr.length)
return _arr[indx];
throw new Error(...)
}
and backwards iteration:
for(int i = end - 1; i = 0; --i)
...
vs
for(uint i = end - 1; i length; --i)
...
Ok about the same, but I find the second more clear, the
i length clearly indicates iteration over the whole array.
And that second wrong bit of code on the blog is wrong
with signed numbers as well:
int len = strlen(some_c_str);
// say some_c_str is empty so len = 0
int i;
for (i = 0; i len - 1; ++i) {
// so len - 1 == -1
// iterate until i wraps round and becomes -1
}
Using 'int's doesn't magically fix it. Wrong code is just wrong.
I do think that allowing un-casted assignments between signed/unsigned
is a problem though; that's where most of the bugs creep up I've come
across crop up. I think D should simply disallow implicit mixing of
signd-ness.
Hasn't that been discussed before? (I'm not referring to the recent post
in d.learn) It seems familiar.
--
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
Re: Signed word lengths and indexes
div0 wrote: I do think that allowing un-casted assignments between signed/unsigned is a problem though; that's where most of the bugs creep up I've come across crop up. I think D should simply disallow implicit mixing of signd-ness. Andrei and I went down that alley for a while. It's not practical. Hasn't that been discussed before? (I'm not referring to the recent post in d.learn) It seems familiar. Yes, many times.
Re: Signed word lengths and indexes
div0 d...@users.sourceforge.net writes: for(uint i = end - 1; i length; --i) ... What does length represent here? It's not clear to me how i descending toward zero is going to break the guard condition. -- Steven E. Harris
Re: Signed word lengths and indexes
On 06/14/2010 05:48 PM, Walter Bright wrote: bearophile wrote: I have found a Reddit discussion few days old: http://www.reddit.com/r/programming/comments/cdwz5/the_perils_of_unsigned_iteration_in_cc/ It contains this, that I quote (I have no idea if it's true), plus follow-ups: At Google using uints of all kinds for anything other than bitmasks or other inherently bit-y, non computable things is strongly discouraged. This includes things like array sizes, and the warnings for conversion of size_t to int are disabled. I think it's a good call. I have expressed similar ideas here: http://d.puremagic.com/issues/show_bug.cgi?id=3843 Unless someone explains me why I am wrong, I will keep thinking that using unsigned words to represent lengths and indexes, as D does, is wrong and unsafe, and using signed words (I think C# uses ints for that purpose) in D is a better design choice. D provides powerful abstractions for iteration; it is becoming less and less desirable to hand-build loops with for-statements. Ooo ooo, can we remove it? As for unsafe, I think you need to clarify this, as D is not memory unsafe despite the existence of integer over/under flows. I think the problem is people don't generally think of fixnums as fixnums when they use them. Just recently I was reading about some security vulnerabilities in ruby from a few years ago which were caused when whoever wrote the underlying C didn't take integer overflow into consideration. What I take away from this anecdote is that it's that much harder to write trustworthy code in D. As always, the existence of issue 259 doesn't help matters. And from personal experience, I submit that checking for overflow is very painful to do manually (I tried to write a modular arithmetic lib for fixnums - and gave up rather quickly). Want language support (or library support, I don't care). In a language as greatly numerically unsafe as D (silly C-derived conversion rules, Actually, I think they make a lot of sense, and D's improvement on them that only disallows conversions that lose bits based on range propagation is far more sensible than C#'s overzealous restrictions. fixed-sized numbers used everywhere on default, no runtime numerical overflows) the usage of unsigned numbers can be justified inside bit vectors, bitwise operations, and few other similar situations only. If D wants to be a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. it must understand that numerical safety is one of the not secondary things that make those languages as Ruby and Python more productive. I have a hard time believing that Python and Ruby are more productive primarily because they do not have an unsigned type. They're more productive because their built in number types aren't fixnums. That's a nice large class of errors that don't exist in those languages. Python did not add overflow protection until 3.0, so it's very hard to say this crippled productivity in early versions. http://www.python.org/dev/peps/pep-0237/ Ruby Python 3.0 dynamically switch to larger integer types when overflow happens. This is completely impractical in a systems language, and is one reason why Ruby Python are execrably slow compared to C-style languages.
Re: Signed word lengths and indexes
Walter Bright: D provides powerful abstractions for iteration; it is becoming less and less desirable to hand-build loops with for-statements. I agree. As for unsafe, I think you need to clarify this, as D is not memory unsafe despite the existence of integer over/under flows. Modern languages must understand that there are other forms of safety beside memory safety. Integer overflows and signed-unsigned conversion-derived bugs can cause disasters as well. In current D language the usage of unsigned numbers is a safety hazard. So far nothing I have seen written by you or other people has shown that this is false. Actually, I think they make a lot of sense, and D's improvement on them that only disallows conversions that lose bits based on range propagation is far more sensible than C#'s overzealous restrictions. 1) I'd like D to use signed words to represent lengths and array indexes. We are going to 64 bit systems where 63 bits can be enough for lenghts. If arrays of 4 billion items are seen as important on 32 bit systems too, then use a long :-) 2) I don't like D to silently gulp down expressions that mix signed and unsigned integers and spit out wrong results when the integers were negative. I have a hard time believing that Python and Ruby are more productive primarily because they do not have an unsigned type. Python is very productive (for small or medium sized programs! On large programs Python is less good) because of a quite long list of factors. My experience with D and Python (and several other languages) has shown me that Python not using fixnums is one of the factors that help productivity. It's surely not the only factor, and I agree with you that it's not the most important, but it's surely one of the significant factors and it can't be ignored. Python integers don't overflow, this at the same time allows you to safe brain time and brain power thinking about possible overflows and the code to avoid their risk, and makes coding more relaxed. And if you try to write 50 Project Euler programs in Python and D you will surely see how many bugs the Python code has avoided you compared to D. Finding and fixing such bugs in D code requires lot of time that you save in Python. In D there are other bugs derived from mixing signed and unsigned numbers (and you can't avoid them just avoiding using unsigned numbers in your code, because lenghts and indexes and other things use them). Python did not add overflow protection until 3.0, so it's very hard to say this crippled productivity in early versions. http://www.python.org/dev/peps/pep-0237/ You are wrong. Python 2.x dynamically switches to larger integer types when overflow happens. This is done transparently and avoids bugs and keeps programs more efficient. This is on Python V.2.6.5 but similar things happen in much older versions of Python: a = 2 type(a) type 'int' a += 10 ** 1000 len(str(a)) 1001 type(a) type 'long' Ruby Python 3.0 dynamically switch to larger integer types when overflow happens. This is wrong. Python 3.0 has just the multi-precision integer type, that is called int. For small values it can and will probably use under the cover an user-invisible optimization that is essentially the same thing that Python 2.x does. At the moment Python 3 integers are a bit slower than Python 2.x ones because this optimization is not done yet, one of the main design goals of Python is to keep the C interpreter of Python itself really simple, so even not expert C programmer can hack it and help in the develpment of Python. The PEP 237 and its unification of types was done because: 1) there's no need to keep two integer types in the language, you can just keep one and the language can use invisible optimizations where possible. Python is designed to be simple, so removing one type is good. 2) Actually in very uncommon situations the automatic switch to multi-precision integers can't happen. Such situations are very hard to find, they do not come up in normal numerical code, they come up when you use C extensions (or Python standard library code that is written in C). You can program every day four years in Python 2.x and never find such cases. This is completely impractical in a systems language, and is one reason why Ruby Python are execrably slow compared to C-style languages. Lisp languages can be only a 1.0-3.0 times slower can C despite using mostly multi-precision numbers. So I don't think well implemented multi-precision numbers are so bad in a very fast language. And where performance really matters fixnums can be used. In the last years I am starting to think that using fixnums everywhere is a premature optimization. But anyway, the purpose of my original post was not to advocate the replacement of fixnums in D with multi-precision numbers, it was about the change of array indexes and lenghts from unsigned to signed. Python is slow compared to D, and
Re: Signed word lengths and indexes
div0:
Well for a start, you lose half your addressable memory.
This matters mostly with char/ubyte/byte arrays on 32 bit systems. If you have
arrays of shorts, ints or pointers/references or you are on 64 bit systems this
is not so important.
And the extra safety it gives me is a price I can pay.
And if you don't want to pay that addressable indexes price you can use longs
on 32 bit systems :-)
unsigned numbers are only a problem if you don't understand how they work, but
that goes for just about everything else as well.
This can help you understand why you are very wrong:
Array bound errors are a problem only if you don't understand how arrays work.
I have understood how unsigned numbers work, but I keep writing some bugs once
in a while.
Personally I hate the use of signed numbers as array indices; it's moronic and
demonstrates the writers lack of understanding.
I am not moronic, and C# designers are smart people.
It's very rare to actually want to index an array with a negative number.
That's beside the main point. The main problems come from mixing signed and
unsigned values.
c.f.
Item getItem(int indx) {
if(indx = 0 indx _arr.length)
return _arr[indx];
throw new Error(...)
}
vs.
// cleaner no?
Item getItem(uint indx) {
if(indx _arr.length)
return _arr[indx];
throw new Error(...)
}
The second is shorter (and one less test can make it a bit faster) but it's not
cleaner.
Using 'int's doesn't magically fix it. Wrong code is just wrong.
I agree. But ints can avoid some bugs.
Hasn't that been discussed before?
Discussions about signed-unsigned-derived troubles have happened before.
But this time I have expressed a focused request, to turn indexes and lenghts
into signed words (as I have written in my enhancement request). I think this
was not discussed before in a focused way (or I was not present yet).
Bye,
bearophile
Re: Signed word lengths and indexes
bearophile: 2) I don't like D to silently gulp down expressions that mix signed and unsigned integers and spit out wrong results when the integers were negative. Walter, answering something similar: Andrei and I went down that alley for a while. It's not practical. OK. Then just removing as many unsigned words as possible from normal code (you can see this as the code you want to write in SafeD) can be an alternative. The indexes and lengths are a common source of unsigned word usage inside SafeD programs. Bye, bearophile
Re: Signed word lengths and indexes
Ellery Newcomer wrote: On 06/14/2010 05:48 PM, Walter Bright wrote: D provides powerful abstractions for iteration; it is becoming less and less desirable to hand-build loops with for-statements. Ooo ooo, can we remove it? No :-) I have a hard time believing that Python and Ruby are more productive primarily because they do not have an unsigned type. They're more productive because their built in number types aren't fixnums. That's a nice large class of errors that don't exist in those languages. Like I said, this didn't appear in Python until quite recently (3.0), so that cannot be the primary productivity advantage of Python.
Re: Signed word lengths and indexes
bearophile wrote: Walter Bright: As for unsafe, I think you need to clarify this, as D is not memory unsafe despite the existence of integer over/under flows. Modern languages must understand that there are other forms of safety beside memory safety. Integer overflows and signed-unsigned conversion-derived bugs can cause disasters as well. In current D language the usage of unsigned numbers is a safety hazard. So far nothing I have seen written by you or other people has shown that this is false. D's safe mode, integer overflow *cannot* lead to memory corruption. So when you say something is unsafe, I think it's reasonable to ask what you mean by it. For example, if you define safe as guaranteed to not have bugs, then you're requiring that there be a proof of correctness for all programs in D. Actually, I think they make a lot of sense, and D's improvement on them that only disallows conversions that lose bits based on range propagation is far more sensible than C#'s overzealous restrictions. 1) I'd like D to use signed words to represent lengths and array indexes. This would lead to silent breakage of code transferred from C and C++. We've tried very hard to not have such things in D. The idea is that code that looks the same either behaves the same or issues an error. There's no way to make your proposal pass this requirement. We are going to 64 bit systems where 63 bits can be enough for lenghts. If arrays of 4 billion items are seen as important on 32 bit systems too, then use a long :-) 2) I don't like D to silently gulp down expressions that mix signed and unsigned integers and spit out wrong results when the integers were negative. That idea has a lot of merit for 64 bit systems. But there are two problems with it: 1. D source code is supposed to be portable between 32 and 64 bit systems. This would fail miserably if the sign of things silently change in the process. 2. For an operating system kernel's memory management logic, it still would make sense to represent the address space as a flat range from 0..n, not one that's split in the middle, half of which is accessed with negative offsets. D is supposed to support OS development. I have a hard time believing that Python and Ruby are more productive primarily because they do not have an unsigned type. Python is very productive (for small or medium sized programs! On large programs Python is less good) because of a quite long list of factors. My experience with D and Python (and several other languages) has shown me that Python not using fixnums is one of the factors that help productivity. It's surely not the only factor, and I agree with you that it's not the most important, but it's surely one of the significant factors and it can't be ignored. We can argue forever with how significant it is, I don't assign nearly as much to it as you do. Python integers don't overflow, this at the same time allows you to safe brain time and brain power thinking about possible overflows and the code to avoid their risk, and makes coding more relaxed. And if you try to write 50 Project Euler programs in Python and D you will surely see how many bugs the Python code has avoided you compared to D. Finding and fixing such bugs in D code requires lot of time that you save in Python. This is where we differ. I very rarely have a bug due to overflow or signed/unsigned differences. If you use the D loop abstractions, you should never have these issues with it. Python did not add overflow protection until 3.0, so it's very hard to say this crippled productivity in early versions. http://www.python.org/dev/peps/pep-0237/ You are wrong. Python 2.x dynamically switches to larger integer types when overflow happens. This is done transparently and avoids bugs and keeps programs more efficient. This is on Python V.2.6.5 but similar things happen in much older versions of Python: a = 2 type(a) type 'int' a += 10 ** 1000 len(str(a)) 1001 type(a) type 'long' Here's what the wikipedia said about it. In Python, a number that becomes too large for an integer seamlessly becomes a long.[1] And in Python 3.0, integers and arbitrary sized longs are unified. -- http://en.wikipedia.org/wiki/Integer_overflow (Just switching to long isn't good enough - what happens when long overflows? I generally don't like solution like this because it makes tripping the bug so rare that it can lurk for years. I prefer to flush bugs out in the open early.) This is completely impractical in a systems language, and is one reason why Ruby Python are execrably slow compared to C-style languages. Lisp languages can be only a 1.0-3.0 times slower can C despite using mostly multi-precision numbers. So I don't think well implemented multi-precision numbers are so bad in a very fast language. 3x is a BIG deal. If you're running a major site, this means you only need 1/3 of the hardware, and 1/3 of the electric bill. If you're
Re: Signed word lengths and indexes
Hello Steven, div0 d...@users.sourceforge.net writes: for(uint i = end - 1; i length; --i) ... What does length represent here? It's not clear to me how i descending toward zero is going to break the guard condition. My thought exactly. If ij and you --i, I'd assume ij, if your code depends on the case where the assumption is wrong, don't ask me to do a code review because I won't sign off on it. -- ... IXOYE
Re: Signed word lengths and indexes
Walter Bright: Like I said, this didn't appear in Python until quite recently (3.0), so that cannot be the primary productivity advantage of Python. You are wrong, see my other answer. Bye, bearophile
Re: Constraints error messages [Was: Re: Constrained Templates]
Hello bearophile,
A syntax like the following allows to add the user-defined error
messages too, but it's bad looking, so probably something quite better
can be invented:
template Foo(T)
if (condition1) else pragma(msg, error message1)
if (condition2) else pragma(msg, error message2) {
}
I like the idea, but how should it interact with overloaded templates?
template Foo(T) if(cond1!T) else pragma(msg, a) {}
template Foo(T) if(cond2!T) else pragma(msg, b) {}
Don't run any of the elses unless all the options fail and then run all of
them?
--
... IXOYE
Re: D const enables multi-reader synchronization
On Mon, 14 Jun 2010 15:17:57 -0400, Tomek Sowiński j...@ask.me wrote: This is a continuation of a recent thread Synchronized const methods on D.learn. Currently only one thread at a time can execute a synchronized method. But think about D's const -- it's deep, so if a method is const, it can't possibly mutate its object. So many synchronized const method calls could safely look-but-not-touch the same object at the same time. The chain of questions that stems from the above is: 1. Is letting many readers in on an object really safe? Know any multi-threading quirk that would make sh*t hit the fan? 2. If answer to 1. is yes, would there be room in the current implementation of synchronized keyword for a readers-writer lock? 3. If answer to 2. is yes, how do we tackle write-starvation? In a read-mostly scenario the mutating thread may be held up forever. More on readers-writer lock: http://en.wikipedia.org/wiki/Readers-writer_lock Tomek This has been suggested before and has been rejected. The major issue is that CREW (concurrent-read exclusive-write) locks are known to be not composite and therefore its trivial to write code which results in a deterministic dead-lock. The problem lies in that the const method can have access to a non-const reference to its object via method arguments and/or globals. Thus, a read-lock can be obtained first and then later a write lock is attempted. Since the first read lock will never be released, the write lock can never be taken and a deadlock occurs.
Re: D const enables multi-reader synchronization
Tomek Sowiñski Wrote: This is a continuation of a recent thread Synchronized const methods on D.learn. Currently only one thread at a time can execute a synchronized method. But think about D's const -- it's deep, so if a method is const, it can't possibly mutate its object. So many synchronized const method calls could safely look-but-not-touch the same object at the same time. It's an interesting idea but I'd recommend against it for a few reasons: 1. Acquiring, using, and releasing a reader lock is actually more expensive than a plain old mutex so it isn't a good idea to use one just because you can. A ReadWriteMutex is really for addressing convoying problems on containers. 2. The typical implementation of a ReadWriteMutex doesn't permit recursive up/downgrades from reader to writer and such. It's technically possible to do this, but doing so requires a lot more machinery and consequently trades away even more performance. That said, if you're inclined to experiment there's a ReadWriteMutex in core.sync.rwmutex (which you already may know).
Re: TDPL shipping off Amazon
On 14.6.2010 13:18, Andrei Alexandrescu wrote: Olli Aalto wrote: On 11.6.2010 18:34, Andrei Alexandrescu wrote: Looks like Amazon has finally stocked up on TDPL and is delivering it as of today. Just received my Collector's Edition. :) O. I'm starting to sweat over here. Andrei Don't worry. At least I like your writing style very much. It's very pleasant to read. O.
Re: Forwarding constructor arguments to super
pillsy:
Is there a good way to forward constructor arguments to a superclass
constructor?
This seems to work for simple situations, but maybe it doesn't work in more
complex cases:
import std.traits: ParameterTypeTuple;
mixin template This() {
this(ParameterTypeTuple!(super.__ctor) args) { super(args); }
}
class Foo {
int _x;
float _f;
this(int x, float f) {
this._x = x;
this._f = f;
}
}
class Bar : Foo {
mixin This;
}
void main() {
auto b = new Bar(10, 1.5);
}
Bye,
bearophile
Re: Minimize lock time
On Thu, 10 Jun 2010 02:54:37 -0400, Kagamin s...@here.lot wrote:
Let's consider the following code:
synchronized(syncRoot)
{
if(condition)opSuccess();
else writeln(possibly,slow);
}
Suppose the else close doesn't need to be executed in lock domain and
can be slow. How to minimize lock time here?
synchronized(syncRoot)
{
if(condition)opSuccess();
else goto Lwrite;
}
Lwrite: writeln(possibly,slow);
We can do this... but...
What about using a Mutex object?
mut.lock();
if(condition)
{
scope(exit) mut.unlock();
opSuccess();
}
else
{
mut.unlock();
writeln(possibly, slow);
}
I think it's in core.sync or something like that. Mutex can even take
over the standard monitor element of another object, so for instance you
could assign it as the monitor of your syncRoot, so your other code that
uses syncRoot and synchronized still works.
-Steve
Re: Arithmetic conversions and a surprise with 'max'
On Fri, 11 Jun 2010 15:00:19 -0400, Ali Çehreli acehr...@yahoo.com wrote:
The following program demonstrates a problem that I just hit. It is a
known gotcha of arithmetic conversion rules.
The program is trying to center some text around an index of a char
array. To avoid negative index values, it calls 'max' to limit the
starting offset at 0.
import std.algorithm;
void main()
{
// An empty line
char[10] line = ' ';
// We want to center some text around the first quarter mark
int center_of_text = line.length / 4;
string text = 01234567;
// To be safe, we want to limit the starting index at 0.
// (No negative index please!)
int start = max(0, center_of_text - text.length / 2);
assert(start = 0); // FAILS!
}
The problem is due to converting the second argument of max to unsigned.
These kinds of things can typically be converted into a different form
that removes the subtraction, or uses it in a safe way:
int start = center_of_text - min(center_of_text, text.length / 2);
-Steve
Re: undefined identifier with scope statement?
I'm going to guess that the given case is an accepts-invalid bug caused by scope getting re written as a try/finally with the writeln at the bottom of some scope containing res and the other cases put it outside the scope. File a bug and see what happens. http://d.puremagic.com/issues/show_bug.cgi?id=4313
Re: Yet more OPTLINK woes
On 13.05.2010 21:07, torhu wrote: On 13.05.2010 10:39, Daniel Keep wrote: Attached both regular and decaffeinated^Hgutted versions. Most likely DMD turns VisitorCtfe.d into an invalid object file. But since you don't need to link with objects that contain only ctfe functions... http://d.puremagic.com/issues/show_bug.cgi?id=4315
[Issue 2938] incorrect code generated for assignment to assoc array element
http://d.puremagic.com/issues/show_bug.cgi?id=2938 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #2 from Don clugd...@yahoo.com.au 2010-06-14 01:32:05 PDT --- *** This issue has been marked as a duplicate of issue 2451 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2451] Adding structs that use opAssign or postblit to an AA is broken
http://d.puremagic.com/issues/show_bug.cgi?id=2451 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||crist...@zerobugs.org --- Comment #6 from Don clugd...@yahoo.com.au 2010-06-14 01:32:05 PDT --- *** Issue 2938 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2707] std.getopt unittest does not test boolean
http://d.puremagic.com/issues/show_bug.cgi?id=2707 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||bugzi...@kyllingen.net Resolution||FIXED --- Comment #1 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-06-14 03:46:07 PDT --- Fixed DMD 2.029. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2840] Missing line number for int %= complex (D1 only)
http://d.puremagic.com/issues/show_bug.cgi?id=2840 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Don clugd...@yahoo.com.au 2010-06-14 04:33:01 PDT --- Fixed DMD2.062. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2840] Missing line number for int %= complex (D1 only)
http://d.puremagic.com/issues/show_bug.cgi?id=2840 --- Comment #5 from Don clugd...@yahoo.com.au 2010-06-14 04:33:26 PDT --- Fixed DMD1.062. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4109] writeln doesn't work with empty static array
http://d.puremagic.com/issues/show_bug.cgi?id=4109 bearophile_h...@eml.cc changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #2 from bearophile_h...@eml.cc 2010-06-14 04:39:14 PDT --- Reopened. Phobos needs to be debugged with warnings on. If I compile that program with: dmd -w test.d DMD 2.047 prints: ...\src\phobos\std\format.d(2040): Warning: statement is not reachable ...\src\phobos\std\format.d(2041): Warning: statement is not reachable -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4309] New: String literal passed by ref causes segfault
http://d.puremagic.com/issues/show_bug.cgi?id=4309
Summary: String literal passed by ref causes segfault
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@kyllingen.net
--- Comment #0 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-06-14
05:20:01 PDT ---
The following compiles, but causes a segmentation fault when run:
void foo(ref string s)
{
s = hello yourself; // Anything that changes s will do.
}
void main()
{
foo(hello);
}
I'm guessing that the compiler should catch this and provide an error saying
hello is not an lvalue. At least that's what it does if one tries something
similar with an array literal.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4310] New: std.stdarg 64-Bit problems?
http://d.puremagic.com/issues/show_bug.cgi?id=4310 Summary: std.stdarg 64-Bit problems? Product: D Version: 2.030 Platform: x86_64 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: mrmoc...@gmx.de --- Comment #0 from Trass3r mrmoc...@gmx.de 2010-06-14 06:31:29 PDT --- I'm not sure, but the code given at http://digitalmars.com/d/2.0/variadic-function-templates.html uses size_t.sizeof instead of int.sizeof -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4311] New: Applying a template to a variadic template parameter in a templated function's parameter list breaks compilation
http://d.puremagic.com/issues/show_bug.cgi?id=4311
Summary: Applying a template to a variadic template parameter
in a templated function's parameter list breaks
compilation
Product: D
Version: D2
Platform: x86_64
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas simen.kja...@gmail.com 2010-06-14 06:39:51
PDT ---
Test case:
template foo( T... ) {
alias T[0] foo; // Does not matter what is in here
}
auto bar( T... )( foo!T arg ) {
}
bar!( int, float )( 2 );
Error: template bar(T...) does not match any function template declaration
Error: template bar(T...) cannot deduce template function from argument types
!(1,2)()
Error: template instance errors instantiating template
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4311] Applying a template to a variadic template parameter in a templated function's parameter list breaks compilation
http://d.puremagic.com/issues/show_bug.cgi?id=4311 --- Comment #1 from Simen Kjaeraas simen.kja...@gmail.com 2010-06-14 06:42:13 PDT --- Also, this works: alias bar!( int, float ) baz; baz( 2, 3 ); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2275] std.utf.toUTF16z() should return const(wchar)*
http://d.puremagic.com/issues/show_bug.cgi?id=2275 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added CC||bugzi...@kyllingen.net AssignedTo|and...@metalanguage.com |bugzi...@kyllingen.net --- Comment #1 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-06-14 06:44:10 PDT --- http://www.dsource.org/projects/phobos/changeset/1640 toMBSz() was fixed three years ago: http://www.dsource.org/projects/phobos/changeset/402/trunk/phobos/std/windows/charset.d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2451] Adding structs that use opAssign or postblit to an AA is broken
http://d.puremagic.com/issues/show_bug.cgi?id=2451 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #7 from Don clugd...@yahoo.com.au 2010-06-14 06:46:04 PDT --- *** Issue 4121 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4121] Associative array value bigint assign
http://d.puremagic.com/issues/show_bug.cgi?id=4121 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #1 from Don clugd...@yahoo.com.au 2010-06-14 06:46:04 PDT --- *** This issue has been marked as a duplicate of issue 2451 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3355] std.string.cmp works incorrectly for mixed-type and different-length strings
http://d.puremagic.com/issues/show_bug.cgi?id=3355 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added CC||bugzi...@kyllingen.net AssignedTo|and...@metalanguage.com |bugzi...@kyllingen.net --- Comment #1 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-06-14 07:10:22 PDT --- http://www.dsource.org/projects/phobos/changeset/1641 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2126] class template specialization and inheritance
http://d.puremagic.com/issues/show_bug.cgi?id=2126 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||spec CC||clugd...@yahoo.com.au Component|www.digitalmars.com |DMD Version|unspecified |D1 D2 Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4312] New: std.traits.ReturnType no longer accepts function literals
http://d.puremagic.com/issues/show_bug.cgi?id=4312
Summary: std.traits.ReturnType no longer accepts function
literals
Product: D
Version: future
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: sandf...@jhu.edu
--- Comment #0 from Rob Jacques sandf...@jhu.edu 2010-06-14 08:43:52 PDT ---
std.traits.ReturnType no longer accepts function literals. Here is a simplified
test case:
void main(string[] args) {
writeln( (ReturnType!( function(int a){return a;} )).stringof );
return;
}
Results in the error:
Error: function std.traits.__funcliteral1 cannot access frame of function
__funcliteral1
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4109] writeln doesn't work with empty static array
http://d.puremagic.com/issues/show_bug.cgi?id=4109 Shin Fujishiro rsi...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #3 from Shin Fujishiro rsi...@gmail.com 2010-06-14 08:42:42 PDT --- Okay, I fixed it in svn r1642. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1351] Discrepancies in the language specification
http://d.puremagic.com/issues/show_bug.cgi?id=1351 --- Comment #11 from Ellery Newcomer ellery-newco...@utulsa.edu 2010-06-14 10:44:58 PDT --- Created an attachment (id=661) adds links, fixes productions, adjusts some formatting No claims to infallibility. In particular, someone had better check PowExpression, as I believe it was in the wrong place and I moved it, but I'm not so confident about it. Aziz: for DeclaratorSuffixes, the [ exp .. exp ] syntax is not currently supported by dmd (v2 at least), and it probably never was, and I don't think it should be. (of course I don't think DeclaratorSuffixes should exist at all, except for the parameter part, since it's a kludge for c-style types) I haven't touched NewExpression, Protection, or SwitchStatement (at least I don't think I did) IsExpression: I hate D. How about we just pretend this one doesn't exist? I think everything else either is already fixed or is fixed by this patch -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4313] New: undefined identifier error with scope guard statement
http://d.puremagic.com/issues/show_bug.cgi?id=4313
Summary: undefined identifier error with scope guard statement
Product: D
Version: 2.041
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: mrmoc...@gmx.de
--- Comment #0 from Trass3r mrmoc...@gmx.de 2010-06-14 11:45:44 PDT ---
import std.stdio;
void main()
{
scope(exit) writeln(res);
auto res = 0;
}
This compiles, but using failure or success in the scope guard statement gives
undefined identifier res.
The question is, if this case is an accepts-invalid or if the other two cases
are rejects-valid.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4313] undefined identifier error with scope guard statement
http://d.puremagic.com/issues/show_bug.cgi?id=4313 Trass3r mrmoc...@gmx.de changed: What|Removed |Added Keywords||accepts-invalid --- Comment #1 from Trass3r mrmoc...@gmx.de 2010-06-14 12:47:08 PDT --- Seems a bit strange. According to CompoundStatement::semantic this is rewritten as try-catch-finally. Even scope(exit) would have the auto res = 0 in the try block which would result in undefined identifier. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4314] New: Expression array1 array2 doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=4314
Summary: Expression array1 array2 doesn't compile
Product: D
Version: D1 D2
Platform: Other
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nfx...@gmail.com
--- Comment #0 from nfx...@gmail.com 2010-06-14 13:28:22 PDT ---
This stopped working in dmd 1.062 (maybe also affects D2):
void main() {
int[] a, b;
if (a b) {}
}
rt.d(3): Error: Array operation a b not implemented
This prevents compilation of at least one (Linux specific) module with Tango
(in Tango trunk).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4315] New: Invalid object file created when appending const char[0] to char[]
http://d.puremagic.com/issues/show_bug.cgi?id=4315
Summary: Invalid object file created when appending const
char[0] to char[]
Product: D
Version: D1
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: to...@yahoo.com
--- Comment #0 from to...@yahoo.com 2010-06-14 16:17:35 PDT ---
DMD 1.061.
---
void main()
{
char[] a;
const b = ;
//const char[0] b; // fails
//char[0] b; // ok
//const b = x; // ok
//const char[] b = ; // ok
//auto b = ; // ok
a ~= b;
}
---
Output:
d:\prog\test\D\mathevaldmd -run test
OPTLINK (R) for Win32 Release 8.00.1
Copyright (C) Digital Mars 1989-2004 All rights reserved.
test.obj(test) Offset 0018FH Record Type 009D
Error 16: Index Range
--- errorlevel 1
optlink 8.00.2 silently ignores this error, I'll create another bug report for
that.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4315] Invalid object file created when appending const char[0] to char[]
http://d.puremagic.com/issues/show_bug.cgi?id=4315 nfx...@gmail.com changed: What|Removed |Added Keywords||rejects-valid CC||nfx...@gmail.com --- Comment #1 from nfx...@gmail.com 2010-06-14 16:31:53 PDT --- Under Linux, with 1.062, I get: Error: no definition for static _D2fd4mainFZv1bG0a It's not even a linker error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3602] ICE(tocsym.c) compiling a class, if its super class has preconditions
http://d.puremagic.com/issues/show_bug.cgi?id=3602
Stewart Gordon s...@iname.com changed:
What|Removed |Added
CC||s...@iname.com
Platform|Other |All
OS/Version|Linux |All
Severity|critical|regression
--- Comment #4 from Stewart Gordon s...@iname.com 2010-06-14 18:30:05 PDT ---
The given testcase is invalid. However, by fixing the errors, it's
reproducible under Windows:
- imagebox.d -
module imagebox;
import box;
class ImageBox: Box {
override void paint(int x, int y)
in {
assert(x 0);
assert(y 0);
}
body {
}
}
- box.d -
module box;
class Box {
void paint(int x, int y)
in {
assert(x 0);
assert(y 0);
}
body {
}
}
--
C:\Users\Stewart\Documents\Programming\D\Tests\bugs\bz3602dmd -c imagebox.d
box.d(5): Error: function __require forward declaration
linkage = 0
Assertion failure: '0' on line 381 in file 'tocsym.c'
abnormal program termination
--
This has broken SDWF.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
