Steel Bank Common Lisp

On Thu, Nov 24, 2005 at 06:47:06PM +0530, Joshua N Pritikin wrote:
> Hi, I tried using sbcl 0.9.5.50 to load KM and clib
> 
>   http://www.cs.utexas.edu/users/mfkb/RKF/km.html
> &
>   http://www.cs.utexas.edu/users/mfkb/RKF/clib.html
> 
> sbcl blows up with an out-of-memory error.  My machine has 700M of RAM.
> Is there some configuration option for sbcl which might help?

This report is a bit low on details. It'd help to know at least:

  * What platform (os, architecture) is this?
  * What exact out-of-memory error are you getting? "Argh! 
    gc_find_freeish_pages failed"?
  * What exact steps are you doing to trigger the error? Preferably
    with a level of detail sufficient to allow someone with no
    knowledge of KM to repeat the problem. I tried the following,
    but it only used modest amounts of memory:
    
    (load "km-2-0-19.lisp")
    (km)
    (load-kb "tmp/rkf-clib-one.km" :verbose t)

That said... Do you perhaps declaim (OPTIMIZE (DEBUG 3)) in your
.sbclrc?

-- 
Juho Snellman

On Sun, Nov 27, 2005 at 01:47:52AM +0200, Juho Snellman wrote:
> On Thu, Nov 24, 2005 at 06:47:06PM +0530, Joshua N Pritikin wrote:
> > Hi, I tried using sbcl 0.9.5.50 to load KM and clib
> >=20
> >   http://www.cs.utexas.edu/users/mfkb/RKF/km.html
> > &
> >   http://www.cs.utexas.edu/users/mfkb/RKF/clib.html
> >=20
> > sbcl blows up with an out-of-memory error.  My machine has 700M of RAM.
> > Is there some configuration option for sbcl which might help?
>=20
> This report is a bit low on details. It'd help to know at least:
>=20
>   * What platform (os, architecture) is this?

Debian GNU/Linux 2.6.13.4 i686

>   * What exact out-of-memory error are you getting? "Argh!=20
>     gc_find_freeish_pages failed"?

Yes, "gc_find_free_space failed" to be exact.

>   * What exact steps are you doing to trigger the error? Preferably
>     with a level of detail sufficient to allow someone with no
>     knowledge of KM to repeat the problem. I tried the following,
>     but it only used modest amounts of memory:

Here is a session log:

joshua@...:~$ sbcl
This is SBCL 0.9.6, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (load "km.fasl")
STYLE-WARNING: defining *KM-PACKAGE* as a constant, even though the name
follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *VAR-MARKER-CHAR* as a constant, even though the name
follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *CLASSIFY-IN-LOCAL-SITUATIONS* as a constant, even though
the name follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *GLOBAL-SITUATION* as a constant, even though the name
follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *DEFAULT-FAIL-MODE* as a constant, even though the name
follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *BUILT-IN-SEQ-AGGREGATION-SLOTS* as a constant, even though
the name follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *BUILT-IN-SUBSLOTS* as a constant, even though the name
follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *DEFAULT-DEFAULT-FLUENT-STATUS* as a constant, even though
the name follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *COMMENT-MARKER-CHAR* as a constant, even though the name
follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *INDENT-INCREMENT* as a constant, even though the name
follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *PRUNE-POINTS* as a constant, even though the name follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *IGNORE-ITEMS* as a constant, even though the name follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING: defining *MAXDEPTH* as a constant, even though the name
follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING: defining *CHECKPOINT* as a constant, even though the name
follows
the usual naming convention (names like *FOO*) for special variables
STYLE-WARNING:
   defining *MAX-CONCAT-LENGTH* as a constant, even though the name
