Re: Reflection
On 02/28/2012 07:27 AM, Joshua Niehus wrote: On Tuesday, 28 February 2012 at 06:10:11 UTC, Jesse Phillips wrote: It is a template. I see, thanks. And I bet its not possible to figure out if a template is a function template or a class template etc... You can trivially test whether the symbol is callable with some specific arguments, if that helps: is(typeof(writeln(arg1,arg2,arg3)))
Re: Is empty array null?
2012/2/28 Pedro Lacerda pslace...@gmail.com So are a newly allocated array and a null one just the same thing? int[] a = [], b = null; assert(a == b); assert(a.length == b.length); assert(a.ptr == a.ptr); Hi all, Sorry if this is a stupid question - I'm new to D but I've been keeping an eye on it for quite a while (and also read the book). Coming from the Java/C# world, not distinguishing between an empty array and null feels strange to me. Is this so for strings as well? ...and in Pedros example, if you assign null to b and then try to access b.length, don't you get a NullPointerException? What am I missing? / Mikael
Re: Is empty array null?
Mikael Lindsten: Coming from the Java/C# world, not distinguishing between an empty array and null feels strange to me. Is this so for strings as well? ...and in Pedros example, if you assign null to b and then try to access b.length, don't you get a NullPointerException? What am I missing? Maybe you need to read the D book again :-) In D there are no NullPointerExceptions, current D implementations use segfaults. D strings are a subset of D dynamic arrays. D dynamic arrays are implemented with a small 2-words long struct-like entity that is composed by pointer+length allocated in place, where the pointer points to the contents of the array (chars or numbers or other things) (and there is a bit more stuff in the allocated memory block to manage array appending a bit more efficiently). So you are always allowed to read the array/string length. Bye, bearophile
Re: class templates and static if
On 28.02.2012 2:17, Ali Çehreli wrote: On 02/27/2012 02:06 PM, Jonathan M Davis wrote: I'm not saying that dmd doesn't ever optimize switch statements. I'm just saying that as I understand it, it doesn't always do so (its performance with ranged case statements isn't great for instance). Odds are that it _does_ optimize straight integer case statements fairly well, because that's the classic C stuff (and if you've verified that, all the better - I haven't). I would say use switch when you have multiple choises over one variable, because the compiler *can* do much better job then with if/else chain (even for strings, e.g. hashing, same binary-search approach). Because the if/else chain fixes the order of comparisons it can't become faster at all (or it would be an aggressive optimization). It's just wrong idea to lose this opportunity with switch. I have played with this optimization recently. (Could be dmd 2.057.) No, dmd did not optimize a straightforward switch statement over a ubyte expression with about two hundred ubyte cases. Hate to say it but I see it in real-world code, VM performance almost doubled. Mm care to share you experiments? Alternatively just dissemble any regex sample, seek out mangled trash of _xxx_eval_ function. The assembly contained conditional jump statements, not a table. And yes, I did try with -O. But I am not sure that a lookup table really is an optimization with modern CPUs. A series of conditional jumps that fit the CPU's cache could be faster than a table that's outside of the cache. I think accessing the cache is hundreds of times faster than accessing memory outside of the cache. It's all about branch prediction really - hundreds of cmp xxx je xxx stall pipelines pretty darn well. Though the effect might depend on the code size inside these case branches. BTW tables should be somewhere close, though I haven't checked this. -- Dmitry Olshansky
Re: Is empty array null?
On Tuesday, 28 February 2012 at 08:38:10 UTC, Mikael Lindsten wrote: Coming from the Java/C# world, not distinguishing between an empty array and null feels strange to me. Is this so for strings as well? ...and in Pedros example, if you assign null to b and then try to access b.length, don't you get a NullPointerException? What am I missing? / Mikael string is an array, alias immutable(char)[], so the same rules apply. There is no NullPointerException, it is a segfault/Access Violation/Bus Error. An empty array and a null array are equal. And this definition does work well. You can distinguish between an empty array and a null array by using the 'is' operator. What is pointed out here is that an empty array literal, [], is null while an empty array is not. This behavior is easy to explain in terms sf why, but may not be a good choice for sake of consistency.
Re: Is empty array null?
2012/2/28 Jesse Phillips jessekphillip...@gmail.com
string is an array, alias immutable(char)[], so the same rules apply.
I know about string being an alias, hence the question. This means that I
can doif (someString.length) { ... }without worrying about the null
case (?). That's great!
There is no NullPointerException, it is a segfault/Access Violation/Bus
Error.
Ah, that will take some getting used to. =)
I guess there's a good reason though (there seems to be good reasoning
behind most of the design choises). Off topic, but may I ask what might be
the reason?
An empty array and a null array are equal. And this definition does work
well.
You can distinguish between an empty array and a null array by using the
'is' operator. What is pointed out here is that an empty array literal, [],
is null while an empty array is not. This behavior is easy to explain in
terms sf why, but may not be a good choice for sake of consistency.
Yes, that feels kind of wrong to me - that an empty array literal is null
while an empty array isn't. It's not intuitive, easily explainable or not.
/ Mikael
Random behavior using a wrapped C library
I'm getting some unexpected results (crashes or random behavior) when
using a wrapped C struct in a library. I have no idea why this is
happening as everything else (including other wrapped structs) seems to
work just fine.
Could it be some alignment issues..?
extern(C):
//typedef unsigned char uint8;
alias ubyte uint8;
//typedef struct {
// uint8 r,g,b;
//} TCOD_color_t;
struct TCOD_color_t {
uint8 r,g,b;
};
//typedef void * TCOD_console_t;
alias void* TCOD_console_t;
//TCODLIB_API void TCOD_console_set_default_background(TCOD_console_t
con,TCOD_color_t col);
void TCOD_console_set_default_background(TCOD_console_t con,TCOD_color_t
col);
Whenever I use I call this function using TCOD_color_t(255,255,255) it
seems to set a random other value.
Also, when calling get_default_background (not shown here), I get random
results back.
I know the library works fine from C, so it has to be somewhere in my
wrapper.
Does anyone spot any obvious flaws in my wrapping above? Or has any other
hints on what might have gone wrong?
I've only tested this on linux64.
Thanks.
Re: Is empty array null?
On 02/28/2012 05:25 AM, Mikael Lindsten wrote:
This means that
I can doif (someString.length) { ... }without worrying about the
null case (?). That's great!
Correct
Re: Random behavior using a wrapped C library
http://d.puremagic.com/issues/show_bug.cgi?id=5570
Re: Random behavior using a wrapped C library
On Tue, 28 Feb 2012 16:58:13 +0100, Trass3r u...@known.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=5570 Thanks. I've literally spent hours testing various things without any luck - would have been simpler if I knew asm :/ A blocker for using x64 on linux then.
Comparison of TickDuration and StopWatch.peek
Hello everyone,
I have the following code snippet:
import core.time:TickDuration;
import std.datetime: StopWatch, AutoStart;
void main()
{
auto wait = TickDuration.from!`msecs`(1000);
auto timer = StopWatch(AutoStart.yes);
while (timer.peek wait) // Okay.
{ }
while (wait = timer.peek) // Compile error.
{ }
}
I would like to know why the second ‘while’ doesn't compile. The error is:
comparison.d(13): Error: function core.time.TickDuration.opCmp (ref
const(TickDuration) rhs) const is not callable using argument types
(TickDuration)
comparison.d(13): Error: timer.peek() is not an lvalue
which I don't really understand. There shouldn't be a difference in
‘’ and ‘=’ apart from their result, or should there be? =/ Same
thing happens for ‘’.
Also, I can use ‘peek’ without parenthesis even though it isn't marked
as @property on dlang.org, am I missing something? I probably read the
spec incorrectly somewhere for this one.
Thanks, Matej
Re: Comparison of TickDuration and StopWatch.peek
On Tuesday, February 28, 2012 19:15:01 Matej Nanut wrote:
Hello everyone,
I have the following code snippet:
import core.time: TickDuration;
import std.datetime: StopWatch, AutoStart;
void main()
{
auto wait = TickDuration.from!`msecs`(1000);
auto timer = StopWatch(AutoStart.yes);
while (timer.peek wait) // Okay.
{ }
while (wait = timer.peek) // Compile error.
{ }
}
I would like to know why the second ‘while’ doesn't compile. The error is:
comparison.d(13): Error: function core.time.TickDuration.opCmp (ref
const(TickDuration) rhs) const is not callable using argument types
(TickDuration)
comparison.d(13): Error: timer.peek() is not an lvalue
which I don't really understand. There shouldn't be a difference in
‘’ and ‘=’ apart from their result, or should there be? =/ Same
thing happens for ‘’.
Also, I can use ‘peek’ without parenthesis even though it isn't marked
as @property on dlang.org, am I missing something? I probably read the
spec incorrectly somewhere for this one.
It looks like TickDuration only has an overload for opCmp which takes a const
ref, and a const ref must be an lvalue (unlike in C++, which allows const to
take a temporary). The reason that the first one works is that the right-hand
side is a variable.
Create a bug report for it ( http://d.puremagic.com/issues ), and it should be
fixed for the next release. In the meantime, you'll have to assign the right-
hand side to a variable and use that in the condition rather than using the
return value directly.
- Jonathan M Davis
Re: Comparison of TickDuration and StopWatch.peek
Also you can force property calls in your code if you compile with -property. Property notation has not been enforced so far, but might be in the future afaik.
Re: Comparison of TickDuration and StopWatch.peek
So I can call any (void) method without parenthesis without -property? I guess I'll just add -property to all my programs from now on. But why isn't .peek() a property? In std.container, for example, the BinaryHeap has a .front property (even though it isn't declared as such on dlang.org, but the comments say it is one). I find .front and .peek have more or less the same meaning, obviously for different data structures. The time complexities are probably different as well. But I find the meaning to be synonymous. Although this might be a re-run of the .by(Value|Key) debate a while ago. I will create a report later this evening: should it be about D not having the same lvalue semantics as C++ or the actual implementation of opCmp for TickDuration? Thanks, Matej On 28 February 2012 20:04, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Also you can force property calls in your code if you compile with -property. Property notation has not been enforced so far, but might be in the future afaik.
Re: Reflection
On Tuesday, February 28, 2012 06:56:10 Joshua Niehus wrote:
Hello,
I dont understand the following snippet's output:
import std.stdio, std.traits;
void main() {
writeln(isSomeFunction!(writeln));
writeln(isCallable!(writeln));
writeln(Yes I am...);
}
/* OUTPUT */
false
false
Yes I am...
If 'writeln' isn't a method/function and it's not callable, then
what is it?
writeln doesn't even really exist as far as the compiler is concerned until
it's been instantiated. So, testing writeln isn't going to work. You need to
either test a specific instantiation (e.g. isSomeFunction!(writeln!string))),
or you need to just test that particular call works (e.g.
is(typeof(writeln(arg. The second is probably better, since that's
generally what you really care about - is it compilable with the given set of
arguments.
- Jonathan M Davis
Re: Comparison of TickDuration and StopWatch.peek
On Tuesday, February 28, 2012 20:14:14 Matej Nanut wrote: So I can call any (void) method without parenthesis without -property? I guess I'll just add -property to all my programs from now on. But why isn't .peek() a property? In std.container, for example, the BinaryHeap has a .front property (even though it isn't declared as such on dlang.org, but the comments say it is one). I find .front and .peek have more or less the same meaning, obviously for different data structures. The time complexities are probably different as well. But I find the meaning to be synonymous. Although this might be a re-run of the .by(Value|Key) debate a while ago. In some cases, you can debate ad-naseum as to whether something should be considered a property or not. In the case of peek, SHOO made it a normal function, so that's the way that it is. It _is_ different from front, however, in that it will return a different value every call if the stopwatch is still running, and I could see someone thinking that that would make it so that it's not a property. It's certainly debatable though. I will create a report later this evening: should it be about D not having the same lvalue semantics as C++ or the actual implementation of opCmp for TickDuration? Give your code example and mark it as a druntime bug. It's TickDuration that's the issue, not the lvalue semantics. For better or worse, D is not going to be changed to allow you to pass rvalues to const ref like C++ will let you do. It will continue to insist on lvalues for all ref parameters, const or otherwise. - Jonathan M Davis
Re: Random behavior using a wrapped C library
A blocker for using x64 on linux then. Use gdc. Better codegen anyway.
Re: Random behavior using a wrapped C library
On 2/29/2012 1:10 AM, simendsjo wrote: On Tue, 28 Feb 2012 16:58:13 +0100, Trass3r u...@known.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=5570 Thanks. I've literally spent hours testing various things without any luck - would have been simpler if I knew asm :/ A blocker for using x64 on linux then. Have you tested on 32-bit yet? I had the exact same problem with one of my wrappers when passing a struct by value, but on 32-bit Windows. Luckily, in my case it was simple enough to implement the function in D to work around it. I'm curious to know if it's related.
passing a string with the character as an argument
Greetings!
I have this program,
import std.process : system;
import std.stdio;
int main(char[][] args)
{
char[] cmd;
for (int i=1;iargs.length;i++)
{
cmd ~= args[i] ~ ;
}
writefln(cmd);
return(1);
}
if I compile it and run it this way,
test 1! 2@ 3 4#
the result is
1! 2@ 3
So, if I pass a string with an , the argument array stops right
before the . How can I pass a in a string? I tried escaping it,
but it does not work either.
thanks for the help.
jic
Re: passing a string with the character as an argument
On 29 February 2012 18:51, jic cabr...@wrc.xerox.com wrote:
Greetings!
I have this program,
import std.process : system;
import std.stdio;
int main(char[][] args)
{
char[] cmd;
for (int i=1;iargs.length;i++)
{
cmd ~= args[i] ~ ;
}
writefln(cmd);
return(1);
}
if I compile it and run it this way,
test 1! 2@ 3 4#
the result is
1! 2@ 3
So, if I pass a string with an , the argument array stops right
before the . How can I pass a in a string? I tried escaping it,
but it does not work either.
thanks for the help.
jic
This is more a shell problem than a D one. Assuming that you are using
a *nix shell (so csh, tcsh, bash or zsh) you need escape the with a
backslash, like so: \. You should be getting an error on your shell,
saying that it cannot find the command 4#.
Its because '' is a special character used to fork a process into the
background, useful for gui programs and the like.
I have tried your code, using a *nix shell, and using 3\ works.
If you are on Windows, then I don't know why this is happening.
--
James Miller
Re: Random behavior using a wrapped C library
On Wed, 29 Feb 2012 05:03:30 +0100, Mike Parker aldac...@gmail.com wrote: On 2/29/2012 1:10 AM, simendsjo wrote: On Tue, 28 Feb 2012 16:58:13 +0100, Trass3r u...@known.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=5570 Thanks. I've literally spent hours testing various things without any luck - would have been simpler if I knew asm :/ A blocker for using x64 on linux then. Have you tested on 32-bit yet? I had the exact same problem with one of my wrappers when passing a struct by value, but on 32-bit Windows. Luckily, in my case it was simple enough to implement the function in D to work around it. I'm curious to know if it's related. Yes. Tested on x32, and it works just fine. I'll use ia32libs and -m32 for the time being then. A strange thing is that memory consumption went _up_ when everything was compiled as x32.
Re: Random behavior using a wrapped C library
On 29 February 2012 19:30, simendsjo simend...@gmail.com wrote: On Wed, 29 Feb 2012 05:03:30 +0100, Mike Parker aldac...@gmail.com wrote: On 2/29/2012 1:10 AM, simendsjo wrote: On Tue, 28 Feb 2012 16:58:13 +0100, Trass3r u...@known.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=5570 Thanks. I've literally spent hours testing various things without any luck - would have been simpler if I knew asm :/ A blocker for using x64 on linux then. Have you tested on 32-bit yet? I had the exact same problem with one of my wrappers when passing a struct by value, but on 32-bit Windows. Luckily, in my case it was simple enough to implement the function in D to work around it. I'm curious to know if it's related. Yes. Tested on x32, and it works just fine. I'll use ia32libs and -m32 for the time being then. A strange thing is that memory consumption went _up_ when everything was compiled as x32. I don't know much, but wouldn't bigger register sizes mean that less data needs shuffled in and out of memory? Resulting in less instructions and therefore less memory usage? I'm just guessing though -- James Miller
Re: passing a string with the character as an argument
On 29-2-2012 7:06, James Miller wrote:
On 29 February 2012 18:51, jiccabr...@wrc.xerox.com wrote:
Greetings!
I have this program,
import std.process : system;
import std.stdio;
int main(char[][] args)
{
char[] cmd;
for (int i=1;iargs.length;i++)
{
cmd ~= args[i] ~ ;
}
writefln(cmd);
return(1);
}
if I compile it and run it this way,
test 1! 2@ 3 4#
the result is
If you are on Windows, then I don't know why this is happening.
On windows the ampersand also has a special meaning. In that case
try the carrot ^ to escape
test 1! 2@ 3^ 4#
Jos
Re: Random behavior using a wrapped C library
On Wednesday, 29 February 2012 at 06:30:27 UTC, simendsjo wrote: A strange thing is that memory consumption went _up_ when everything was compiled as x32. Data/code/symbols size?
Re: passing a string with the character as an argument
On 29 February 2012 20:21, Jos van Uden user@domain.invalid wrote:
On 29-2-2012 7:06, James Miller wrote:
On 29 February 2012 18:51, jiccabr...@wrc.xerox.com wrote:
Greetings!
I have this program,
import std.process : system;
import std.stdio;
int main(char[][] args)
{
char[] cmd;
for (int i=1;iargs.length;i++)
{
cmd ~= args[i] ~ ;
}
writefln(cmd);
return(1);
}
if I compile it and run it this way,
test 1! 2@ 3 4#
the result is
If you are on Windows, then I don't know why this is happening.
On windows the ampersand also has a special meaning. In that case
try the carrot ^ to escape
test 1! 2@ 3^ 4#
Jos
Today I Learned that windows has insane escaping.
--
James Miller
