Interfaces based on TypeTuple?
How can I achieve something like the following? I want to create
a class B that has all the interfaces of the class passed as a
template parameter.
import std.trats;
interface I0 {}
interface I1 {}
class A : I0, I1 {}
class B!C : InterfacesTuple!C {}
void main() {
B!A a;
}
Re: Interfaces based on TypeTuple?
On Wednesday, 25 December 2013 at 07:45:37 UTC, Øivind wrote:
How can I achieve something like the following? I want to
create a class B that has all the interfaces of the class
passed as a template parameter.
import std.trats;
interface I0 {}
interface I1 {}
class A : I0, I1 {}
class B!C : InterfacesTuple!C {}
void main() {
B!A a;
}
The above fails with the following error on DMD 2.064.2
/d925/f379.d(8): Error: { } expected following aggregate
declaration
/d925/f379.d(8): Error: Declaration expected, not '!'
/d925/f379.d(12): Error: unrecognized declaration
Re: Interfaces based on TypeTuple?
On Wednesday, 25 December 2013 at 07:45:37 UTC, Øivind wrote:
class B!C : InterfacesTuple!C {}
You probably meant:
class B(C) : InterfacesTuple!C {}
Re: Function declaration
On Wednesday, December 25, 2013, quot;Casper Færgemand\quot; lt;shortt...@hotmail.comgt;quot;@puremagic.com wrote: Never mind, found it. I searched for parameters and found it in http://dlang.org/declaration.html#DeclaratorSuffix Thanks. :3 I had a lot of problems with function declarations when testing the example D grammar. If you find any mistake in the provided D grammar, could you push it as an issue in Pegged?
Re: Interfaces based on TypeTuple?
On Wednesday, 25 December 2013 at 07:49:35 UTC, Jakob Ovrum wrote:
On Wednesday, 25 December 2013 at 07:45:37 UTC, Øivind wrote:
class B!C : InterfacesTuple!C {}
You probably meant:
class B(C) : InterfacesTuple!C {}
Yes, stupid typo. Thanks for the quick answer. Awesome that this
works :)
Re: rmdirRecurse vs readonly
On Tuesday, 24 December 2013 at 16:11:15 UTC, Ali Çehreli wrote:
On 12/24/2013 04:13 AM, Lemonfiend wrote:
std.file.rmdirRecurse refuses to remove readonly files.
How would I go about deleting them anyway?
Call std.file.setAttributes() first, which has apparently been
added just three days ago: :)
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L971
If you can't work with git head version of dmd, then do what it
does yourself, depending on your platform:
void setAttributes(in char[] name, uint attributes)
{
version (Windows)
{
cenforce(SetFileAttributesW(std.utf.toUTF16z(name),
attributes), name);
}
else version (Posix)
{
assert(attributes = mode_t.max);
cenforce(!chmod(toStringz(name),
cast(mode_t)attributes), name);
}
}
For example, if you are on Linux:
import core.sys.posix.sys.stat;
import std.conv;
// ...
chmod(/my/file, cast(mode_t)octal!777)
Ali
Haha, how very timely.
Thanks! And merry xmas :)
dmd simple loop disassembly - redundant instruction?
Hello,
I am studying the difference between x86 generated code of DMD
and C/C++ compilers on Windows (simply put: why exactly, and by
what margin, DMD-compiled D code is often slower than
GCC-compiled C/C++ equivalent).
Now, I have this simple D program:
-
immutable int MAX_N = 1_000_000;
void main () {
int [MAX_N] a;
foreach (i; 0..MAX_N)
a[i] = i;
}
-
(I know there's iota in std.range, and it turns out to be even
slower - but that's a high level function, and I'm trying to
understand the lower-level details now.)
The assembly (dmd -O -release -inline -noboundscheck, then
obj2asm) has the following piece corresponding to the cycle:
-
L2C:mov -03D0900h[EDX*4][EBP],EDX
mov ECX,EDX
inc EDX
cmp EDX,0F4240h
jb L2C
-
Now, I am not exactly fluent in assembler, but the mov ECX, EDX
seems unnecessary. The ECX register is explicitly used three
times in the whole program, and it looks like this instruction
can at least be moved out of the loop, if not removed completely.
Is it indeed a bug, or there's some reason here? And if the
former, where do I report it - at http://d.puremagic.com/issues/,
as with the front-end?
I didn't try GDC or LDC since I didn't find a clear instruction
for using them under Win32. If there is one, please kindly point
me to it. I found a few explanations for GDC, but had a hard
time trying to figure out which is the most current one.
Note that the C++ version does the same with four instructions
instead of five, as D version is expected to be if we remove the
instruction in question. Indeed, it goes like (code inside the
loop):
-
L3:
movl%eax, _a(,%eax,4)
addl$1, %eax
cmpl$100, %eax
jne L3
-
The full assembly listings, and the source codes (D and C++), are
here:
http://acm.math.spbu.ru/~gassa/dlang/simple_loop/
I've tried a few other versions as well. Changing the loop to an
explicit for (int i = 0; i MAX_N; i++) (a2.d) does not affect
the generated assembly. Making the array dynamic (a3.d) leads to
five instructions, all seemingly important. A __gshared static
array (a4.d) gives the same seemingly unneeded instruction but
with EAX instead of ECX:
-
L2: mov _D2a41aG100i[EDX*4],EDX
mov EAX,EDX
inc EDX
cmp EDX,0F4240h
jb L2
-
Ivan Kazmenko.
Re: dmd simple loop disassembly - redundant instruction?
On Wednesday, 25 December 2013 at 12:03:08 UTC, Ivan Kazmenko wrote: Now, I am not exactly fluent in assembler, but the mov ECX, EDX seems unnecessary. The ECX register is explicitly used three times in the whole program, and it looks like this instruction can at least be moved out of the loop, if not removed completely. Is it indeed a bug, or there's some reason here? And if the former, where do I report it - at http://d.puremagic.com/issues/, as with the front-end? Did you try something like: for(immutable i; 0..MAX_N) a[i] = i; too? One thing to note is that, technically, i is a _copy_ of the iterated number. So things like for(i; 0..5) i++; have no effect (it will loop 5 times regardless). Indeed, in your case, this could be optimized out, but in general the extra instruction is technically correct. I don't know if making i immutable would change things, but it might give the compiler enough of a hint to do the correct optimization here.
Re: dmd simple loop disassembly - redundant instruction?
On Wednesday, 25 December 2013 at 12:43:05 UTC, Chris Cain wrote: Did you try something like: for(immutable i; 0..MAX_N) a[i] = i; too? One thing to note is that, technically, i is a _copy_ of the iterated number. So things like for(i; 0..5) i++; have no effect (it will loop 5 times regardless). Indeed, in your case, this could be optimized out, but in general the extra instruction is technically correct. I don't know if making i immutable would change things, but it might give the compiler enough of a hint to do the correct optimization here. Thanks, that sounded reasonable. Still, in this particular case, the generated assembly remained the same.
Re: Function declaration
On Wednesday, 25 December 2013 at 08:34:27 UTC, Philippe Sigaud wrote: On Wednesday, December 25, 2013, quot;Casper Færgemand\quot; lt;shortt...@hotmail.comgt;quot;@puremagic.com wrote: Never mind, found it. I searched for parameters and found it in http://dlang.org/declaration.html#DeclaratorSuffix Thanks. :3 I had a lot of problems with function declarations when testing the example D grammar. If you find any mistake in the provided D grammar, could you push it as an issue in Pegged? Yes, certainly.
Re: My first D module - Critiques welcome.
You could also do some neat stuff with opDispatch. Someone actually wrote an article about using it with roman numerals: http://idorobots.org/2012/03/04/romans-rubies-and-the-d/ The idea is actually brilliant. :) I think I may use it in the future when I need to deal with roman numbers. -- Dejan Lekic dejan.lekic (a) gmail.com http://dejan.lekic.org
Re: Making associatvie array from array of pairs
On Tuesday, 24 December 2013 at 14:39:16 UTC, Timon Gehr wrote:
On 12/24/2013 12:36 PM, Dfr wrote:
Let's say i have array of kind:
auto a = [[1,FF], [2, 00FF00], ...];
Is there simple way to turn it into associative array of kind:
string[string] b = [1: FF, 2: 00FF00, ...];
void main(){
import std.array, std.algorithm, std.typecons;
auto a = [[1,FF], [2, 00FF00], /+...+/];
auto aa = a.map!(x=tuple(x[0],x[1])).assocArray;
import std.stdio;
writeln(aa);
}
This example looks cleanest, but not compile with error:
Error: no property 'assocArray' for type 'MapResult!(__lambda9,
immutable(char[][])[])'
Re: Making associatvie array from array of pairs
Dfr: This example looks cleanest, but not compile with error: Error: no property 'assocArray' for type 'MapResult!(__lambda9, immutable(char[][])[])' It compiles for me. Bye, bearophile
Re: dmd simple loop disassembly - redundant instruction?
Ivan Kazmenko:
I am studying the difference between x86 generated code of DMD
and C/C++ compilers on Windows (simply put: why exactly, and by
what margin, DMD-compiled D code is often slower than
GCC-compiled C/C++ equivalent).
Now, I have this simple D program:
-
immutable int MAX_N = 1_000_000;
void main () {
int [MAX_N] a;
foreach (i; 0..MAX_N)
a[i] = i;
}
-
(I know there's iota in std.range, and it turns out to be even
slower - but that's a high level function, and I'm trying to
understand the lower-level details now.)
The assembly (dmd -O -release -inline -noboundscheck, then
obj2asm) has the following piece corresponding to the cycle:
-
L2C:mov -03D0900h[EDX*4][EBP],EDX
mov ECX,EDX
inc EDX
cmp EDX,0F4240h
jb L2C
-
ldc2 optimizes the useless loop away:
__Dmain:
xorl%eax, %eax
ret
If I modify the code returning some value from the int main:
return a[7];
ldc2 gives the loop code:
LBB0_1:
movl%eax, 12(%esp,%eax,4)
incl%eax
cmpl$100, %eax
jne LBB0_1
If I use iota ldc2 copiles the loop to exactly the same asm:
foreach (i; MAX_N.iota)
Bye,
bearophile
Re: My first D module - Critiques welcome.
On 12/25/13 15:07, Dejan Lekic wrote:
You could also do some neat stuff with opDispatch. Someone
actually
wrote an article about using it with roman numerals:
http://idorobots.org/2012/03/04/romans-rubies-and-the-d/
The idea is actually brilliant. :)
I think I may use it in the future when I need to deal with roman numbers.
Note that the D’s version has no runtime overhead at all part is not true -
- there still is the overhead of a function call (which he admits to later).
A truly overhead-less version would be:
struct Roman {
template opDispatch(string number) {
enum num = number.replace(IV, )
.replace(IX, V)
.replace(XL, )
.replace(XC, L);
enum opDispatch = num.count('I')
+ num.count('V') * 5
+ num.count('X') * 10
+ num.count('L') * 50
+ num.count('C') * 100;
}
}
artur
Re: Making associatvie array from array of pairs
On Wednesday, 25 December 2013 at 14:44:57 UTC, bearophile wrote: Dfr: This example looks cleanest, but not compile with error: Error: no property 'assocArray' for type 'MapResult!(__lambda9, immutable(char[][])[])' It compiles for me. Bye, bearophile Sorry, just forgot to import std.array, now it works, thank you.
Re: Function declaration
From http://dlang.org/declaration.html#Parameter Parameter: InOutopt BasicType Declarator InOutopt BasicType Declarator ... InOutopt BasicType Declarator = DefaultInitializerExpression InOutopt Type InOutopt Type ... How do I add a declarator to a parameter like char * format? I altered the language specification to add a InOutopt Type Declarator, but is there another way? The specification overall is really good, but I've found a few missing things elsewhere, and I'm wondering if it really is missing or I'm missing the point. :P I can't see any way to add a parameter name to something of type Type.
Re: Thrift maintained..?
On Saturday, 21 December 2013 at 19:20:44 UTC, Martin Nowak wrote: Rebuild autoconf and automake files? Try ./bootstrap.sh ./configure make. That's what actually breaks it. I was messing around on another box where Thrift compiled just fine and found my configure script was not calling ./bootstrap.sh first so it was using old Makefiles. Unfortunately I don't know how long ago I ran bootsrap.sh on that box so I don't know what version broke the Makefile generation. I've filed a bug: https://issues.apache.org/jira/browse/THRIFT-2294
joiner correct usage
Hello, following code: import std.algorithm : joiner; string joined = joiner([hello, world], ); Results in: Error: cannot implicitly convert expression (joiner(...)) of type Result to string Any idea how to make this work ?
Re: joiner correct usage
On Wed, Dec 25, 2013 at 06:21:17PM +, Dfr wrote: Hello, following code: import std.algorithm : joiner; string joined = joiner([hello, world], ); Results in: Error: cannot implicitly convert expression (joiner(...)) of type Result to string Any idea how to make this work ? joiner returns a range object, not an array. To get an array out of it, do this: import std.array : array; import std.algorithm : joiner; string joined = joiner([hello, world], ).array; T -- Spaghetti code may be tangly, but lasagna code is just cheesy.
Re: joiner correct usage
On Wednesday, 25 December 2013 at 18:41:47 UTC, H. S. Teoh wrote: import std.array : array; import std.algorithm : joiner; string joined = joiner([hello, world], ).array; T Ha! Error: cannot implicitly convert expression (array(joiner([hello, world], ))) of type dchar[] to string std.conv.to should be used instead: import std.conv : to; string joined = joiner([hello, world], ).to!string;
Re: Function declaration
On Wed, Dec 25, 2013 at 4:57 PM, Casper Færgemand\ shortt...@hotmail.com@puremagic.com wrote: From http://dlang.org/declaration.html#Parameter Parameter: InOutopt BasicType Declarator InOutopt BasicType Declarator ... InOutopt BasicType Declarator = DefaultInitializerExpression InOutopt Type InOutopt Type ... How do I add a declarator to a parameter like char * format? I altered the language specification to add a InOutopt Type Declarator, but is there another way? The specification overall is really good, but I've found a few missing things elsewhere, and I'm wondering if it really is missing or I'm missing the point. :P I can't see any way to add a parameter name to something of type Type. I'll consider that as a D grammar question, and not a Pegged-specific question, since Pegged just uses a copy of the D site grammar :-) As to this specific question, my answer is halas: I don't know. I find parts of the D grammar a bit complicated for my taste (with 200 different rules, it's the most complicated programming language grammar I know of). I'll let some grammar specialist answers there (there are a few around these parts). I know some people have a cleaned-up, alternate grammar, but I can't remember the link.
Re: Function declaration
On 12/25/2013 04:57 PM, Casper Færgemand shortt...@hotmail.com wrote: From http://dlang.org/declaration.html#Parameter Parameter: InOutopt BasicType Declarator InOutopt BasicType Declarator ... InOutopt BasicType Declarator = DefaultInitializerExpression InOutopt Type InOutopt Type ... How do I add a declarator to a parameter like char * format? I altered the language specification to add a InOutopt Type Declarator, but is there another way? The specification overall is really good, but I've found a few missing things elsewhere, and I'm wondering if it really is missing or I'm missing the point. :P I can't see any way to add a parameter name to something of type Type. The following is a parse tree for char* format: Parameter /|\ / | \ / | \ / BasicType \ InOut_opt|\ BasicTypeX Declarator | / | \ 'char' / Identifier \ / | DeclaratorSuffixes_opt / 'format' / BasicType2Opt / BasicType2 / '*' I consider the grammar specification (as well as some details of what is valid syntax) to be quite inelegant, unnecessarily repetitive and inconvenient for parser generators, but I am not sure if a clean-up would be welcome.
Re: Function declaration
On Wednesday, 25 December 2013 at 21:23:23 UTC, Philippe Sigaud wrote: I'll consider that as a D grammar question, and not a Pegged-specific question, since Pegged just uses a copy of the D site grammar :-) Thank you regardless. I'll be sure to submit some issues once we're a bit further down the road. Error handling is what has displeased me the most so far, with only a single test case ever displaying something useful. I'm not sure what the solution should be though, perhaps the matches that munched the most tokens before failing? Also, it should be possible to detect non-munching cycles aka. left recursion without too much extra compile time. It's funny because it's fine on compile time, but instant death at runtime. I'll post some of that once we're further. On Wednesday, 25 December 2013 at 22:28:06 UTC, Timon Gehr wrote: The following is a parse tree for char* format: snip Oooh, I missed that. I didn't think it possible one would dissect it like that. In my mind it would make more sense to keep char and * together, since it's a type of its own. Interesting. And weird. I consider the grammar specification (as well as some details of what is valid syntax) to be quite inelegant, unnecessarily repetitive and inconvenient for parser generators, but I am not sure if a clean-up would be welcome. I'm not sure. I haven't imported too much yet, but the only thing I've had to work around was left recursion in some arithmetic expressions (add and mul I believe). It's complicated for sure, but the language specification has survived nearly intact. My only past experience is the toy language Tiger made for education and stories I've been told of normal language specifications being really awful. So some copy paste is nice for a change. I'd still like a look at a clean grammar if anyone has one around.
Human stupidity or is this a regression?
Perhaps should have written and/or in the subject line since the two
are not mutually exclusive.
I was showing off D to friends the other day:
import std.stdio;
void main()
{
foreach (d; 你好)
writeln(d);
}
IIRC, this used to work fine, with the variable d getting deduced as
dchar and correctly reassembling the UTF-8 bytes into Unicode codepoints.
But when I run this code in OSX, dmd v2.064, I get this:
$ dmd -run uni.d
�
�
�
�
�
�
It's clearly printing the bytes. When I print the typeof(d) I get
immutable(char), so that confirms the type is not deduced as dchar.
I could have sworn this used to work. Is my memory failing me, or was
this a deliberate change at some point? Perhaps a regression?
L.
Re: get address of object if opCast is overridden
On 12/2/12, 21:25, js.mdnq wrote: I'm not just comparing them but using them as a unique ID for the objects in an algorithm to prevent computing over the same object more than once. o.toHash() ?? (Which incidentally just casts the reference to a hash_t, exactly what you want to do.)
Re: Human stupidity or is this a regression?
Lionello Lunesu: I could have sworn this used to work. Is my memory failing me, or was this a deliberate change at some point? Perhaps a regression? It's not a regression, it's a locked-in design mistake. Write it like this and try again: foreach (dchar d; 你好) Bye, bearophile
Re: Human stupidity or is this a regression?
On 12/26/13, 11:58, bearophile wrote: Lionello Lunesu: I could have sworn this used to work. Is my memory failing me, or was this a deliberate change at some point? Perhaps a regression? It's not a regression, it's a locked-in design mistake. Write it like this and try again: foreach (dchar d; 你好) Bye, bearophile Yeah, that's what I ended up doing. But D being D, the default should be safe and correct. I feel we could take this breaking change since it would not silently change the code to do something else. You'll get prompted and we could special case the error message to give a meaningful hint. L
Re: dmd simple loop disassembly - redundant instruction?
On Wednesday, 25 December 2013 at 14:51:11 UTC, bearophile wrote: ldc2 optimizes the useless loop away: __Dmain: xorl%eax, %eax ret If I modify the code returning some value from the int main: return a[7]; ldc2 gives the loop code: LBB0_1: movl%eax, 12(%esp,%eax,4) incl%eax cmpl$100, %eax jne LBB0_1 If I use iota ldc2 copiles the loop to exactly the same asm: foreach (i; MAX_N.iota) Glad to know that! But what about DMD? Anyone?.. If someone with better knowledge in assembly confirms the instruction is unnecessary, I'll file a bug report (at http://d.puremagic.com/issues/ I presume). Ivan Kazmenko.
Error: non-constant expression
Hello, this example: import std.array; import std.algorithm; import std.typecons; auto a = [[test, 1]]; auto b = a.map!(x=tuple(x[1],x[0])).assocArray; Gives me Error: static variable a cannot be read at compile time When add const: const auto a = [[test, 1]]; const auto b = a.map!(x=tuple(x[1],x[0])).assocArray; Gives another error: Error: non-constant expression [1:test] Any idea what is wrong ?
Error: conflicting Ddoc and obj generation options
I'm newbie for D. I have tried build with custom library but the build is failed. ubuntu@9ffb916910cd:~/dshttpd$ dub Building configuration application, build type debug Compiling... Error: conflicting Ddoc and obj generation options Error: DMD compile run failed with exit code 1 What's means Error: conflicting Ddoc and obj generation options ? Thanks for read.
