1. Problems with C floats
- Posted by irv Jan 30, 2010
- 2458 views
Are there known bugs when passing Eu values to C_FLOAT ? I have several routines in EuGTK which worked fine with Eu 3, but no longer work properly now with 4.0. Each of these routines has one thing in common, they pass floats to c_func or c_proc.
2. Re: Problems with C floats
- Posted by jimcbrown (admin) Jan 30, 2010
- 2524 views
Are there known bugs when passing Eu values to C_FLOAT ? I have several routines in EuGTK which worked fine with Eu 3, but no longer work properly now with 4.0. Each of these routines has one thing in common, they pass floats to c_func or c_proc.
There were some, that have been fixed. If there are still problems, it's either a new bug or a previously fixed bug that broke again recently...
3. Re: Problems with C floats
- Posted by irv Jan 30, 2010
- 2485 views
For a test, in the demos there's callc.exu - copying the last test, and changing the C_DOUBLE to a C_FLOAT, we have this code:
puts(1, "\n> printf test:\n") s = define_c_proc(libc, "printf", {C_POINTER, C_INT, C_DOUBLE, C_INT, C_DOUBLE}) format = allocate_string("Here are 4 numbers: %d, %.3f, %d, %e\n") c_proc(s, {format, 111, 222.222, 333, 444.4444}) puts(1, "\n> printf test:\n") s = define_c_proc(libc, "printf", {C_POINTER, C_INT, C_DOUBLE, C_INT, C_FLOAT}) format = allocate_string("Here are 4 numbers: %d, %.3f, %d, %e\n") c_proc(s, {format, 111, 222.222, 333, 444.4444})
and get this printed:
> printf test: Here are 4 numbers: 111, 222.222, 333, 4.444444e+02 > printf test: Here are 4 numbers: 111, 222.222, 333, 1.332670e-269
Now, I may be doing something foolishly wrong, but the results I'm getting from my GTK programs indicate that something isn't getting through properly, and it only happens when C_FLOATs are involved.
4. Re: Problems with C floats
- Posted by jimcbrown (admin) Jan 30, 2010
- 2495 views
Yep, I can reproduce the bug.
Looking at line 182 of be_callc.c it is not obvious to me what the cause of the bug is. The casting code looks correct...
I think printf() is a bad example however. See http://www.eskimo.com/scs/cclass/int/sx11c.html and http://en.wikipedia.org/wiki/Stdarg.h#Type_safety
"A float will automatically be promoted to a double."
So when dealing with vararg functions in C, one must always use C_DOUBLE and never C_FLOAT, or things break... likewise, never use C_CHAR or C_SHORT for varargs functions.
5. Re: Problems with C floats
- Posted by mattlewis (admin) Jan 30, 2010
- 2498 views
Are there known bugs when passing Eu values to C_FLOAT ? I have several routines in EuGTK which worked fine with Eu 3, but no longer work properly now with 4.0. Each of these routines has one thing in common, they pass floats to c_func or c_proc.
I don't think so. Can you post some more details? I did this test:
// irv.c // build with: $ gcc -shared -fPIC -ldl irv.c -o irv.so #include <stdio.h> void test_float( double foo, float bar ){ printf( "double: %f\nfloat: %f\n", foo, bar ); }
...and then called it using:
-- irv.ex include std/dll.e constant irv = open_dll( "./irv.so" ), test_float = define_c_proc( irv, "test_float", {C_DOUBLE, C_FLOAT}) c_proc( test_float, { 0.25, 0.75})
Then I get:
$ eui irv double: 0.250000 float: 0.750000
So it looks good to me.
Matt
6. Re: Problems with C floats
- Posted by mattlewis (admin) Jan 30, 2010
- 2555 views
puts(1, "\n> printf test:\n") s = define_c_proc(libc, "printf", {C_POINTER, C_INT, C_DOUBLE, C_INT, C_FLOAT}) format = allocate_string("Here are 4 numbers: %d, %.3f, %d, %e\n") c_proc(s, {format, 111, 222.222, 333, 444.4444})
Now, I may be doing something foolishly wrong, but the results I'm getting from my GTK programs indicate that something isn't getting through properly, and it only happens when C_FLOATs are involved.
I think that printf expects a double float (64-bits) with the %f format. And if you send a known float in C code, the compiler will cast it to a double (which is what I suspect is happening in the example I posted). In this case, it expects a double, and ends up reading past your 32-bit float, because that's all it knows. There's no way for printf to be able to tell what you've actually passed to it, other than the clues you give in the format string.
Can you create a minimal code sample (C and euphoria) that demonstrates the problem?
Matt
7. Re: Problems with C floats
- Posted by jimcbrown (admin) Jan 30, 2010
- 2502 views
puts(1, "\n> printf test:\n") s = define_c_proc(libc, "printf", {C_POINTER, C_INT, C_DOUBLE, C_INT, C_FLOAT}) format = allocate_string("Here are 4 numbers: %d, %.3f, %d, %e\n") c_proc(s, {format, 111, 222.222, 333, 444.4444})
I think that printf expects a double float (64-bits) with the %f format.
Matt
The test used %e format, not %f format.
But OTOH I think all of printf's formats might expect doubles.. as I posted already in this thread.
8. Re: Problems with C floats
- Posted by irv Jan 30, 2010
- 2508 views
irv@irv-laptop ~ $ eui irv.ex double: 0.250000 float: 0.000000Note: Euphoria Interpreter 4.0.0 development (r3059) for Linux, same with 3061.
Note2: There's no printf involvement with the routines I'm having trouble with, it's just passing floating point values to graphics routines for positioning purposes.
9. Re: Problems with C floats
- Posted by mattlewis (admin) Jan 31, 2010
- 2416 views
irv@irv-laptop ~ $ eui irv.ex double: 0.250000 float: 0.000000Note: Euphoria Interpreter 4.0.0 development (r3059) for Linux, same with 3061.
Note2: There's no printf involvement with the routines I'm having trouble with, it's just passing floating point values to graphics routines for positioning purposes.
Yeah, I understand. printf is just the easiest way to see what's getting passed. I was running r3054, but I get the expected results after updating to 3061, too. I'm using gcc 4.4.1, BTW.
I can't get it to break. I switched order, changed the format to %e, added some other variables to pass...Can anyone else reproduce this?
Matt
10. Re: Problems with C floats
- Posted by jimcbrown (admin) Jan 31, 2010
- 2431 views
irv@irv-laptop ~ $ eui irv.ex double: 0.250000 float: 0.000000Note: Euphoria Interpreter 4.0.0 development (r3059) for Linux, same with 3061.
Note2: There's no printf involvement with the routines I'm having trouble with, it's just passing floating point values to graphics routines for positioning purposes.
I assume this rules out any and all use of varargs or stdargs ?
11. Re: Problems with C floats
- Posted by irv Jan 31, 2010
- 2419 views
I assume this rules out any and all use of varargs or stdargs ?
Yes, the routine in question needs the following: C_POINTER, C_FLOAT, C_FLOAT, C_FLOAT, C_INT No varargs involved, and the same routine in GTK works correctly when called by a C program.
12. Re: Problems with C floats
- Posted by jimcbrown (admin) Jan 31, 2010
- 2446 views
I can't get it to break. I switched order, changed the format to %e, added some other variables to pass...Can anyone else reproduce this?
Matt
No, it works for me... r3023
For reference, I'm placing the binary I'm using and my irv.so file online @
13. Re: Problems with C floats
- Posted by irv Jan 31, 2010
- 2406 views
WooHoo! The eui from above (version r3023) works fine! (both with the test program and with GTK) Something changed after that.
14. Re: Problems with C floats
- Posted by mattlewis (admin) Jan 31, 2010
- 2433 views
I assume this rules out any and all use of varargs or stdargs ?
Yes, the routine in question needs the following: C_POINTER, C_FLOAT, C_FLOAT, C_FLOAT, C_INT No varargs involved, and the same routine in GTK works correctly when called by a C program.
OK, I updated my test program:
// irv.c // build with $ gcc -shared -fPIC -ldl irv.c -o irv.so #include <stdio.h> void test_float( float foo, double bar, int baz ){ printf( "double: %e\nfloat: %e\nint: %d\n", foo, bar, baz ); } void test_irv( int *ptr, float f1, float f2, float f3, int i ){ printf( "ptr: %p\nf1: %f (%x)\nf2: %f (%x)\nf3: %f (%x)\ni: %d\n", ptr, f1, *(int*)(&f1), f2, *(int*)(&f2), f3, *(int*)(&f3), i ); }
...and the euphoria code:
-- irv.ex include std/dll.e constant irv = open_dll( "./irv.so" ), test_float = define_c_proc( irv, "test_float", {C_FLOAT, C_DOUBLE, C_INT}), test_irv = define_c_proc( irv, "test_irv", {C_POINTER, C_FLOAT, C_FLOAT, C_FLOAT, C_INT} ) c_proc( test_float, { 0.25, 0.75, 9}) c_proc( test_irv, { 0xDEADBEEF, 1, 2, 0.5, 8008135} )
And then I get:
$ gcc --version gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ eui -version Euphoria Interpreter 4.0.0 development (r3061M) for Linux Using System Memory $ eui irv double: 2.500000e-01 float: 7.500000e-01 int: 9 ptr: 0xdeadbeef f1: 1.000000 (3f800000) f2: 2.000000 (40000000) f3: 0.500000 (3f000000) i: 8008135
It all looks correct to me. However, this was with a locally built binary. I grabbed the latest eubin, and I got:
$ ./eui irv double: 4.601707e-34 float: 7.500000e-01 int: 9 ptr: 0xdeadbeef f1: 2.000000 (40000000) f2: 0.500000 (3f000000) f3: 0.000000 (818eaff) i: 8008135
What binary are you using? There's definitely something going on here.
Matt
15. Re: Problems with C floats
- Posted by mattlewis (admin) Jan 31, 2010
- 2437 views
WooHoo! The eui from above (version r3023) works fine! (both with the test program and with GTK) Something changed after that.
I don't think it's anything that changed in the source. I tried the eubins version of r3023, and I got the same bad results. I think there's something funky about the build environment for eubins.
Matt
16. Re: Problems with C floats
- Posted by irv Jan 31, 2010
- 2402 views
Yes, that is it (eubins). I compiled 3058 from source, and it works ok.
17. Re: Problems with C floats
- Posted by irv Jan 31, 2010
- 2405 views
Yes, that is it (eubins). I compiled 3058 from source, and it works ok.
HOWEVER - while sending floats now works, getting them back from a c routine still fails!
18. Re: Problems with C floats
- Posted by jimcbrown (admin) Jan 31, 2010
- 2440 views
Yes, that is it (eubins). I compiled 3058 from source, and it works ok.
HOWEVER - while sending floats now works, getting them back from a c routine still fails!
I posted the following files:
http://malcom.unkmar.com/irv2.c http://malcom.unkmar.com/irv2.ex http://malcom.unkmar.com/irv2.so
and I get the expected output (1.5) from the C function. I ran it with the same r3023 binary...
19. Re: Problems with C floats
- Posted by mattlewis (admin) Jan 31, 2010
- 2380 views
Yes, that is it (eubins). I compiled 3058 from source, and it works ok.
HOWEVER - while sending floats now works, getting them back from a c routine still fails!
I updated my test to:
// irv.c // build with $ gcc -shared -fPIC -ldl irv.c -o irv.so #include <stdio.h> void test_float( float foo, double bar, int baz ){ printf( "double: %e\nfloat: %e\nint: %d\n", foo, bar, baz ); } float test_irv( int *ptr, float f1, float f2, float f3, int i ){ printf( "ptr: %p\nf1: %f (%x)\nf2: %f (%x)\nf3: %f (%x)\ni: %d\n", ptr, f1, *(int*)(&f1), f2, *(int*)(&f2), f3, *(int*)(&f3), i ); return f1 + f2; }
...and...
-- irv.ex include std/dll.e constant irv = open_dll( "./irv.so" ), test_float = define_c_proc( irv, "test_float", {C_FLOAT, C_DOUBLE, C_INT}), test_irv = define_c_func( irv, "test_irv", {C_POINTER, C_FLOAT, C_FLOAT, C_FLOAT, C_INT}, C_FLOAT ) c_proc( test_float, { 0.25, 0.75, 9}) ? c_func( test_irv, { 0xDEADBEEF, 1.1, 2.3, 0.5, 8008135} )
And I get:
$ eui irv double: 2.500000e-01 float: 7.500000e-01 int: 9 ptr: 0xdeadbeef f1: 1.100000 (3f8ccccd) f2: 2.300000 (40133333) f3: 0.500000 (3f000000) i: 8008135 3.399999976
Or did you mean as a callback? That shouldn't have ever worked. A euphoria callback routine assumes that it's getting back all 32-bit integers, so you'd need to convert the float:
function my_callback( atom the_float ) poke4( buffer, the_float ) the_float = float32_to_atom( peek( { buffer, 4 } ) ) return 0 end function
Matt
20. Re: Problems with C floats
- Posted by irv Jan 31, 2010
- 2414 views
Your tests work. This is a different problem - many GTK routines return 2 or more values, as follows:
void gtk_window_get_default_size (GtkWindow *window, gint *width, gint *height);By allocating variables and passing them to the routine, they get filled in with the current values. This works fine as long as the vars are integers, pointers, or doubles, but when they are floats, I get an machine exception. I tried using safe.e, but can't see anything there to help. Perhaps this is related to the previous problem when passing floats to a c routine?
21. Re: Problems with C floats
- Posted by mattlewis (admin) Jan 31, 2010
- 2375 views
Your tests work. This is a different problem - many GTK routines return 2 or more values, as follows:
void gtk_window_get_default_size (GtkWindow *window, gint *width, gint *height);By allocating variables and passing them to the routine, they get filled in with the current values. This works fine as long as the vars are integers, pointers, or doubles, but when they are floats, I get an machine exception. I tried using safe.e, but can't see anything there to help. Perhaps this is related to the previous problem when passing floats to a c routine?
Not sure what you're doing as far as passing floats:
// irv.c // build with $ gcc -shared -fPIC -ldl irv.c -o irv.so #include <stdio.h> void pbr_float( float * pf ){ *pf += 5.5f; }
...and then...
-- irv.ex include std/dll.e include std/machine.e include std/convert.e constant irv = open_dll( "./irv.so" ), pbr_float = define_c_proc( irv, "pbr_float", {C_POINTER} ) atom ptr = allocate( 4 ) poke( ptr, atom_to_float32( 1.5 ) ) c_proc( pbr_float, {ptr} ) ? float32_to_atom( peek( ptr & 4 ) )
From that, I get:
$ eui irv 7
...which is correct.
Matt
22. Re: Problems with C floats
- Posted by jimcbrown (admin) Jan 31, 2010
- 2407 views
Yes, that is it (eubins). I compiled 3058 from source, and it works ok.
HOWEVER - while sending floats now works, getting them back from a c routine still fails!
I posted the following files:
http://malcom.unkmar.com/irv2.c http://malcom.unkmar.com/irv2.ex http://malcom.unkmar.com/irv2.so
and I get the expected output (1.5) from the C function. I ran it with the same r3023 binary...
Sorry, that should be
http://malcom.unkmar.com/lostsouls/irv2.c http://malcom.unkmar.com/lostsouls/irv2.ex http://malcom.unkmar.com/lostsouls/irv2.so
23. Re: Problems with C floats
- Posted by jimcbrown (admin) Jan 31, 2010
- 2378 views
Your tests work. This is a different problem - many GTK routines return 2 or more values, as follows:
void gtk_window_get_default_size (GtkWindow *window, gint *width, gint *height);By allocating variables and passing them to the routine, they get filled in with the current values. This works fine as long as the vars are integers, pointers, or doubles, but when they are floats, I get an machine exception. I tried using safe.e, but can't see anything there to help. Perhaps this is related to the previous problem when passing floats to a c routine?
You know, it'd help a lot if you posted example code demonstrating the bug...
Anyways, I updated the tests here:
http://malcom.unkmar.com/lostsouls/irv3.c http://malcom.unkmar.com/lostsouls/irv3.ex http://malcom.unkmar.com/lostsouls/irv3.so
And I get the expected results. So this looks like it works fine, or at least I can't reproduce the issue...
24. Re: Problems with C floats
- Posted by jimcbrown (admin) Jan 31, 2010
- 2369 views
Perhaps this is related to the previous problem when passing floats to a c routine?
What problem?
25. Re: Problems with C floats
- Posted by irv Jan 31, 2010
- 2368 views
If I knew enough C to write the tests, I wouldn't need Euphoria. I'll just wait until someone else has the same problem, and it gets fixed.
26. Re: Problems with C floats
- Posted by jimcbrown (admin) Jan 31, 2010
- 2495 views
If I knew enough C to write the tests, I wouldn't need Euphoria. I'll just wait until someone else has the same problem, and it gets fixed.
Can't you post a small GTK/euGTK demo that demonstrates the issue that you are seeing?
27. Re: Problems with C floats
- Posted by mattlewis (admin) Jan 31, 2010
- 2368 views
If I knew enough C to write the tests, I wouldn't need Euphoria. I'll just wait until someone else has the same problem, and it gets fixed.
The problem is, from what you've said, the bug appears to be in your euphoria code, not euphoria itself. We've come up with test scenarios to try the things you've discovered. Admittedly, there appears to be something wrong with the eubins build, but the problem appears to be there, not with the euphoria code. I'm happy to help figure it out, but I think we need an example that demonstrates the issue.
Matt
28. Re: Problems with C floats
- Posted by irv Jan 31, 2010
- 2351 views
I'm not going to bother, there are only two or three functions that return multiple floating point values in GTK, and they're not very important. I'll just comment those out.
29. Re: Problems with C floats
- Posted by irv Feb 01, 2010
- 2292 views
// irv.c // build with $ gcc -shared -fPIC -ldl irv3.c -o irv3.so #include <stdio.h> static int a = 12; static double b = 34567890; static float c = 67.890123; void test_float(int *foo, double *bar, float *baz){ printf( "C in:\n\tfoo: %d\n\tbar: %e\n\tbaz: %f\n\n", *foo,*bar,*baz); printf("C routine changes values & should return \n\t12, \t34567890, \t67.890123\n\n"); *foo = a; *bar = b; *baz = c; printf( "C out:\n\tfoo: %d\n\tbar: %e\n\tbaz: %f\n\n", *foo,*bar,*baz); }
-- irv3.ex include std/dll.e include std/memory.e include std/convert.e as convert constant irv = open_dll( "./irv3.so" ), test1 = define_c_proc( irv, "test_float", {C_POINTER,C_POINTER,C_POINTER}), test2 = define_c_proc( irv, "test_float", {C_INT,C_DOUBLE,C_FLOAT}) atom ptr1 = allocate(4), ptr2 = allocate(8), ptr3 = allocate(8) poke(ptr1,convert:int_to_bytes(123)) poke(ptr2,convert:atom_to_float64(123456789)) poke(ptr3,convert:atom_to_float32(3.14159)) puts(1,"Eu sends: 123, 123456789, 3.14159 to C routine:\n") -- change the following to test2, and you get a machine exception: c_proc( test1, {ptr1,ptr2,ptr3}) puts(1,"Eu received:\n") puts(1,"\tINT:") ? peek(ptr1) puts(1,"\tDBL:") ? convert:float64_to_atom(peek({ptr2,8})) puts(1,"\tFLT:") ? convert:float32_to_atom(peek({ptr3,4}))
This is the best I can do without knowing any C. Test 1 successfully passes values both ways. Test 2 crashes every time, no matter what values are sent.
30. Re: Problems with C floats
- Posted by mattlewis (admin) Feb 01, 2010
- 2271 views
void test_float(int *foo, double *bar, float *baz){
constant irv = open_dll( "./irv3.so" ), test1 = define_c_proc( irv, "test_float", {C_POINTER,C_POINTER,C_POINTER}), test2 = define_c_proc( irv, "test_float", {C_INT,C_DOUBLE,C_FLOAT})
This is the best I can do without knowing any C. Test 1 successfully passes values both ways. Test 2 crashes every time, no matter what values are sent.
Yes, I would expect test 2 to crash, because you're not passing pointers when that's what is expected by the C code. Actually, by abusing the concept of a double, you can "make it work" like this:
atom buffer = allocate( 8 ) poke4( buffer, ptr2 & ptr3 ) c_proc( test2, { ptr1, float64_to_atom( peek( buffer & 8 ) ), 0} )
Of course, that's not useful, but hopefully demonstrates a little what's going on there.
Actually, I'd really rather see the bit of EuGTK that's failing. Can you point me to something to download and try out? Something that's failing, that is?
Matt
31. Re: Problems with C floats
- Posted by irv Feb 01, 2010
- 2298 views
It would be a lot more help and take less of your time if you would just write the correct way to send and receive values using test2. Don't change the dll, just the Eu calling code.
32. Re: Problems with C floats
- Posted by mattlewis (admin) Feb 01, 2010
- 2330 views
It would be a lot more help and take less of your time if you would just write the correct way to send and receive values using test2. Don't change the dll, just the Eu calling code.
Given the C function you're trying to communicate with using test2, test2 is incorrect. test1 is the correct way. Alternatively, could you post the GTK function prototype, and I'll tell you how I'd call it?
Matt
33. Re: Problems with C floats
- Posted by irv Feb 01, 2010
- 2297 views
void gtk_misc_get_alignment (GtkMisc *misc, gfloat *xalign, gfloat *yalign) { g_return_if_fail (GTK_IS_MISC (misc)); if (xalign) *xalign = misc->xalign; if (yalign) *yalign = misc->yalign; }
34. Re: Problems with C floats
- Posted by mattlewis (admin) Feb 01, 2010
- 2287 views
void gtk_misc_get_alignment (GtkMisc *misc, gfloat *xalign, gfloat *yalign) { g_return_if_fail (GTK_IS_MISC (misc)); if (xalign) *xalign = misc->xalign; if (yalign) *yalign = misc->yalign; }
OK, I think the GtkMisc can be assumed to be an opaque handle for our purposes, and that you only ever store the pointer, since it's a pointer to some widget. And I gfloat is just a typedef for a float, so I'd probably wrap it like something like this:
constant gtk_misc_get_alignment = define_c_proc( gtk, "GtkMisc", { C_POINTER, C_POINTER, C_POINTER } ) gtk_misc_buffer = allocate( 8 ), xalign = gtk_misc_buffer, yalign = xalign + 4 function get_alignment( atom misc ) c_proc( gtk_misc_get_alignment, { xalign, yalign } ) return { float32_to_atom( peek( xalign & 4 ), float32_to_atom( peek( yalign & 4 ) } end function
Matt
36. Re: Problems with C floats
- Posted by jacques_desch Feb 01, 2010
- 2256 views
void gtk_misc_get_alignment (GtkMisc *misc, gfloat *xalign, gfloat *yalign) { g_return_if_fail (GTK_IS_MISC (misc)); if (xalign) *xalign = misc->xalign; if (yalign) *yalign = misc->yalign; }
OK, I think the GtkMisc can be assumed to be an opaque handle for our purposes, and that you only ever store the pointer, since it's a pointer to some widget. And I gfloat is just a typedef for a float, so I'd probably wrap it like something like this:
constant gtk_misc_get_alignment = define_c_proc( gtk, "GtkMisc", { C_POINTER, C_POINTER, C_POINTER } ) gtk_misc_buffer = allocate( 8 ), xalign = gtk_misc_buffer, yalign = xalign + 4 function get_alignment( atom misc ) c_proc( gtk_misc_get_alignment, { xalign, yalign } ) return { float32_to_atom( peek( xalign & 4 ), float32_to_atom( peek( yalign & 4 ) } end function
Matt
Matt, you forgot the first argument, the pointer to GtkObject
Jacques
37. Re: Problems with C floats
- Posted by irv Feb 01, 2010
- 2259 views
OK, I think that solved the last problem remaining with GTK. I'll send the update to RDS tomorrow. Thanks for the assistance.
38. Re: Problems with C floats
- Posted by irv Feb 21, 2010
- 2155 views
Problem with the eubins builds still exists: With r3094 from the eubins, and the test from post #19 above, I get this:
double: 4.602295e-34 float: 7.500000e-01 int: 9 ptr: 0xdeadbeef f1: 2.300000 (40133333) f2: 0.500000 (3f000000) f3: 0.000000 (818efff) i: 8008135 2.799999952
Whereas, with the same version built from svn on my own laptop, I get this:
double: 2.500000e-01 float: 7.500000e-01 int: 9 ptr: 0xdeadbeef f1: 1.100000 (3f8ccccd) f2: 2.300000 (40133333) f3: 0.500000 (3f000000) i: 8008135 3.399999976
39. Re: Problems with C floats
- Posted by jimcbrown (admin) Mar 20, 2010
- 2091 views
Someone reported issues with EuGTK crashing with c_func()/c_proc(). I think the issue with eubins is still there.
Problem with the eubins builds still exists: With r3094 from the eubins, and the test from post #19 above, I get this:
double: 4.602295e-34 float: 7.500000e-01 int: 9 ptr: 0xdeadbeef f1: 2.300000 (40133333) f2: 0.500000 (3f000000) f3: 0.000000 (818efff) i: 8008135 2.799999952
Whereas, with the same version built from svn on my own laptop, I get this:
double: 2.500000e-01 float: 7.500000e-01 int: 9 ptr: 0xdeadbeef f1: 1.100000 (3f8ccccd) f2: 2.300000 (40133333) f3: 0.500000 (3f000000) i: 8008135 3.399999976
40. Re: Problems with C floats
- Posted by irv Mar 20, 2010
- 2017 views
Someone reported issues with EuGTK crashing with c_func()/c_proc(). I think the issue with eubins is still there.
This may be a different problem. The float problem only affects two of my demos, and they don't crash, just set positions incorrectly (floats are used to set those positions).
If there are other crashes, I'd like to see what error messages show up. It would help me fix things. Bear in mind, some of my demos use the latest GTK library, some of the demos which use recently implemented controls will not run on earlier GTK libraries.
41. Re: Problems with C floats
- Posted by irv Apr 02, 2010
- 1953 views
Since the problem with floats still exists on r3132 from the eubins for Linux, I have compiled a version which does not have the problem, and will try to keep it in sync with the svn.
Get the eubins here if you need it: http://etcwebspace.com/users/irvm