<div><span class="gmail_quote"></span>0. My OpenAL demo now works fine. The segmentation fault was because I<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">was passing a Lisp rational where a float was needed. My poor-man's<br>version of VZN generated wrappers which coerced all arguments before
<br>calling the true C binding. A quick glance at the CFFI defcfun expansion<br>suggests automatic conversion is being done there, as well. What am I<br>missing? Does the mechanism not attempt converting rationals to floats?
</blockquote><div><br>
Luis, could I do this with type translators? I'm guessing type-translators<br>
are already doing the Lisp float to :float conversion? I'd like to do this for strings too.<br>
Does anybody have any thoughts on an interface for these sorts of conversions?<br>
My idea of manually overriding declarations with more type information is<br>
far less automatic than what I think people would find convenient.<br>
 <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">1. I think VZN should export all symbols. It was a total pain doing<br>those manually. Besides, C does not do exported vs. imported, so trying
<br>not to export all symbols is an "extra". And the cost of that extra is<br>the aggravation of having to manually cobble together all the symbols to<br>be exported.</blockquote><div><br>
Okay. Maybe 'export' should become 'supress'? <br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2. The latest VZN gens two warnings:<br><br>; While compiling (METHOD CHECK-AND-MARK-ARTIFICIAL (T)) in
<br>C:\0devtools\verrazano\frontend\simplifier.lisp:<br>Warning: Variable NODE-OR-EDGE is never used.</blockquote><div><br>
Yeah, I noticed that last night. I'll fix it soon as I get back to my computer. <br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">; While compiling (METHOD GENERATE-PACKAGE ((EQL :CFFI-BACKEND) T T)) in<br>C:\0devtools\verrazano\cffi-backend\generator.lisp:
<br>Warning: variable BK is used yet it was declared ignored</blockquote><div><br>
If I don't (declare (ignore bk)) then SBCL complains that the variable bk<br>
is declared but never used. Is there an idiomatic NOP on a variable?<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">4. (VZN) al.h or someone has: #define AL_FALSE 0 and #define AL_NO_ERROR<br>AL_FALSE. The second define does not make it into the bindings because
<br>it does not look like a numeric constant. I can add it to the generated<br>bindings manually, but then I have to do it every time I regen the<br>bindings. Would it make sense to allow users to provide code in the<br>defbinding form which will get blindly copied into the output?:
</blockquote><div><br>
That error specifically will get fixed when I implement macroexpansion in the macro-reading code. <br>
I'm trying to read the standard and figure out the macroexpansion algorithm they specify (ordering, termination, etc).<br>
As for adding something to the generated code, I thought about that, but it seems to me to make more sense<br>
to have a secondary file openal-library-extra.lisp:<br>
<br>
(in-package "OPENAL-LIBRARY")<br>
<br>
(defconstant +al-no-error+ 0)<br>
<br>
Any particular reason putting that in the input file is better?<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Btw, why not defconstant when translating #defines?<br>
</blockquote><div><br>
Because:<br>
<br>
#define A 1<br>
do_something()<br>
#define A 2<br>
do_something_else() <br>
<br>
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.</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Anyway, congrats to all on the first "live" set of bindings.</blockquote><div><br>

Thanks for all the effort you've put in to finding and reporting bugs!<br>
<br>
Sincerely,<br>
    Rayiner Hashem<br>
 </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">--<br>Kenny<br><br>Why Lisp? <a href="http://lisp.tech.coop/RtL%20Highlight%20Film">
http://lisp.tech.coop/RtL%20Highlight%20Film</a><br><br>"I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it."<br>    Elwood P. Dowd, "Harvey", 1950<br><br>
<br><br>_______________________________________________<br>fetter-devel mailing list<br><a href="mailto:fetter-devel@common-lisp.net">fetter-devel@common-lisp.net</a><br><a href="http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel">
http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel</a><br></blockquote></div><br>