[fetter-devel] various

[Rayiner Hashem]

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?

> 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?

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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/fetter-devel/attachments/20050907/b7fd8533/attachment.html>