Re: How can I teach cffi-features-p to test for :cygwin (or :windows)

On Sat, Jan 31, 2009 at 6:26 AM, Luís Oliveira <luismbo <at> gmail.com> wrote:
> On Thu, Jan 29, 2009 at 3:24 AM, Mirko Vukovic <mirko.vukovic <at> gmail.com> wrote:
>> The package maintainer tried using the :cygwin feature, but
>> cffi-feature-p does not capture it.
>
> We're using ALEXANDRIA:FEATUREP since 0.10.0, so it should work.
>
> --
> Luís Oliveira
> http://student.dei.uc.pt/~lmoliv/
>

My mistake.  I reloaded, and it does work as advertised.

Re: The use of wrappers in deployed applications

On Fri, Jan 30, 2009 at 6:05 AM, John Fremlin <jf <at> msi.co.jp> wrote:
>> I strongly recommend calling cffi:load-foreign-library at run time
>> only (never before delivery).  That gives you control over how the
>> library is loaded on startup (for example reporting errors to the
>> user).
[...]
> Luis, would you consider a patch to add a special variable
> *cffi-wrapper-delay-load* which would set a special mode for the
> generated wrapper.lisps?

I'd rather solve the problem in a more general way. (And document it
in the manual.) Every library out there calls LOAD-FOREIGN-LIBRARY at
load-time. What can we do to make that work in delivery-friendly way?
Not using absolute paths is one way, but is that not enough for the
wrapper libs?

Perhaps CFFI can unload the foreign libraries before delivery and take
care of reloading them later, thereby providing
*FOREIGN-LIBRARY-DIRECTORIES* and, eventually, error-handling hooks?

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/

New patches: 1-Feb-2009

Sun Feb  1 18:17:00 UTC 2009  Luis Oliveira <loliveira <at> common-lisp.net>
  tagged 0.10.4

Sun Feb  1 18:16:53 UTC 2009  Luis Oliveira <loliveira <at> common-lisp.net>
  * update cffi.asd for version 0.10.4

    M ./cffi.asd -1 +1

An updated tarball of CFFI's source can be downloaded here:
http://common-lisp.net/project/cffi/tarballs/cffi-090201.tar.gz

Darcsweb URL:
http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

Unloading libraries for delivery

Luís Oliveira <luismbo <at> gmail.com> writes:
> On Fri, Jan 30, 2009 at 6:05 AM, John Fremlin <jf <at> msi.co.jp> wrote:
[...]
>> Luis, would you consider a patch to add a special variable
>> *cffi-wrapper-delay-load* which would set a special mode for the
>> generated wrapper.lisps?
>
> I'd rather solve the problem in a more general way. (And document it
> in the manual.) Every library out there calls LOAD-FOREIGN-LIBRARY at
> load-time. What can we do to make that work in delivery-friendly way?

That's a really good point. Even if you give a quite extensive selection
of places to search for a library in, when the image is dumped the one
location where it was found on the dumping machine is stored in the
image. Restarting the image will crash before reaching user code, if
the library is not in the exact same place (as I understand it).

The ability to unload all libraries before dumping makes a lot of sense.

> Not using absolute paths is one way, but is that not enough for the
> wrapper libs?

The C libraries for wrapper files are generated inside the source
directory, or wherever asdf decides to put them. This generally means
that delivery without source (or at least, without the structure of the
source tree) is inconvenient.

It would be great if the list of the generated libraries could be
queried at delivery time, so they can all be copied into a destination
directory. 

New patches: 2-Feb-2009

Mon Feb  2 01:22:03 UTC 2009  Stelian Ionescu <sionescu <at> common-lisp.net>
  * Make sure that 64bit constants are groveled correctly on 32bit platforms.

    M ./grovel/grovel.lisp -1 +6

An updated tarball of CFFI's source can be downloaded here:
http://common-lisp.net/project/cffi/tarballs/cffi-090202.tar.gz

Darcsweb URL:
http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi-cffi;a=summary

Grovelling 64-bit constants

Hello,

I am trying to grovel some constants from libraw1394 and came across
this problem:

libraw1394/csr.h contains:
#define CSR_REGISTER_BASE  0xfffff0000000ULL

Grovelling this using
(include "libraw1394/csr.h")
(constant (+csr-register-base+ "CSR_REGISTER_BASE"))
sets +csr-register-base+ to -268435456.

This is with the current version of cffi from darcs on SBCL 1.0.25
(Linux x86).

Regards,
--

-- 
Julian Stecklina

Well, take it from an old hand: the only reason it would be easier to
program in C is that you can't easily express complex problems in C,
so you don't. - Erik Naggum (in comp.lang.lisp)

Re: Grovelling 64-bit constants

