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
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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
GSLL-devel mailing list GSLL-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
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@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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
GSLL-devel mailing list GSLL-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
GSLL-devel mailing list GSLL-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
Just checking:
Does this (loading fsbv's only pkgdlc.lisp & convert.lisp) mean that foreign arrays are unavailable to grid (and gsll)?
I implemented these compilation suggestions to the latest releases of fsbv and gsd, on clisp and cygwin and foreign arrays don't work: (grid:map-grid :source #'(lambda (i j) (+ i j)) :destination-specification '((foreign-array 2 2) double-float))
while natives do: (grid:map-grid :source #'(lambda (i j) (+ i j)) :destination-specification '((array 2 2) double-float))
I ask because today I tried to revive gsll on cygwin 1.7 after a long break. I had compilation errors related to foreign-arrays and complex-float-c.
I am not in a rush to compile gsll on cygwin/clisp since I do have it going nicely on sbcl. I can wait for the reimplementation of fsbv that Liam was talking about.
Mirko On Tue, Nov 30, 2010 at 12:38 PM, Liam Healy lhealy@common-lisp.net wrote:
Yes.
... stuff deleted
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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
GSLL-devel mailing list GSLL-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
-
Liam Healy -
Mirko Vukovic -
Sumant Oemrawsingh