Re: SDL with D

2011-07-12 Thread Dainius (GreatEmerald)
I see. And what about Lua? I see lots and lots of different libraries
for that on dsource, and there is even some support in Derelict as
well. I assume that LuaD is the one in active development and most
fitting for current D2?


Re: opCast, c bindings and normal casts.

2011-07-12 Thread Johannes Pfau
Johannes Pfau wrote:
Hi,

I have a wrapper for a object aware c library (cairo). Take for
example two classes, Surface and a subclass, ImageSurface. Now this
code has to be valid:
---
auto ptr = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 512, 512);
Surface s = new Surface(ptr);
ImageSurface imgs = cast(ImageSurface)s;
---

As D cannot know that 's' really should be an ImageSurface, I have
implemented opCast to get this example working:
---
class Surface
{
static Surface castFrom(Surface other)
{
return other;
}

T opCast(T)() if(isImplicitlyConvertible!(T, Surface))
{
return T.castFrom(this);
}
}
class ImageSurface : Surface
{
static ImageSurface castFrom(Surface other)
{
auto type = cairo_surface_get_type(other.nativePointer);
if(type == cairo_surface_type_t.CAIRO_SURFACE_TYPE_IMAGE)
{
return new ImageSurface(other.nativePointer);
}
else
return null;
}
}
---

This code works quite well. But it performs unnecessary calls to
cairo_surface_get_type (and allocates unnecessary objects) for simple
cases:
---
auto surface = new ImageSurface(Format.CAIRO_FORMAT_ARGB32, 400, 400);
Surface tmp = cast(Surface)surface;
ImageSurface test = cast(ImageSurface)as;
---

In this case, the first D object already is an ImageSurface so the
custom opCast code isn't needed for the last line.

So the question is: Is there some way to check in the opCast function
if a normal D object cast would succeed and then just return it's
result?


In case anyone's interested:
I think this could be done with _d_dynamic_cast from rt.cast_
(druntime).
I've dropped the opCast/castFrom approach though (not working in some
cases), so I haven't tested this.

-- 
Johannes Pfau



Declaring a D pointer to a C function

2011-07-12 Thread Johannes Pfau
From a discussion related to derelict:
How do you write this:
---
alias extern(C) int function(void* test) FTInitFunc;
FTInitFunc FT_Init_FreeType
---
without the alias?
---
extern(C) int function(void* test) FT_Init_FreeType;
---
is not the same!
both are fields containing a C function pointer, but the first field
has D name mangling (_D4test16FT_Init_FreeTypePUPvZi) and the second
has C name mangling: (FT_Init_FreeType, which conflicts with the C
function FT_Init_FreeType)

And a related question from stackoverflow:
(http://stackoverflow.com/questions/6257078/casting-clutteractor-to-clutterstage)
How to write this:
---
alias extern(C) void function(void*, const char*) setTitleFunc;
auto clutter_stage_set_title =
getSym!(setTitleFunc)(clutter_stage_set_title);
---
without the alias?

http://d.puremagic.com/issues/show_bug.cgi?id=2168 and
http://d.puremagic.com/issues/show_bug.cgi?id=4288 seem to be related,
extern(C) seems to work almost nowhere ;-)


-- 
Johannes Pfau



Re: SDL with D

2011-07-12 Thread Mike Parker

On 7/12/2011 4:21 PM, Dainius (GreatEmerald) wrote:

I see. And what about Lua? I see lots and lots of different libraries
for that on dsource, and there is even some support in Derelict as
well. I assume that LuaD is the one in active development and most
fitting for current D2?


Derelict has no Lua binding yet. It's on the todo list. I'm waiting for 
Lua 5.2 to be released.


Re: SDL with D

2011-07-12 Thread Dainius (GreatEmerald)
According to the Derelict page, there already are unofficial bindings.
But I guess they wouldn't work with Derelict2 anyway.


Re: Declaring a D pointer to a C function

2011-07-12 Thread Marco Cosentino

On 12/07/2011 11:36, Johannes Pfau wrote:

 From a discussion related to derelict:
How do you write this:
---
alias extern(C) int function(void* test) FTInitFunc;
FTInitFunc FT_Init_FreeType
---
without the alias?
---
extern(C) int function(void* test) FT_Init_FreeType;
---
is not the same!
both are fields containing a C function pointer, but the first field
has D name mangling (_D4test16FT_Init_FreeTypePUPvZi) and the second
has C name mangling: (FT_Init_FreeType, which conflicts with the C
function FT_Init_FreeType)

