Kenny Tilton ktilton@nyc.rr.com writes:

I guess ACL is a little fussy with that message. Anyway, may as well clean that up on our end.

Sorry for taking a bit longer to reply, went to the American embassy yesterday... man, are you people crazy.. "you don't look like this foto in your ID", "what's your father's last name?", "and his middle name?"... Oh well, I probably should have shaved.

Anyway, fixed this and pushed a patch with 2 new tests included. A test for a void function too, because I recall one of the lisps returns (values) instead of NIL. Hmm, what do you people prefer for :void functions? (values) or NIL?

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.