[GSLL-devel] grid, foreign-array, fsbv and libffi

[Liam Healy]

I just chatted with Xach on #quicklisp and he's doing an update to ql
tomorrow, so that will have the better-separated pieces of FSBV I just
pushed today.  I think that there may be CL implementations that can
do call by value, but the responses to postings on cffi-devel asking
whether they can do it in CFFI was negative, so that's why I wrote
FSBV.  I asked them at the beginning if they wanted to incorporate it
into CFFI and Luis answered me in the affirmative a few months ago.
I've made a start at that but haven't done anything in several weeks.

Also I made a mistake which you probably caught, "It happens that GSD
defines complex foreign types but does NOT call functions with those
arguments by value; GSLL optionally uses them by value."

Liam

On Tue, Nov 30, 2010 at 12:54 PM, Sumant Oemrawsingh <soemraws at xs4all.nl> wrote:
> Hi Liam,
>
> Thanks for your answer. I am using quicklisp as well under windows, so
> I have fsbv installed, and that is when I noticed the problems
> concerning libffi under windows. While trying to fix the issues, I
> noticed that it was more intricate than I expected.
>
> Integrating fsbv into cffi would indeed be an elegant solution. And I
> understand that libffi is required for by-value calls; thanks for the
> explanation. I never realised that this can't be done with the (lisp
> implementation dependent) ffi. I just assumed it was only a matter of
> wrapping those functions into cffi.
>
> Anyway, thanks again. I'll get the new fsbv and try to get
> foreign-array working under windows. And maybe with some effort and
> the miracle of christmas, I can manage to get fsbv working _with_
> libffi under windows!
>
> -Sumant
>
> On Tue, Nov 30, 2010 at 12:38:41PM -0500, Liam Healy wrote:
>> Yes.
>>
>> I'm in the process of changing FSBV (and GSLL, and to some extent GSD)
>> with two intertwined goals.  One goal is to have all foreign struct
>> interface handled in one place, so that e.g. complex-double-c (in GSD)
>> and sf-result (in GSLL) are handled the same way.  Since this is (for
>> now) being done in FSBV, it has the effect of splitting FSBV into two
>> parts, say "FS" (foreign structures) and "FSBV" (foreign structures by
>> value).   The first part will handle conversions between foreign and
>> CL objects, as with #'object and #'(setf object).  It happens that GSD
>> defines complex foreign types but call functions with those arguments
>> by value; GSLL optionally uses them by value.
>>
>> The second goal is a long-term one of integrating FSBV into CFFI.
>> When I do that, the part that just addresses foreign structures (not
>> by-value calls) will (I'm hoping) be loaded automatically.   Then,
>> foreign-array will only require CFFI (which it already does).  The "by
>> value" part will be an optional system for CFFI users,  because it
>> requires libffi.
>>
>> I hope the explanation is clear.  To answer your specific question:
>> I've pushed a new version of FSBV; in that version, you only have to
>> load pkgdcl.lisp and convert.lisp, and you won't need libffi.  Sorry
>> for the awkward state; for the time being FSBV is mandatory, but I'm
>> hoping that goes away in the not-too-distant future.  I didn't make a
>> separate branch because it does work as-is, and I figured most people
>> were getting these systems via quicklisp, which already installs the
>> entire FSBV.
>>
>> Liam
>>
>> On Tue, Nov 30, 2010 at 11:58 AM, Sumant Oemrawsingh <soemraws at xs4all.nl> wrote:
>> > Hi Liam,
>> >
>> > Recently, I tried getting foreign-array working on windows (with
>> > sbcl). I noticed that foreign-array uses fsbv (apparently) and fsbv
>> > uses libffi. I haven't dug around in the code yet, but I was wondering
>> > if you have a quick explanation why libffi is used, and why cffi is
>> > not sufficient. The reason I ask is because I'm wondering if it would
>> > be possible to hack it under windows so it doesn't need libffi (which
>> > apparently is quite difficult to get working there).
>> >
>> > Thanks,
>> > Sumant
>> >
>> > _______________________________________________
>> > GSLL-devel mailing list
>> > GSLL-devel at common-lisp.net
>> > http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>> >
>>
>> _______________________________________________
>> GSLL-devel mailing list
>> GSLL-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>
> _______________________________________________
> GSLL-devel mailing list
> GSLL-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>