Luke J Crook | 3 Nov 01:17 2009

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
Luís Oliveira | 3 Nov 11:54 2009
Picon

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/
Sebastian Tennant | 7 Nov 23:17 2009

Re: memutil.lisp breaks compile

Quoth Henrik Hjelte <henrik <at> evahjelte.com>:
> http://www.mail-archive.com/cffi-devel <at> common-lisp.net/msg01656.html

This link appears to be broken (404 Not Found).

Was it intended to point to this conversation:

 http://thread.gmane.org/gmane.lisp.cffi.devel/1720

by chance?

> If there is a problem compiling it is usually because a version of cffi
> pretends to be uffi, and the cffi developers refuses to fix this.

Opinion is divided.  To name but a few:

Jeff Cunningham and Hans Hübner think it should be renamed.

Luís Olivera and Daniel Herring think it's best left as it is.

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.

(Continue reading)

Luís Oliveira | 8 Nov 13:26 2009
Picon

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/
Samium Gromoff | 10 Nov 16:26 2009
Picon

GC write-protected mappings vs. the OS kernel

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.

Normally, with userspace code, this isn't a problem, because,
as pointed on #lisp, the SEGV is handled by the lisp runtime
and the user code is resumed.

However this, understandably, interacts badly with kernel's
expectations, which simply refuses to write to a write-protected
region.

That is where my discovery ended, and a discussion on #lisp ensued,
including, among others, Alastair Bridgewater, James Knight and
Paul Khuong.  The rough consensus seemed to be (correct me if I got this
wrong) that SBCL needs to provide an abstraction for the missing
operation, as the chances of kernel adopting a mechanism allowing
to perform syscall continuation[1] through invocation of user-provided
fault handlers are pretty slim.

While thinking about this I have stumbled upon:

  http://common-lisp.net/project/cffi/darcs/cffi/doc/shareable-vectors.txt

which says:

  The implementation must guarantee the memory pointed to by PTR-VAR
  will not be moved during the dynamic contour of this operator, either
(Continue reading)

Juho Snellman | 10 Nov 16:42 2009
Picon
Picon

Re: GC write-protected mappings vs. the OS kernel

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?

--

-- 
Juho Snellman

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Samium Gromoff | 10 Nov 16:50 2009
Picon

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
Samium Gromoff | 10 Nov 17:11 2009
Picon

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
(Continue reading)

Juho Snellman | 10 Nov 17:12 2009
Picon
Picon

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
Nikodemus Siivola | 11 Nov 18:18 2009
Picon

Re: GC write-protected mappings vs. the OS kernel

2009/11/10 Juho Snellman <jsnell <at> iki.fi>:
> 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).

By a happy coincidence, I've been working on this area recently.
Expect to see a commit that keeps track of unboxed pages in saved
cores soonish...

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Gmane