follows
the usual naming convention (names like *FOO*) for special variables
Resetting KM...
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
      KM - THE KNOWLEDGE MACHINE - INFERENCE ENGINE v2.0.19
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Copyright (C) 1994-2005 Peter Clark and Bruce Porter. KM comes with
ABSOLUTELY
NO WARRANTY. This is free software, and you are welcome to redistribute
it
under certain conditions. Type (license) for details.

Documentation at http://www.cs.utexas.edu/users/mfkb/km/
Type (km) for the KM interpreter prompt!
T
* (defun load-lib (&optional (comp-path "./components/"))
  (let (result)
    (dolist (component (traverse-directory comp-path) result)
      (cond
        ((equal (pathname-type component) "km")
         (load-kb component)
         (setf result (cons (pathname-name component) result)))
        ((equal (pathname-type component) "lisp")
         (load component))))))

(defun traverse-directory (root-dir-path)
  (let ((dir-list (directory root-dir-path)) sub-dir-path result)
    (dolist (element dir-list result)
      (if (directory (setf sub-dir-path (concatenate 'string
root-dir-path (pathname-name element) "/")))
          (setf result (append (traverse-directory sub-dir-path)
result))
          (setf result (cons element result))))))



; in: LAMBDA NIL
;     (TRAVERSE-DIRECTORY COMP-PATH)
;=20
; caught STYLE-WARNING:
;   undefined function: TRAVERSE-DIRECTORY

;=20
; caught STYLE-WARNING:
;   This function is undefined:
;     TRAVERSE-DIRECTORY
;=20
; compilation unit finished
;   caught 2 STYLE-WARNING conditions

LOAD-LIB
*=20
TRAVERSE-DIRECTORY
* (load-lib "clib/components/")
Argh! gc_find_free_space failed (first_page), nbytes=3D8.
   Gen Boxed Unboxed LB   LUB  !move  Alloc  Waste   Trig    WP  GCs
Mem-age
   0:     0     0     0     0     0        0     0  2000000    0   0
0.0000
   1:     0     0     0     0     0        0     0  2000000    0   0
0.0000
   2:     0     0     0     0     0        0     0  2000000    0   0
0.0000
   3: 51878   679    21    24     0 215401208 56584  2000000    0   0
2.5204
   4:     0     0     0     0     0        0     0  2000000    0   0
0.0000
   5:     0     0     0     0     0        0     0  2000000    0   0
0.0000
   6:     1     0     0     0     0     4096     0  2000000    1   0
0.0000
   Total bytes allocated=3D520273944
fatal error encountered in SBCL pid 3134(tid 3085338304)
The system is too badly corrupted or confused to continue at the Lisp
level. If the system had been compiled with the SB-LDB feature, we'd
drop
into the LDB low-level debugger now. But there's no LDB in this build,
so
we can't really do anything but just exit, sorry.

On Sun, Nov 27, 2005 at 01:47:52AM +0200, Juho Snellman wrote:
> That said... Do you perhaps declaim (OPTIMIZE (DEBUG 3)) in your
> .sbclrc?

I tried that but it appears that the sbcl available from debian unstable
doesn't include debugging support:

;   The function DEBUG is undefined, and its name is reserved by ANSI CL
so
that
;   even if it were defined later, the code doing so would not be
portable.

Shall I recompile sbcl with some debugging options enabled?

On Sun, 27 Nov 2005, Joshua N Pritikin wrote:

> On Sun, Nov 27, 2005 at 01:47:52AM +0200, Juho Snellman wrote:
>> That said... Do you perhaps declaim (OPTIMIZE (DEBUG 3)) in your
>> .sbclrc?
>
> I tried that but it appears that the sbcl available from debian unstable
> doesn't include debugging support:
>
> ;   The function DEBUG is undefined, and its name is reserved by ANSI CL
> so
> that
> ;   even if it were defined later, the code doing so would not be
> portable.

Whatever you did was not

  (DECLAIM (OPTIMIZE (DEBUG 3)))

