Février 2012 - Gambit-list - mailman.iro.umontreal.ca

Re: [gambit-list] c interface: enums issue
by Álvaro Castro-Castilla 05 Fév '12

05 Fév '12

Hi Mikael, This is the solution that seems to work, wrapping it. (define cairo-create-surface (c-lambda (unsigned-char* int int int int) cairo-surface-t* " cairo_format_t format; switch (___arg2) { case -1: format = CAIRO_FORMAT_INVALID; break; case 0: format = CAIRO_FORMAT_ARGB32; break; case 1: format = CAIRO_FORMAT_RGB24; break; case 2: format = CAIRO_FORMAT_A8; break; case 3: format = CAIRO_FORMAT_A1; break; case 4: format = CAIRO_FORMAT_RGB16_565; break; default: format = CAIRO_FORMAT_RGB24; break; } ___result = cairo_image_surface_create_for_data(___arg1, format, ___arg3, ___arg4, ___arg5); ")) It is rather inconvenient, though. I think there should be a better way. Also, this crashes Gambit, just per se: (define CAIRO_FORMAT_RGB24 ((c-lambda () cairo-format-t "___result = CAIRO_FORMAT_RGB24;"))) Best regards, Álvaro 2012/2/5 Mikael <mikael.rcv(a)gmail.com> > Hi, do something like this: In cairo-image-surface-create-for-data, do > printf("Wnt %i got %i\n",CAIRO_FORMAT_RGB24,___arg2); and rerun your > previous tests, do they make more sense now? In case the both values > printed are the same, your sigsegvcomes from elsewhere. Brgds > > 2012/2/5 Álvaro Castro-Castilla <alvaro.castro.castilla(a)gmail.com> > >> hi Mikael, >> >> Thanks for your response. >> Unfortunately, your solution also breaks. Actually, it is doing more or >> less the same I did. What you say should be used like this, right?: >> (image-surface (cairo-image-surface-create-for-data >> (SDL::surface-pixels sdl-surface) >> (CAIRO_FORMAT_RGB24) >> maxx >> maxy >> (SDL::screen-pitch sdl-surface))) >> > > In case you have (define CAIRO_FORMAT_RGB24 ((c-lambda () cairo-format-t > "___result = CAIRO_FORMAT_RGB24;")) already, you should type only > CAIRO_FORMAT_RGB24 here not (CAIRO_FORMAT_RGB24). > > >> What I was proposing just decides the output at runtime (the argument is >> an int, but passed to a function that converts it into a enum -should >> convert-): >> (image-surface (cairo-image-surface-create-for-data >> (SDL::surface-pixels sdl-surface) >> (cairo-format CAIRO_FORMAT_RGB24) >> maxx >> maxy >> (SDL::screen-pitch sdl-surface))) >> > > In the Scheme world I think there should only be the need for one > representation/form of the C constant. > > But the result is the same: segfault. Using your first solution >> (returning an int) causes the same problem I got at the >> beginning: (cairo#cairo-image-surface-create-for-data '#<|unsigned char*| >> #16 0x7f584104c000> 0 500 500 2000) >> > > To make this one spin, just declare the second argument of this procedure > as an int also. Does it work? > > >> >> Thanks for your help. >> >> Best regards >> >> >> >> On Sun, Feb 5, 2012 at 6:35 PM, Mikael <mikael.rcv(a)gmail.com> wrote: >> >>> If those are int consts from the C header files of the lib, then import >>> them as is fromt here (define CAIRO_FORMAT_ARGB32 ((c-lambda () int >>> "___result = CAIRO_FORMAT_ARGB32;")) etc. , and any arguments that need >>> them declare as int too. >>> >>> If they're C enums, maybe you want another datatype declaration of them >>> than int - though I suppose int ought to be generally viable for that too. >>> >>> The exception in your example below is not so strange, as the second arg >>> is an int while the procedure is declared as cairo-format-t. For it to >>> work, I suppose define CAIRO_FORMAT_RGB24 to ((c-lambda () cairo-format-t >>> "___result = CAIRO_FORMAT_RGB24;")) . Works? >>> >>> 2012/2/5 Álvaro Castro-Castilla <alvaro.castro.castilla(a)gmail.com> >>> >>>> Hi, >>>> >>>> I'm using my ffi cairo bindings, that worked fine in the past. However >>>> now that I'm using Gambit compiled with C++ support it stopped working. >>>> >>>> >>>> >>>> >>>> I got this error: >>>> >>>> *** ERROR IN main-sdl#main, "main-sdl.scm"@19.24 -- (Argument 2) Can't >>>> convert to C type >>>> (cairo#cairo-image-surface-create-for-data '#<|unsigned char*| #16 >>>> 0x7f33ba191000> 1 500 500 2000) >>>> >>>> On the ffi side, things are declared like this: >>>> >>>> (c-define-type cairo-format-t "cairo_format_t") >>>> (define CAIRO_FORMAT_ARGB32 0) >>>> (define CAIRO_FORMAT_RGB24 1) >>>> (define CAIRO_FORMAT_A8 2) >>>> (define CAIRO_FORMAT_A1 3) >>>> (define CAIRO_FORMAT_RGB16_565 4) >>>> (define cairo-image-surface-create-for-data (c-lambda (unsigned-char* >>>> cairo-format-t int int int) cairo-surface-t* >>>> "cairo_image_surface_create_for_data")) >>>> >>>> And used like this: >>>> >>>> (cairo-image-surface-create-for-data >>>> (SDL::surface-pixels sdl-surface) >>>> CAIRO_FORMAT_RGB24 >>>> maxx >>>> maxy >>>> (SDL::screen-pitch sdl-surface)) >>>> >>>> I've tried with this idea: >>>> >>>> (define cairo-format >>>> (c-lambda (int) cairo-format-t >>>> " >>>> switch (___arg1) { >>>> case 0: ___result = CAIRO_FORMAT_ARGB32; break; >>>> case 1: ___result = CAIRO_FORMAT_RGB24; break; // and so >>>> on... >>>> } >>>> ")) >>>> >>>> And then calling on the Scheme side "(cairo-format CAIRO_FORMAT_RGB24)" >>>> instead of just using the int directly, but it segfaults. >>>> >>>> >>>> How should I really handle enums properly? >>>> >>>> >>>> >>>> Best regards, >>>> >>>> >>>> _______________________________________________ >>>> Gambit-list mailing list >>>> Gambit-list(a)iro.umontreal.ca >>>> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >>>> >>>> >>> >> >

2 1

c interface: enums issue
by Álvaro Castro-Castilla 05 Fév '12

05 Fév '12

Hi, I'm using my ffi cairo bindings, that worked fine in the past. However now that I'm using Gambit compiled with C++ support it stopped working. I got this error: *** ERROR IN main-sdl#main, "main-sdl.scm"@19.24 -- (Argument 2) Can't convert to C type (cairo#cairo-image-surface-create-for-data '#<|unsigned char*| #16 0x7f33ba191000> 1 500 500 2000) On the ffi side, things are declared like this: (c-define-type cairo-format-t "cairo_format_t") (define CAIRO_FORMAT_ARGB32 0) (define CAIRO_FORMAT_RGB24 1) (define CAIRO_FORMAT_A8 2) (define CAIRO_FORMAT_A1 3) (define CAIRO_FORMAT_RGB16_565 4) (define cairo-image-surface-create-for-data (c-lambda (unsigned-char* cairo-format-t int int int) cairo-surface-t* "cairo_image_surface_create_for_data")) And used like this: (cairo-image-surface-create-for-data (SDL::surface-pixels sdl-surface) CAIRO_FORMAT_RGB24 maxx maxy (SDL::screen-pitch sdl-surface)) I've tried with this idea: (define cairo-format (c-lambda (int) cairo-format-t " switch (___arg1) { case 0: ___result = CAIRO_FORMAT_ARGB32; break; case 1: ___result = CAIRO_FORMAT_RGB24; break; // and so on... } ")) And then calling on the Scheme side "(cairo-format CAIRO_FORMAT_RGB24)" instead of just using the int directly, but it segfaults. How should I really handle enums properly? Best regards,

2 2

Make precise calculations query
by Mikael 05 Fév '12

05 Fév '12

Dear Marc or Brad, I'd be curious to know if there is any way to ensure that calculations in Gambit become completely exact? What I'm looking for is that as flonum operations by nature are inexact (+ 0.1 0.2 would be a good example), would there be a way to use bignum-only operations, or have some kind of configuration that uses fixnum when applicable and otherwise bignum only. Is there anything like this - I know fixnum and flonum ops can be accessed under fixnum+ etc., but what about the bignums, (bignum+ 99999999999999999999 2)? Afaik the bignum library is completely exact for + and -, and has a precision of at least 10^-17 for the rest of the operations (* / modulo sqrt expt etc), is this the way? Kind regards, Mikael

2 3

static lib question
by REPLeffect 03 Fév '12

03 Fév '12

Let's say I have the following set of files ... f1a.scm and f1b.c f2a.scm and f2b.c f3.scm File f1a.scm contains scheme procedures that call C functions in f1b.c. File f2a.scm contains scheme procedures that call C funcitons in f2b.c. I would like to build a static library f1.a from f1a.scm and f1b.c, and likewise I wish to build a static library f2.a from f2a.scm and f2b.c. Finally, assume f3.scm will call scheme procedures from both the f1.a and f2.a static libraries. What are the appropriate commands for: 1) building the f1.a and f2.a static libraries 2) compiling and linking f3.scm with *both* of those static libraries at the same time. (I'm looking for an example using gcc on a Linux platform.)

3 7

compiling Gambit 4.6.3 under MinGW/MSys
by REPLeffect 01 Fév '12

01 Fév '12

I just thought I'd share this in case it helps someone else. To compile Gambit 4.6.3 in the MinGW/MSys shell, I had to add the following flags to the gcc commands for compiling C files to object files: -fpermissive -fno-keep-inline-dllexport Recent versions of MinGW use gcc version 4.6.1, which I suspect has stricter default requirements on the C code than prior versions of gcc, and I believe that's why I had to add -fpermissive. The -fno-keep-inline-dllexport flag was added because I was getting an out of memory error compiling at least one C file. I also added -Wno-write-strings because I was tired of warning messages. It's a bit of a hack (and I'm sure there is a more correct place to put this), but I modified the configure script to do this by adding it in the FLAGS_OBJ line here: case "$target_os" in mingw*) # add Windows libraries needed by MinGW LIBS="$LIBS -lws2_32" FLAGS_OBJ="$FLAGS_OBJ -D_WINDOWS -Wno-write-strings -fpermissive -fno-keep-inline-dllexport" If Marc (or others) want more detail, I'd be happy to oblige. I can extract the 4.6.3 tar file somewhere else and try to build it, and not the exact error messages, etc.

2 6

tell ___BOOL to be bool?
by REPLeffect 01 Fév '12

01 Fév '12

Would it be possible to get a configure option that will allow ___BOOL to be defined as bool instead of int? I understand at least some of the reasons behind defining it as int for compatibility with some compilers. It would just be nice to be able to chose to have it be bool instead. Perhaps there are ramifications which I have not considered. But it makes it nice for interfacing with my C++ code to have ___BOOL actually be bool (unless, of course, unconsidered ramifications would have detrimental effects on me -- in which case, please feel free to enlighten me) :-D

3 4