New patches: 31-Dec-2008

Wed Dec 31 01:57:14 UTC 2008  Luis Oliveira <loliveira <at> common-lisp.net>
  * Experimental DEFCSTRUCT feature: accessors.

  CFFI> (macroexpand-1 '(defcstruct (foo :conc-name foo-)
                          (a :int)))
  ;;; ... 
  (defun foo-a (pointer-to-foo)
    (foreign-slot-value pointer-to-foo 'foo 'a))
  (defun (setf foo-a) (value pointer-to-foo)
    (foreign-slot-set value pointer-to-foo 'foo 'a))
  ;;; ... 

    M ./src/types.lisp -8 +26

Wed Dec 31 01:51:45 UTC 2008  Luis Oliveira <loliveira <at> common-lisp.net>
  * Improvements to the :ARRAY type.

  - Got rid of the :AUTO-ARRAY type. Add translators to :ARRAY
    directly instead.
  - Make the :ARRAY type aggregate. This way it can be used
    inside structures as an alternative to the :COUNT slot option.
  - Add TRANSLATE-AGGREGATE-TO-FOREIGN method that lets us do
    (setf (foreign-slot-value ptr 'struct 'slot-name) #(1 2 3))

    M ./src/types.lisp -16 +30

Wed Dec 31 01:48:50 UTC 2008  Luis Oliveira <loliveira <at> common-lisp.net>
  * Apply translators to FOREIGN-SLOT-VALUE on aggregate slots

proposed patch for clisp

FFI is an optional clisp feature.  Thus I propose adding it to CFFI's list 
of dependencies.

diff cffi.asd
    :author "James Bielman  <jamesjb <at> jamesjb.com>"
    :version "0.10.3"
    :licence "MIT"
-  :depends-on (alexandria trivial-features babel)
+  :depends-on (alexandria trivial-features babel #+clisp ffi)
    :components
    ((:module src
      :serial t

This allows ASDF users to autodetect that CFFI can't load, instead of 
waiting for the failure at compile time.

Thanks,
Daniel

Re: proposed patch for clisp

On Fri, Jan 2, 2009 at 5:26 AM, Daniel Herring <dherring <at> tentpost.com> wrote:
> FFI is an optional clisp feature.  Thus I propose adding it to CFFI's list
> of dependencies.
[...]
> +  :depends-on (alexandria trivial-features babel #+clisp ffi)
[...]

How about a #-ffi (error "CFFI requires a version of CLISP compiled
with the FFI module.") in src/cffi-clisp.lisp? Or something like that
in cffi.asd. What'd be the advantage of putting that in the ASD file?

--

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

Re: proposed patch for clisp

"Luís Oliveira" <luismbo <at> gmail.com> writes:
> How about a #-ffi (error "CFFI requires a version of CLISP compiled
> with the FFI module.") in src/cffi-clisp.lisp? Or something like that
> in cffi.asd. What'd be the advantage of putting that in the ASD file?

Presumably you'd also want runtime warning for CFFI compiled in an image
with FFI and loaded in one without.

--

-- 
I write stuff at http://failex.blogspot.com/ now.  But the post
formatter and themes are terrible for sharing code, the primary
content, so it might go away sooner or later.

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

Re: proposed patch for clisp

On Fri, 2 Jan 2009, Luís Oliveira wrote:

> On Fri, Jan 2, 2009 at 5:26 AM, Daniel Herring <dherring <at> tentpost.com> wrote:
>> FFI is an optional clisp feature.  Thus I propose adding it to CFFI's list
>> of dependencies.
> [...]
>> +  :depends-on (alexandria trivial-features babel #+clisp ffi)
> [...]
>
> How about a #-ffi (error "CFFI requires a version of CLISP compiled
> with the FFI module.") in src/cffi-clisp.lisp? Or something like that
> in cffi.asd. What'd be the advantage of putting that in the ASD file?

I'm trying to write a tool to load a collection of ASDF packages, skipping 
those which won't work on a given implementation/platform.  With ffi in 
the ASD defsystem, I can query asdf:component-depends-on before loading or 
handle ASDF:MISSING-DEPENDENCY at load time.

An ad-hoc error requires me to know in advance not to load CFFI, but it 
does provide a custom error message.

- Daniel

P.S.  I think its an ASDF defect that there is no mechanism for separately 
specifying dependencies on other packages, *features*, and arbitrary 
predicate functions.  With optional documentation for each.

_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net

Re: proposed patch for clisp

On Fri, 2009-01-02 at 00:26 -0500, Daniel Herring wrote:
> FFI is an optional clisp feature.  Thus I propose adding it to CFFI's list 
> of dependencies.
> 
> diff cffi.asd
>     :author "James Bielman  <jamesjb <at> jamesjb.com>"
>     :version "0.10.3"
>     :licence "MIT"
> -  :depends-on (alexandria trivial-features babel)
> +  :depends-on (alexandria trivial-features babel #+clisp ffi)
>     :components
>     ((:module src
>       :serial t
> 
> This allows ASDF users to autodetect that CFFI can't load, instead of 
> waiting for the failure at compile time.

have you actually tried to do this and managed to load CFFI ? on my
computer I get a "component #:FFI not found, required by #<SYSTEM "cffi"
#x2060D7B6>"

--

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

_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net

Re: proposed patch for clisp

On Fri, 2 Jan 2009, Stelian Ionescu wrote:

> On Fri, 2009-01-02 at 00:26 -0500, Daniel Herring wrote:
>> FFI is an optional clisp feature.  Thus I propose adding it to CFFI's list
>> of dependencies.
>>
>> diff cffi.asd
>>     :author "James Bielman  <jamesjb <at> jamesjb.com>"
>>     :version "0.10.3"
>>     :licence "MIT"
>> -  :depends-on (alexandria trivial-features babel)
>> +  :depends-on (alexandria trivial-features babel #+clisp ffi)
>>     :components
>>     ((:module src
>>       :serial t
>>
>> This allows ASDF users to autodetect that CFFI can't load, instead of
>> waiting for the failure at compile time.
>
> have you actually tried to do this and managed to load CFFI ? on my
> computer I get a "component #:FFI not found, required by #<SYSTEM "cffi"
> #x2060D7B6>"

No I hadn't.  This was a scatterbrained idea.  Sorry for the noise.

- Daniel

[PATCH] 64-bit support for Allegro, and allocate stack objects in the static area

Happy new year!

On 64-bit Allegro, run

(cffi:defcfun strerror :string (errnum :int))
(strerror 1)

and you will probably get

Received signal number 4 (Illegal instruction)
   [Condition of type EXCL:SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL]

at least if the returned pointer is more than 32-bits.

The problem is that without this patch, cffi-allegro.lisp does not
support 64-bit pointers. Does the patch address the problem properly?
It seems to work for us.

The use of :unsigned-nat instead of :unsigned-long is recommended by
Franz because on Windows 64-bit :unsigned-long is still 32-bits.

--- a/addons/cffi_0.10.3/src/cffi-allegro.lisp
+++ b/addons/cffi_0.10.3/src/cffi-allegro.lisp
 <at>  <at>  -135,7 +135,7  <at>  <at>  SIZE-VAR is supplied, it will be bound to SIZE during BODY."
           ;; stack allocation pattern
           `(let ((,size-var ,size))
              (declare (ignorable ,size-var))
-             (ff:with-stack-fobject (,var '(:array :char ,size))
+             (ff:with-stack-fobject (,var '(:array :char ,size) :allocation :foreign-static-gc)
                (let ((,var (ff:fslot-address ,var)))

Re: [PATCH] 64-bit support for Allegro, and allocate stack objects in the static area

On Mon, Jan 5, 2009 at 1:02 AM, John Fremlin <jf <at> msi.co.jp> wrote:
>  <at>  <at>  -263,12 +263,12  <at>  <at>  SIZE-VAR is supplied, it will be bound to SIZE during BODY."
>           :unsigned-long) 'integer)
>         (:float 'single-float)
>         (:double 'double-float)
> -        (:foreign-address :foreign-address)
> +        (:foreign-address 'integer)
>         (:void 'null))))

This change is somewhat unexpected, is it really necessary?

>  (defun foreign-allegro-type (type)
>   (if (eq type :foreign-address)
> -      nil
> +      :unsigned-nat
>       type))
>
>  (defun allegro-type-pair (type)

Does it work if you use :FOREIGN-ADDRESS instead of :UNSIGNED-NAT in
FOREIGN-ALLEGRO-TYPE?

I'm asking these questions because I suspect both changes break with
older versions of Allegro but I can't test it since the express
edition 7.0 is no longer available. It's probably not a big deal but
I'd like to at least try to maintain compatibility.

--

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

Re: [PATCH] 64-bit support for Allegro, and allocate stack objects in the static area

On Mon, 5 Jan 2009 03:14:13 +0000, "Luís Oliveira" <luismbo <at> gmail.com> wrote:

> On Mon, Jan 5, 2009 at 1:02 AM, John Fremlin <jf <at> msi.co.jp> wrote:
> >  <at>  <at>  -263,12 +263,12  <at>  <at>  SIZE-VAR is supplied, it will be bound to SIZE during BODY."
> >           :unsigned-long) 'integer)
> >         (:float 'single-float)
> >         (:double 'double-float)
> > -        (:foreign-address :foreign-address)
> > +        (:foreign-address 'integer)
> >         (:void 'null))))
> 
> This change is somewhat unexpected, is it really necessary?

Yes.

It is needed because now foreign-allegro-type does not return nil
for :foreign-address, and so Allegro will actually check the second
value from allegro-type-pair (which it ignored before because the first
value was nil).

> >  (defun foreign-allegro-type (type)
> >   (if (eq type :foreign-address)
> > -      nil
> > +      :unsigned-nat
> >       type))
> >
> >  (defun allegro-type-pair (type)
> 
> Does it work if you use :FOREIGN-ADDRESS instead of :UNSIGNED-NAT in
> FOREIGN-ALLEGRO-TYPE?