And a related question from stackoverflow:
(http://stackoverflow.com/questions/6257078/casting-clutteractor-to-clutterstage)
How to write this:
---
alias extern(C) void function(void*, const char*) setTitleFunc;
auto clutter_stage_set_title =
getSym!(setTitleFunc)(clutter_stage_set_title);
---
without the alias?

http://d.puremagic.com/issues/show_bug.cgi?id=2168 and
http://d.puremagic.com/issues/show_bug.cgi?id=4288 seem to be related,
extern(C) seems to work almost nowhere ;-)




You should declare the function pointer without the extern(C).

Example:
alias int function(void* test) FTInitFunc;

extern(C) int foo(void* test){  }

FTInitFunc foo_ptr = foo;

This worked for me.


Re: Declaring a D pointer to a C function

2011-07-12 Thread Trass3r

You should declare the function pointer without the extern(C).

Example:
alias int function(void* test) FTInitFunc;

extern(C) int foo(void* test){  }

FTInitFunc foo_ptr = foo;

This worked for me.


That's a bug.


Re: A possible feature request: Make writef with %s call to!string for char* parameters

2011-07-12 Thread Steven Schveighoffer
On Mon, 11 Jul 2011 16:37:12 -0400, Andrej Mitrovic  
andrej.mitrov...@gmail.com wrote:



import std.stdio;
import std.string;

void main()
{
char* foo = foo\0.dup.ptr;
writefln(Foo: %s, foo);
}

This will write the address of foo. Often when you link with C code
you have C structures such as this:
struct Info
{
char* name;
char* info;
}

I think it would be convenient if writef would call to!string for
char* parameters behind the scenes if %s is the format specifier.

I mean yes, you can use to!string in your code, or you can write D
classes that wrap C libraries, but when you're *testing* D code ported
from C it would be so much more convenient if you can pass a char* to
writef() and use %s to treat it as a C string without having to go
through the trouble of writing to!string everywhere.


I feel uneasy with this feature.  Basically, this means writef makes the  
assumption that char * always means zero-terminated string.  But that is  
not necessarily true.  There is a huge problem with this in C, it's called  
buffer overflow errors.  I'd rather you have to be specific when dealing  
with writef, it would be too easy to get back into buffer overflow hell.


That being said, there should be an easy way to create a char array from a  
zero-terminated string *without* allocation.  Essentially, you need to do  
strlen on the string, and then convert to an array.  This is superior to  
to!string since you do not need to make a copy of the data (especially if  
just printing it, that would be a waste).


I don't know if such a thing exists, it definitely would be a useful thing  
I think.


-Steve


Re: Is there any way I can have one handler for multiple exceptions?

2011-07-12 Thread Steven Schveighoffer
On Mon, 11 Jul 2011 18:08:19 -0400, Andrej Mitrovic  
andrej.mitrov...@gmail.com wrote:



I'm trying to do something like the following:

import std.exception;

class Foo : Exception
{
this(string msg) { super(msg); }
}

class Bar : Exception
{
this(string msg) { super(msg); }
}

void main()
{
try
{
}
catch (Foo) catch (Bar)
{
}
}

Some function might throw two types of exceptions, but I don't care
which one it is, I'd like to handle them both within one catch block.
Is this possible?


Call a function?


void main()
{
   void handleEx(Exception e)
   {
  // exception handling code here
   }

   try
   {
   }
   catch(Foo f)
   {
  handleEx(f);
   }
   catch(Bar b)
   {
  handleEx(b);
   }
}

Another option is *shudders* goto.

-Steve


Re: Declaring a D pointer to a C function

2011-07-12 Thread Steven Schveighoffer

On Tue, 12 Jul 2011 05:36:15 -0400, Johannes Pfau s...@example.com wrote:


From a discussion related to derelict:
How do you write this:
---
alias extern(C) int function(void* test) FTInitFunc;
FTInitFunc FT_Init_FreeType
---
without the alias?
---
extern(C) int function(void* test) FT_Init_FreeType;
---
is not the same!
both are fields containing a C function pointer, but the first field
has D name mangling (_D4test16FT_Init_FreeTypePUPvZi) and the second
has C name mangling: (FT_Init_FreeType, which conflicts with the C
function FT_Init_FreeType)

And a related question from stackoverflow:
(http://stackoverflow.com/questions/6257078/casting-clutteractor-to-clutterstage)
How to write this:
---
alias extern(C) void function(void*, const char*) setTitleFunc;
auto clutter_stage_set_title =
getSym!(setTitleFunc)(clutter_stage_set_title);
---
without the alias?


extern(C) extern(C) maybe?  :)

or maybe:

extern(C) int function(void * test) extern(C) FT_Init_FreeType;

Just some thoughts, it probably doesn't work.

-Steve


Re: This seems like what could be a common cause of bugs

2011-07-12 Thread Steven Schveighoffer

On Mon, 11 Jul 2011 16:46:07 -0400, Nick Sabalausky a@a.a wrote:


Steven Schveighoffer schvei...@yahoo.com wrote in message




Hm... I didn't know about that switch, I thought warnings were enabled
with -w and that made them errors.

I suppose you could stick this in there.



-wi: Enable warnings
-w: Enable warnings and treat them as errors

Didn't used to have -wi, but I bugged the hell out of Walter about it. ;)

The --help screen describes -w and -wi differently than above, but the  
above

is more accurate.


Yes, but this is getting into territory where the false positive rate  
might get high.  I don't think it should be an error under -w.  So that  
means -wi and -w would cover different sets of warnings.


-Steve


template instance cannot use local 'f' as parameter to non-global template

2011-07-12 Thread Trass3r

Is this a bug? If not, how do you make it work?

void h() {}

class Bla
{
mixin wrap!h;
}

mixin template wrap(alias f)
{
void blub(alias g = f)()
{
}
}

void main()
{
Bla b = new Bla();
b.blub();
}

test.d(18): Error: template instance cannot use local 'f' as parameter to  
non-global template blub(alias g = f)

test.d(18): Error: template instance forward reference of f
test.d(18): Error: template instance test.Bla.wrap!(h).blub!(f) error  
instantiating


Re: opCast, c bindings and normal casts.

2011-07-12 Thread Steven Schveighoffer

On Sat, 09 Jul 2011 05:47:51 -0400, Johannes Pfau s...@example.com wrote:


Hi,

I have a wrapper for a object aware c library (cairo). Take for
example two classes, Surface and a subclass, ImageSurface. Now this
code has to be valid:
---
auto ptr = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 512, 512);
Surface s = new Surface(ptr);
ImageSurface imgs = cast(ImageSurface)s;
---

As D cannot know that 's' really should be an ImageSurface, I have
implemented opCast to get this example working:
---
class Surface
{
static Surface castFrom(Surface other)
{
return other;
}
   T opCast(T)() if(isImplicitlyConvertible!(T, Surface))
{
return T.castFrom(this);
}
}
class ImageSurface : Surface
{
static ImageSurface castFrom(Surface other)
{
auto type = cairo_surface_get_type(other.nativePointer);
if(type == cairo_surface_type_t.CAIRO_SURFACE_TYPE_IMAGE)
{
return new ImageSurface(other.nativePointer);
}
else
return null;
}
}
---

This code works quite well. But it performs unnecessary calls to
cairo_surface_get_type (and allocates unnecessary objects) for simple
cases:
---
auto surface = new ImageSurface(Format.CAIRO_FORMAT_ARGB32, 400, 400);
Surface tmp = cast(Surface)surface;
ImageSurface test = cast(ImageSurface)as;
---

In this case, the first D object already is an ImageSurface so the
custom opCast code isn't needed for the last line.

So the question is: Is there some way to check in the opCast function
if a normal D object cast would succeed and then just return it's
result?


I think a factory method would work well here.

If you have a finite set of classes you are creating, a factory method can  
simply use a switch on the cairo_surfase_type, and you could even put it  
in Surface:


auto s = Surface.create(ptr); // automatically creates the correct derived  
class.


Then use dynamic cast to get to the expected derived class.

If you do not have a finite set of classes, you may be able to use runtime  
type info (a la object.factory).  But from your example, it seems like  
cairo defines an enum which encapsulates all classes.


Another option, judging from your code, if cairo's functions to create  
surface objects are specific to the derived type (i.e.  
cairo_image_surface_create = ImageSurface), then you could simply wrap  
the cairo functions.  Basically avoid calling the C creation routines  
outside the D class constructors.


-Steve


Re: opCast, c bindings and normal casts.