...or something is deeply wrong. In either case doing this is a bad
idea. DEBUG 3 is currently something you should reserve for local
declares with SBCL. For ease of debugging something like

  (DECLAIM (OPTIMIZE (DEBUG 2) (SPEED 0) (SPACE 0)))

should do the job fairly well without killing the performance quite
as throughly as DEBUG 3.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

On Friday 25 November 2005 16:26, Marijn Haverbeke wrote:
> First off, I haven't been able to find any comprehensive information
> on the add-fd-handler function and related stuff, so I might be
> missing something obvious here. I use these handlers for accepting
> connections on a server socket, something like this:
>
>   (let ((socket (make-instance 'inet-socket :type :stream :protocol
> :tcp))) (socket-bind socket ip port)
>     (socket-listen socket 64)
>     (add-fd-handler (socket-file-descriptor socket) :input
> (make-connection-handler socket)))
>
> Where make-connection-handler generates a function that will accept
> and handle the connection. I stole this system from the Araneida
> webserver and it used to work perfectly. But I wanted to use threads
> in my program, so I recompiled SBCL (0.9.4) with sb-thread support
> (Suse Linux on an intel 32-bit processor, kernel version 2.6.8). The
> threads seem to work, but since the fd-handlers do not seem to work
> at all with the thread-enabled SBCL. The add-fd-handler function does
> not produce an error, and does return a handler, but the handler
> never gets called (at least, it does not get called in situations
> where it should get called). I could replace it with a thread that
> tries to accept sockets, but the program also still uses Araneida and
> I'd rather not go hacking in there.
>
> So is this a known problem? And is there a solution?
>
> Thanks for reading,
> Marijn

=46D handlers are per thread ergo they only have a chance to run if=20
serve-event is called in the same thread. This works for me:

(defun make-connection-handler (socket)
  (lambda (&rest args)
    (format t "Connection handler called with: ~S on socket ~S~%" args=20
socket)
    (force-output)))

