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'?
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?
- (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?
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.
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!
Sincerely, Rayiner Hashem
--
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
fetter-devel mailing list fetter-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel