[cffi-devel] Re: [fetter-devel] various

[Kenny Tilton]

Rayiner Hashem wrote:

> 0. My OpenAL demo now works fine. The segmentation fault was because I
>
>     was passing a Lisp rational where a float was needed. My poor-man's
>     version of VZN generated wrappers which coerced all arguments before
>     calling the true C binding. A quick glance at the CFFI defcfun
>     expansion
>     suggests automatic conversion is being done there, as well. What am I
>     missing? Does the mechanism not attempt converting rationals to
>     floats? 
>
>
> Luis, could I do this with type translators? I'm guessing type-translators
> are already doing the Lisp float to :float conversion? I'd like to do 
> this for strings too.
> Does anybody have any thoughts on an interface for these sorts of 
> conversions?
> My idea of manually overriding declarations with more type information is
> far less automatic than what I think people would find convenient.
>  
>
>     1. I think VZN should export all symbols. It was a total pain doing
>     those manually. Besides, C does not do exported vs. imported, so
>     trying
>     not to export all symbols is an "extra". And the cost of that extra is
>     the aggravation of having to manually cobble together all the
>     symbols to
>     be exported.
>
>
> Okay. Maybe 'export' should become 'supress'?

Sure. Suppress, unexport, hide,.... give the eager beavers a way to keep 
down the symbol count. btw, does gccxml expose anything in/around that 
"extern "C"" stuff?

>
>
>     2. The latest VZN gens two warnings:
>
>     ; While compiling (METHOD CHECK-AND-MARK-ARTIFICIAL (T)) in
>     C:\0devtools\verrazano\frontend\simplifier.lisp:
>     Warning: Variable NODE-OR-EDGE is never used.
>
>
> Yeah, I noticed that last night. I'll fix it soon as I get back to my 
> computer.
>
>     ; While compiling (METHOD GENERATE-PACKAGE ((EQL :CFFI-BACKEND) T
>     T)) in
>     C:\0devtools\verrazano\cffi-backend\generator.lisp:
>     Warning: variable BK is used yet it was declared ignored
>
>
> If I don't (declare (ignore bk)) then SBCL complains that the variable bk
> is declared but never used. Is there an idiomatic NOP on a variable?

    (declare (ignorable bk))

Then you can use it or not and the compiler will remain silent in both 
cases.

>
>  
>
>     4. (VZN) al.h or someone has: #define AL_FALSE 0 and #define
>     AL_NO_ERROR
>     AL_FALSE. The second define does not make it into the bindings
>     because
>     it does not look like a numeric constant. I can add it to the
>     generated
>     bindings manually, but then I have to do it every time I regen the
>     bindings. Would it make sense to allow users to provide code in the
>     defbinding form which will get blindly copied into the output?: 
>
>
> That error specifically will get fixed when I implement macroexpansion 
> in the macro-reading code.
> I'm trying to read the standard and figure out the macroexpansion 
> algorithm they specify (ordering, termination, etc).
> As for adding something to the generated code, I thought about that, 
> but it seems to me to make more sense
> to have a secondary file openal-library-extra.lisp:
>
> (in-package "OPENAL-LIBRARY")
>
> (defconstant +al-no-error+ 0)
>
> Any particular reason putting that in the input file is better?

One-stop shopping. The binding definition then says it all, and I look 
one place to maintain or check things. Likewise on the output side, 
openal-library.lisp has it all. I am guessing this would be easy (famous 
last words) so the simplicity of one specification and one output seem 
to justify it. ie, I would not suggest this if it meant a week of work.

>
>
>     Btw, why not defconstant when translating #defines?
>
>
> Because:
>
> #define A 1
> do_something()
> #define A 2
> do_something_else()
>
> is legal C code. A naive translation using defconstant will create 
> compile time errors, while using defparameter, it'll compile and have 
> the correct semantics as well. I can write a pass to promote 
> non-duplicate #define's to defconstants, if that'll help with 
> error-checking user code.

Does defconstant help the compiler generate faster code? I do not know, 
I am not a compiler person.

>
>     Anyway, congrats to all on the first "live" set of bindings.
>
>
> Thanks for all the effort you've put in to finding and reporting bugs!

I just mentioned my success on c.l.l and invited more folks to join the 
fun. I know how much it helps to have other people testing and 
exercising the code so I just have to fix the bugs they find. It is 
truly painful to test something after working on it for a long time.

Next stop for me is OpenGL, after that Freeglut for my first callbacks. 
Then I can do ImageMagick (my test code runs under OpenGL).

But how will I do a C++ library such as FTGL, where I need to get a C++ 
class instantiated? Currently I use C glue.

-- 
Kenny

Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it."
    Elwood P. Dowd, "Harvey", 1950