Re: FLI type error
"Paul Werkowski (as pw at snoopy dot qozzy dot com)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
I found it! Replace (:pointer glchar) with (:reference-pass :ef-mb-string) On 3/7/2026 3:15 PM, David McClain wrote: > Well, as I stated, this is Common Lisp, not ML. So no type inference (or very restricted), and no unification between two type trees. > > See section 5.2 of the FLI Manual. I believe there is also some info in the section that talks about REF-IN and REF-OUT parameters. > > > >> On Mar 7, 2026, at 12:51, Paul Werkowski (as pw at snoopy dot qozzy dot com) <[email protected]> wrote: >> >> This the definition of one of the functions in question: >> >> (fli:define-foreign-function (gl-get-uniform-location >> "glGetUniformLocation" >> :source) >> ((program gluint) >> (name (:pointer glchar))) >> :result-type glint >> :language :ansi-c) >> >> where >> >> (fli:define-c-typedef (gluint (:foreign-name "GLuint")) >> (:unsigned :int)) >> >> >> (fli:define-c-typedef (glchar (:foreign-name "GLchar")) >> :char) >> >> >> On 3/7/2026 2:21 PM, David McClain wrote: >>> The problem I have in my system is that I am using the extended char set in Lisp, and I don’t see a way to explicitly specify a string in BASE-CHAR. >>> >>> I think the only way to do that is with COERCE. And BASE-STRING and CHARACTER-STRINGS both present themselves the same way on printed output. >>> >>> A few years ago we were doing lots of crypto communication from Lisp, and one of the guys developed some kind of a reader macro, IIRC, that could be used to specify a literal string of BASE-CHAR. I will look around in my parts bin… >>> >>> >>>> On Mar 7, 2026, at 12:17, David McClain <[email protected]> wrote: >>>> >>>> Yes, so do I. But I was asking about type inference in LW FLI (aka unification). I don’t think LW has type inference capabilities. There can be some weak inference capabilities in the conversion of Lisp strings to FLI:CHAR pointers. But I think that comes about by having defined convertors, not naturally part of the FLI, but an augmentation provided by Martin and company… >>>> >>>> >>>>> On Mar 7, 2026, at 12:14, Paul Werkowski <[email protected]> wrote: >>>>> >>>>> I get "Hello". >>>>> >>>>> On 3/7/2026 2:11 PM, David McClain wrote: >>>>>> (coerce "Hello" 'base-string) >>>>>> >>>>>> But, is LW smart enough to see the transitive closure from GLCHAR to BASE-CHAR? >>>>>> >>>>>>> On Mar 7, 2026, at 12:08, Paul Werkowski (as pw at snoopy dot qozzy dot com) <[email protected]> wrote: >>>>>>> >>>>>>> No, *default-character-element-type* is BASE-CHAR. >>>>>>> >>>>>>> On 3/7/2026 2:04 PM, David McClain wrote: >>>>>>>> Web search shows GLCHAR is 8-bit char (ASCII ?). We had 30+ years of stability and simplicity once EBCDIC gave way to ASCII. >>>>>>>> >>>>>>>> But my recent experience with the Rust world shows that simplicity is no longer relevant. Very possibly you are using Wide Lisp chars instead of BASE-CHAR? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 7, 2026, at 11:24, Paul Werkowski (as pw at snoopy dot qozzy dot com) <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Well, GLCHAR is lisp :char. I see that the FLI manual has things like convert-to-foreign-type etc. I shall poke around in there for awhile. >>>>>>>>> >>>>>>>>> Thanks for the suggestion, >>>>>>>>> PW >>>>>>>>> >>>>>>>>> On 3/7/2026 12:43 PM, David McClain wrote: >>>>>>>>>> No… I now see. >>>>>>>>>> >>>>>>>>>> It appears that Lisp cannot automatically convert your Lisp string to the required C type (:POINTER OPENGL:GLCHAR). There has always been a sometimes conversion ability to allow Lisp strings to become C strings. But your required type is not a “C String” kind of pointer. >>>>>>>>>> >>>>>>>>>> Yes, even though it probably really is a C string type, I have no idea whether OPENGL:GLCHAR is a 8-bit ASCII char, or a Unicode wide char, etc. So probably no implicit LW conversions would apply. >>>>>>>>>> >>>>>>>>>> IOW… you probably now have to provide your own explicit conversions. >>>>>>>>>> >>>>>>>>>> - DM >>>>>>>>>> >>>>>>>>>>> On Mar 7, 2026, at 10:37, David McClain <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Both of these get a runtime error >>>>>>>>>>>> "aPos" (and "triangleColor") cannot be converted to foreign type >>>>>>>>>>>> (:POINTER OPENGL:GLCHAR). >>>>>>>>>>>> >>>>>>>>>>> Offhand… did the OpenGL API change since 10 years ago? Perhaps now expects an array of char, or a string pointer? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Mar 7, 2026, at 09:59, Paul Werkowski (as pw at snoopy dot qozzy dot com) <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I'm looking at some code from 5-10 years ago, experimenting with OPENGL, that uses the LW example code to setup the interface. The icosahedron example works fine so no issue there. >>>>>>>>>>>> >>>>>>>>>>>> Here are two fragments from my code. >>>>>>>>>>>> >>>>>>>>>>>> (let ((pos-attr (gl-get-attrib-location shader-pgm "aPos")) >>>>>>>>>>>> >>>>>>>>>>>> (let((unicolor (gl-get-uniform-location >>>>>>>>>>>> shader-pgm "triangleColor"))) >>>>>>>>>>>> >>>>>>>>>>>> Both of these get a runtime error >>>>>>>>>>>> "aPos" (and "triangleColor") cannot be converted to foreign type >>>>>>>>>>>> (:POINTER OPENGL:GLCHAR). >>>>>>>>>>>> >>>>>>>>>>>> GLCHAR is defined in opengl/types.lisp as >>>>>>>>>>>> >>>>>>>>>>>> (fli:define-c-typedef (glchar (:foreign-name "GLchar")) >>>>>>>>>>>> :char) >>>>>>>>>>>> >>>>>>>>>>>> Same issue with both LWW 8.1.2 64 bit and 7.1.2 32 bit. >>>>>>>>>>>> >>>>>>>>>>>> This all used to work. What could be wrong??? >>>>>>>>>>>> >>>>>>>>>>>> Puzzled again, >>>>>>>>>>>> Paul >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Lisp Hug - the mailing list for LispWorks users >>>>>>>>>>>> [email protected] >>>>>>>>>>>> http://www.lispworks.com/support/lisp-hug.html >>>>>>>>> _______________________________________________ >>>>>>>>> Lisp Hug - the mailing list for LispWorks users >>>>>>>>> [email protected] >>>>>>>>> http://www.lispworks.com/support/lisp-hug.html >>>>>>> _______________________________________________ >>>>>>> Lisp Hug - the mailing list for LispWorks users >>>>>>> [email protected] >>>>>>> http://www.lispworks.com/support/lisp-hug.html >> _______________________________________________ >> Lisp Hug - the mailing list for LispWorks users >> [email protected] >> http://www.lispworks.com/support/lisp-hug.html _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html