2011-07-12 Thread Johannes Pfau
Steven Schveighoffer wrote:
On Sat, 09 Jul 2011 05:47:51 -0400, Johannes Pfau s...@example.com
wrote:

 Hi,

 I have a wrapper for a object aware c library (cairo). Take for
 example two classes, Surface and a subclass, ImageSurface. Now this
 code has to be valid:
 ---
 auto ptr = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 512, 512);
 Surface s = new Surface(ptr);
 ImageSurface imgs = cast(ImageSurface)s;
 ---

 As D cannot know that 's' really should be an ImageSurface, I have
 implemented opCast to get this example working:
 ---
 class Surface
 {
 static Surface castFrom(Surface other)
 {
 return other;
 }
T opCast(T)() if(isImplicitlyConvertible!(T, Surface))
 {
 return T.castFrom(this);
 }
 }
 class ImageSurface : Surface
 {
 static ImageSurface castFrom(Surface other)
 {
 auto type = cairo_surface_get_type(other.nativePointer);
 if(type == cairo_surface_type_t.CAIRO_SURFACE_TYPE_IMAGE)
 {
 return new ImageSurface(other.nativePointer);
 }
 else
 return null;
 }
 }
 ---

 This code works quite well. But it performs unnecessary calls to
 cairo_surface_get_type (and allocates unnecessary objects) for simple
 cases:
 ---
 auto surface = new ImageSurface(Format.CAIRO_FORMAT_ARGB32, 400,
 400); Surface tmp = cast(Surface)surface;
 ImageSurface test = cast(ImageSurface)as;
 ---

 In this case, the first D object already is an ImageSurface so the
 custom opCast code isn't needed for the last line.

 So the question is: Is there some way to check in the opCast function
 if a normal D object cast would succeed and then just return it's
 result?

I think a factory method would work well here.

If you have a finite set of classes you are creating, a factory method
can simply use a switch on the cairo_surfase_type, and you could even
put it in Surface:

auto s = Surface.create(ptr); // automatically creates the correct
derived class.

Then use dynamic cast to get to the expected derived class.

If you do not have a finite set of classes, you may be able to use
runtime type info (a la object.factory).  But from your example, it
seems like cairo defines an enum which encapsulates all classes.

Another option, judging from your code, if cairo's functions to
create surface objects are specific to the derived type (i.e.  
cairo_image_surface_create = ImageSurface), then you could simply
wrap the cairo functions.  Basically avoid calling the C creation
routines outside the D class constructors.

-Steve

Thanks for answering.
I already use such a factory method (called createFromNative). I also
create the correct D objects if the Surfaces are created from D
as in your second suggestion (I still need createFromNative, as there
are methods like cairo_pattern_get_surface which receive Surfaces from
cairo).
Thinking about it the whole opCast stuff is indeed obsolete as long as
all code correctly calls createFromNative. I first wanted to make it
possible to add Surface wrappers outside of cairoD, but I dropped that
idea. Without that feature a factory method should be enough.

-- 
Johannes Pfau



Re: Centralizable configured compile-time class instantiation

2011-07-12 Thread shd
Firstly, thanks for response.
2011/7/11 Jesse Phillips jessekphillip...@gmail.com:
 I'm sorry to say that I don't exactly know what you are trying to achieve or 
 problems you are having. I'm going to trying  and provide details on what I 
 have gotten out of your message.

Hopefully i'll clarify it more.

 You can do compile-time configuration, this however is not a replacement to 
 run-time configuration files.

I'm aware, and that's not my goal - let me clarify difference between
my run-time and compile-time configs.
Run-time configuration for my project might be delegated to optional
`util.cfg` package which is able to read let's say XML file that will
store things like resolution or something.

While i'm trying to make my potentially very big project possible to
make in reasonable time, i'm pretty focused on code-reusing and making
use of third-party libraries. Because external code quality might
change, my preferences might change, and APIs are not what i'd love to
work with i'd like to try pay price of composing D object interfaces i
like, and implement them with wrappers that are connecting with
external code.

So, back on to my previous example of runtime `util.cfg`, it might use
filesystem/http reader and xml/cvs formatter from package `io` (this
is gonna be run-time configuration) BUT besides of that i might like
to change xml phobos wrapper (actually this example is not the best)
with rapidxml or whatever and *this* is gonna be compile-time config.
So, config has to be configured and it is going to be configured
statically.

Ps. Don't get me wrong, i'm not in love with wrapping standard
library, but there are other classes which i'm going to use which have
no interface in phobos. This was just an example.

 What you are trying to do, you probably don't want to do. It sounds like you 
 should be providing a library that can be expanded on rather than a 
 configurable implementation. Maybe this is what you are trying to do, and it 
 might help to think of it in this form instead.

Well, my end-goal is to provide complete application. Because i
embrace code reusability, i love specialized libraries and when i'll
need to implement something specialized, then share it - i'd love to
do that. I'm afraid it's more like framework than library, but i don't
like frameworks because they force you to use everything. What i'd
like to achieve is to let someone use only parts of my code for
plugging it into his application, lessen dependencies as much as i
can, while remain type-safe.

Actually, project structure looks like that:
* project/
  * bin/
  * work/
  * docs/
  * iface/
* ae
* ge
* pe
(...)
  * impl/
* glfw
  * ge.window
  * io.hid.keyboard
  * io.hid.mouse
  (you can add other window toolkits, or just separate OpenGL
context creation code and user-input handling from different
libraries)
  * h3d