On Tue, 2009-02-10 at 19:12 +0100, Julian Stecklina wrote:
> Hello,
> 
> I am trying to grovel some constants from libraw1394 and came across
> this problem:
> 
> libraw1394/csr.h contains:
> #define CSR_REGISTER_BASE  0xfffff0000000ULL
> 
> Grovelling this using
> (include "libraw1394/csr.h")
> (constant (+csr-register-base+ "CSR_REGISTER_BASE"))
> sets +csr-register-base+ to -268435456.
> 
> This is with the current version of cffi from darcs on SBCL 1.0.25
> (Linux x86).

I too use this configuration and I get
(cl:defconstant +csr-register-base+ 281474708275200)

What gcc version are you using ? Could you compile and run the attached
C file and tell me what it reports ?

--

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

Re: Grovelling 64-bit constants

Stelian Ionescu <stelian.ionescu-zeus@...> writes:

> On Tue, 2009-02-10 at 19:12 +0100, Julian Stecklina wrote:
>> Hello,
>> 
>> I am trying to grovel some constants from libraw1394 and came across
>> this problem:
>> 
>> libraw1394/csr.h contains:
>> #define CSR_REGISTER_BASE  0xfffff0000000ULL
>> 
>> Grovelling this using
>> (include "libraw1394/csr.h")
>> (constant (+csr-register-base+ "CSR_REGISTER_BASE"))
>> sets +csr-register-base+ to -268435456.
>> 
>> This is with the current version of cffi from darcs on SBCL 1.0.25
>> (Linux x86).
>
> I too use this configuration and I get
> (cl:defconstant +csr-register-base+ 281474708275200)
>
> What gcc version are you using ? Could you compile and run the attached
> C file and tell me what it reports ?

Works... Sorry, I had CFFI 0.10.4 in my ASDF path. The darcs version
works fine.

Regards,
--

-- 

CCL Too few arguments in call to #<Compiled-function CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION #x30004143F48F>

When compiling my package GSLL (http://repo.or.cz/w/gsll.git) with the
lastest version of CFFI (from darcs repo yesterday) in Clozure CL, I
get an error
Too few arguments in call to #<Compiled-function
CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION #x30004143F48F>
If I use the CFFI version that's in Debian lenny, 20080217-1, it
compile, loads, and runs fine.
Also the CFFI darcs version compiles, loads and runs fine under SBCL.
The relevant GSLL source file is here:
http://repo.or.cz/w/gsll.git?a=blob;f=init/callback.lisp;h=63e84165b7bd8aaa7188d3b5805b99fecf99dddb;hb=f23f16afcda15531e6442837e13198834894d757

Any ideas as to why I get this error?

Liam

 ccl
Welcome to Clozure Common Lisp Version 1.2-r10552  (LinuxX8664)!
? (clc:clc-require :gsll-tests)
> Error: Too few arguments in call to #<Compiled-function CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION #x30004142FEDF>:
>        2 arguments provided, at least 3 required.
> While executing: CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 > (:b)
*(7F5A58D4C548) : 0 (NOTICE-FOREIGN-STRUCT-DEFINITION GSL-FUNCTION
(#'POINTER (PARAMETERS POINTER))) 7
 (7F5A58D4C5A0) : 1 (FUNCALL #'#<Anonymous Function #x3000400B59AF>
#<FASLSTATE  #x7F5A58B39F3D>) 77
 (7F5A58D4C5C0) : 2 (%FASLOAD
"/var/cache/common-lisp-controller/1000/ccl/local/home/liam/mathematics/gsll/init/callback.lx64fsl"

Re: CCL Too few arguments in call to #<Compiled-function CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION #x30004143F48F>

On Mon, 2009-02-23 at 10:22 -0500, Liam Healy wrote:
> When compiling my package GSLL (http://repo.or.cz/w/gsll.git) with the
> lastest version of CFFI (from darcs repo yesterday) in Clozure CL, I
> get an error
> Too few arguments in call to #<Compiled-function
> CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION #x30004143F48F>
> If I use the CFFI version that's in Debian lenny, 20080217-1, it
> compile, loads, and runs fine.
> Also the CFFI darcs version compiles, loads and runs fine under SBCL.
> The relevant GSLL source file is here:
> http://repo.or.cz/w/gsll.git?a=blob;f=init/callback.lisp;h=63e84165b7bd8aaa7188d3b5805b99fecf99dddb;hb=f23f16afcda15531e6442837e13198834894d757
> 
> Any ideas as to why I get this error?

I guess that you're having a problem of stale FASLs: try (asdf:oos
'asdf:load-op :gsll :force t) and if that doesn't work remove all FASLs
from /var/cache/common-lisp-controller and retry. A good advice would be
not to use c-l-c at all IMO.

--

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel