Re: Problem with Hiredis Binding
On 1/6/2012 2:34 PM, Puming wrote: In http://dlang.org/interfaceToC.html it says in 32bit system c_long is equivalent to `long long` in C. Is this wrong? Well, either the documentation is wrong or the implementation is. Looks like one for Bugzilla.
Re: Singleton Pattern
thank you, you answer is very helpful.
Re: Problem with Hiredis Binding
Mike Parker wrote: > On 1/6/2012 2:34 PM, Puming wrote: >> >>> >> In http://dlang.org/interfaceToC.html it says in 32bit system c_long is >> equivalent to `long long` in C. Is this wrong? > > Well, either the documentation is wrong or the implementation is. Looks > like one for Bugzilla. The documentation is wrong. c_long is meant to be used _only_ for C's "long" type, so it must be 32bit for 32bit architectures and 64bit for (most) 64bit architectures. See also: http://en.wikipedia.org/wiki/64-bit#64- bit_data_models No need to file a bug though, I posted a fix here: https://github.com/D- Programming-Language/d-programming-language.org/pull/55
Re: Problem with Hiredis Binding
Puming: > 1. "long long" in C is always 64bit, so in D it's "long"; In C "long long" isn't always 64 bit. Bye, bearophile
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On 29/12/2011 19:09, Jacob Carlborg wrote: Could druntime hook up on the atexit function to run destructors and similar when the program exits? I'm not sure. Maybe it could be called upon to run static destructors and destruct heap-allocated objects. But in order to call scope guards and RAII, it would need to unwind the call stack, which could get complicated if you're trying to do it from within a function. It's much simpler not to use exit() and throw a custom exception instead. Stewart.
Re: Problem with Hiredis Binding
On 1/6/12, Johannes Pfau wrote: > The documentation is wrong. That was my fault. I was going to fix the original docs which had no mention of c_long/c_ulong and I ended up screwing up the tables. Sorry!
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
Just implement your own exception type, e.g. ExitException, and then use:
void main() { try { realMain(); } catch (ExitException e) { return 0; }
void exit() { throw ExitException(); }
where realMain is the actual main function. Then just call exit()
whenever you want to.
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
That should have been int main.
Compile-time evaluation of real expressions?
Hi All, As I understand it, compile-time execution *should* be able to evaluate floating-point functions, correct? Currently, I have this code: private static real cross_angles[6] = [ real.nan, real.nan, real.nan, atan(sqrt(5)), PI_4, atan(sqrt(5)-2) ]; But the compiler is complaining: /mnt/1/usr/include/d2/4.6/std/math.d:623: Error: asm statements cannot be interpreted at compile time /mnt/1/usr/include/d2/4.6/std/math.d:591: Error: cannot evaluate atan2(x,1.0e+0L) at compile time Is this an artifact of using gdc-4.6 instead of dmd? Or are certain floating-point functions not allowed in compile-time expressions? Thanks! P.S. I just starting learning and using D recently -- and totally loving it. T -- Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce
Re: Compile-time evaluation of real expressions?
On 06-01-2012 23:21, H. S. Teoh wrote: Hi All, As I understand it, compile-time execution *should* be able to evaluate floating-point functions, correct? Currently, I have this code: private static real cross_angles[6] = [ real.nan, real.nan, real.nan, atan(sqrt(5)), PI_4, atan(sqrt(5)-2) ]; But the compiler is complaining: /mnt/1/usr/include/d2/4.6/std/math.d:623: Error: asm statements cannot be interpreted at compile time /mnt/1/usr/include/d2/4.6/std/math.d:591: Error: cannot evaluate atan2(x,1.0e+0L) at compile time Is this an artifact of using gdc-4.6 instead of dmd? Or are certain floating-point functions not allowed in compile-time expressions? Thanks! P.S. I just starting learning and using D recently -- and totally loving it. T Most likely those functions are just implemented using inline assembly, therefore not usable in CTFE. -- - Alex
Re: Compile-time evaluation of real expressions?
On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote: > Most likely those functions are just implemented using inline assembly, > therefore not usable in CTFE. Yeah, several functions in std.math use inline assembly. So, for them to be able to be used at compile time, either the compiler must be expanded to be able to run asm statements at compile time (which may or may not be planned and may or may not be reasonable), or those functions need another branch (using __cfte in an if condition) which doesn't use assembly. Or I suppose that if the extra check for __ctfe isn't considered particularly acceptable (after all, they're already using assembly), then separate functions meant specifically for CTFE would be necessary. I don't know what Don's preferred approach would be, but presumably, it would be up to him since he's the primary maintainer of both CTFE and std.math. An enhancement request for it should probably be opened: d.puremagi.com/issues - Jonathan M Davis
Re: Compile-time evaluation of real expressions?
On 01/06/2012 03:37 PM, Jonathan M Davis wrote: An enhancement request for it should probably be opened: d.puremagi.com/issues http://d.puremagic.com/issues/ Ali
Re: Compile-time evaluation of real expressions?
On 07-01-2012 00:37, Jonathan M Davis wrote: On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote: Most likely those functions are just implemented using inline assembly, therefore not usable in CTFE. Yeah, several functions in std.math use inline assembly. So, for them to be able to be used at compile time, either the compiler must be expanded to be able to run asm statements at compile time (which may or may not be planned and may or may not be reasonable), or those functions need another branch (using __cfte in an if condition) which doesn't use assembly. Or I suppose that if the extra check for __ctfe isn't considered particularly acceptable (after all, they're already using assembly), then separate functions meant specifically for CTFE would be necessary. I don't know what Don's preferred approach would be, but presumably, it would be up to him since he's the primary maintainer of both CTFE and std.math. An enhancement request for it should probably be opened: d.puremagi.com/issues - Jonathan M Davis Allowing asm in CTFE would probably be way more work than it's worth. You'd basically need full-blown analysis of x86 assembly plus an interpreter. Even then, x86 is not typed, so it's going to be a major pain... -- - Alex
Re: Compile-time evaluation of real expressions?
On Sat, Jan 07, 2012 at 12:49:46AM +0100, Alex Rønne Petersen wrote: > On 07-01-2012 00:37, Jonathan M Davis wrote: > >On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote: > >>Most likely those functions are just implemented using inline > >>assembly, therefore not usable in CTFE. > > > >Yeah, several functions in std.math use inline assembly. So, for them > >to be able to be used at compile time, either the compiler must be > >expanded to be able to run asm statements at compile time (which may > >or may not be planned and may or may not be reasonable), or those > >functions need another branch (using __cfte in an if condition) which > >doesn't use assembly. Or I suppose that if the extra check for __ctfe > >isn't considered particularly acceptable (after all, they're already > >using assembly), then separate functions meant specifically for CTFE > >would be necessary. [...] >From my limited experience, I'd say that having two versions of the function is probably the least painful way to go. [...] > Allowing asm in CTFE would probably be way more work than it's worth. > You'd basically need full-blown analysis of x86 assembly plus an > interpreter. Even then, x86 is not typed, so it's going to be a major > pain... [...] I admit I've no idea how the D compiler implements compile-time evaluation, but is it possible for the compiler to actually emit code for compile-time functions containing asm blocks and, say, execute it in a sandbox, and read the values out from the machine registers? Or does this create more problems than it solves? T -- Verbing weirds language. -- Calvin (& Hobbes)
Is this really a bug?
Hi, I've read on Bugzilla Issue 6398 that this is a bug:
static int value;
ref foo(){ printf("getter\n"); return value; }
ref foo(int x){ printf("setter\n"); value = x; return value; }
void main(){ foo = 1; } // Should print "setter", but print "getter" in 2.054
But, this is pretty convenient syntax, no? That way you could implement only
one function foo() and use it as setter and getter.
I'm a bit confused about it.
Thanks,
Daniel
Re: An issue with lazy delegates
On 5/01/12 5:26 AM, Andrej Mitrovic wrote:
The first call doesn't do anything because the delegate is wrapped
inside of another delegate. I want this template to be versatile
enough to be used by both lazy expressions and delegate literals, but
I don't know how.
void test(T)(lazy T dg)
{
static if (is(T == delegate))
dg()();
else
dg();
}
void main()
{
test( writeln("a") );
test( { writeln("b"); } );
}
Re: Is this really a bug?
On 7/01/12 1:19 AM, Daniel wrote:
Hi, I've read on Bugzilla Issue 6398 that this is a bug:
static int value;
ref foo(){ printf("getter\n"); return value; }
ref foo(int x){ printf("setter\n"); value = x; return value; }
void main(){ foo = 1; } // Should print "setter", but print "getter" in 2.054
But, this is pretty convenient syntax, no? That way you could implement only
one function foo() and use it as setter and getter.
I'm a bit confused about it.
Thanks,
Daniel
It is convenient syntax, but sometimes you want the getter to return a
ref, but want the setter to do something different to "getter() = x".
This bug says that there is no way to override a ref returning getter
with a custom setter.
Re: An issue with lazy delegates
Hah, I never thought of using that check. Thanks.
Re: Compile-time evaluation of real expressions?
On 07/01/2012 00:31, H. S. Teoh wrote: I admit I've no idea how the D compiler implements compile-time evaluation, but is it possible for the compiler to actually emit code for compile-time functions containing asm blocks and, say, execute it in a sandbox, and read the values out from the machine registers? Or does this create more problems than it solves? Doing this would mean you can't do cross-compilation, eg using x86 to compile for ARM. Which means you'd need to use a virtual machine for it, which is almost certainly more effort than it's worth. -- Robert http://octarineparrot.com/
Re: Compile-time evaluation of real expressions?
On Sat, Jan 07, 2012 at 02:15:39AM +, Robert Clipsham wrote:
> On 07/01/2012 00:31, H. S. Teoh wrote:
> >I admit I've no idea how the D compiler implements compile-time
> >evaluation, but is it possible for the compiler to actually emit code
> >for compile-time functions containing asm blocks and, say, execute it
> >in a sandbox, and read the values out from the machine registers? Or
> >does this create more problems than it solves?
>
> Doing this would mean you can't do cross-compilation, eg using x86 to
> compile for ARM. Which means you'd need to use a virtual machine for
> it, which is almost certainly more effort than it's worth.
[...]
But doesn't the use of asm{} already prevent cross-compilation in the
first place? Or does the D compiler actually translate the instructions
into the target platform? In which case, doesn't it already know enough
to be able to interpret it?
I'm pretty sure I'm missing something obvious.
T
--
Customer support: the art of getting your clients to pay for your own
incompetence.
Re: Compile-time evaluation of real expressions?
On 07/01/2012 02:28, H. S. Teoh wrote:
On Sat, Jan 07, 2012 at 02:15:39AM +, Robert Clipsham wrote:
On 07/01/2012 00:31, H. S. Teoh wrote:
I admit I've no idea how the D compiler implements compile-time
evaluation, but is it possible for the compiler to actually emit code
for compile-time functions containing asm blocks and, say, execute it
in a sandbox, and read the values out from the machine registers? Or
does this create more problems than it solves?
Doing this would mean you can't do cross-compilation, eg using x86 to
compile for ARM. Which means you'd need to use a virtual machine for
it, which is almost certainly more effort than it's worth.
[...]
But doesn't the use of asm{} already prevent cross-compilation in the
first place? Or does the D compiler actually translate the instructions
into the target platform? In which case, doesn't it already know enough
to be able to interpret it?
I'm pretty sure I'm missing something obvious.
T
version(X86) asm
{
// X86 ASM
}
else version(ARM) asm
{
// ARM ASM
}
// etc
--
Robert
http://octarineparrot.com/
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On 06/01/2012 14:44, Andrej Mitrovic wrote:
Just implement your own exception type, e.g. ExitException, and then use:
That's more or less what people have already said. What's more, Ashish has already
suggested a further improvement whereby the custom exception carries an exit code.
void main() { try { realMain(); } catch (ExitException e) { return 0; }
That should have been int main.
That's not the only typo - you've forgotten to finish that function with a return for if
ExitException is never thrown and a closing }.
Stewart.
Re: Compile-time evaluation of real expressions?
On 01/07/2012 12:37 AM, Jonathan M Davis wrote: On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote: Most likely those functions are just implemented using inline assembly, therefore not usable in CTFE. Yeah, several functions in std.math use inline assembly. So, for them to be able to be used at compile time, either the compiler must be expanded to be able to run asm statements at compile time (which may or may not be planned and may or may not be reasonable), or those functions need another branch (using __cfte in an if condition) which doesn't use assembly. Or I suppose that if the extra check for __ctfe isn't considered particularly acceptable (after all, they're already using assembly) [snip.] If the if condition is a constant, there is no runtime overhead.
Re: Compile-time evaluation of real expressions?
On Saturday, January 07, 2012 04:49:27 Timon Gehr wrote: > On 01/07/2012 12:37 AM, Jonathan M Davis wrote: > > On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote: > >> Most likely those functions are just implemented using inline > >> assembly, > >> therefore not usable in CTFE. > > > > Yeah, several functions in std.math use inline assembly. So, for them to > > be able to be used at compile time, either the compiler must be > > expanded to be able to run asm statements at compile time (which may or > > may not be planned and may or may not be reasonable), or those > > functions need another branch (using __cfte in an if condition) which > > doesn't use assembly. Or I suppose that if the extra check for __ctfe > > isn't considered particularly acceptable (after all, they're already > > using assembly) [snip.] > > If the if condition is a constant, there is no runtime overhead. Ah, good point - though depending on what the compiler does, that may only be the case with -O. But anyone who really cares about that level of performance would be compiling with -O anyway. - Jonathan M Davis