* ge.renderer
(...)
  (you can add any other renderers or parts of game engines if
they let you to do that)
* project_name
  * package.interfaces implemented by me
  * pe
* bullet
* ode
* newton
(code is opensource and publicly accessible but excuse me i don't
quote anything because it's currently ugly and unprofessional so i'm
not proud of it yet, although i figured it out it's best way to do my
way, it just needs time and work to be proud)

So, i could easily change libraries, someone might use parts of my
code by implementing bounding interfaces and as side effect i could
easily benchmark how different implementations act in my project (like
with C++ PAL).

So, if i'll handle task of abstracting all this out, and get
reasonable performance that's the other topic, but i believe it's
worth a try. All i need is to have a tool that lets me choose
implementation at compile time without interface file modification.
Any clues?

 D provides Anti-Highjacking measures to prevent a module from calling into 
 code it did not know existed upon creation. This does prevent some 
 interesting (and useful) patterns from being used, but generally it just 
 results in unexpected, hard to track bugs.

Any anti-anti-hijacking ideas? :)


Re: Declaring a D pointer to a C function

2011-07-12 Thread Johannes Pfau
Steven Schveighoffer wrote:
On Tue, 12 Jul 2011 05:36:15 -0400, Johannes Pfau s...@example.com
wrote:

 From a discussion related to derelict:
 How do you write this:
 ---
 alias extern(C) int function(void* test) FTInitFunc;
 FTInitFunc FT_Init_FreeType
 ---
 without the alias?
 ---
 extern(C) int function(void* test) FT_Init_FreeType;
 ---
 is not the same!
 both are fields containing a C function pointer, but the first field
 has D name mangling (_D4test16FT_Init_FreeTypePUPvZi) and the second
 has C name mangling: (FT_Init_FreeType, which conflicts with the C
 function FT_Init_FreeType)

 And a related question from stackoverflow:
 (http://stackoverflow.com/questions/6257078/casting-clutteractor-to-clutterstage)
 How to write this:
 ---
 alias extern(C) void function(void*, const char*) setTitleFunc;
 auto clutter_stage_set_title =
 getSym!(setTitleFunc)(clutter_stage_set_title);
 ---
 without the alias?

extern(C) extern(C) maybe?  :)

or maybe:

extern(C) int function(void * test) extern(C) FT_Init_FreeType;

Nope, that doesn't work:
-
test.d(3): no identifier for declarator int C function(void* test)
test.d(3): semicolon expected, not 'extern'
test.d(3): no identifier for declarator FT_Init_FreeType
-

also, if that worked, shouldn't it be equal to this?
-
extern(C) int function(void* test) FT_Init_FreeType;
-
This works, but it's not what I want.
Derelict needs a _field_, FT_Init_FreeType with D name mangling. So the
usual {module}.{module}.FT_Init_FreeType in mangled form.
This _field_ should contain a pointer to a extern(C) function.

This code with alias does just that:
 ---
 alias extern(C) int function(void* test) FTInitFunc;
 FTInitFunc FT_Init_FreeType
 ---
but it's not practical for derelict to include aliases for all
functions, so the above must be accomplished without the alias.

I think it should be something like this:
-
extern(C) int function(void * test) extern(D) FT_Init_FreeType;
(extern(C) int function(void * test)) FT_Init_FreeType;
extern(C)(int function(void * test)) FT_Init_FreeType;
extern(C){int function(void * test)} FT_Init_FreeType;
-
None of these work, though.

Just some thoughts, it probably doesn't work.

-Steve


-- 
Johannes Pfau



Re: Declaring a D pointer to a C function

2011-07-12 Thread Johannes Pfau
Trass3r wrote:
 You should declare the function pointer without the extern(C).

 Example:
 alias int function(void* test) FTInitFunc;

 extern(C) int foo(void* test){  }

 FTInitFunc foo_ptr = foo;

 This worked for me.

That's a bug.

I agree. It looks like the above code assigns a extern(C) function
pointer to a field which should only accept D function pointers.
I guess if you then call foo_ptr dmd will use the D calling convention
and that'll crash, at least for more complicated functions.

-- 
Johannes Pfau



Re: Declaring a D pointer to a C function

2011-07-12 Thread Steven Schveighoffer

On Tue, 12 Jul 2011 09:42:22 -0400, Johannes Pfau s...@example.com wrote:


Steven Schveighoffer wrote:

On Tue, 12 Jul 2011 05:36:15 -0400, Johannes Pfau s...@example.com
wrote:


