Re: Tuple to tuple conversion
Lars T. Kyllingstad pub...@kyllingen.nospamnet wrote: FWIW, I've run across the same error, while writing code that had nothing to do with tuples. And I've seen others complaining about it too. It seems to be a rather elusive bug in Phobos. This has now been tracked down to the importing of std.typecons in two included files. Test case: // module a; import std.typecons; alias Tuple!( float ) foo; // module b; import std.typecons; -- Simen
Re: D Programming Language
On Tue, 08 Jun 2010 11:23:23 +0100, Patrick Byrne wrote: Amazon (UK) tells me that publication of this book is delayed. Is it still coming soon, please? I also ordered it from Amazon UK, and got the same message. But the book is, as far as I know, finished and printed. So I suppose it's mostly a matter of transportation time. :) -Lars
Re: Tuple to tuple conversion
On Tue, 08 Jun 2010 12:39:43 +0200, Simen kjaeraas wrote: Simen kjaeraas simen.kja...@gmail.com wrote: Lars T. Kyllingstad pub...@kyllingen.nospamnet wrote: FWIW, I've run across the same error, while writing code that had nothing to do with tuples. And I've seen others complaining about it too. It seems to be a rather elusive bug in Phobos. This has now been tracked down to the importing of std.typecons in two included files. Test case: // module a; import std.typecons; alias Tuple!( float ) foo; // module b; import std.typecons; Forgot to mention, this only happens with -unittest. http://d.puremagic.com/issues/show_bug.cgi?id=4294 That's consistent with my experiences too. It seems to be triggered by a Phobos unittest. Still, I can't reproduce it with your test case. Which DMD version are you using? -Lars
Re: Tuple to tuple conversion
Lars T. Kyllingstad pub...@kyllingen.nospamnet wrote: I'm not sure I understand this. Do you then import a and b into another module to reproduce the error? This doesn't do it for me... As the bug report says: dmd -unittest a b -- Simen
Re: Tuple to tuple conversion
On Tue, 08 Jun 2010 12:56:04 +0200, Simen kjaeraas wrote: Lars T. Kyllingstad pub...@kyllingen.nospamnet wrote: That's consistent with my experiences too. It seems to be triggered by a Phobos unittest. Still, I can't reproduce it with your test case. Which DMD version are you using? 2.045. Actually, I can't reproduce it now either. Ah, found the problem. dmd a b -unittest works. dmd b a -unittest does not. Ok, now I can reproduce it too, with 2.046. This just makes it even more clear that it is a DMD bug, not a Phobos one. I've been running into a lot of these order-of-compilation bugs lately. :( -Lars
Re: D Programming Language
On 08/06/10 11:23, Patrick Byrne wrote: Amazon (UK) tells me that publication of this book is delayed. Is it still coming soon, please? -- Patrick Byrne I ordered it from amazon.com, it was half the priceof the UK version ;) I've had no delay message about it for a while now, the last one I got said June 25 2010 - August 04 2010 though... Guess we'll see though! Given that it's already been dispatched from the printers, I'm quietly optimistic it'll arrive before then. Robert
Re: Tuple to tuple conversion
On Tue, 08 Jun 2010 19:39:43 +0900, Simen kjaeraas simen.kja...@gmail.com wrote: Simen kjaeraas simen.kja...@gmail.com wrote: Lars T. Kyllingstad pub...@kyllingen.nospamnet wrote: FWIW, I've run across the same error, while writing code that had nothing to do with tuples. And I've seen others complaining about it too. It seems to be a rather elusive bug in Phobos. This has now been tracked down to the importing of std.typecons in two included files. Test case: // module a; import std.typecons; alias Tuple!( float ) foo; // module b; import std.typecons; Forgot to mention, this only happens with -unittest. http://d.puremagic.com/issues/show_bug.cgi?id=4294 Same issue? http://d.puremagic.com/issues/show_bug.cgi?id=4003
Re: D Programming Language
On Tue, 08 Jun 2010 13:00:51 +0100, Robert Clipsham wrote: On 08/06/10 11:23, Patrick Byrne wrote: Amazon (UK) tells me that publication of this book is delayed. Is it still coming soon, please? -- Patrick Byrne I ordered it from amazon.com, it was half the priceof the UK version ;) I don't know when you ordered it, but that has changed now, at least. At amazon.co.uk it costs £18.50, while at amazon.com it sells for $42.70 -- roughly £29. Also, for Europeans, the delivery cost is lower if you order from UK. -Lars
Re: D Programming Language
On 08/06/10 13:12, Lars T. Kyllingstad wrote: I don't know when you ordered it, but that has changed now, at least. At amazon.co.uk it costs £18.50, while at amazon.com it sells for $42.70 -- roughly £29. Also, for Europeans, the delivery cost is lower if you order from UK. -Lars I ordered it a few weeks after it was up on Amazon, at the time it was about £30 in the UK and $42.70 in the US (I know they're roughly the same now, it worked out about £10 cheaper at the time though). As for delivery cost, I always wait until there's a selection of things I want to buy to get free delivery ;)
Re: why is this cast necessary?
Hi Steve,
On Mon, 07 Jun 2010 23:46:40 -0400, Steven Schveighoffer wrote:
On Mon, 07 Jun 2010 23:02:48 -0400, Graham Fawcett fawc...@uwindsor.ca
wrote:
Hi folks,
This program works as expected in D2:
import std.stdio;
import std.algorithm;
T largestSubelement(T)(T[][] lol) {
alias reduce!ab?a:b max;
return cast(T) max(map!max(lol)); // the cast matters...
}
void main() {
auto a = [[1,2,3],[4,5,6],[8,9,7]];
assert (largestSubelement(a) == 9);
auto b = [howdy, pardner];
assert (largestSubelement(b) == 'y');
auto c = [[1u, 3u, 45u, 2u], [29u, 1u]];
assert (largestSubelement(c) == 45u);
}
But if I leave out the 'cast(T)' in line 7, then this program will not
compile:
lse.d(6): Error: cannot implicitly convert expression
(reduce(map(lol))) of type dchar to immutable(char)
lse.d(14): Error: template instance
lse.largestSubelement!(immutable(char)) error
instantiating
Where did the 'dchar' came from? And why does the cast resolve the
issue?
In a recent update, Andrei changed char[] and wchar[] to bi-directional
ranges of dchar instead of straight arrays (at least, I think that was
the change) in the eyes of the range types. I think this is where the
dchar comes from.
If you had a char[], and the 'max' element was a sequence of 2 code
points, how do you return a single char for that result?
Thank you. This makes sense.
Regards,
Graham
std.array.Appender with fixed size arrays
Hi,
While trying to get some things to build in D2, i noticed that the code:
import std.array;
void main (string[] args)
{
string s;
auto app = appender(s);
app.put(['a', 'b']);
}
/
works, but if it's changed to;
char[2] tmp = ['a', 'b'];
app.put(tmp);
then it fails. Seems to be because char[2] isn't a forward range, so it
doesn't match the version of put that takes a range.
Is this a bug?
Re: std.array.Appender with fixed size arrays
Richard Webb: char[2] tmp = ['a', 'b']; app.put(tmp); then it fails. Seems to be because char[2] isn't a forward range, so it doesn't match the version of put that takes a range. Is this a bug? Maybe it's not a bug, but it's a limitation. With some more work on the Appender then this limit can be removed. If you want you can fix the problem and submit a patch in bugzilla. Probably it's not too much hard to do. Bye, bearophile
Re: std.array.Appender with fixed size arrays
Richard Webb wrote:
Hi,
While trying to get some things to build in D2, i noticed that the code:
import std.array;
void main (string[] args)
{
string s;
auto app = appender(s);
app.put(['a', 'b']);
}
/
works, but if it's changed to;
char[2] tmp = ['a', 'b'];
app.put(tmp);
then it fails. Seems to be because char[2] isn't a forward range, so it
doesn't match the version of put that takes a range.
Is this a bug?
The problem is due to a relatively recent change to D2: the size of
fixed sized arrays may not be changed. (I like how it fits their name. :) )
Ali
template specialization
This code:
import std.stdio;
class A {
void get (T:ubyte)(T[] buffer) {
writefln( get (T:ubyte)(T[] buffer)\n);
}
void get (T:byte)(T[] buffer) {
writefln( get (T:byte)(T[] buffer)\n);
}
void get (T)(T[] buffer) {
writefln( get (T)(T[] buffer)\n);
}
}
void main () {
A foo = new A;
ubyte[100] ub;
byte[100] bb;
int[100] ib;
foo.get( ub);
foo.get( bb);
foo.get( ib);
}
Generates:
get (T:ubyte)(T[] buffer)
get (T:ubyte)(T[] buffer)
get (T)(T[] buffer)
Note: If get(T:byte) preceeded get(T:ubyte) then get(T:byte) would be
called in both cases.
Q: Is this the way it's supposed to be?
Thanks, Larry
Re: template specialization
Larry Luther larry.lut...@dolby.com wrote: get (T:ubyte)(T[] buffer) get (T:ubyte)(T[] buffer) get (T)(T[] buffer) Q: Is this the way it's supposed to be? Looks very much correct, yes. Is there a problem? -- Simen
Re: template specialization
On 08/06/10 22:25, Larry Luther wrote:
Q: Is this the way it's supposed to be?
Yes, byte implicitly casts to ubyte so it's accepted. Try switching the
templates round, they will both be byte. The way around this is to add
template constraints to the templates:
void get(T:ubyte)(T[] buffer) if( is( T == ubyte ) ) { }
void get(T:byte)(T[] buffer) if( is( T == byte ) ) { }
etc.
Hope this helps,
Robert
Re: template specialization
On 06/08/2010 05:01 PM, Robert Clipsham wrote:
On 08/06/10 22:25, Larry Luther wrote:
Q: Is this the way it's supposed to be?
Yes, byte implicitly casts to ubyte so it's accepted. Try switching the
templates round, they will both be byte. The way around this is to add
template constraints to the templates:
void get(T:ubyte)(T[] buffer) if( is( T == ubyte ) ) { }
void get(T:byte)(T[] buffer) if( is( T == byte ) ) { }
etc.
Hope this helps,
Robert
bit odd though, since byte[] isn't implicitly convertible to ubyte[].
no wait! yes it is!
void get(T:ubyte[])(T t){}
..
get(new byte[](1));
no wait! no it isn't!
ubyte[] u = new byte[](1);
and is it just me, or does the following silently cast away immutability?
get(hi mom!);
Re: template specialization
Thanks guys. Simen asked: Is there a problem?. Well, I kind of expected a ubyte buffer to be matched with a get(T:ubyte). I thought methods were searched for the best match. Larry
Re: template specialization
Larry Luther wrote: Thanks guys. Simen asked: Is there a problem?. Well, I kind of expected a ubyte buffer to be matched with a get(T:ubyte). I thought methods were searched for the best match. No, C++ does it that way, and it gets horrendously complicated. In D, it has to match exactly.
