trivial-features

The latest version of trivial-features no longer works in Edi's Lisp Starter-
Pack, which now returns the following error during the unpacking process; Error 
with invalid byte: 10 in #(110 32 116 104 101 10 107 101).

Was the package built differently to the previous working release?

- Luke

Re: trivial-features

On Tue, Nov 3, 2009 at 12:17 AM, Luke J Crook <luke <at> balooga.com> wrote:
> The latest version of trivial-features no longer works in Edi's Lisp Starter-
> Pack, which now returns the following error during the unpacking process; Error
> with invalid byte: 10 in #(110 32 116 104 101 10 107 101).
>
> Was the package built differently to the previous working release?

I don't think so, no. Got any more details? A backtrace perhaps?

--

-- 
Luís Oliveira
http://r42.eu/~luis/

Re: memutil.lisp breaks compile

On Sat, Nov 7, 2009 at 10:17 PM, Sebastian Tennant
<sebyte <at> smolny.plus.com> wrote:
> Luís is concerned about breaking things that depend on (or at least benefit
> from) his kludge (no offence intended).  Daniel Herring makes the point that
> hijacking names to provide upgarde/compatibility layers is a time-honoured
> tradition.
>
> In my humble opinion, hijacking names works for comprehensive drop-in
> replacements based on consensus amongst parties.  CFFI is clearly not a
> comprehensive drop-in replacement for UFFI and there's clearly no consensus on
> the issue.  I'm therefore in favour of changing the name.

Patches for CFFI and, most importantly, clbuild are very much welcome. 

--

-- 
Luís Oliveira
http://r42.eu/~luis/

Re: [Sbcl-devel] GC write-protected mappings vs. the OS kernel

From: Juho Snellman <jsnell <at> iki.fi>
> Samium Gromoff <_deepfire <at> feelingofgreen.ru> writes:
> 
>> Good day,
>> 
>> While debugging mysterious ioctl() failures in lh-usb on SBCL,
>> I have discovered that using CFFI:WITH-POINTER-TO-VECTOR-DATA
>> doesn't guarantee that the vector is in a writable region.
> 
> I thought we'd never write protect specialized raw arrays (either they
> are in the nursery, or they're tenured into an unboxed region which
> never get wpd). And passing generic arrays to ffi doesn't feel right.
> What's the use case?

Array element type is (unsigned-byte 8), use case is shovelling
data in/out a USB device using bulk transfers via ioctl().

regards,
  Samium Gromoff
--
                                 _deepfire-at-feelingofgreen.ru
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Re: [Sbcl-devel] GC write-protected mappings vs. the OS kernel

From: Samium Gromoff <_deepfire <at> feelingofgreen.ru>
> From: Juho Snellman <jsnell <at> iki.fi>
>> Samium Gromoff <_deepfire <at> feelingofgreen.ru> writes:
>> 
>>> Good day,
>>> 
>>> While debugging mysterious ioctl() failures in lh-usb on SBCL,
>>> I have discovered that using CFFI:WITH-POINTER-TO-VECTOR-DATA
>>> doesn't guarantee that the vector is in a writable region.
>> 
>> I thought we'd never write protect specialized raw arrays (either they
>> are in the nursery, or they're tenured into an unboxed region which
>> never get wpd). And passing generic arrays to ffi doesn't feel right.
>> What's the use case?
> 
> Array element type is (unsigned-byte 8), use case is shovelling
> data in/out a USB device using bulk transfers via ioctl().

A missing detail: while the vector is created in a live core all /seems/
to be well[1].  But when it comes from a dumped core, it gets a chance
(there doesn't appears to be a determinism there) of being in a
write-protected region.

regards,
  Samium Gromoff
--
1. It might be just that I didn't have enough statistics, as I'm working
mainly with cores of my own dumping.  Eh, hehe.

                                 _deepfire-at-feelingofgreen.ru

Re: [Sbcl-devel] GC write-protected mappings vs. the OS kernel

Samium Gromoff <_deepfire <at> feelingofgreen.ru> writes:
> A missing detail: while the vector is created in a live core all /seems/
> to be well[1].  But when it comes from a dumped core, it gets a chance
> (there doesn't appears to be a determinism there) of being in a
> write-protected region.

Yeah, that'd explain it. We don't correctly restore information about
whether a page is boxed or unboxed when loading a core (relevant bits
in coreparse.c, and in gencgc.c:gencgc_pickup_dynamic).

--

-- 
Juho Snellman

CFFI problem in Lispworks 5.1 32-bit with :long-long emulation

The problem manifests itself while trying to compile the latest
CL-SQLite; but can be replicated with:

(defcfun test :int64)

Error: :LONG-LONG fell through ECASE expression.
Wanted one of (:CHAR :UNSIGNED-CHAR :SHORT :UNSIGNED-SHORT :INT
:UNSIGNED-INT :LONG :UNSIGNED-LONG :FLOAT :DOUBLE :POINTER :VOID).
  1 (abort) Return to level 0.
  2 Return to top loop level 0.

The long-long gets through and fails in the lispworks-specific "Ecase"
(that has them removed for non-64-bit lispworks).

It looks as though something higher up is meant to filter/emulate this.

There seems to be emulation code in types.lisp

The :long-long comes from the method

(defmethod canonicalize ((tp emulated-llong)) :long-long)

But somehow this :long-long proliferates down all the way to the
lispworks-specific code.

By the way, and I don't know if this is relevant; but (fli:size-of
'(:long :long :int)) returns 8 in this Lispworks - I mention it only as
someone on #lisp asked me to try it.

Re: CFFI problem in Lispworks 5.1 32-bit with :long-long emulation

On Thu, Nov 19, 2009 at 5:33 PM, Matt Lamari <matt.lamari <at> gmail.com> wrote:
> (defcfun test :int64)
[...]
> The long-long gets through and fails in the lispworks-specific "Ecase"
> (that has them removed for non-64-bit lispworks).

Long-long emulation is not implemented for DEFCFUN, DEFCALLBACK, etc.
It turns out that Lispworks does in fact support long-long on 32-bit
platforms for DEFCFUN at least. Please let me know if the attached
patch works for you.

--

-- 
Luís Oliveira
http://r42.eu/~luis/

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

New patches: 25-Nov-2009

Tue Nov 24 18:20:02 EST 2009  Luis Oliveira <loliveira <at> common-lisp.net>
  * cffi-manual: the :STRING type does not support ub8 arrays anymore

    M ./doc/cffi-manual.texinfo -8 +2

Tue Nov 24 18:17:41 EST 2009  Luis Oliveira <loliveira <at> common-lisp.net>
  * libtest: support 64-bit on OSX Leopard

    M ./tests/GNUmakefile -6 +8

Tue Nov 24 18:14:42 EST 2009  Luis Oliveira <loliveira <at> common-lisp.net>
  * cffi-tests: show Lispworks the full path to libm.dylib

    M ./tests/bindings.lisp +2

Tue Nov 24 18:13:21 EST 2009  Luis Oliveira <loliveira <at> common-lisp.net>
  * cffi-lispworks: turns out Lispworks does support llong on 32-bit platforms

    M ./src/cffi-lispworks.lisp -2 +2

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

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