> I have 32 bit Ubuntu installed on 64 bit hardware. I guess I should change
> to 64 bit linux, since the 64 bit version of PicoLisp seems to be really
> good for interacting with foreign libraries. But thats a complete new
Yes, that's recommendable. The 64-bit version also has other advantages,
like coroutines and more efficient arithmetics.
> > This looks good. You should be able to call that library directly from
> > the 64-bit version, analog to "lib/openGl.l" (or "lib/math64.l" for
> > another example).
> It is that analogy that I still don´t understand, since these two example
> files only have some constant definitions and a lot of Picolisp function
> definitions that do nothing else but use their arguments to call a native
> function with the same number of arguments.
That's the trick! ;-)
They are just convenience functions, and not absolutely necessary. For
example, to create a window, we have
(de glutCreateWindow (Name)
(native `*GlutLib "glutCreateWindow" NIL Name) )
so that you can simply call
But you might well also call
(native `*GlutLib "glutCreateWindow" NIL "MyWindow")
> Therefore, the openGL file looks a bit magic to me - do the native functions
> return nothing, and do they only use numbers or lists as parameters, no need
> for special data-types?
Most OpenGL functions do not take fancy arguments or return complicated
The 'native' function can do more, however (See doc/refN.html#native).
Besides scalar types for simple numbers and UTF-8 strings, it returns
and accepts (up to a certain degree) s-expressions describing nested
> I would expect the first step for building an PicoLisp-R or Picolisp-GRASS
> interface would be to map all possible data types in that languages to
> PicoLisp classes, and then write the calls to the native functions.
Well, I'm not sure here. To my feeling mapping to classes would not be
practical, but nested list <-> C-structures would. Let's see ...