From a discussion related to derelict:
How do you write this:
---
alias extern(C) int function(void* test) FTInitFunc;
FTInitFunc FT_Init_FreeType
---
without the alias?
---
extern(C) int function(void* test) FT_Init_FreeType;
---
is not the same!
both are fields containing a C function pointer, but the first field
has D name mangling (_D4test16FT_Init_FreeTypePUPvZi) and the second
has C name mangling: (FT_Init_FreeType, which conflicts with the C
function FT_Init_FreeType)

And a related question from stackoverflow:
(http://stackoverflow.com/questions/6257078/casting-clutteractor-to-clutterstage)
How to write this:
---
alias extern(C) void function(void*, const char*) setTitleFunc;
auto clutter_stage_set_title =
getSym!(setTitleFunc)(clutter_stage_set_title);
---
without the alias?


extern(C) extern(C) maybe?  :)

or maybe:

extern(C) int function(void * test) extern(C) FT_Init_FreeType;


Nope, that doesn't work:
-
test.d(3): no identifier for declarator int C function(void* test)
test.d(3): semicolon expected, not 'extern'
test.d(3): no identifier for declarator FT_Init_FreeType
-

also, if that worked, shouldn't it be equal to this?
-
extern(C) int function(void* test) FT_Init_FreeType;
-
This works, but it's not what I want.
Derelict needs a _field_, FT_Init_FreeType with D name mangling. So the
usual {module}.{module}.FT_Init_FreeType in mangled form.
This _field_ should contain a pointer to a extern(C) function.



Oh, I misread which one did which.  I thought it was the opposite.

Hm... so extern(C) affects both the function pointer type and the name  
mangling.  Interesting.


But wait, don't normal D functions have C calling convention?  I thought  
that was one of the benefits of D's ABI?


-Steve


Re: Declaring a D pointer to a C function

2011-07-12 Thread Marco Cosentino

On 12/07/2011 13:15, Trass3r wrote:

You should declare the function pointer without the extern(C).

Example:
alias int function(void* test) FTInitFunc;

extern(C) int foo(void* test){  }

FTInitFunc foo_ptr = foo;

This worked for me.


That's a bug.


Oh, well, I forgot to mention that the function pointer is a callback 
that gets called by a linked C library. IMHO I don't think that the 
alias definition should carry with her the informations about the 
calling convention. This is a convention for the caller and the callee.


Re: Declaring a D pointer to a C function

2011-07-12 Thread Steven Schveighoffer
On Tue, 12 Jul 2011 09:53:28 -0400, Steven Schveighoffer  
schvei...@yahoo.com wrote:


But wait, don't normal D functions have C calling convention?  I thought  
that was one of the benefits of D's ABI?


Tested it out, definitely is different.  So this clearly needs to be  
addressed.


-Steve


Re: This seems like what could be a common cause of bugs

2011-07-12 Thread Kagamin
Steven Schveighoffer Wrote:

 Yes, but this is getting into territory where the false positive rate  
 might get high.

I bet it will be difficult to find a real-world example of this false positive.


Re: This seems like what could be a common cause of bugs

2011-07-12 Thread Steven Schveighoffer

On Tue, 12 Jul 2011 11:07:57 -0400, Kagamin s...@here.lot wrote:


Steven Schveighoffer Wrote:


Yes, but this is getting into territory where the false positive rate
might get high.


I bet it will be difficult to find a real-world example of this false  
positive.


It depends on how the warning is triggered.

Does this fail?

double x = 1;

Does this:

double x = 1 / 2;

How about this:

void foo(int x, int y)
in
{
   assert(y != 0);
   assert(x % y == 0);
}
body
{
  double z = x / y;
}

The reason for declaring something a double is not always because you want  
the thing you are assigning it to be a double expression.  For instance,  
sometimes I do something like this:


int z = x / y;

And then realize, all the places where I use z, I actually want to be  
doubles, so I simply change it to:


double z = x / y;

To avoid frequent casting.

-Steve


Re: Centralizable configured compile-time class instantiation

2011-07-12 Thread Kagamin
shd Wrote:

 Actually, project structure looks like that:
 * project/
   * bin/
   * work/
   * docs/
   * iface/
 * ae
 * ge
 * pe
 (...)
   * impl/
 * glfw
   * ge.window
   * io.hid.keyboard
   * io.hid.mouse
   (you can add other window toolkits, or just separate OpenGL
 context creation code and user-input handling from different
 libraries)
   * h3d
 * ge.renderer
 (...)
   (you can add any other renderers or parts of game engines if
 they let you to do that)
 * project_name
   * package.interfaces implemented by me
   * pe
 * bullet
 * ode
 * newton
 (code is opensource and publicly accessible but excuse me i don't
 quote anything because it's currently ugly and unprofessional so i'm
 not proud of it yet, although i figured it out it's best way to do my
 way, it just needs time and work to be proud)
 
 So, i could easily change libraries, someone might use parts of my
 code by implementing bounding interfaces and as side effect i could
 easily benchmark how different implementations act in my project (like
 with C++ PAL).
 
 So, if i'll handle task of abstracting all this out, and get
 reasonable performance that's the other topic, but i believe it's
 worth a try. All i need is to have a tool that lets me choose
 implementation at compile time without interface file modification.
 Any clues?

