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]>
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
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.