Re: FLI type error

Martin Simmons <[email protected]>
Newsgroups gmane.lisp.lispworks.general
Message-ID <[email protected]> 
Yes, that's the simplest way.

The LW compiler can do type inferencing for Lisp types, but this isn't a case
where it would be valid because "char *" in C is used for more than just a
string being passed into a function (e.g. see the POSIX function gethostname).

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/



>>>>> On Sun, 8 Mar 2026 14:35:20 -0400, Paul Werkowski (as pw at snoopy dot qozzy dot com) said:
> 
> 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
> 

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.