Hello.
I am trying to simplify ASDF-Install'ing Cells-GTK on different platforms. When trying with ECL, I find the following problem: CFFI defines uffi-compat package with "uffi" alias. Comment even expresses doubt whether it is a good idea. ECL has its own UFFI. So CFFI should either not declare such nickname for ECL or remove the alias from "FFI" package. I think the second is a better (although marginally more complex) behavior, because it increases portability and reduces number of people who notice implementation quirks of UFFI package.
I include sample patch to remove this alias. I hope something like that will get into the next release..
Thanks Michael Raskin
--- /home/raskin/.sbcl/site/cffi_0.10.5/uffi-compat/uffi-compat.lisp 2009-06-16 20:20:08.000000000 +0400 +++ /home/raskin/.ecl/site/cffi_0.10.5/uffi-compat/uffi-compat.lisp 2010-01-29 10:58:24.000000000 +0300 @@ -28,6 +28,10 @@
;;; Code borrowed from UFFI is Copyright (c) Kevin M. Rosenberg.
+#+ecl (eval-when (:compile-toplevel :execute :load-toplevel) + (rename-package :ffi :ffi + (remove "UFFI" (package-nicknames :ffi) :test 'equal))) + (defpackage #:cffi-uffi-compat (:nicknames #:uffi) ;; is this a good idea? (:use #:cl)
On Fri, Jan 29, 2010 at 8:05 AM, Michael Raskin f9cef2aa@yandex.ru wrote:
I am trying to simplify ASDF-Install'ing Cells-GTK on different platforms. When trying with ECL, I find the following problem: CFFI defines uffi-compat package with "uffi" alias.
Why use cffi-uffi-compat if ECL already provides its own implementation of the UFFI API?
On 01/29/2010 11:29 AM, Luís Oliveira wrote:
On Fri, Jan 29, 2010 at 8:05 AM, Michael Raskin f9cef2aa@yandex.ru wrote:
I am trying to simplify ASDF-Install'ing Cells-GTK on different platforms. When trying with ECL, I find the following problem: CFFI defines uffi-compat package with "uffi" alias.
Why use cffi-uffi-compat if ECL already provides its own implementation of the UFFI API?
Why special-case something in every program if there is a project that tracks how FFI is implemented across Common Lisp implementations?
So maybe you could take the second option and not bind UFFI nickname on ECL.
Thanks Michael Raskin
On Fri, Jan 29, 2010 at 8:47 AM, Michael Raskin f9cef2aa@yandex.ru wrote:
Why special-case something in every program if there is a project that tracks how FFI is implemented across Common Lisp implementations?
Right. I don't think many projects are using uffi-compat explicitly though.
So maybe you could take the second option and not bind UFFI nickname on ECL.
That sounds like a sensible thing to do, along with a style warning perhaps. Can you confirm that such a warning wouldn't conflict with your asdf-install efforts?
On 01/29/2010 12:00 PM, Luís Oliveira wrote:
On Fri, Jan 29, 2010 at 8:47 AM, Michael Raskin f9cef2aa@yandex.ru wrote:
Why special-case something in every program if there is a project that tracks how FFI is implemented across Common Lisp implementations?
Right. I don't think many projects are using uffi-compat explicitly though.
As opposed to what? With ASDF-Install one has to state all dependencies clearly...
So maybe you could take the second option and not bind UFFI nickname on ECL.
That sounds like a sensible thing to do, along with a style warning perhaps. Can you confirm that such a warning wouldn't conflict with your asdf-install efforts?
Well, ASDF tolerates style-warnings successfully. As far as I remember ASDF-Install doesn't look beyond what ASDF tells it about package health.
On Fri, Jan 29, 2010 at 9:12 AM, Michael Raskin f9cef2aa@yandex.ru wrote:
Right. I don't think many projects are using uffi-compat explicitly though.
As opposed to what? With ASDF-Install one has to state all dependencies clearly...
Well, a common use case is to take a library that supposedly depends on UFFI and make it use CFFI-UFFI-COMPAT through a uffi-compat/uffi.asd. ASDF-Install doesn't quite fit in this scenario, no.
So maybe you could take the second option and not bind UFFI nickname on ECL.
That sounds like a sensible thing to do, along with a style warning perhaps. Can you confirm that such a warning wouldn't conflict with your asdf-install efforts?
Well, ASDF tolerates style-warnings successfully. As far as I remember ASDF-Install doesn't look beyond what ASDF tells it about package health.
I will make this tweak to uffi-compat. I still think you should explicitly change your .asd to not depend on uffi-compat when running on ECL. (I would also advise you to use something like clbuild rather than asdf-install, but that's another matter. :-))
I am trying to simplify ASDF-Install'ing Cells-GTK on different platforms. When trying with ECL, I find the following problem: CFFI defines uffi-compat package with "uffi" alias. Comment even expresses doubt whether it is a good idea. ECL has its own UFFI. So CFFI should either not declare such nickname for ECL or remove the alias from "FFI" package. I think the second is a better (although marginally more complex) behavior, because it increases portability and reduces number of people who notice implementation quirks of UFFI package.
Why load cffi's uffi-compat if ECL has its own UFFI? I don't see the increase in portability.
- Daniel
On 01/30/2010 01:25 PM, dherring@tentpost.com wrote:
package. I think the second is a better (although marginally more complex) behavior, because it increases portability and reduces number of people who notice implementation quirks of UFFI package.
Why load cffi's uffi-compat if ECL has its own UFFI? I don't see the increase in portability.
Well, the question is whether CFFI has more subtle differences when used on different implementations than "native" UFFI implementations have. OK, I am probably wrong.