(let ((socket (make-instance 'sb-bsd-sockets:inet-socket
                             :type :stream :protocol :tcp)))
  (sb-bsd-sockets:socket-bind socket #(127 0 0 1) 3337)
  (sb-bsd-sockets:socket-listen socket 64)
  (sb-sys:add-fd-handler (sb-bsd-sockets:socket-file-descriptor=20
socket) :input
                         (make-connection-handler socket))
  (loop (sb-sys:serve-all-events)))


Cheers, G=C3=A1bor

T24gMTEvMjMvMDUsIFRpbSBEYWx5IEpyLiA8dGltQHRlbmthbi5vcmc+IHdyb3RlOgo+IEhlbGxv
IGFsbCwKPgo+IElmIEkgc2F5IChkaXJlY3RvcnkgI3AiL3RtcC9bUF0qLioiKSwgSSBnZXQgYSB0
eXBlLWVycm9yIGBgVGhlIHZhbHVlICJQIgo+IGlzIG5vdCBvZiB0eXBlIENIQVJBQ1RFUi4nJyAg
SXMgdGhhdCBpbnRlbmRlZCB0byBiZSB0aGF0IHdheT8KPgo+IFlvdSBjYW4gZXNjYXBlIHRoZSBb
LCBidXQgdGhlbiB0aGUgbmFtZXN0cmluZyBlbmRzIHVwIHdpdGggYSBiYWNrc2xhc2gKPiBpbiBp
dDogKG5hbWVzdHJpbmcgI3AiL3RtcC9cXFtQXWZvbyIpID0+ICIvdG1wL1xcW1BdZm9vIi4KCldo
YXQgYWJvdXQgdGhpczoKCiQgdG91Y2ggIltQXWZpbGUiCiQgbHMgXFtQXF0qCltQXWZpbGUKJCBz
YmNsCkNMLVVTRVI+IChkaXJlY3RvcnkgI3AiL3RtcC9cW1BdKiIpCgooI1AiL3RtcC9cXFtQXWZp
bGUiKQoKTWljaGFlbAo=

On Wed, 2005-11-23 at 14:18 -0500, Michael Price wrote:
> On 11/23/05, Tim Daly Jr. <tim@...> wrote:
...
> > You can escape the [, but then the namestring ends up with a backslash
> > in it: (namestring #p"/tmp/\\[P]foo") => "/tmp/\\[P]foo".
> 
> What about this:
> 
> $ touch "[P]file"
> $ ls \[P\]*
> [P]file
> $ sbcl
> CL-USER> (directory #p"/tmp/\[P]*")
> 
> (#P"/tmp/\\[P]file")

Right.  Now there's a backslash in the namestring of that pathname,
which makes it less useful for, e.g., handing to unix system calls.
(Which is, IMHO, not such a silly thing to want to do...)

--
-Tim

T24gMTEvMjMvMDUsIFRpbSBEYWx5IEpyLiA8dGltQHRlbmthbi5vcmc+IHdyb3RlOgo+IE9uIFdl
ZCwgMjAwNS0xMS0yMyBhdCAxNDoxOCAtMDUwMCwgTWljaGFlbCBQcmljZSB3cm90ZToKPiA+IFdo
YXQgYWJvdXQgdGhpczoKPiA+Cj4gPiAkIHRvdWNoICJbUF1maWxlIgo+ID4gJCBscyBcW1BcXSoK
PiA+IFtQXWZpbGUKPiA+ICQgc2JjbAo+ID4gQ0wtVVNFUj4gKGRpcmVjdG9yeSAjcCIvdG1wL1xb
UF0qIikKPiA+Cj4gPiAoI1AiL3RtcC9cXFtQXWZpbGUiKQo+Cj4gUmlnaHQuICBOb3cgdGhlcmUn
cyBhIGJhY2tzbGFzaCBpbiB0aGUgbmFtZXN0cmluZyBvZiB0aGF0IHBhdGhuYW1lLAo+IHdoaWNo
IG1ha2VzIGl0IGxlc3MgdXNlZnVsIGZvciwgZS5nLiwgaGFuZGluZyB0byB1bml4IHN5c3RlbSBj
YWxscy4KPiAoV2hpY2ggaXMsIElNSE8sIG5vdCBzdWNoIGEgc2lsbHkgdGhpbmcgdG8gd2FudCB0
byBkby4uLikKCk15IGJhZCAtLSBkaWRuJ3QgcmVhZCB5b3VyIG9yaWdpbmFsIGVtYWlsIGNsb3Nl
bHkgZW5vdWdoLgoKICBDTC1VU0VSPiAobWFrZS1wYXRobmFtZSA6ZGlyZWN0b3J5ICcoOmFic29s
dXRlICJ0bXAiKSA6bmFtZSAiW1BdZmlsZSIpCgogICNQIi90bXAvXFxbUF1maWxlIgoKICBDTC1V
U0VSPiAocGF0aG5hbWUtbmFtZSAqKQoKICAiW1BdZmlsZSIKCk1pY2hhZWwK

T24gMTEvMjMvMDUsIE1pY2hhZWwgUHJpY2UgPG1pY2hhZWxAZWN0b3NwaGVuby5jb20+IHdyb3Rl
Ogo+ICAgQ0wtVVNFUj4gKG1ha2UtcGF0aG5hbWUgOmRpcmVjdG9yeSAnKDphYnNvbHV0ZSAidG1w
IikgOm5hbWUgIltQXWZpbGUiKQo+Cj4gICAjUCIvdG1wL1xcW1BdZmlsZSIKPgo+ICAgQ0wtVVNF
Uj4gKHBhdGhuYW1lLW5hbWUgKikKPgo+ICAgIltQXWZpbGUiCgpTb3JyeSB0byByZXBseSB0byBt
eXNlbGYsIGJ1dCB0byBjb250aW51ZSB0aGF0IGlkZWE6CgogIENMLVVTRVI+IChjb25jYXRlbmF0
ZSAnc3RyaW5nIChkaXJlY3RvcnktbmFtZXN0cmluZyAqKikgKHBhdGhuYW1lLW5hbWUgKiopKQoK
ICAiL3RtcC9bUF1maWxlIgoKTWljaGFlbAo=

On Nov 23, 2005, at 3:16 PM, Michael Price wrote:

> On 11/23/05, Michael Price <michael@...> wrote:
>>   CL-USER> (make-pathname :directory '(:absolute "tmp") :name 
>> "[P]file")
>>
>>   #P"/tmp/\\[P]file"
>>
>>   CL-USER> (pathname-name *)
>>
>>   "[P]file"
>
> Sorry to reply to myself, but to continue that idea:
>
>   CL-USER> (concatenate 'string (directory-namestring **) 
> (pathname-name **))
>
>   "/tmp/[P]file"

As usual, recipe for disaster.

Your previous suggestion was better.

Cheers
--
Marco

--
Marco Antoniotti					http://bioinformatics.nyu.edu/~marcoxa
NYU Courant Bioinformatics Group		tel. +1 - 212 - 998 3488
715 Broadway 10th FL				fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.

"Tim Daly Jr." <tim@...> writes:

> On Wed, 2005-11-23 at 14:18 -0500, Michael Price wrote:
>> On 11/23/05, Tim Daly Jr. <tim@...> wrote:
> ...
>> > You can escape the [, but then the namestring ends up with a backslash
>> > in it: (namestring #p"/tmp/\\[P]foo") => "/tmp/\\[P]foo".
>> 
>> What about this:
>> 
>> $ touch "[P]file"
>> $ ls \[P\]*
>> [P]file
>> $ sbcl
>> CL-USER> (directory #p"/tmp/\[P]*")
>> 
>> (#P"/tmp/\\[P]file")
>
> Right.  Now there's a backslash in the namestring of that pathname,
> which makes it less useful for, e.g., handing to unix system calls.
> (Which is, IMHO, not such a silly thing to want to do...)

This is why God^WThe SBCL Development Team gave us sb-posix.

In general, Lisp namestrings are not Unix pathnames; no need to go as
far as #\[ characters: you'll see the same effect with files with a
Unix pathname containing #\*.

The pattern matching in DIRECTORY does indeed look broken, though, but
what's _meant_ to happen with your namestring "[P]*.*" is that it
would match all files beginning with an uppercase P.

Cheers,

Christophe

T24gMTEvMjMvMDUsIE1pY2hhZWwgUHJpY2UgPG1pY2hhZWxAZWN0b3NwaGVuby5jb20+IHdyb3Rl
Ogo+IE9uIDExLzIzLzA1LCBNaWNoYWVsIFByaWNlIDxtaWNoYWVsQGVjdG9zcGhlbm8uY29tPiB3
cm90ZToKPiA+ICAgQ0wtVVNFUj4gKG1ha2UtcGF0aG5hbWUgOmRpcmVjdG9yeSAnKDphYnNvbHV0
ZSAidG1wIikgOm5hbWUgIltQXWZpbGUiKQo+ID4KPiA+ICAgI1AiL3RtcC9cXFtQXWZpbGUiCj4g
Pgo+ID4gICBDTC1VU0VSPiAocGF0aG5hbWUtbmFtZSAqKQo+ID4KPiA+ICAgIltQXWZpbGUiCj4K
PiBTb3JyeSB0byByZXBseSB0byBteXNlbGYsIGJ1dCB0byBjb250aW51ZSB0aGF0IGlkZWE6Cj4K
PiAgIENMLVVTRVI+IChjb25jYXRlbmF0ZSAnc3RyaW5nIChkaXJlY3RvcnktbmFtZXN0cmluZyAq
KikgKHBhdGhuYW1lLW5hbWUgKiopKQo+Cj4gICAiL3RtcC9bUF1maWxlIgoKV2hhdCdzIGJvdGgg
aW50ZXJlc3RpbmcgYW5kIGFubm95aW5nIGlzIHRoaXM6CgpDTC1VU0VSPiAobWFrZS1wYXRobmFt
ZSA6ZGlyZWN0b3J5ICcoOmFic29sdXRlICJ0bXAiICJbUF1kaXIiKSA6bmFtZSAiW1BdZmlsZSIp
KQoKI1AiL3RtcC9cXFtQXWRpci9cXFtQXWZpbGUiCgpDTC1VU0VSPiAoZGlyZWN0b3J5LW5hbWVz
dHJpbmcgKikKCiIvdG1wL1xcW1BdZGlyLyIKCkNMLVVTRVI+IChkaXJlY3RvcnktbmFtZXN0cmlu
ZyAjcCIvdG1wL1xcW1BdZGlyL1xcW1BdZmlsZSIpCgpkZWJ1Z2dlciBpbnZva2VkIG9uIGEgVFlQ
RS1FUlJPUjogVGhlIHZhbHVlICJQIiBpcyBub3Qgb2YgdHlwZSBCQVNFLUNIQVIuCgpUeXBlIEhF
TFAgZm9yIGRlYnVnZ2VyIGhlbHAsIG9yIChTQi1FWFQ6UVVJVCkgdG8gZXhpdCBmcm9tIFNCQ0wu
CgpyZXN0YXJ0cyAoaW52b2thYmxlIGJ5IG51bWJlciBvciBieSBwb3NzaWJseS1hYmJyZXZpYXRl
ZCBuYW1lKToKICAwOiBbQUJPUlRdIEV4aXQgZGVidWdnZXIsIHJldHVybmluZyB0byB0b3AgbGV2
ZWwuCgooU0ItS0VSTkVMOkhBSVJZLURBVEEtVkVDVE9SLVNFVCAiXFxbIiAyICJQIikKMF0KCldo
aWNoIHNlZW1zIHdyb25nIHRvIG1lLgoKQW5vdGhlciAiZnVuIiB0aGluZyB0byBkbyBpcyB0byBn
byBpbnRvIGEgZGlyZWN0b3J5IHdoZXJlIGFueSBwYXJlbnQKZGlyZWN0b3J5IGhhcyB0aGUgW10g
Y2hhcmFjdGVycyBpbiBpdHMgbmFtZSBhbmQgdHJ5IHRvIGxvYWQgdGhlCm9zaWNhdC10ZXN0IG9y
IHRlcm1pbmZvIHBhY2thZ2VzIHVzaW5nIGFzZGYuCgpNaWNoYWVsCg==

On Wed, 23 Nov 2005, Michael Price wrote:

> directory has the [] characters in its name and try to load the
> osicat-test or terminfo packages using asdf.

Osicat relies on the fundamentally broken assumption that NAMESTRING
gives you an Unix pathname.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

I've played around with building double-clickable apps with carbon,  
but I haven't gotten to the objc/cocoa bridge state yet. Doing  
something like the CLOS/cocoa bridge from OpenMCL seems a bit  
complicated, but just calling objc_mesg_send or whatever it is should  
be fairly straightforward (famous last words).

In any case, I'm very interested in working on something like this.  
In particular, access to the CoreGraphics/CoreVideo is something I'd  
like to have. I'd be interested in hearing more details about how the  
stuff you've got so far is working.

Cyrus

On Nov 22, 2005, at 12:33 PM, Michael Price wrote:

> Has anyone played around with using sbcl and CFFI to interface with
> objective-c cocoa code on Mac OS X?
>
> I have a small roguelike engine written in lisp that was designed to
> be the "M" in a MVC application. I'd like the view to be cocoa with
> the controller interfacing between the two using CFFI (or something
> like it.) The interface to the model is simple and only calls for
> passing strings and the occasional structure back and forth.
>
> I can just stick sbcl and the relevant core image in the resource
> bundle and give Mac users the standard drag-and-drop interface to
> application installation.Other than the download being a bit larger
> than Mac users are accustomed to I think this is a win-win scenario --
> I get to write most of the application in LISP without having to
> burden the end user with installing LISP (or even knowing its there.)
>
> Has anyone done something similar? I'd be interested in potential
> pitfalls before going too far down this path.
>
> Michael
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help

Michael Price <ectospheno@...> writes:
> Has anyone played around with using sbcl and CFFI to interface with
> objective-c cocoa code on Mac OS X?

IIRC, James Bielman has the beginnings of an Objective-C bridge on top
of CFFI. So, perhaps you should try to contact him directly or through
the CFFI mailing list.

-- 
Luís Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

Heiko Schr=F6ter <schroete@...> writes:

> Description of failure:
> 1) Installed 0.9.5 ALPHA binary from SBCL Download page. Works ok.
> 2) Downloaded sbcl 0.9.6 src.
> 3) Compilation looks ok, during linking the following message occurs:
>
> <snip>
> Thread model: posix
> gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)
>  /usr/lib/gcc-lib/alpha-unknown-linux-gnu/3.3.2/collect2 --eh-frame-hdr -=
m=20
> elf64alpha -O1 -export-dynamic -dynamic-linker /lib/ld-linux.so.2 -o=20
> sbcl /usr/lib/gcc-lib/alpha-unknown-linux-gnu/3.3.2/../../../crt1.o /usr/=
lib/gcc-lib/alpha-unknown-linux-gnu/3.3.2/../../../crti.o /usr/lib/gcc-lib/=
alpha-unknown-linux-gnu/3.3.2/crtbegin.o=20
> -L/usr/lib/gcc-lib/alpha-unknown-linux-gnu/3.3.2=20
> -L/usr/lib/gcc-lib/alpha-unknown-linux-gnu/3.3.2/../../.. -T=20
> ld-script.alpha-linux alloc.o backtrace.o breakpoint.o coreparse.o dynbin=
d.o=20
  ^^^^^^^^^^^^^^^^^^^^^

Here's the important bit.  To ensure that C library functions are
linked under the 32-bit ceiling (for the 32-bit alpha port), we use a
linker script.  Unfortunately, the linker script is strongly
version-dependent, so a linker script which works on gcc 2.95 and
the 2.2 kernel won't work on gcc 3 and 2.6 kernels.

The good news is that this problem has probably been solved by the
debian folks; try getting the debian source package and examining the
linker script they provide: it's more likely to work on your system.
(The reason we haven't updated it in our repository is that the
sourceforge alpha is running old versions of software, and that's the
only alpha sbcl developers have access to.)

I hope that helps.  (If this sounds insanely difficult, let me know;
I'll try to upload a 0.9.7 binary in any case, once that's released in
about a week or so).

Cheers,

Christophe

Il 2005-11-18, Christophe Rhodes <csr21@...> ha scritto:
> Heiko Schröter <schroete@...> writes:
>
> The good news is that this problem has probably been solved by the
> debian folks; try getting the debian source package and examining the

I did port the linker script forward. And it does seem to work for
alpha.

> I hope that helps.  (If this sounds insanely difficult, let me know;
> I'll try to upload a 0.9.7 binary in any case, once that's released in
> about a week or so).

If needed I could make an 'official' version on a debian alpha stable
machine.

Groetjes, Peter

-- 
signature -at- pvaneynd.mailworks.org 
http://www.livejournal.com/users/pvaneynd/
"God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|

Gisle S=E6lensminde <Gisle.Salensminde@...> writes:

> How can I specify that a file is encoded with Latin1, and
> not ascii or utf8.

Use :external-format :latin1 in the call to OPEN.

Cheers,

Christophe