You want an IOC container like Unity?
And you want the interface-to-class mapping to be configurable externally 
rather than version out these classes directly in source?
like
version(UseGL)
{
  static import wrappers.gl;
  alias wrappers.gl.WindowImpl Window;
}
else version(UseWhat)
{
  static import wrappers.what;
  alias wrappers.what.WindowImpl Window;
}
container.register!(IWindow,Window)();

client:

IWindow myWindow=container.resolve!(IWindow)();


Re: Centralizable configured compile-time class instantiation

2011-07-12 Thread shd
2011/7/12 Kagamin s...@here.lot:
 You want an IOC container like Unity?
exactly
 And you want the interface-to-class mapping to be configurable externally 
 rather than version out these classes directly in source?
 like
 version(UseGL)
 {
  static import wrappers.gl;
  alias wrappers.gl.WindowImpl Window;
 }
 else version(UseWhat)
 {
  static import wrappers.what;
  alias wrappers.what.WindowImpl Window;
 }
 container.register!(IWindow,Window)();

 client:

 IWindow myWindow=container.resolve!(IWindow)();

that's right :)


Re: Running DMD tests

2011-07-12 Thread Trass3r
Am 13.06.2011, 23:55 Uhr, schrieb Peter Alexander  
peter.alexander...@gmail.com:



I'm trying to run the test suite for DMD, but I'm running into issues.
Do I need to set up my environment differently to run dmd in  
development? How can I get around this?


To quote IRC:

In theory it's simple: go to dmd/test and run make.
In practice you need to have druntime and phobos installed at the right  
places.
I think if you clone dmd, druntime, and phobos and put them all in the  
same directory, then you build dmd, druntime, and phobos, then you should  
be able to run the test suite.


you also need to have a dmd.conf that's not included with the suite :   

Ah, yeah, true. And since I remember I made my dmd.conf point to those  
places, maybe you don't need to have druntime and phobos there after all.
But it's still a good idea to be able to get non-release druntime (and to  
some extent phobos) when playing with non-release versions of DMD.


Re: Is there any way I can have one handler for multiple exceptions?

2011-07-12 Thread Andrej Mitrovic
On 7/12/11, Steven Schveighoffer schvei...@yahoo.com wrote:
 Call a function?
 void main()
 {
 void handleEx(Exception e)
 {
// exception handling code here
 }

 try
 {
 }
 catch(Foo f)
 {
handleEx(f);
 }
 catch(Bar b)
 {
handleEx(b);
 }
 }

Yeah that's what I did finally.


 Another option is *shudders* goto.

 -Steve


Get outta here! :p


Re: Running DMD tests

2011-07-12 Thread David Nadlinger
The problem you are experiencing comes from no dmd.conf being included 
with the Git repository. Either you can add one to your Git clone 
directory, or use your normal system-wide installation which probably 
has all the paths set up correctly by specifying the DMD variable: »make 
DMD=/usr/local/bin/dmd«.


David


On 6/13/11 11:55 PM, Peter Alexander wrote:

I'm trying to run the test suite for DMD, but I'm running into issues.

I've cloned dmd from github, and successfully built dmd, but when I run
'make' from the dmd/test dir, I get:

$ make
Creating output directory: test_results
Building d_do_test tool
object.d: Error: module object is in file 'object.d' which cannot
be read
Specify path to file 'object.d' with -I switch
make: *** [test_results/d_do_test] Error 1

Do I need to set up my environment differently to run dmd in
development? How can I get around this?

Note: I'm running OSX 10.6.7

Thanks




Re: translate a macro to D

2011-07-12 Thread teo

 I think you may be confusing function templates with plain templates?

Yes, I was a bit confused by the syntax, but I found that type of 
templates on page 281 in TDPL. That is an eponymous template.
Thanks.


Re: Running DMD tests

2011-07-12 Thread Trass3r

Am 12.07.2011, 20:57 Uhr, schrieb David Nadlinger s...@klickverbot.at:
or use your normal system-wide installation which probably has all the  
paths set up correctly by specifying the DMD variable: »make  
DMD=/usr/local/bin/dmd«.


Thanks a lot for that hint!


starting independent processes

