Re: FLI type error
"David McClain (as dbm at refined-audiometrics dot com)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
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