headers
Reini Urban | 1 Apr 2007 15:49
Picon
Gravatar

cffi-clisp.lisp multiple-value-bind usage of variable "error" conflicts with another package

>I am attempting to use cffi on a Clisp 2.41 build running under Cygwin.
>I can get cffi to load using asdf, but when I loaded a package that uses
>cffi, I got an error message "ERROR is a constant: may not be used as a
>variable".

>In cffi-clisp.lisp, around line 234;
>    (multiple-value-bind (ff error) ...
>is causing the problem. I patched this to:
>   (multiple-value-bind (ff fferror)
>and also corrected the subsequent two references to error on lines 249
>and 250 and managed to get past this particular problem.

>In trying to localize the source of the name conflict, it appears that
>one of the optional modules that I have included in Clisp is the source
>of the conflit. These would include GDI, PCRE, RAWSOCK, LDAP, FASTCGI or
>ZLIB. The BASE build without the optional modules didn't have the name
>conflict, while the FULL build does. I have not determined which of the
>modules above was defining the constant "error".

I found the culprit. Of course it was me who introduced it.
GDI.lisp defines it.
Will be fixed asap.

--

-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/
Permalink | Reply | 0 comments |
headers
Henry Irvine | 12 Apr 2007 04:18
Picon
Favicon

Problems with Openmcl on Mac/Intel

Hello,
(cross posted to openmcl devel and cffi devel)

I am running into difficulties getting the CFFI tests to run on a mac  
pro (darwin X8664).
Openmcl is up to date, and I am using darcs to stay current with CFFI.
The problem is that CFFI can't load a foreign library.  CFFI itself  
compiles,
but any time a call to load-foreign-library is made, the results  
below occur.

The same source with sbcl on the same machine
runs all tests w/o failures.

I don't understand what is supposed to be happening well enough to  
troubleshoot it further.
Any insight or suggestions appreciated.

Backtrace:
   0: (CFFI::FL-ERROR "Unable to load any of the alternatives:~%   ~S")
       Locals:
         CFFI::CONTROL = "Unable to load any of the alternatives:~%    
~S"
         CFFI::ARGUMENTS = (("libtest.so" "libtest32.so"))
   1: (CFFI:LOAD-FOREIGN-LIBRARY 'CFFI:LOAD-FOREIGN-LIBRARY)
       Locals:
         #:USE-VALUE = #<RESTART USE-VALUE #x421706D>
         #:RETRY = #<RESTART CFFI::RETRY #x421701D>
         CCL::%RESTARTS% = ((#<RESTART CCL::RETRY-LOAD #x42172AD>
			    #<RESTART CCL::SKIP-LOAD #x42172FD>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Gary Byers | 12 Apr 2007 04:38
Favicon

Re: Problems with Openmcl on Mac/Intel

Are you trying to load a 32-bit foreign library in a 64-bit lisp ?
(I don't know what "libtest.so" is, but the value of CFFI::ARGUMENTS
in frame 0 makes me wonder about that.)

If this is the problem, I imagine that the CFFI test suite has options
to generate 64-bit test libraries; I seem to remember a similar issue
with ppc64.

In the shell,

shell> file /path/to/libtest.so

or

shell> lipo /path/to/libtest.so -info

might help to determine the architecture of the library.

On Wed, 11 Apr 2007, Henry Irvine wrote:

> Hello,
> (cross posted to openmcl devel and cffi devel)
>
> I am running into difficulties getting the CFFI tests to run on a mac
> pro (darwin X8664).
> Openmcl is up to date, and I am using darcs to stay current with CFFI.
> The problem is that CFFI can't load a foreign library.  CFFI itself
> compiles,
> but any time a call to load-foreign-library is made, the results
> below occur.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Henry Irvine | 12 Apr 2007 05:26
Picon
Favicon

Re: [Openmcl-devel] Problems with CFFI and Openmcl on Mac/Intel


On Apr 11, 2007, at 10:38 PM, Gary Byers wrote:
> Are you trying to load a 32-bit foreign library in a 64-bit lisp ?
> (I don't know what "libtest.so" is, but the value of CFFI::ARGUMENTS
> in frame 0 makes me wonder about that.)
>
> If this is the problem, I imagine that the CFFI test suite has options
> to generate 64-bit test libraries; I seem to remember a similar issue
> with ppc64.
>
> In the shell,
>
> shell> file /path/to/libtest.so
>
> or
>
> shell> lipo /path/to/libtest.so -info
>
> might help to determine the architecture of the library.

How right you are...

~/lisp/Lisp_Sources/site/cffi/tests $ file libtest.so
libtest.so: Mach-O bundle i386
~/lisp/Lisp_Sources/site/cffi/tests $ file libtest2.so
libtest2.so: Mach-O bundle i386
~/lisp/Lisp_Sources/site/cffi/tests $ lipo libtest.so -info
Non-fat file: libtest.so is architecture: i386
~/lisp/Lisp_Sources/site/cffi/tests $ lipo libtest2.so -info
Non-fat file: libtest2.so is architecture: i386
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luís Oliveira | 12 Apr 2007 05:37
Picon
Gravatar

Re: Re: [Openmcl-devel] Problems with CFFI and Openmcl on Mac/Intel

On 12/04/07, Henry Irvine <henryirvine <at> yahoo.com> wrote:
> I added a -m64 flag to the makefile for the test libs,
> now they are

I don't have access to darwin/x86-64, so I can't test this. A patch to
the Makefile would be great. :-)

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Permalink | Reply | 0 comments |
headers
Sean | 12 Apr 2007 16:05
Picon
Gravatar

translate-type-from-foreign

Hi all,
 I've noticed that in the upgrade from cffi 0.9.1 to 0.9.2 that there 
 were a few lines removed from early-types.lisp namely :

-;; Default Translators for foreign-struct-type
-(defmethod translate-type-from-foreign (value (type
foreign-struct-type))
-  (translate-from-foreign value (name type)))
-
-(defmethod translate-type-to-foreign (value (type foreign-struct-type))
-  (translate-to-foreign value (name type)))

I've been specialising translate-to-foreign to automatically convert c
structures to their equivalent lisp counterparts but without these lines
this obviously no longer works. 

Was this removal deliberate and if so what is the preferred way to
accomplish this?

Cheers,
  Sean.

--

-- 
...Please don't assume Lisp is only useful for Animation and Graphics,
AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor
applications, Expert Systems, Finance, Intelligent Agents, Knowledge
Management, Mechanical CAD, Modeling and Simulation, Natural Language,
Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web
Authoring just because these are the only things they happened to list.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Luis Oliveira | 12 Apr 2007 18:40
Picon
Gravatar

Re: translate-type-from-foreign

Sean <rosssd <at> gmail.com> writes:
> I've been specialising translate-to-foreign to automatically convert c
> structures to their equivalent lisp counterparts but without these lines
> this obviously no longer works.
>
> Was this removal deliberate and if so what is the preferred way to
> accomplish this?

Hmm.  I tried to track this alleged removal, unsuccessfully. :-) Are you
sure you didn't add that code yourself?  I can't find this code in
either 0.9.0 or 0.9.1.

In any case, you bring up a good point, which I've mentioned before too:
  <http://article.gmane.org/gmane.lisp.cffi.devel/1033>

Using the cffi-newtypes branch (which I hope to merge soon, since there
haven't been any complaints, unless James has any objections), you could
do something like this:

  (defcstruct %my-struct ...)

  (define-foreign-type my-struct-type ()
    ()
    (:actual-type %my-struct)
    (:simple-parser my-struct))

  (defmethod translate-from-foreign (value (type my-struct-type)) ...)
  (defmethod translate-to-foreign (value (type my-struct-type)) ...)
  (defmethod free-translated-object (value (type my-struct-type) param) ...)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sean | 13 Apr 2007 12:41
Picon
Gravatar

Re: Re: translate-type-from-foreign

On Thu, 2007-04-12 at 17:40 +0100, Luis Oliveira wrote: 
> Hmm.  I tried to track this alleged removal, unsuccessfully. :-) Are you
> sure you didn't add that code yourself?  I can't find this code in
> either 0.9.0 or 0.9.1.

<cough> <cough>, good catch. I swear one day I'll learn not to change
source code residing in asdf-install/site/ .

> In any case, you bring up a good point, which I've mentioned before too:
>   <http://article.gmane.org/gmane.lisp.cffi.devel/1033>
> 
> Using the cffi-newtypes branch (which I hope to merge soon, since there
> haven't been any complaints, unless James has any objections), you could
> do something like this:
> 
>   (defcstruct %my-struct ...)
> 
>   (define-foreign-type my-struct-type ()
>     ()
>     (:actual-type %my-struct)
>     (:simple-parser my-struct))
> 
>   (defmethod translate-from-foreign (value (type my-struct-type)) ...)
>   (defmethod translate-to-foreign (value (type my-struct-type)) ...)
>   (defmethod free-translated-object (value (type my-struct-type) param) ...)
> 
> Now, perhaps defcstruct could take an option to define a type class thus
> avoiding the need to define a wrapper type.  Perhaps something like
> this?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luis Oliveira | 15 Apr 2007 23:09
Picon
Gravatar

Re: translate-type-from-foreign

Sean <rosssd <at> gmail.com> writes:
> What does the :simple-parser slot-option do?

The (:simple-parser foo) in (define-foreign-type foo-type ...) expands to:

  (define-parse-method foo ()
    (make-instance 'foo-type))

> I'm just wondering does this provide any value other than the ability to
> define translations on c-structs? Not that this is the wrong way to do
> it but it does seem like a large amount of work to enable translations.

I agree that it's unfortunate that you need to define an extra type to
wrap the struct type and add translations, which is why I propose a
:CLASS option to defcstruct that would do that for you.

The big change in cffi-newtypes is that type translators work with
objects of type CFFI::FOREIGN-TYPE instead of symbols naming types.  To
answer your question, I do think this provides a lot of value.
Inheritance is more intituite (plain CLOS) and you handle type
arguments, e.g. (:string :encoding foo), which you can save as slots in
your type instance, much more easily.

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Permalink | Reply | 0 comments |
headers
Jonathan Johansen | 16 Apr 2007 14:19
Picon

problem "asdf:loading" cffi

Hi All,

I'm trying to compile the current version of CFFI (0.9.2)
in Clisp (2.39) on Ubuntu with asdf.  I entered:
    (asdf:oos 'asdf:load-op :cffi)
It then proceeded to load cffi.asd with no problems, and loads
utils.fas, features.fas and cffi-clisp.fas without problems, and then
complains in the following way:
***  -  READ: input stream
          #<INPUT BUFFERED FILE-STREAM CHARACTER
             #P"/var/cache/common-lisp-controller/1000/clisp/local/home/jon/code/
systems/cffi_0.9.2/src/package.fas"
              <at> 1>
          has reached its end
Does anyone know why this happens?  (If I should go ask this question
on the clisp or
asdf mailing list, I welcome your directions :).  Yes, I'm a newbie.
If more information is needed, I'm happy to oblige.

Regards, Jonathan Johansen
framlingham(at)gmail(dot)com
Permalink | Reply | 1 comment |

Gmane