2011-07-12 Thread captaindet

i am just in the middle of my first little d project. i came to the point where 
i have to start new processes command line style incl arguments. they need to 
run independent of the main program, i.e., several such processes need to be 
started and must run parallel while the main program continues and maybe even 
finishes.

in c/c++ (M$ VS2005, e.g.) this can be achieved using one of the spawnXXX 
functions with mode=P_DISPATCH (value 4).

phobos has a similar function std.process.spawnvp, however, P_DISPATCH doesn't 
seem to be supported (not defined and when using '4L' anyway resulting in a 
crash).

so the main question is: what do i do instead? (win32 system)


also i noticed that std.process.spawnvp with mode=P_NOWAIT seems to be broken. 
it behaves as if mode=P_WAIT: the parent thread is halted until child thread 
has finished. if this at least would be multithreaded i might be able to live 
with it (and let the parent process silently wait in the background even though 
it is done).

thx,  det


Re: Declaring a D pointer to a C function

2011-07-12 Thread Andrej Mitrovic
I just had a bug where a D function is implicitly converted to an
extern(C) function pointer.

I've had this definition:
alias extern (C) void function(void* userData) PaStreamFinishedCallback;

And this extern(C) function:
PaError  Pa_SetStreamFinishedCallback(PaStream* stream,
PaStreamFinishedCallback streamFinishedCallback);

And I used this callback:
void StreamFinished(void* userData)
{
auto localData = cast(TestData*)userData;
writefln(Stream Completed: %s, localData.message);
}

// this is where the binding takes place
void main() { ...; SetStreamFinishedCallback(..., StreamFinished); }

That code is invalid. The fix is to add extern(C) to my callback:
extern(C) void StreamFinished(void* userData)

Is this going to be fixed any time soon? Allowing callbacks with D
calling convention where a C callback is expected should be an error,
and this is like the 10th time I've ran into this bug.


Re: Declaring a D pointer to a C function

2011-07-12 Thread Trass3r

Is this going to be fixed any time soon? Allowing callbacks with D
calling convention where a C callback is expected should be an error,
and this is like the 10th time I've ran into this bug.


http://d.puremagic.com/issues/show_bug.cgi?id=3797


Re: Declaring a D pointer to a C function

2011-07-12 Thread Andrej Mitrovic
On 7/12/11, Trass3r u...@known.com wrote:
 Is this going to be fixed any time soon? Allowing callbacks with D
 calling convention where a C callback is expected should be an error,
 and this is like the 10th time I've ran into this bug.

 http://d.puremagic.com/issues/show_bug.cgi?id=3797

Thanks, I'm voting this up


Re: Declaring a D pointer to a C function

2011-07-12 Thread Andrej Mitrovic
Oh there's a pull already, this is great.
https://github.com/D-Programming-Language/dmd/pull/96


Uninitialized floating-point exceptions - optional compile-time warnings?

2011-07-12 Thread Andrej Mitrovic
I'm wondering about this:

void main()
{
import std.math;
FloatingPointControl fpc;
fpc.enableExceptions(FloatingPointControl.severeExceptions);

float foo;
}

Declaring uninitialized floating point variables after enabling severe
exceptions will throw at runtime:
object.Error: Invalid Floating Point Operation

I don't know whether this is intentional or not, if it is then:

Why not make this an optional compile-time warning as well? The
compiler is smart enough to figure out that foo was declared
uninitialized. Perhaps we could add another switch for this purpose.

I'm running into a lot of these uninitialized floating-point issues
lately, and that's exactly why I'm using FloatingPointControl. However
this is only useful at runtime. If the compiler can catch some of
these at compile-time via some optional switch that would make the
situation much better.


Re: Uninitialized floating-point exceptions - optional compile-time

2011-07-12 Thread bearophile
Andrej Mitrovic:


 I don't know whether this is intentional or not, 

I think it was not intentional. Regarding your successive questions, Don is 
your man and best hope.

Bye,
bearophile


Re: Uninitialized floating-point exceptions - optional compile-time

2011-07-12 Thread Andrej Mitrovic
I think he's on a vacation though. :p


Re: Centralizable configured compile-time class instantiation

2011-07-12 Thread Jesse Phillips
shd Wrote:

 Firstly, thanks for response.

After reading Kagamin's response, I'm not sure I understand you still. You want 
to have code reuse, you want to have run-time and compile-time configuration, 
but you don't want to make use of the technologies/techniques/patterns which 
facilitate these.

You say no to libraries, you say no to frameworks, you say no to versioning and 
desire the benefits of these without what they entail. If you come up with an 
alternative, then please do bring it forward. I don't see how anyone will be 
able to get you what you want.