From rayiner at gmail.com Fri Sep 2 09:58:13 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Fri, 2 Sep 2005 05:58:13 -0400 Subject: [fetter-devel] C++ Support Message-ID: I finally checked the code for C++ support into Verrazano's CVS. It's not completely-complete (it's missing two features as described in the report I just sent), but its nifty nonetheless. The FLTK demo kinda sucks right now though. It will be improved as soon as I get callback support working properly in SBCL. I'll also post some stuff on the webpage about how to get the demos working. Sincerely, Rayiner Hashem -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayiner at gmail.com Fri Sep 2 09:51:02 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Fri, 2 Sep 2005 05:51:02 -0400 Subject: [fetter-devel] Summer of Code Report Message-ID: I've attached a report detailing Verrazano's status with relation to its Summer of Code goals. Sincerely, Rayiner Hashem -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: soc-endgame.pdf Type: application/pdf Size: 36070 bytes Desc: not available URL: From ungil at mac.com Fri Sep 2 10:05:44 2005 From: ungil at mac.com (Carlos Ungil) Date: Fri, 2 Sep 2005 12:05:44 +0200 Subject: [fetter-devel] problem with arrays? Message-ID: Hello, I don't know if you're aware of this problem, I'm reporting it just in case. From files -----[array.binding]----- (defbinding "array-library" (nicknames "array") (include "array.h")) ---------- and -----[array.h]----- typedef char char_array[10]; ---------- (verrazano:create-binding "array.binding" "array-library.lisp" :cffi-backend t) produces the following output: -----[array-library.lisp]----- (defpackage "ARRAY-LIBRARY" (:use #:COMMON-LISP #:CFFI) (:nicknames "ARRAY") (:export)) (asdf:operate 'asdf:load-op 'verrazano-support) (cffi:define-foreign-type char-array () 'anonymous12) (progn) ---------- Anonymous12 is not defined anywhere; is this a bug or am I missing something? Cheers, Carlos From ungil at mac.com Fri Sep 2 11:05:23 2005 From: ungil at mac.com (Carlos Ungil) Date: Fri, 2 Sep 2005 13:05:23 +0200 Subject: [fetter-devel] problem with arrays? In-Reply-To: References: Message-ID: <754ec93f5c677d375174afdefd0bac6a@mac.com> Hello, thanks for your reply. I tried to simplify the report, but I did simplify it too much :-) In fact the error appears when I use the array in a structure: -----[array.h]----- typedef char char_array[10]; typedef struct two_char_arrays { char_array first; char_array second; } two_char_arrays; ---------- (cffi:define-foreign-type char-array () 'anonymous4713) > CHAR-ARRAY (cffi:defcstruct two-char-arrays-1 (first char-array) (second char-array)) > Unknown CFFI type: ANONYMOUS4713. By the way, I'm ignoring the (asdf:operate 'asdf:load-op 'verrazano-support) line. I cannot find other references to "verrazano-support" anywhere. What's it supossed to do? Regards, Carlos On Sep 2, 2005, at 12:39 PM, Rayiner Hashem wrote: > Not a bug, just an artifact of the fact that C-FFI doesn't have an > array type, but Verrazano does. The C-FFI backend lowers arrays to > bare pointers, so the code should still work. > > On the other hand, your comment made me realize quite a significant > oversight with regards to arrays as arguments to virtual functions or > members of arrays. I'll fix those shortly. Thanks! > > Sincerely, > ??? Rayiner Hashem > > On 9/2/05, Carlos Ungil wrote: >> >> I don't know if you're aware of this problem, I'm reporting it just in >> case. >> >> From files >> >> -----[array.binding]----- >> (defbinding "array-library" >> ???? (nicknames "array") >> ?? (include "array.h")) >> ---------- >> >> and >> >> -----[array.h]----- >> typedef char char_array[10]; >> ---------- >> >> (verrazano:create-binding "array.binding" "array-library.lisp" >> :cffi-backend t) >> produces the following output: >> >> -----[array-library.lisp]----- >> (defpackage "ARRAY-LIBRARY" (:use #:COMMON-LISP #:CFFI) (:nicknames >> "ARRAY") >> ??(:export)) >> >> (asdf:operate 'asdf:load-op 'verrazano-support) >> (cffi:define-foreign-type char-array () 'anonymous12) >> (progn) >> ---------- >> >> Anonymous12 is not defined anywhere; is this a bug or am I missing >> something? >> >> Cheers, >> >> Carlos >> >> _______________________________________________ >> fetter-devel mailing list >> fetter-devel at common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel From rayiner at gmail.com Fri Sep 2 11:26:06 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Fri, 2 Sep 2005 07:26:06 -0400 Subject: [fetter-devel] problem with arrays? In-Reply-To: <754ec93f5c677d375174afdefd0bac6a@mac.com> References: <754ec93f5c677d375174afdefd0bac6a@mac.com> Message-ID: Now that's a bug. Let me see what I can do about it :) As for verrazano-support, it's a small library that bindings use to access to C++ virtual table lookups and virtual function calls. You can check it out as the verrazano-support module in CVS. Just stick it in /usr/lib/sbcl where asdf can find it. On 9/2/05, Carlos Ungil wrote: > > Hello, > > thanks for your reply. > > I tried to simplify the report, but I did simplify it too much :-) > > In fact the error appears when I use the array in a structure: > > -----[array.h]----- > typedef char char_array[10]; > > typedef struct two_char_arrays > { > char_array first; > char_array second; > } two_char_arrays; > ---------- > > (cffi:define-foreign-type char-array () 'anonymous4713) > > CHAR-ARRAY > (cffi:defcstruct two-char-arrays-1 (first char-array) (second > char-array)) > > Unknown CFFI type: ANONYMOUS4713. > > By the way, I'm ignoring the (asdf:operate 'asdf:load-op > 'verrazano-support) line. > I cannot find other references to "verrazano-support" anywhere. What's > it supossed to do? > > Regards, > > Carlos > > On Sep 2, 2005, at 12:39 PM, Rayiner Hashem wrote: > > > Not a bug, just an artifact of the fact that C-FFI doesn't have an > > array type, but Verrazano does. The C-FFI backend lowers arrays to > > bare pointers, so the code should still work. > > > > On the other hand, your comment made me realize quite a significant > > oversight with regards to arrays as arguments to virtual functions or > > members of arrays. I'll fix those shortly. Thanks! > > > > Sincerely, > > Rayiner Hashem > > > > On 9/2/05, Carlos Ungil wrote: > >> > >> I don't know if you're aware of this problem, I'm reporting it just in > >> case. > >> > >> From files > >> > >> -----[array.binding]----- > >> (defbinding "array-library" > >> (nicknames "array") > >> (include "array.h")) > >> ---------- > >> > >> and > >> > >> -----[array.h]----- > >> typedef char char_array[10]; > >> ---------- > >> > >> (verrazano:create-binding "array.binding" "array-library.lisp" > >> :cffi-backend t) > >> produces the following output: > >> > >> -----[array-library.lisp]----- > >> (defpackage "ARRAY-LIBRARY" (:use #:COMMON-LISP #:CFFI) (:nicknames > >> "ARRAY") > >> (:export)) > >> > >> (asdf:operate 'asdf:load-op 'verrazano-support) > >> (cffi:define-foreign-type char-array () 'anonymous12) > >> (progn) > >> ---------- > >> > >> Anonymous12 is not defined anywhere; is this a bug or am I missing > >> something? > >> > >> Cheers, > >> > >> Carlos > >> > >> _______________________________________________ > >> 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: From rayiner at gmail.com Mon Sep 5 09:13:05 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Mon, 5 Sep 2005 05:13:05 -0400 Subject: [fetter-devel] Recent Updates Message-ID: There have been two recent updates to Verrazano: 1) Portability fixes to get it running on Windows. 2) Preprocessor support, for getting #define constants out of header files. The former should make life easier for anybody trying to use Verrazano on Windows (I myself have tried it with Allegro 7 on Win2k). The latter should make using generated bindings quite a bit easier for older-style C libraries that put constants in #define's instead of as constant integers or inside enumerations. I'm also working on getting out Windows binaries for GCC-XML, as the current 0.60 binaries on the GCC-XML page are missing some rather handy features. Sincerely, Rayiner Hashem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ktilton at nyc.rr.com Mon Sep 5 16:36:17 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 05 Sep 2005 12:36:17 -0400 Subject: [fetter-devel] Recent Updates In-Reply-To: References: Message-ID: <431C7401.2070505@nyc.rr.com> Rayiner Hashem wrote: > There have been two recent updates to Verrazano: > > 1) Portability fixes to get it running on Windows. > 2) Preprocessor support, for getting #define constants out of header > files. > > The former should make life easier for anybody trying to use Verrazano > on Windows (I myself have tried it with Allegro 7 on Win2k). > The latter should make using generated bindings quite a bit easier for > older-style C libraries that put constants in #define's instead > of as constant integers or inside enumerations. I'm also working on > getting out Windows binaries for GCC-XML, as the current 0.60 > binaries on the GCC-XML page are missing some rather handy features. Will I need the new gccxml binary to get the #defines? I ran the latest from CVS (ran fine out of the box on ACL7/WinXP) and got the .cpp and .xml files but no .mac, died on that being missing. kt From ktilton at nyc.rr.com Mon Sep 5 17:21:55 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 05 Sep 2005 13:21:55 -0400 Subject: [fetter-devel] Recent Updates In-Reply-To: <431C7401.2070505@nyc.rr.com> References: <431C7401.2070505@nyc.rr.com> Message-ID: <431C7EB3.7040502@nyc.rr.com> Kenny Tilton wrote: > > > Rayiner Hashem wrote: > >> There have been two recent updates to Verrazano: >> >> 1) Portability fixes to get it running on Windows. >> 2) Preprocessor support, for getting #define constants out of header >> files. >> >> The former should make life easier for anybody trying to use >> Verrazano on Windows (I myself have tried it with Allegro 7 on Win2k). >> The latter should make using generated bindings quite a bit easier >> for older-style C libraries that put constants in #define's instead >> of as constant integers or inside enumerations. I'm also working on >> getting out Windows binaries for GCC-XML, as the current 0.60 >> binaries on the GCC-XML page are missing some rather handy features. > > > Will I need the new gccxml binary to get the #defines? I ran the > latest from CVS (ran fine out of the box on ACL7/WinXP) and got the > .cpp and .xml files but no .mac, died on that being missing. OK, hang on. In the first test I ran with my own openal.binding, which looks like this: (defbinding "openal-library" (nicknames "al") (flags "") (include "AL/al.h" "AL/alut.h") (export "alenable" "aldisable") (override "")) You may recall I had to elim the flags to get things running. With that binding I got the xml output and died on no mac output. When I switched to the testsuite openal.binding I get the error "gccxml does not support bcc32" or something to that effect. That sounds like I do need the new gccxml. Yes? kt From ktilton at nyc.rr.com Tue Sep 6 17:22:32 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 06 Sep 2005 13:22:32 -0400 Subject: [fetter-devel] various Message-ID: <431DD058.7020008@nyc.rr.com> After a little wrestling with Verrazano I am now trying to port my existing OpenAL demo to use the CFFI bindings generated by VZN. I got a couple of warnings from ACL: Warning: :call-direct ignored; no argument types specified. ; While compiling (:TOP-LEVEL-FORM "openal-lib2.lisp" 10554) in C:\0dev\cl-openal\openal-lib2.lisp: Why the Hell are they not reporting on which defun? I will go digging to see if I can find which, but it may not matter. Anyway, I took a look at the expansion of: (cffi:defcfun ("alutUnloadWAV" alutunloadwav) alvoid (anonymous1 :int) (anonymous2 :pointer) (anonymous3 :unsigned-int) (anonymous4 :unsigned-int)) namely.... (PROGN (FF:DEF-FOREIGN-CALL (|%cffi-foreign-function/ALUTUNLOADWAV| "alutUnloadWAV") ((#:G1004 :INT INTEGER) (#:G1005 (* :VOID) INTEGER) (#:G1006 :UNSIGNED-INT INTEGER) (#:G1007 :UNSIGNED-INT INTEGER)) :RETURNING (:VOID NULL) :CALL-DIRECT T :ARG-CHECKING NIL :STRINGS-CONVERT NIL) (DEFUN ALUTUNLOADWAV (ANONYMOUS1 ANONYMOUS2 ANONYMOUS3 ANONYMOUS4) (CFFI::TRANSLATE-OBJECTS (#:G1000 #:G1001 #:G1002 #:G1003) (ANONYMOUS1 ANONYMOUS2 ANONYMOUS3 ANONYMOUS4) (:INT :POINTER :UNSIGNED-INT :UNSIGNED-INT) ALVOID (|%cffi-foreign-function/ALUTUNLOADWAV| #:G1000 #:G1001 #:G1002 #:G1003)))) I think there is a problem here in that the raw entry |%cffi-foreign-function/ALUTUNLOADWAV| is not really an inviting way to code raw calls to the API. Maybe I am wrong on this--perhaps the idea is that one would relatively rarely want to convert values explicitly and then call the raw function, so it is OK to make users write something like: (defun alutunloadwav-raw (a1 a2 a3 a4) (|%cffi-foreign-function/ALUTUNLOADWAV a1 a2 a3 a4) But is that raw name reliable between CFFI releases? What I did with my FFI utils was reserve the C name for raw functions and use the Lispified name for functions which autoconverted parameters and return values. I also allowed for pre- and post-processing. -- 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 From ktilton at nyc.rr.com Wed Sep 7 03:49:55 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 06 Sep 2005 23:49:55 -0400 Subject: [fetter-devel] OpenAL or Bust Message-ID: <431E6363.3020904@nyc.rr.com> My OpenAL code also uses stuff from alc.h, so I modified my binding def: (defbinding "openal-library" (nicknames "al") (flags "") (include "AL/al.h" "AL/alc.h" "AL/alut.h") (export "alenable" "aldisable") (override "")) This yielded amongst other good stuff: (cffi:defcstruct alcdevice-struct) ...on which we get divide-by-zero in CFFI because notice-foreign-struct-definition initializes max-align to zero and that never gets bumped up (because there are no slots and that is when it gets adjusted) and then gets used in a rem to determine padding. Checking alc.h and the rest of the al includes, I do not see any actual definition for alcdevice-struct. I guess the type is needed to define the functions which get passed a pointer to a device struct, but the actual make-up of the struct is pure internal. I will let you all fight it out, but it looks as if CFFI needs to be more tolerant? I will try initializing the max-align to 2 and see how much further I get. -- 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 From rayiner at gmail.com Wed Sep 7 05:54:40 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Wed, 7 Sep 2005 01:54:40 -0400 Subject: [fetter-devel] Verrazano Anonymous CVS Message-ID: I'd just like to point out that Verrazano's anonymous CVS seems to be working now. For awhile, a few people had problems getting it to work. If anybody is still having such problems, please contact me. Sincerely, Rayiner Hashem From ktilton at nyc.rr.com Wed Sep 7 15:55:12 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 07 Sep 2005 11:55:12 -0400 Subject: [fetter-devel] various Message-ID: <431F0D60.70909@nyc.rr.com> 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? 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. 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. ; 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 3. (CFFI) As advertised in earlier epistles, these are coming from somewhere: ; While compiling (:TOP-LEVEL-FORM "openal-library.lisp" 2333) in C:\0dev\cl-openal\openal-library.lisp: Warning: :call-direct ignored; no argument types specified. ; While compiling (:TOP-LEVEL-FORM "openal-library.lisp" 2333) in C:\0dev\cl-openal\openal-library.lisp: Warning: :call-direct ignored; no argument types specified. ; While compiling (:TOP-LEVEL-FORM "openal-library.lisp" 2333) in C:\0dev\cl-openal\openal-library.lisp: Warning: :call-direct ignored; no argument types specified. This is AllegroCL. Looks like CFFI needs to avoid inserting the :call-direct in some cases. Let me know if you need the actual code and I will try to figure out which are squawking. 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?: (defbinding "openal-library" (nicknames "al") (flags "") (include "AL/al.h" "AL/alc.h" "AL/alut.h") (export "alenable" "aldisable") (export....) (override "") (append (defparameter +al-no-error+ 0))) Btw, why not defconstant when translating #defines? Anyway, congrats to all on the first "live" set of bindings. -- 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 From ktilton at nyc.rr.com Wed Sep 7 16:05:40 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 07 Sep 2005 12:05:40 -0400 Subject: [fetter-devel] various In-Reply-To: <431F0D60.70909@nyc.rr.com> References: <431F0D60.70909@nyc.rr.com> Message-ID: <431F0FD4.2050400@nyc.rr.com> Kenny Tilton wrote: > 3. (CFFI) As advertised in earlier epistles, these are coming from > somewhere: > > ; While compiling (:TOP-LEVEL-FORM "openal-library.lisp" 2333) in > C:\0dev\cl-openal\openal-library.lisp: > Warning: :call-direct ignored; no argument types specified. (cffi:defcfun ("alutExit" alutexit) alvoid) expands to: (PROGN (FF:DEF-FOREIGN-CALL (|%cffi-foreign-function/ALUTEXIT| "alutExit") NIL :RETURNING (:VOID NULL) :CALL-DIRECT T :ARG-CHECKING NIL :STRINGS-CONVERT NIL) (DEFUN ALUTEXIT () (CFFI::TRANSLATE-OBJECTS NIL NIL NIL ALVOID (|%cffi-foreign-function/ALUTEXIT|)))) I guess ACL is a little fussy with that message. Anyway, may as well clean that up on our end. -- 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 From rayiner at gmail.com Wed Sep 7 18:28:58 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Wed, 7 Sep 2005 14:28:58 -0400 Subject: [fetter-devel] various In-Reply-To: <431F0D60.70909@nyc.rr.com> References: <431F0D60.70909@nyc.rr.com> Message-ID: 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: From ktilton at nyc.rr.com Wed Sep 7 19:33:58 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 07 Sep 2005 15:33:58 -0400 Subject: [fetter-devel] various In-Reply-To: References: <431F0D60.70909@nyc.rr.com> Message-ID: <431F40A6.1030800@nyc.rr.com> 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 From ktilton at nyc.rr.com Thu Sep 8 04:34:52 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 08 Sep 2005 00:34:52 -0400 Subject: [fetter-devel] Big huge OpenGL-library on win32 Message-ID: <431FBF6C.5030805@nyc.rr.com> The opengl headers gl.h and glu.h require windows.h to get a clean compile. Of course windows.h includes everything, so (congratulations!) VZN produces a one megabyte source file opengl-library.lisp. ACL is trying to compile that as I write this. I tried hacking at GL.h and glu.h to get them to compile without windows.h. This got gl.h to compile: #define APIENTRY #define WINGDIAPI ...but that did not work for glu.h (and I cannot quite make out why that is not compiling). I went looking for headers not so win-centric, but all I could find was a gl.h which gave me the idea for those #defines. Any thoughts? It occurred to me after seeing the same result on winsock.h (which also requires windows.h) that it would be nice if gccxml (or now Verrazano) could accept two kinds of headers, one kind just to get a clean compile, the other to be turned into bindings. I believe gccxml output indicates in which source file a symbol was defined... perhaps VZN could use that info to solve this problem? -- 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 From ktilton at nyc.rr.com Thu Sep 8 06:54:28 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 08 Sep 2005 02:54:28 -0400 Subject: [fetter-devel] Big huge OpenGL-library on win32 In-Reply-To: References: <431FBF6C.5030805@nyc.rr.com> Message-ID: <431FE024.1050800@nyc.rr.com> Rayiner Hashem wrote: > Ouch. Well, I suppose it's good news that it parsed windows.h without > crashing :-/ > You're right, the correct solution is to use GCC-XML's source file > definition tag to > supress certain definitions. The tricky part is defining bindings that > refer to stuff in those > headers without pulling in all of those headers. Come to think of it, > it shouldn't be too hard. > VNZ first generates a queue of definitions, then goes through the > queue and outputs each one. > To create this queue, it walks the tree starting at the root. Instead, > I could attach to each > node a tag saying in what file it was defined, then collect all the > tags referring to the headers > in which we're interested, and use those as the roots of the walk I'll be honest, i have not bothered to understand your algorithm or data structures. You seemed to have things in control so I guessed they were fine. That said, fer sher, start only from symbols from headers of interest. Like a mark and sweep GC. Anything you do not reach does not need a binding. > . Incidentally, how long did > it take to generate the bindings? I do not know, I fell asleep in my chair waiting. I am not kidding. :) So we definitely need to do something. > If it was too long to be comfortable (with such a huge IR), it > might be worth it to prune definitions at an earlier stage, before the > simplification passes. > > I'm just finishing up support for exporting all definitions. I'll do > this modification sometime tomorrow. Great. I was not looking forward to coding all the needed exports for OpenGL. I could not believe how many I need from a small API like OpenAL, never mind my simple demo. -- 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 From ktilton at nyc.rr.com Thu Sep 8 16:54:32 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 08 Sep 2005 12:54:32 -0400 Subject: [fetter-devel] hmmm.... Message-ID: <43206CC8.1090502@nyc.rr.com> I think I know what happened when I fell asleep. I think the system crashed midway through writing out the lisp bindings. I just ran again to get a timing. First time crashed windows, but before writing out any bindings. Second time shows I was not dreaming: 1.3mb of bindings vs 0.36mb I sent you. About to try compiling that, but I wanted to rush you this correction before waiting any longer. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Thu Sep 8 16:59:50 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 08 Sep 2005 12:59:50 -0400 Subject: [fetter-devel] hmmm.... In-Reply-To: <43206CC8.1090502@nyc.rr.com> References: <43206CC8.1090502@nyc.rr.com> Message-ID: <43206E06.8010004@nyc.rr.com> No luck. Right at the top of the file: (defpackage "OPENGL-LIBRARY" (:use #:COMMON-LISP #:CFFI) (:nicknames "GL") (:export "GLSCISSOR" "GLVERTEX3F")) (in-package "OPENGL-LIBRARY") (asdf:operate 'asdf:load-op 'verrazano-support) (cffi:defcstruct irpcchannelbuffer-1 (data :char 0)) (cffi:define-foreign-type long () ':long) (cffi:define-foreign-type hresult () 'long) (cffi:define-foreign-type rpcoledatarep () ':unsigned-long) (cffi:define-foreign-type dword () ':unsigned-long) (cffi:defcstruct tagrpcolemessage (reserved1 :pointer) (datarepresentation rpcoledatarep) (buffer :pointer) (cbbuffer dword) (imethod dword) (reserved2 anonymous17266) (rpcflags dword)) and anonymous17266 does not appear again. btw, the timing of the create was: ; cpu time (non-gc) 256,169 msec (00:04:16.169) user, 841 msec system ; cpu time (gc) 20,008 msec user, 220 msec system ; cpu time (total) 276,177 msec (00:04:36.177) user, 1,061 msec system ; real time 364,534 msec (00:06:04.534) ; space allocation: ; 352,492,413 cons cells, 552,004,584 other bytes, 8,447 static bytes I am going to take a break to look at cl-sockets now, then try Verrazano on FTGL later on. kenny ps. I will send you the latest files next. From tomi.neste at netikka.fi Fri Sep 9 14:27:37 2005 From: tomi.neste at netikka.fi (Tomi K Neste) Date: Fri, 09 Sep 2005 17:27:37 +0300 Subject: [fetter-devel] Undefined functions with FLTK Message-ID: While playing with the fltk bindings in the testsuite I noticed that some (most?) of the fltk function bindings generated weren't valid. I get a lot of 'Undefined alien: "_ZN9Fl_Input_8textfontEh"' style warnings and the mangled names generated for functions like "fl-widget-callback..." don't really exist in the fltk.so. It looks like these should be treated as virtual functions, just like is done with "fl-widget-delete". So, would that just be an unimplemented feature, bug or misunderstanding in my part? This is with the latest gccxml & SBCL 0.94. From asimon at math.bme.hu Sat Sep 10 16:35:54 2005 From: asimon at math.bme.hu (Andras Simon) Date: Sat, 10 Sep 2005 18:35:54 +0200 (CEST) Subject: [fetter-devel] unnamed bit fields Message-ID: The following (from waistatus.h on Linux) struct { unsigned int __w_termsig:7; /* Terminating signal. */ unsigned int __w_coredump:1; /* Set if dumped core. */ unsigned int __w_retcode:8; /* Return code if exited normally. */ unsigned int:16; } __wait_terminated; (a member of a union) is translated to (cffi:defcstruct wait-anonymous338 (--w-termsig :unsigned-int) (--w-coredump :unsigned-int) (--w-retcode :unsigned-int) ( :unsigned-int)) and causes error while parsing arguments to DESTRUCTURING-BIND: invalid number of elements in (:UNSIGNED-INT) to satisfy lambda list (CFFI::SLOTNAME TYPE &OPTIONAL (COUNT 1)): between 2 and 3 expected, but 1 found [Condition of type SB-KERNEL::ARG-COUNT-ERROR] in sbcl. I don't know how cffi expects bit-field definitions (or whether it supports them in the first place). The way I got it here is via (defbinding "pcre-library" (nicknames "pcre") (include "pcre.h") (export "match" "imatch" "pcre-info" "pcre-compile" "pcre-exec" "pcre-version") (override "")) and (verrazano:create-binding (verrazano:setup-build "gccxml" "/tmp/") "/tmp/pcre.binding" "/tmp/pcre-library.lisp" :cffi-backend nil) Andras From luismbo at gmail.com Sat Sep 10 17:16:12 2005 From: luismbo at gmail.com (Luis Oliveira) Date: Sat, 10 Sep 2005 18:16:12 +0100 Subject: [fetter-devel] unnamed bit fields In-Reply-To: References: Message-ID: On 10/set/2005, at 17:35, Andras Simon wrote: > The following (from waistatus.h on Linux) > > struct > { > unsigned int __w_termsig:7; /* Terminating signal. */ > unsigned int __w_coredump:1; /* Set if dumped core. */ > unsigned int __w_retcode:8; /* Return code if exited normally. > */ > unsigned int:16; > } __wait_terminated; > > (a member of a union) is translated to > > (cffi:defcstruct wait-anonymous338 (--w-termsig :unsigned-int) > (--w-coredump :unsigned-int) (--w-retcode :unsigned-int) ( > :unsigned-int)) > > and causes > > error while parsing arguments to DESTRUCTURING-BIND: > invalid number of elements in > (:UNSIGNED-INT) > to satisfy lambda list > (CFFI::SLOTNAME TYPE &OPTIONAL (COUNT 1)): > between 2 and 3 expected, but 1 found > [Condition of type SB-KERNEL::ARG-COUNT-ERROR] > > in sbcl. I don't know how cffi expects bit-field definitions (or > whether it supports them in the first place). No, CFFI doesn't support bit-fields yet. But the problem there is that the last structure slot is nameless. I'd say you could generate bindings to PCRE without that header, but I might be wrong. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt From asimon at math.bme.hu Sat Sep 10 18:56:31 2005 From: asimon at math.bme.hu (Andras Simon) Date: Sat, 10 Sep 2005 20:56:31 +0200 (CEST) Subject: [fetter-devel] unnamed bit fields In-Reply-To: References: Message-ID: On Sat, 10 Sep 2005, Luis Oliveira wrote: > > No, CFFI doesn't support bit-fields yet. But the problem there is that the > last structure slot is nameless. Yes, that's what the error message suggested (hence the Subject). But then it occurred to me that perhaps this was only the tip of the iceberg (ie., that there were no bit-fields at all). > I'd say you could generate bindings to PCRE > without that header, but I might be wrong. Thanks for the suggestion, I'll try that. The question is whether this is possible without modifying system header files. And anyway, maybe Verrazano shouldn't output stuff that cffi doesn't understand. Another example is (cffi:defcstruct lldiv-t (quot long long int) (rem long long int)) By the way, it's Verrazano/cffi that I'm interested in, not pcre. Andras From ktilton at nyc.rr.com Mon Sep 12 20:12:39 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 12 Sep 2005 16:12:39 -0400 Subject: [fetter-devel] next review steps Message-ID: <4325E137.1010505@nyc.rr.com> ok, back in action. my current task is to take my working acl/win32 openal demo (using CFFI bindings generated by vzn) and try running it under; Lispworks/win32 CLisp/win32 Corman Lisp/win32 other? Armed bear? ECL? GCL? and then: OpenMCL/OSX I may ask for others to try the code on various *nix platforms. Then I will review the documentation and test suite for completeness and make my CFFI-Luis evaluation (tho with time I would like to get a GLUT demo running to test callbacks). After that I will return to VZN and see if Rayiner has my OpenGL bindings problem resolved. I will also look at FTGL, a C++ library, then do my VZN evaluation. Did you gentlemen prepare student evaluations and forward them to Heow? I would like to see those so I know what you /think/ is there and so we can resolve any differences before getting to Google. Also, James, did you see my request for input on Luis's work? You have been the true mentor on that project, so I value your input. cheers, kenny From ktilton at nyc.rr.com Mon Sep 12 21:09:15 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 12 Sep 2005 17:09:15 -0400 Subject: [fetter-devel] verrazano-support requirement Message-ID: <4325EE7B.7000205@nyc.rr.com> Two thoughts re the verrazano-support package: minor: the openal-library generated by vzn requires verrrazano-support (it tries to load it), but the bindings per se do not. A small nicety would be to avoid an unnecessary dependency. But this goes away if... how about moving vzn support code into CFFI? Maybe we establish a rule of thumb: anything required at runtime goes in CFFI, and VZN is not needed at runtime (including any "support" package). I know vzn wants to support multiple backends, but multiple Lisp universal FFI backends? Why? UFFI is known to need an update, but an update never comes and CFFI is probably the last straw for UFFI. Hang on: is a better alternative to write the VZN-support code directly into the bindings file? Perhaps as an option the defbinding? I would just like to see xxx-library.lisp work as a standalone set of bindings, either by adding to it or by requiring certain code of any candidate backend. Thoughts? -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From luismbo at gmail.com Mon Sep 12 21:48:38 2005 From: luismbo at gmail.com (Luis Oliveira) Date: Mon, 12 Sep 2005 22:48:38 +0100 Subject: [fetter-devel] Re: [cffi-devel] next review steps In-Reply-To: <4325E137.1010505@nyc.rr.com> References: <4325E137.1010505@nyc.rr.com> Message-ID: <162f37085e80b1a4d283bc39e70478e8@gmail.com> On 12/set/2005, at 21:12, Kenny Tilton wrote: > ok, back in action. > > my current task is to take my working acl/win32 openal demo (using > CFFI bindings generated by vzn) and try running it under; > > Lispworks/win32 Make sure you download the latest cffi-luis tarball, it contains an important bugfix for Lispworks. > CLisp/win32 I have never tested this particular combination. Not sure if it needs the patch mentioned in cffi's homepage or not. Or what's happening with calling convention, etc... (will try it out tonight) > Corman Lisp/win32 > other? Armed bear? ECL? GCL? Like I mentioned in my final report Corman, ECL and GCL are not quite working at the moment. I don't think Armed Bear CL is able to access C libraries though, at least not without writint some JNI or something like that (my experience with Java is limited). > and then: OpenMCL/OSX That'll work fine. OpenMCL passes all tests except callbacks.double and callbacks.float due to a bug that has been fixed in its CVS version. > Then I will review the documentation and test suite for completeness > and make my CFFI-Luis evaluation (tho with time I would like to get a > GLUT demo running to test callbacks). Regarding the docs. Do you think a toc with one-line descriptions similar to what's in UFFI's docs would be a good idea? > Did you gentlemen prepare student evaluations and forward them to Heow? What evaluations? -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt From rayiner at gmail.com Tue Sep 13 03:03:05 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Mon, 12 Sep 2005 23:03:05 -0400 Subject: [fetter-devel] unnamed bit fields In-Reply-To: References: Message-ID: Been AFK this weekend, so sorry for the belated reply. The first problem is a bug in the simplifier which I've fixed in my tree. The second problem is a bug in the C-FFI backend's "C to C-FFI" type translation table. I've added "long long int" to the type table. I'll have to hunt down what other fundamental types GCC-XML emits that aren't in the C or C++ standards :-/ The issue about bitfields is a bigger problem. It won't keep the library from compiling, but to be able to access the bitfields, I'd have to write a lowering pass that would collapse the bitfield members and generate wrapper functions for doing the bit-twiddling to access those members. Luis, is bitfield support in the cards for C-FFI, or would I be better of writing the lowering pass? Sincerely, Rayiner Hashem On 9/10/05, Andras Simon wrote: > > > > On Sat, 10 Sep 2005, Luis Oliveira wrote: > > > > > No, CFFI doesn't support bit-fields yet. But the problem there is that > the > > last structure slot is nameless. > > Yes, that's what the error message suggested (hence the Subject). But > then it occurred to me that perhaps this was only the tip of the > iceberg (ie., that there were no bit-fields at all). > > > > I'd say you could generate bindings to PCRE > > without that header, but I might be wrong. > > Thanks for the suggestion, I'll try that. The question is whether this > is possible without modifying system header files. And anyway, maybe > Verrazano shouldn't output stuff that cffi doesn't understand. Another > example is > > (cffi:defcstruct lldiv-t (quot long long int) (rem long long int)) > > By the way, it's Verrazano/cffi that I'm interested in, not pcre. > > Andras > _______________________________________________ > 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: From luismbo at gmail.com Tue Sep 13 03:33:19 2005 From: luismbo at gmail.com (Luis Oliveira) Date: Tue, 13 Sep 2005 04:33:19 +0100 Subject: [fetter-devel] unnamed bit fields In-Reply-To: References: Message-ID: <09e4c5c5d5044068a391b03e4f188b3f@gmail.com> On 13/set/2005, at 04:03, Rayiner Hashem wrote: > The issue about bitfields is a bigger problem. It won't keep the > library from > compiling, but to be able to access the bitfields, I'd have to write > a lowering > pass that would collapse the bitfield members and generate wrapper > functions > for doing the bit-twiddling to access those members. Luis, is > bitfield support in > the cards for C-FFI, or would I be better of writing the lowering > pass? Well, yes, CFFI should support bitfields. In my todo list. Is this high-priority? -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt From rayiner at gmail.com Tue Sep 13 04:33:31 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Tue, 13 Sep 2005 00:33:31 -0400 Subject: [fetter-devel] unnamed bit fields In-Reply-To: <09e4c5c5d5044068a391b03e4f188b3f@gmail.com> References: <09e4c5c5d5044068a391b03e4f188b3f@gmail.com> Message-ID: For me, not particularly. Verrazano will work without it, it just won't be able to access variables in bitfields. Actually, once I get this OpenGL stuff finished, I'll go ahead and write a pass to at least collapse the bitfield members, so users can do their own bit-twiddling to get access to each sub-field. Sincerely, Rayiner Hashem On 9/12/05, Luis Oliveira wrote: > > On 13/set/2005, at 04:03, Rayiner Hashem wrote: > > The issue about bitfields is a bigger problem. It won't keep the > > library from > > compiling, but to be able to access the bitfields, I'd have to write > > a lowering > > pass that would collapse the bitfield members and generate wrapper > > functions > > for doing the bit-twiddling to access those members. Luis, is > > bitfield support in > > the cards for C-FFI, or would I be better of writing the lowering > > pass? > > Well, yes, CFFI should support bitfields. In my todo list. Is this > high-priority? > > -- > Lu?s Oliveira > http://student.dei.uc.pt/~lmoliv/ > Equipa Portuguesa do Translation Project > http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ktilton at nyc.rr.com Tue Sep 13 05:06:42 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 13 Sep 2005 01:06:42 -0400 Subject: [fetter-devel] unnamed bit fields In-Reply-To: <09e4c5c5d5044068a391b03e4f188b3f@gmail.com> References: <09e4c5c5d5044068a391b03e4f188b3f@gmail.com> Message-ID: <43265E62.4000808@nyc.rr.com> Luis Oliveira wrote: > On 13/set/2005, at 04:03, Rayiner Hashem wrote: > >> The issue about bitfields is a bigger problem. It won't keep the >> library from >> compiling, but to be able to access the bitfields, I'd have to write >> a lowering >> pass that would collapse the bitfield members and generate wrapper >> functions >> for doing the bit-twiddling to access those members. Luis, is >> bitfield support in >> the cards for C-FFI, or would I be better of writing the lowering pass? > > > Well, yes, CFFI should support bitfields. In my todo list. Is this > high-priority? > Didn't this start with a problem report from your first customer? Or were they just making an observation? If the former, that gives you a measure of how serious the problem is -- it came up in normal usage, not some arcane stress test. So that makes it higher priority. Also, it is one of your first customers, and you only get once chance to make a first impression. My 2c. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From luismbo at gmail.com Tue Sep 13 05:23:49 2005 From: luismbo at gmail.com (Luis Oliveira) Date: Tue, 13 Sep 2005 06:23:49 +0100 Subject: [fetter-devel] unnamed bit fields In-Reply-To: <43265E62.4000808@nyc.rr.com> References: <09e4c5c5d5044068a391b03e4f188b3f@gmail.com> <43265E62.4000808@nyc.rr.com> Message-ID: On 13/set/2005, at 06:06, Kenny Tilton wrote: > Didn't this start with a problem report from your first customer? Or > were they just making an observation? If the former, that gives you a > measure of how serious the problem is -- it came up in normal usage, > not some arcane stress test. So that makes it higher priority. Also, > it is one of your first customers, and you only get once chance to > make a first impression. Indeed, you have a point there. However, I don't see any much support for bitfields in other FFI's (only Allegro supports that AFAICT from a quick skim through the various docs). I suspect the details of bitfields vary a lot between compilers/abis. This particular customer didn't actually need bitfields, though. Verrazano was generating unnecessary/unused struct typedefs, right? -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt From rayiner at gmail.com Tue Sep 13 05:32:51 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Tue, 13 Sep 2005 01:32:51 -0400 Subject: [fetter-devel] unnamed bit fields In-Reply-To: References: <09e4c5c5d5044068a391b03e4f188b3f@gmail.com> <43265E62.4000808@nyc.rr.com> Message-ID: (I've CC'ed Andras to this message) It kind of depends on what Andras was doing. Bitfields are part of the wait.h API. As far as being unnecessary or unused, it also depends on what PCRE imports and uses from wait.h. It's probable that to use PCRE, he doesn't need bitfield support per-se, just for Verrazano to transform structs with bitfields into a format that gives an equivalent memory layout. If that's the case, then the fix should be quick in coming (its basically a bug fix). If Andras needs bitfield support, then I can write a lowering pass, or Luis can implement bitfields. Either one is fine with me, especially since I'll apparently need the lowering pass anyway to target other FFIs. Sincerely, Rayiner Hashem On 9/13/05, Luis Oliveira wrote: > > On 13/set/2005, at 06:06, Kenny Tilton wrote: > > Didn't this start with a problem report from your first customer? Or > > were they just making an observation? If the former, that gives you a > > measure of how serious the problem is -- it came up in normal usage, > > not some arcane stress test. So that makes it higher priority. Also, > > it is one of your first customers, and you only get once chance to > > make a first impression. > > Indeed, you have a point there. > > However, I don't see any much support for bitfields in other FFI's > (only Allegro supports that AFAICT from a quick skim through the > various docs). I suspect the details of bitfields vary a lot between > compilers/abis. > > This particular customer didn't actually need bitfields, though. > Verrazano was generating unnecessary/unused struct typedefs, right? > > -- > Lu?s Oliveira > http://student.dei.uc.pt/~lmoliv/ > Equipa Portuguesa do Translation Project > http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asimon at math.bme.hu Tue Sep 13 11:31:18 2005 From: asimon at math.bme.hu (Andras Simon) Date: Tue, 13 Sep 2005 13:31:18 +0200 (CEST) Subject: [fetter-devel] unnamed bit fields In-Reply-To: References: <09e4c5c5d5044068a391b03e4f188b3f@gmail.com> <43265E62.4000808@nyc.rr.com> Message-ID: On Tue, 13 Sep 2005, Rayiner Hashem wrote: > It kind of depends on what Andras was doing. Bitfields are part of the Just giving Verrazano/CFFI a test-drive. I choose pcre because it looked like something I could test easily. (Unlike OpenAL and OpenGL/Glut which Verrazano/CFFI has no problem dealing with (very impressive!), but I do.) So, I'd say just follow your schedule, and deal with bitfields when you see fit. Andras From ktilton at nyc.rr.com Tue Sep 13 17:15:23 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 13 Sep 2005 13:15:23 -0400 Subject: [fetter-devel] belated mentoring Message-ID: <4327092B.30403@nyc.rr.com> Just noticed foreign-alloc (while looking for foreign-allocate ), which reminds me of Tilton's Law of Abbreviation: Only abbreviate names (a) longer than six characters (b) where a reasonable abbreviation saves more than half the characters. Exceptions are made where a well-known abbreviation exists, such as serial-no instead of serial-number (number having only six characters). The nice thing about a strict abbreviations rule is the elimination of coding anxiety / guesswork / aproposing. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From rayiner at gmail.com Tue Sep 13 18:15:18 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Tue, 13 Sep 2005 14:15:18 -0400 Subject: [fetter-devel] unnamed bit fields In-Reply-To: References: <09e4c5c5d5044068a391b03e4f188b3f@gmail.com> <43265E62.4000808@nyc.rr.com> Message-ID: I'll go ahead and fix the bitfield structure layout bug and commit it along with the stuff opengl/windows fixes in the next day or two.. After that, I'll get to work on accessing bitfields and arrays in structures. No point hemming and hawing about it, as I'll have to write it eventually :) Sincerely, Rayiner On 9/13/05, Andras Simon wrote: > > > > On Tue, 13 Sep 2005, Rayiner Hashem wrote: > > > It kind of depends on what Andras was doing. Bitfields are part of the > > Just giving Verrazano/CFFI a test-drive. I choose pcre because it > looked like something I could test easily. (Unlike OpenAL and > OpenGL/Glut which Verrazano/CFFI has no problem dealing with (very > impressive!), but I do.) So, I'd say just follow your schedule, and > deal with bitfields when you see fit. > > Andras > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ktilton at nyc.rr.com Tue Sep 13 18:24:11 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 13 Sep 2005 14:24:11 -0400 Subject: [fetter-devel] unnamed bit fields In-Reply-To: References: <09e4c5c5d5044068a391b03e4f188b3f@gmail.com> <43265E62.4000808@nyc.rr.com> Message-ID: <4327194B.9080709@nyc.rr.com> Rayiner Hashem wrote: > I'll go ahead and fix the bitfield structure layout bug and commit it > along with the stuff opengl/windows fixes in the next day or two.. > After that, I'll get to work on accessing bitfields and arrays in > structures. No point hemming and hawing about it, as I'll have to > write it eventually :) Yes, Tilton's Law of Programming: "Keep moving foward." And the Corrollary: "The first time you run into an issue is only the first time you will run into it." Thanks for getting the hood up to handle this. kt From luismbo at gmail.com Tue Sep 13 21:53:56 2005 From: luismbo at gmail.com (Luis Oliveira) Date: Tue, 13 Sep 2005 22:53:56 +0100 Subject: [fetter-devel] belated mentoring In-Reply-To: <4327092B.30403@nyc.rr.com> References: <4327092B.30403@nyc.rr.com> Message-ID: On 13/set/2005, at 18:15, Kenny Tilton wrote: > Just noticed foreign-alloc (while looking for foreign-allocate ), > which reminds me of Tilton's Law of Abbreviation: Only abbreviate > names (a) longer than six characters (b) where a reasonable > abbreviation saves more than half the characters. Exceptions are made > where a well-known abbreviation exists, such as serial-no instead of > serial-number (number having only six characters). foreign-allocate (clisp), allocate-foreign-object and malloc (lispworks), foreign-alloc. Hmm.. I like them all. But James is the guy in charge of API naming. :-) I'm all for changing and picking the Right Names anyway. This is the time to do it. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From asimon at math.bme.hu Sat Sep 17 01:02:24 2005 From: asimon at math.bme.hu (Andras Simon) Date: Sat, 17 Sep 2005 03:02:24 +0200 (CEST) Subject: [fetter-devel] unnamed bit fields In-Reply-To: References: Message-ID: The bindings generated for pcre by the latest version of Verrazano compiled cleanly (with the latest CFFI-Luis). Not only that, but PCRE> (foreign-string-to-lisp (pcre-version)) "4.5 01-December-2003" Thanks, Rayiner and Luis! Andras From luismbo at gmail.com Sat Sep 17 01:07:38 2005 From: luismbo at gmail.com (Luis Oliveira) Date: Sat, 17 Sep 2005 02:07:38 +0100 Subject: [fetter-devel] unnamed bit fields In-Reply-To: References: Message-ID: On 17/set/2005, at 02:02, Andras Simon wrote: > PCRE> (foreign-string-to-lisp (pcre-version)) > "4.5 01-December-2003" Out of curiosity, how does Verrazano handle a pointer to char vs. a string. Would it be possible to specify in the binding declaration the default conversion of char* to be CFFI's :string? That way you'd have: PCRE> (pcre-version) "4.5 01-December-2003" -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From rayiner at gmail.com Sun Sep 18 09:37:56 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Sun, 18 Sep 2005 05:37:56 -0400 Subject: [fetter-devel] OpenGL on Windows Message-ID: Well, VZN CVS (as of my last commit friday afternoon) handles OpenGL on Windows just fine. opengl-library is generated without problems, and loads in Allegro without problems. Unfortunately, I had to modify gl.h (slightly) to get it working. The gl.h/glu.h that comes with VC.NET 2005 is actually kind of broken, since it uses definitions declared in windows.h (APIENTRY WINGDIAPI CALLBACK), but doesn't actually include windows.h. Including windows.h in one of these files results in a GCC-XML output file so large, that VZN can't even load it before hitting the heap limit on Allegro 7.0 Trial. The pruning pass was supposed to circumvent this limitation, by pruning the XML tree before conversion to IR (when memory usage really blows up), but the pruning pass doesn't even get to run before VZN runs out of memory. Well, so much for that theory. In any case, if anybody is attempting to run a header that includes windows.h, I'd appreciate it if they could tell me whether it works or not. For OpenGL specifically, if including windows.h doesn't work, then just #define'ing APIENTRY WINGDIAPI and CALLBACK as empty space should get the OpenGL binding generated. You can even do this without modifying the header files, by adding "-DAPIENTRY -DWINGDIAPI -DCALLBACK" to the 'flags' field of the input file. Sincerely, Rayiner Hashem -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayiner at gmail.com Mon Sep 19 06:54:40 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Mon, 19 Sep 2005 02:54:40 -0400 Subject: [fetter-devel] FTGL test and other things Message-ID: I've recently added an FTGL test to the testsuite. Currently, its a null test, since all it does is check to see if the binding compiles, but it runs just fine, and I'll flesh it out a bit more when I get the time. FTGL exposed a bug in the dependency sorting algorithm, where the behavior of mutually-referencing structures was poorly defined. Usually, it worked, in FTGL, it didn't. I've modified the algorithm to assume that alias-types don't create dependencies (as typedef doesn't create dependencies), with the effect being that alias types tend to get bubbled up to the beginning of the definition queue where they belong. I've also modified the C++ to CFFI type mapper to map bool to char. This is somewhat less than ideal (but works due to the sizes of the data types involved), and I'll fix that as soon as I get Verrazano generating C-FFI's type mappers. Lastly, I've updated the C-FFI backend to use foreign-alloc instead of foreign-object-alloc (which no longer exists). Sincerely, Rayiner Hashem -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayiner at gmail.com Mon Sep 19 20:40:07 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Mon, 19 Sep 2005 16:40:07 -0400 Subject: [fetter-devel] New features, updates Message-ID: There is a new news item on the page covering items recently added to Verrazano. Specifically, support for arrays in structures was added, along with tests covering OpenGL and libc. Sincerely, Rayiner Hashem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ktilton at nyc.rr.com Wed Sep 21 21:32:36 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 21 Sep 2005 17:32:36 -0400 Subject: [fetter-devel] Re: OpenGL on Windows In-Reply-To: References: Message-ID: <4331D174.804@nyc.rr.com> Rayiner Hashem wrote: > Well, VZN CVS (as of my last commit friday afternoon) handles OpenGL > on Windows just fine. opengl-library is generated without problems, > and loads in Allegro without problems. Unfortunately, I had to modify > gl.h (slightly) to get it working. The gl.h/glu.h that comes with > VC.NET 2005 is actually kind of broken, since it uses > definitions declared in windows.h (APIENTRY WINGDIAPI CALLBACK), but > doesn't actually include windows.h. Including windows.h in one of > these files results in a GCC-XML output file so large, that VZN can't > even load it before hitting the heap limit on Allegro 7.0 Trial. The > pruning pass was supposed to circumvent this limitation, by pruning > the XML tree before conversion to IR (when memory usage really blows > up), but the pruning pass doesn't even get to run before VZN runs out > of memory. Well, so much for that theory. In any case, if anybody is > attempting to run a header that includes windows.h, I'd appreciate it > if they could tell me whether it works or not. For OpenGL > specifically, if including windows.h doesn't work, then just > #define'ing APIENTRY WINGDIAPI and CALLBACK as empty space should get > the OpenGL binding generated. You can even do this without modifying > the header files, by adding "-DAPIENTRY -DWINGDIAPI -DCALLBACK" to the > 'flags' field of the input file. I am not having success with this. Best I can do is edit the vzntemp.cpp to include actual #defines in the .cpp. Turns out freeglut.h itself includes the windows.h file (yes, I am extending the example by pulling in a GLUT as well). But that is after the GL.h and I get errors on the GL.h. Maybe vc++ makes two passes?! Anyway, command-line defines do not seem to have effect. I almost think vc++ is throwing in #defines of its own in some useful (ha!) way. So the moral of the story may be that you can run but not hide from windows.h . In which case it would be great if Vzn could do the pruning by seeing which symbols were declared in desired headers vs all headers required. (If that approach will even work!) I think I will go back to my first success (which included windows.h) and see if ACL will accept the resulting (400+kb) library dot lisp. kt From ktilton at nyc.rr.com Thu Sep 22 01:13:14 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 21 Sep 2005 21:13:14 -0400 Subject: [fetter-devel] Re: OpenGL on Windows In-Reply-To: References: <4331D174.804@nyc.rr.com> Message-ID: <4332052A.1020505@nyc.rr.com> Rayiner Hashem wrote: >>I am not having success with this. Best I can do is edit the vzntemp.cpp >>to include actual #defines in the .cpp. Turns out freeglut.h itself >>includes the windows.h file (yes, I am extending the example by pulling >>in a GLUT as well). But that is after the GL.h and I get errors on the >>GL.h. >> >> > >I'm confused. What kind of errors are you getting? Stuff like >APIENTRY, etc being undefined? > The error message, as usual with C, was fully inscrutable. However, I simply deleted the WINGDIAPI and APIENTRY from the first line that errored and it compiled fine (with the next similar line still erroring). > > > > >>So the moral of the story may be that you can run but not hide from >>windows.h . In which case it would be great if Vzn could do the >>pruning by seeing which symbols were declared in desired headers vs all >>headers required. (If that approach will even work!) >> >> > >That's actually what it does. It sets symbols in the required headers >as the search roots, then marks as reachable anything reachable from >those roots. > I think the problem is that, as you noted, GL.h lacks an include of windows.h, so I list windows.h as a header in the binding definition. What I am angling for is a separate keyword, or some syntax such as: (defbinding "opengl-library" (nicknames "gl") (include ("windows.h" :suppress) "GL/gl.h" "GL/glu.h" "GL/freeglut.h") (override "glGetString" ("string" ("GLenum")))) That gives us full control over the results and lets us get things to compile naturally (by including the necessary header, not tweaking flags or altering headers which would have to re-altered after the next release of the C library). -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Thu Sep 22 11:38:37 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 22 Sep 2005 07:38:37 -0400 Subject: [fetter-devel] ASDF assumption.... Message-ID: <433297BD.4030504@nyc.rr.com> opengl-library.lisp as generated by vzn tries an asdf load-op on verrazano-support, but I like to use the AllegroCL project manager. It is no big deal to have ASDF loaded, but then I also need a file which pushes the verrazano-support directory onto the asdf registry, so /that/ gets set up before opengl-library.lisp gets processed and attempts the asdf operation. I am on record as hoping we can lose this vzn-support package, but as long as it is around I think the right way to go is leave it up to the user to have vzn-support loaded before opengl-library.lisp gets loaded. It is a nice thought to attempt to automate that, but I am uncomfortable that this assumes ASDF. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Thu Sep 22 16:35:45 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 22 Sep 2005 12:35:45 -0400 Subject: [fetter-devel] +gl-modelview+ vs GL_MODELVIEW Message-ID: <4332DD61.20003@nyc.rr.com> I know I mentioned this before, but just to get it back on the table... the lispification of names is a concern. First, it is only done in certain cases. Second, I am not sure it should be done at all, because it just leads to extra work and possible naming conflicts. What would be the problem with sticking with the exact spelling and case of C symbols? -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Thu Sep 22 16:41:33 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 22 Sep 2005 12:41:33 -0400 Subject: [fetter-devel] Re: OpenGL on Windows In-Reply-To: References: <4331D174.804@nyc.rr.com> Message-ID: <4332DEBD.5020306@nyc.rr.com> >That's actually what it does. It sets symbols in the required headers >as the search roots, then marks as reachable anything reachable from >those roots. There could be a bug in that algorithm, but I haven't >encountered anything like that on tests I've done. Although, I haven't >been able to test windows.h specifically yet. Maybe this weekend I'll >sneak into the CS labs and use their copy of the full version of ACL. > > > >>I think I will go back to my first success (which included windows.h) >>and see if ACL will accept the resulting (400+kb) library dot lisp. >> >> > >A 400kb file isn't an indication that the pruning isn't working. At >the moment, #define'ed constants aren't pruned because of the way I >use GCC-XML to do the macro processing. Most of the lines are simple >"defparameter" declarations that shouldn't cause you much more trouble >than some extra memory usage. > So there is no indication in the GCC-XML output where "IMAGE-FILE-MACHINE-ARM" originates? > On my machine, SBCL compiles a similar >300KB file (for something that includes opengl.h just to use GLint), >in a second or two. > Compiling takes a few minutes under ACL7. > Let me know how the loading of that file turns >out. I just tried loading the binding generated for gl.h, glu.h, and >glut.h, and it worked fine (with the undefined alien warnings that >seem to be an SBCL issue). > It compiles and loads OK, now I just have to change the constants to match VZN's renaming of those. btw, I am about to take my Xserve downtown to a colocation facility, might not be online much till evening. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From fgoenninger at prion.de Thu Sep 22 16:38:57 2005 From: fgoenninger at prion.de (Frank Goenninger - PRION Consulting) Date: Thu, 22 Sep 2005 18:38:57 +0200 Subject: [fetter-devel] +gl-modelview+ vs GL_MODELVIEW In-Reply-To: <4332DD61.20003@nyc.rr.com> References: <4332DD61.20003@nyc.rr.com> Message-ID: ;-) I'd also love to see a decision to stick with exact spelling of C symbols !!! Cheers Frank Am 22.09.2005 um 18:35 schrieb Kenny Tilton: > I know I mentioned this before, but just to get it back on the > table... the lispification of names is a concern. First, it is only > done in certain cases. Second, I am not sure it should be done at > all, because it just leads to extra work and possible naming > conflicts. What would be the problem with sticking with the exact > spelling and case of C symbols? > > -- > Kenny > > Why Lisp? http://wiki.alu.org/RtL_Highlight_Film > > "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 > > -- Frank G?nninger CEO / Vorstand PRION Consulting Services AG Phone: +49 711 797353-30 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht URL: From ktilton at nyc.rr.com Thu Sep 22 17:08:24 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 22 Sep 2005 13:08:24 -0400 Subject: [fetter-devel] constants not exported with +s Message-ID: <4332E508.5060100@nyc.rr.com> Looks like the export of constants is sans the bracketing "+"s. eg, the export is of "GL-MODELVIEW-STACK-DEPTH" The constant is (cl:defparameter +gl-modelview-stack-depth+ 2979) -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Thu Sep 22 17:19:10 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 22 Sep 2005 13:19:10 -0400 Subject: [fetter-devel] That's what I get : "IGNORE" "ERROR and "NULL" exported Message-ID: <4332E78E.9020800@nyc.rr.com> Maybe this goes away with better pruning, but I ended up with IGNORE, ERROR, and NULL exported by the GL package. If pruning won't work, I guess we need a way to suppress certain exports. I know you mentioned that possibility... is it functional? (God forbid I should look at the code or doc. ) -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Thu Sep 22 17:22:23 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 22 Sep 2005 13:22:23 -0400 Subject: [fetter-devel] That's what I get : "IGNORE" "ERROR and "NULL" exported In-Reply-To: <4332E78E.9020800@nyc.rr.com> References: <4332E78E.9020800@nyc.rr.com> Message-ID: <4332E84F.5060808@nyc.rr.com> Kenny Tilton wrote: > Maybe this goes away with better pruning, but I ended up with IGNORE, > ERROR, and NULL exported by the GL package. If pruning won't work, I > guess we need a way to suppress certain exports. I know you mentioned > that possibility... is it functional? (God forbid I should look at the > code or doc. ) > Ah, well, those were actually constants +error+, +ignore+, etc, but if we eliminate lispification then the conflict returns. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From rayiner at gmail.com Thu Sep 22 19:20:21 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Thu, 22 Sep 2005 15:20:21 -0400 Subject: [fetter-devel] +gl-modelview+ vs GL_MODELVIEW In-Reply-To: <4332DD61.20003@nyc.rr.com> References: <4332DD61.20003@nyc.rr.com> Message-ID: In my local tree, I've been doing some work to make the naming decision an option for the user. The infrastructure has been there for awhile, it just needs to be turned on. I'll try to get a release of this out by the weekend. On 9/22/05, Kenny Tilton wrote: > I know I mentioned this before, but just to get it back on the table... > the lispification of names is a concern. First, it is only done in > certain cases. Second, I am not sure it should be done at all, because > it just leads to extra work and possible naming conflicts. What would be > the problem with sticking with the exact spelling and case of C symbols? > > -- > Kenny > > Why Lisp? http://wiki.alu.org/RtL_Highlight_Film > > "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 > From ktilton at nyc.rr.com Fri Sep 23 17:18:50 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 23 Sep 2005 13:18:50 -0400 Subject: [fetter-devel] That's what I get II Message-ID: <433438FA.7000805@nyc.rr.com> Just sharing a war story: the bulk of the GLUT symbols did not get emitted because freeglut.h just includes freeglut_std.h and freeglut_ext.h. So my idea that vzn should emit only symbols named in listed headers kinda got in the way. I turned around and listed the two internal headers redundantly in the defbinding. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Mon Sep 26 16:36:22 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 26 Sep 2005 12:36:22 -0400 Subject: [fetter-devel] error on vzntemp.mac already existing Message-ID: <43382386.2000101@nyc.rr.com> Every time I have a problem running vzn, it fails to clean up the temp files such as vzntemp.mac. I then have to delete those manually. You could have the cleanup in an unwind-protect, but I see no danger in superseding any existing file each time it runs. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Tue Sep 27 00:19:08 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 26 Sep 2005 20:19:08 -0400 Subject: [fetter-devel] That's what I get II In-Reply-To: <433438FA.7000805@nyc.rr.com> References: <433438FA.7000805@nyc.rr.com> Message-ID: <43388FFC.1040209@nyc.rr.com> Kenny Tilton wrote: > Just sharing a war story: the bulk of the GLUT symbols did not get > emitted because freeglut.h just includes freeglut_std.h and > freeglut_ext.h. So my idea that vzn should emit only symbols named > in listed headers kinda got in the way. I turned around and listed the > two internal headers redundantly in the defbinding. > This is getting worse. FTGL gets us into C++-land, where we tend to find separate headers for each class. My binding file now looks like this: (defbinding "ftgl-library" (nicknames "ftgl") (include "FTFont.h" "FTGLBitmapFont.h" "FTGLExtrdFont.h" "FTGLOutlineFont.h" "FTGLPixmapFont.h" "FTGLPolygonFont.h" "FTGLTextureFont.h" "FTGlyph.h" "FTGLBitmapGlyph.h" "FTGLExtrdGlyph.h" "FTGLOutlineGlyph.h" "FTGLPixmapGlyph.h" "FTGLPolygonGlyph.h" "FTGLTextureGlyph.h" )) This could get to be a nightmare for a huge library such as a GUI. OK, "nightmare" is a little strong, especially compared to what it is like to hand-code bindings. And I do not think there is any way for vzn to determine on its own "oh, that nested include does not add to the API", nor do I think we want to include all of windows in every win32 binding file. jes' thinkin out loud. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Tue Sep 27 00:27:46 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 26 Sep 2005 20:27:46 -0400 Subject: [fetter-devel] vzn, c++, and vc++? Message-ID: <43389202.5030609@nyc.rr.com> Doh! I just genned the bindings for FTGL and they look great. Love seeing all those public methods exposed, because a new requirement had me getting ready to dive in and extend my C glue to that library to pick up a few more accessors I did not bother to build in before. But... My DLL was built with VC++. Should I even try, or is this bound to fail? How about if I install Cygwin and figure out how to build with that? That is GCC, yes? -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From rayiner at gmail.com Tue Sep 27 06:22:07 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Tue, 27 Sep 2005 02:22:07 -0400 Subject: [fetter-devel] Optional lispification, macro pruning Message-ID: I've recently added support in CVS for making Lispification optional. For this feature, there is a new clause in the defbinding called "OPTIONS". To get straight-C names, use the following clause in your input file: (options :foreign-names). This will prevent Verrazano from doing any name translation. I've also modified the macro reading code to grab filename information from the preprocessor, and use that to add fake XML nodes to the IR. Since this happens before the IR pruning phase, the result is that macro definitions get pruned too. On my machine, this makes OpenGL (including gl.h and glu.h) quite a bit smaller --- about 128K versus 300K before. Sincerely, Rayiner Hashem From ktilton at nyc.rr.com Tue Sep 27 15:14:27 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 27 Sep 2005 11:14:27 -0400 Subject: [fetter-devel] Re: Optional lispification, macro pruning In-Reply-To: References: Message-ID: <433961D3.9040107@nyc.rr.com> Rayiner Hashem wrote: >I've recently added support in CVS for making Lispification optional. >For this feature, there is a new clause in the defbinding called >"OPTIONS". To get straight-C names, use the following clause in your >input file: > >(options :foreign-names). > >This will prevent Verrazano from doing any name translation. > >I've also modified the macro reading code to grab filename information >from the preprocessor, and use that to add fake XML nodes to the IR. >Since this happens before the IR pruning phase, the result is that >macro definitions get pruned too. On my machine, this makes OpenGL >(including gl.h and glu.h) quite a bit smaller --- about 128K versus >300K before. > Works great. My ftgl-library.lisp is only 31k. Next issue. I get these two bindings for FTGL: (cffi:defcfun ("_ZN6FTFont7AdvanceEPKw" FTFont-Advance) :float (this :pointer) (string :pointer)) (cffi:defcfun ("_ZN6FTFont7AdvanceEPKc" FTFont-Advance-1) :float (this :pointer) (string :pointer)) The first corresponds to an overloaded C++ method specialized (if you will) on a string of wchar_ts, the second to a string of chars. I guess that is the trailing w/c in the mangled name. Having done this research (by examining the FTGL C++ source), I guess I will go with Advance-1, but there seems to be a problem here. Just not sure where. Will FTFont-advance above (the one expecting a pointer to an array of wchar_ts) really work for a CFFI string parameter? If not, is the first defcfun above a bug? If we really do end up with two "Advance" defcfuns with the same signature, how will the programmer know which corresponds to the C++ overloaded variant they need to hit, without looking at the source? Is there any way vzn can mimic the C++ mangling and sneak argument type info into the lisp name, or even just emit a defcfun docstring (with suitable enhancement of CFFI:defcfun) or even just a source code comment or (wild dream) produce CLOS methods for an FTFont-Advance GF each specialized appropriately and calling the appropriate C++ mangled defcfun? ie, all defcfuns get mangled names and the unmangled name is reserved for the CLOS GF which will serve to dispatch calls to the appropriate mangled defcfun? -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Tue Sep 27 17:02:11 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 27 Sep 2005 13:02:11 -0400 Subject: [fetter-devel] vzn vs. oo Message-ID: <43397B13.7050503@nyc.rr.com> FTGL is a pretty simple OO library: font class, then subclasses for pixmap, texture, extruded, inter alia. One virtual function is "render". vzn ends up producing (loosely speaking): pixmap-render texture-render extruded-render .... Left as an exercise is restoring the OO. What I would be tempted to do is: (defclass font ....) (defclass texture-font (font) ...) (defmethod render ((f texture-font) string) (texture-render f string)) Does vzn see enough info to restore the polymorphism of the C++ "render" virtual function? Even better would be: (defmethod initialize-instance :after ((f texture-font) &key) (setf (cpp-instance f) (texture-font-new (font-path f)))) As it is I think Vzn falls short of exposing the FTGL API, by leaving restoration of the polymorphism to the user. Or am I missing something or some difficulty? -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From ktilton at nyc.rr.com Tue Sep 27 18:12:26 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 27 Sep 2005 14:12:26 -0400 Subject: [fetter-devel] More on overloaded C++ functions -> Lisp ??? In-Reply-To: <433961D3.9040107@nyc.rr.com> References: <433961D3.9040107@nyc.rr.com> Message-ID: <43398B8A.4090509@nyc.rr.com> > Next issue. I get these two bindings for FTGL: > > (cffi:defcfun ("_ZN6FTFont7AdvanceEPKw" FTFont-Advance) :float > (this :pointer) (string :pointer)) > (cffi:defcfun ("_ZN6FTFont7AdvanceEPKc" FTFont-Advance-1) :float > (this :pointer) (string :pointer)) > > The first corresponds to an overloaded C++ method specialized (if you > will) on a string of wchar_ts, the second to a string of chars. I > guess that is the trailing w/c in the mangled name. Having done this > research (by examining the FTGL C++ source), I guess I will go with > Advance-1, but there seems to be a problem here. Just not sure where. OK, here is a second case of the above, a little hairier: (cl:defun FTFont-Render (this string) (vzn:virtual-funcall this 6 0 :pointer this :pointer string :void)) (cl:defun FTFont-Render-1 (this string) (vzn:virtual-funcall this 7 0 :pointer this :pointer string :void)) This is still the char vs wchar thing, but now I cannot tell which is which. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From rayiner at gmail.com Tue Sep 27 19:31:29 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Tue, 27 Sep 2005 15:31:29 -0400 Subject: [fetter-devel] More on overloaded C++ functions -> Lisp ??? In-Reply-To: <43398B8A.4090509@nyc.rr.com> References: <433961D3.9040107@nyc.rr.com> <43398B8A.4090509@nyc.rr.com> Message-ID: The functions are emitted in the same order as they are declared in the header file.* So the first function is for regular chars, and the second for wide chars. I suppose I could mangle the name to encode this type information, but it'd have to be pretty straight forward to not get completely ugly. How about the name of each type that differs between all overloads of a function name? In this particular case, you'd end up with FTFont-Render-pchar and FTFont-Render-pwchar-t. In more complex cases, you'd get very long function names, so maybe there should be some sort of limit? It's really a trade-off between usability and predictability (the former of which is a function of the latter...) Sincerely, Rayiner Hashem * This isn't quite so fragile as one would expect, since C++ virtual function tables are also defined by the ordering in the header file. Thus, C++ libraries generally don't change the declaration order, because that'd break binary compatibility with client code. Sincerely, Rayiner Hashem On 9/27/05, Kenny Tilton wrote: > > > > Next issue. I get these two bindings for FTGL: > > > > (cffi:defcfun ("_ZN6FTFont7AdvanceEPKw" FTFont-Advance) :float > > (this :pointer) (string :pointer)) > > (cffi:defcfun ("_ZN6FTFont7AdvanceEPKc" FTFont-Advance-1) :float > > (this :pointer) (string :pointer)) > > > > The first corresponds to an overloaded C++ method specialized (if you > > will) on a string of wchar_ts, the second to a string of chars. I > > guess that is the trailing w/c in the mangled name. Having done this > > research (by examining the FTGL C++ source), I guess I will go with > > Advance-1, but there seems to be a problem here. Just not sure where. > > OK, here is a second case of the above, a little hairier: > > (cl:defun FTFont-Render (this string) > (vzn:virtual-funcall this 6 0 :pointer this :pointer string :void)) > (cl:defun FTFont-Render-1 (this string) > (vzn:virtual-funcall this 7 0 :pointer this :pointer string :void)) > > This is still the char vs wchar thing, but now I cannot tell which is > which. > > -- > Kenny > > Why Lisp? http://wiki.alu.org/RtL_Highlight_Film > > "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 > From ktilton at nyc.rr.com Tue Sep 27 20:35:18 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 27 Sep 2005 16:35:18 -0400 Subject: [fetter-devel] Cygwin Blues trying to build win32/gcc DLL for FTGL Message-ID: <4339AD06.6090705@nyc.rr.com> Well, I installed Cygwin and the simplest example (hello world) did not work. The .exe got created without "x" permission. So I set the X permission and it runs. Well, I see an underscore flashing here and there on my bash console window, but no "hello world" and then I have to use the task manager to stop it. :( Somehow I do not feel sanguine about my chances building an FTGL dll using GCC. I suppose I could try, but... ...anybody comfortable with Cygwin who can build a DLL with GCC? or... ...any hope for support soon of VC++ dlls? -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "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 From rayiner at gmail.com Tue Sep 27 21:40:31 2005 From: rayiner at gmail.com (Rayiner Hashem) Date: Tue, 27 Sep 2005 17:40:31 -0400 Subject: [fetter-devel] Cygwin Blues trying to build win32/gcc DLL for FTGL In-Reply-To: <4339AD06.6090705@nyc.rr.com> References: <4339AD06.6090705@nyc.rr.com> Message-ID: There are Cygwin binaries of FTGL on this page: http://lassauge.free.fr/cygwin/en_cygwin.htm Scroll down to the bottom and he mentions how to get it installed using Cygwin's setup.exe. Basically, you start up setup.exe, and point it to: http://lassauge.free.fr/cygwin, then follow the prompts as usual. Hope that helps. Sincerely, Rayiner Hashem On 9/27/05, Kenny Tilton wrote: > Well, I installed Cygwin and the simplest example (hello world) did not > work. > > The .exe got created without "x" permission. > > So I set the X permission and it runs. Well, I see an underscore > flashing here and there on my bash console window, but no "hello world" > and then I have to use the task manager to stop it. :( > > Somehow I do not feel sanguine about my chances building an FTGL dll > using GCC. I suppose I could try, but... > > ...anybody comfortable with Cygwin who can build a DLL with GCC? or... > > ...any hope for support soon of VC++ dlls? > > -- > Kenny > > Why Lisp? http://wiki.alu.org/RtL_Highlight_Film > > "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 > From ktilton at nyc.rr.com Tue Sep 27 21:42:40 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 27 Sep 2005 17:42:40 -0400 Subject: [fetter-devel] More on overloaded C++ functions -> Lisp ??? In-Reply-To: References: <433961D3.9040107@nyc.rr.com> <43398B8A.4090509@nyc.rr.com> <4339AB50.3060703@nyc.rr.com> Message-ID: <4339BCD0.70405@nyc.rr.com> Rayiner Hashem wrote: >Hey! I didn't think about doc strings. That's a good idea. I'll >implement that right now. > Another trick is to manifest the arg type in the arg name: (cl:defun FTFont-Render (this wchar-string)...) (cl:defun FTFont-Render-1 (this char-string)...) Then when a helpful IDE shows the completion of a function invocation one is learning the type as well. I guess this is not so good where the info one needs most is the semantics, such as a make-box function that takes four integers but one can never remember the order (usually left, top, right, bottom). And on reflection, I guess I am normally worried about semantics not type at that point. Anyway, the doc-string will be fine. kt From ktilton at nyc.rr.com Tue Sep 27 22:25:29 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 27 Sep 2005 18:25:29 -0400 Subject: [fetter-devel] Cygwin Blues trying to build win32/gcc DLL for FTGL In-Reply-To: References: <4339AD06.6090705@nyc.rr.com> Message-ID: <4339C6D9.6000903@nyc.rr.com> Rayiner Hashem wrote: >There are Cygwin binaries of FTGL on this page: >http://lassauge.free.fr/cygwin/en_cygwin.htm > Thanks. Meanwhile, I just submitted a favorable evaluation of your project to Google. Congratulations on a fine job. kenny From ktilton at nyc.rr.com Wed Sep 28 20:59:35 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 28 Sep 2005 16:59:35 -0400 Subject: [fetter-devel] Cygwin Blues trying to build win32/gcc DLL for FTGL In-Reply-To: References: <4339AD06.6090705@nyc.rr.com> <433A06FE.9090100@nyc.rr.com> Message-ID: <433B0437.2000101@nyc.rr.com> Rayiner Hashem wrote: >Visual C++ support isn't undoable. > I think I have to wait for this. Load library on AllegroCL reasonably complained about the cyg ftgl dll not being able to find dependent DLLs until I installed them and set up my PATH variable to include cygwin directories, and then it simply hung once it could find everything. No CPU utilization. Lispworks simply registers a module and then must do the heavy lifting on the first FFI call, because the latter is when that hung. kt