Steel Bank Common Lisp

Nicolas Neuss writes:
 > Hello, SBCL users.
 > 
 > I have access to an institute Laptop (G4 Powerbook) running MacOSX (10.3).
 > I have heard from colleagues that Emacs would not work well with this OS,
 > etc.  Therefore, to be sure that I do not sink much time here, I wanted to
 > ask if someone on this list uses an environment consisting of Emacs
 > (XEmacs), SBCL, and ILISP/SLIME on this operating system (if yes, was it
 > difficult to set up?).

        I'm using Emacs (GNU Emacs 21.3.50) on my 1st-generation 12"
PowerBook G4, with SLIME and SBCL. Works great.

        I'm generally happier with XEmacs, but I like the fact that GNU
Emacs does not require X11 to run.

        The main difficulty for me was that I had to compile Emacs
from source, which means that it was not difficult at all :-)

        Note that SBCL has some issues with run-program (or child
processes, in general), probably related to the handling of SIGCHILD
(or U*ix signals in general).

-- 
Raymond Wiker                        Mail:  Raymond.Wiker@...
Senior Software Engineer             Web:   http://www.fast.no/
Fast Search & Transfer ASA           Phone: +47 23 01 11 60
P.O. Box 1677 Vika                   Fax:   +47 35 54 87 99
NO-0120 Oslo, NORWAY                 Mob:   +47 48 01 11 60

Try FAST Search: http://alltheweb.com/

Raymond Wiker <Raymond.Wiker@...> writes:

> Nicolas Neuss writes:
>  > Hello, SBCL users.
>  > 
>  > I have access to an institute Laptop (G4 Powerbook) running MacOSX (10.3).
>  > I have heard from colleagues that Emacs would not work well with this OS,
>  > etc.  Therefore, to be sure that I do not sink much time here, I wanted to
>  > ask if someone on this list uses an environment consisting of Emacs
>  > (XEmacs), SBCL, and ILISP/SLIME on this operating system (if yes, was it
>  > difficult to set up?).
> 
>         I'm using Emacs (GNU Emacs 21.3.50) on my 1st-generation 12"
> PowerBook G4, with SLIME and SBCL. Works great.
> 
>         I'm generally happier with XEmacs, but I like the fact that GNU
> Emacs does not require X11 to run.

What does this mean?  Can Emacs use the native window system and XEmacs
cannot?  Or are you using it from a terminal (which XEmacs should be able
to do as well)?

>         The main difficulty for me was that I had to compile Emacs
> from source, which means that it was not difficult at all :-)
> 
>         Note that SBCL has some issues with run-program (or child
> processes, in general), probably related to the handling of SIGCHILD
> (or U*ix signals in general).

What are these issues?  (I would need run-program soon.)

Thank you for the feedback,

Nicolas.

Nicolas Neuss writes:
 > Raymond Wiker <Raymond.Wiker@...> writes:
 > 
 > >         I'm using Emacs (GNU Emacs 21.3.50) on my 1st-generation 12"
 > > PowerBook G4, with SLIME and SBCL. Works great.
 > > 
 > >         I'm generally happier with XEmacs, but I like the fact that GNU
 > > Emacs does not require X11 to run.
 > 
 > What does this mean?  Can Emacs use the native window system and XEmacs
 > cannot?  Or are you using it from a terminal (which XEmacs should be able
 > to do as well)?

        Yes, Emacs uses the native Mac Window system, which XEmacs is
unable to do.

 > >         The main difficulty for me was that I had to compile Emacs
 > > from source, which means that it was not difficult at all :-)
 > > 
 > >         Note that SBCL has some issues with run-program (or child
 > > processes, in general), probably related to the handling of SIGCHILD
 > > (or U*ix signals in general).
 > 
 > What are these issues?  (I would need run-program soon.)

        Up until a couple of weeks back, SBCL under MacOSX would
occasionally lose SIGCHLD signals. I found two workarounds for this:

        1) Place a call to "sleep" at the end of run-program
(actually, I think this had the effect of waiting for the program to
finish; I would have discovered this if I head tested with something
that actually took longer than 0.5 seconds to run.

        2) Add a call to get-processes-status-changes inside the loop
in process-wait (both are in src/code/run-program.lisp).

        Lennart Staflin discovered that there was a mismatch in the
naming of a primitive function, which caused infinite recursion.
Fixing this meant that SIGCHLD signals would be delivered reliably;
unfortunately, it also meant that SBCL would break into the debugger
on delivery of a deferred SIGCHLD (I think). Christophe Rhodes thinks
this is due to a bug in the (low-level) code that handles defereed
signals. 

        The real solution would be to fix this, but in the meantime I
think it would be possible to simply ignore SIGCHLD, and call
get-processes-status-changes "manually" (or from process-wait, as in
(2), above).

        More details in the sbcl-devel archives.

-- 
Raymond Wiker                        Mail:  Raymond.Wiker@...
Senior Software Engineer             Web:   http://www.fast.no/
Fast Search & Transfer ASA           Phone: +47 23 01 11 60
P.O. Box 1677 Vika                   Fax:   +47 35 54 87 99
NO-0120 Oslo, NORWAY                 Mob:   +47 48 01 11 60

Try FAST Search: http://alltheweb.com/

Nicolas Neuss writes:
> Hello, SBCL users.
> 
> I have access to an institute Laptop (G4 Powerbook) running MacOSX (10.3).
> I have heard from colleagues that Emacs would not work well with this OS,
> etc.  Therefore, to be sure that I do not sink much time here, I wanted to
> ask if someone on this list uses an environment consisting of Emacs
> (XEmacs), SBCL, and ILISP/SLIME on this operating system (if yes, was it
> difficult to set up?).

I've not  checked SBCL on  MacOSX yet (does  it compile to  PPC?), but
emacs and  ilisp work perfectly fine  on emacs. You can  use a vanilla
gnuemacs with X  on MacOSX, or a gnuemacs with Aqua  if you rather not
install X.

For now, I've used openmcl and clisp on MacOSX and both work well.  If
you intend to write GUI  applications, openmcl has a head start, being
able to load  libraries and being able to  use Objective-C objects and
sending them messages.


-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

Raymond Wiker <Raymond.Wiker@...> writes:

>         Lennart Staflin discovered that there was a mismatch in the
> naming of a primitive function, which caused infinite recursion.
> Fixing this meant that SIGCHLD signals would be delivered reliably;
> unfortunately, it also meant that SBCL would break into the debugger
> on delivery of a deferred SIGCHLD (I think). Christophe Rhodes thinks
> this is due to a bug in the (low-level) code that handles defereed
> signals. 

This sounds like a reasonable summary of what I think is happening.  I
still can't investigate this personally, because the only machine I
have access to (SourceForge's compile-farm PPC) is dual-processor,
which in practice means that it doesn't suffer from this problem.  I
live in hope that one of our multitude of users on PPC/Darwin will
find some free time to look at this a little :-) otherwise, I may be
in a position to spend a little (but not a lot) of time on this in
mid- to late-February.

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jan 21, 2004, at 4:12 AM, Nicolas Neuss wrote:

> Hello, SBCL users.
>
> I have access to an institute Laptop (G4 Powerbook) running MacOSX 
> (10.3).
> I have heard from colleagues that Emacs would not work well with this 
> OS,
> etc.  Therefore, to be sure that I do not sink much time here, I 
> wanted to
> ask if someone on this list uses an environment consisting of Emacs
> (XEmacs), SBCL, and ILISP/SLIME on this operating system (if yes, was 
> it
> difficult to set up?).
>
> Thanks,
> Nicolas.

SBCL binaries for OS X will for the time being be available at 
http://www.cs.indiana.edu/~bmastenb/software/SBCL/ - always check that 
page for binaries. SLIME works great for me with GNU emacs. I haven't 
tried the native xemacs available at 
http://homepage.mac.com/pjarvis/xemacs-21.5.9.html but I think most 
xemacs/OS X users simply use X11.

Brian

- --
Brian Mastenbrook
bmastenb@...
http://cs.indiana.edu/~bmastenb/

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQA5y/2nXQDi0istxEQIdOgCg7XmDwozSSjD3uT69wHcEYj7dnh4AoP7z
sBSrsd5W2u9v33peTFm+MEMp
=LZnb
-----END PGP SIGNATURE-----

"Pascal J.Bourguignon" <pjb@...> writes:

> I've not  checked SBCL on  MacOSX yet (does  it compile to  PPC?), but
> emacs and  ilisp work perfectly fine  on emacs. You can  use a vanilla
> gnuemacs with X  on MacOSX, or a gnuemacs with Aqua  if you rather not
> install X.

Do you run Emacs on Darwin (MacOSX 10.3)?  I have just downloaded the 21.3
sources which complain that Emacs has not yet been ported to PPC/Darwin
(but the sources are from March 2003, so things may have changed in CVS).

Nicolas.

On Jan 21, 2004, at 11:09 AM, Nicolas Neuss wrote:

> "Pascal J.Bourguignon" <pjb@...> writes:
>
>> I've not  checked SBCL on  MacOSX yet (does  it compile to  PPC?), but
>> emacs and  ilisp work perfectly fine  on emacs. You can  use a vanilla
>> gnuemacs with X  on MacOSX, or a gnuemacs with Aqua  if you rather not
>> install X.
>
> Do you run Emacs on Darwin (MacOSX 10.3)?  I have just downloaded the 
> 21.3
> sources which complain that Emacs has not yet been ported to PPC/Darwin
> (but the sources are from March 2003, so things may have changed in 
> CVS).
>
> Nicolas.

http://members.shaw.ca/akochoi-emacs/stories/obtaining-and-building.html

--
Brian Mastenbrook
bmastenb@...
http://cs.indiana.edu/~bmastenb/

Nicolas Neuss writes:
> "Pascal J.Bourguignon" <pjb@...> writes:
> 
> > I've not  checked SBCL on  MacOSX yet (does  it compile to  PPC?), but
> > emacs and  ilisp work perfectly fine  on emacs. You can  use a vanilla
> > gnuemacs with X  on MacOSX, or a gnuemacs with Aqua  if you rather not
> > install X.
> 
> Do you run Emacs on Darwin (MacOSX 10.3)?  I have just downloaded the 21.3
> sources which complain that Emacs has not yet been ported to PPC/Darwin
> (but the sources are from March 2003, so things may have changed in CVS).
> 
> Nicolas.

I'm running 10.2.8.

I've compiled 21.3.50.2 out of the box for aqua.
And I've also the emacs that comes with fink, 21.2-25, for terminal and X.


-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

Pascal J.Bourguignon <pjb@...> writes:

> * (lisp-implementation-version)
> "0.pre8.104"

Wow, that's old :-) 

> * (eval-when (:compile-toplevel)
>   (format t "~S~%" (logical-pathname-translations "PACKAGE"))
>   (with-open-file  (file "PACKAGE:COM;INFORMATIMAGO;COMMON-LISP;HTML401.LISP"
>                          :direction :input)
>     (with-open-file (out "test.out" :direction :output
>                          :if-does-not-exist :create
>                          :if-exists :supersede)
>       (format out "~S~%" (read file nil nil)))))

You are aware, are you not, that this form is defined to do nothing
and return NIL when evaluated by the interactor?

> unhandled condition (of type SIMPLE-ERROR):
>   Pathname components from SOURCE and FROM args to TRANSLATE-PATHNAME
> did not match:
>   :NEWEST NIL

Yeah, this is a problem.  The good news is that Paul Dietz has
finished (or maybe "given up" is a better phrase) testing
implementations' pathname compliance with the ANSI specification, so
there's a little more of a safety net when it comes to making pathname
modifications.

What I would like to see, I think, is a pathname implementation that
is almost completely version-agnostic.  Certainly, :newest and nil
versions ought to match, but I think probably also numbered versions
should be canonicalized to one or the other as soon as possible, since
supporting them is otherwise ludicrous on a Unix or Windows base.  The
possibility of losing versions when interfacing with filesystems such
as reiser4 or clearcase does not bother me overmuch, since it's
unlikely that purely-integral versions will map to these things
anyway.

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

Pascal J.Bourguignon <pjb@...> writes:

> (DEFINE-CONDITION DATA-ERROR (ERROR)
>     :DOCUMENTATION "The variable name that contains a bad value.")
>   (:DOCUMENTATION "A condition occuring when bad input data is detected.")

This causes no problems with current CVS, or indeed the latest
released version of SBCL.

> (I'd have  tested it with the CVS  head, but the test  suite gives the
> following error on the current CVS head:
> Top 10 dynamic instance types:
> unhandled condition (of type SB-INT:BUG):
>     failed AVER: "(SAP= CURRENT END)"

I don't see this, but here it's possible that your CVS HEAD isn't the
same as my CVS HEAD, thanks to SourceForge's slightly odd way of
managing access to source.  I would guess that this version is one of
the ones affected by the GCish problems of a week or so ago.

In general, though, it's somewhat hard to guess what the problem is
(in either of your two bug reports) without even the crutch of a
version number.  (lisp-implementation-version) is intended to provide
a sufficiently fine-grained distinction that developers, or indeed
anyone with access to the CVS history, can work out what changes could
have caused the general problems observed; without it, one has to fall
back on deduction and ESP in equal measure to divine what the issues
involved are -- and these are, sadly, more fallible than knowledge.

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

Christophe Rhodes writes:
 > Lennart Staflin <lenst@...> writes:
 > 
 > > With the help of #lisp on irc, I tracked it to a call to
 > > sb!unix::receive-pending-interrupt, that was recursing
 > > indefinitely. It seems that a VOP definition is missing for PPC. There
 > > is a define-vop for do-pending-interrupt, it seems the name was
 > > changed, but not in all backends. I changed the name in
 > > ppc/system.lisp and rebuild sbcl. 
 > 
 > I've committed this fix for the PPC in sbcl-0.8.7.10, because it's
 > clearly what was intended.
 > 
 > > After that run-program no longer
 > > hangs, but occasionally it signals an error:
 > >
 > > * (time (run-program "/bin/sh" '("ls")) )
 > > debugger invoked on a SIMPLE-ERROR in thread 6058: breakpoint/trap at
 > > #X22A7720
 > 
 > On the only MacOS machine I have access to, I can't reproduce this;
 > Brian Mastenbrook suggests that this might be because it's a dual
 > processor machine.

        I did this on my 867 MHz PB12, and saw this behaviour when I
tried to build the contrib stuff. I have some other local
modifications, though, taken from Brian Mastenbrook's web page (the
one with the instructions for building SBCL under Panther and on G5s).

        It seemed that I got a breakpoint every time run-program was
called from make-target-contrib (3 times?)

        I also tried provoking this by calling run-program from the
REPL, and eventually managed to wedge SBCL (the test was something
like "echo hello, world").

Raymond Wiker <Raymond.Wiker@...> writes:

> Christophe Rhodes writes:
>  > On the only MacOS machine I have access to, I can't reproduce this;
>  > Brian Mastenbrook suggests that this might be because it's a dual
>  > processor machine.
>
>         I did this on my 867 MHz PB12, and saw this behaviour when I
> tried to build the contrib stuff. I have some other local
> modifications, though, taken from Brian Mastenbrook's web page (the
> one with the instructions for building SBCL under Panther and on G5s).
>
>         It seemed that I got a breakpoint every time run-program was
> called from make-target-contrib (3 times?)
>
>         I also tried provoking this by calling run-program from the
> REPL, and eventually managed to wedge SBCL (the test was something
> like "echo hello, world").

Well, with the new, more correct RECEIVE-PENDING-INTERRUPT
implementation, what *should* be happening is that the system should
indeed get a SIGTRAP, get into sigtrap_handler (in
src/runtime/ppc-arch.c), and execute the trap_PendingInterrupt case in
the switch statement: move the PC forward over the current
instruction, handle the pending interrupt, and resume execution.

What's actually happening, I don't know.  gdb is the enemy of your
enemy, I'm afraid.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

Edi Weitz <edi@...> writes:

> [test for the presence of a particular bug]
> I get 35 here. Is that good or bad?

Good.  Or bad, since this means that you have a different problem.
Sorry that this didn't help.

Wolfgang

Edi Weitz <edi@...> writes:

> On Sun, 4 Jan 2004 18:50:20 -0700, Kevin Rosenberg <kevin@...> wrote:
>
>> Edi Weitz wrote:
>>> the build process hangs forever and CPU usage (kernel) approaches
>>> 100%. Any idea what could be the cause?
>>
>> That occurred to me the one time I tried to build SBCL
>> 0.8.6.something on SuSE AMD64 Pro 9 using :sb-thread.
>>
>>> 2. Try building without thread support?
>>
>> I've successfully built many versions of SBCL on SuSE AMD64 Pro 9
>> without thread support.
>
> Yes, I can confirm that it builds without thread support. What could
> be the cause? Is this related to the SIGRTMIN problem?
>
> Of course, I'd like to have thread support... :(

This just happened to me, too :-/

Are you running a 2.6.x kernel, or a kernel otherwise with NPTL (the
new Posix threads implementation)?  If so, try adding :sb-futex as
well as :sb-thread to *features* (though no guarantees, I'm afraid).

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

On Wed, 07 Jan 2004 11:54:05 +0000, Christophe Rhodes <csr21@...> wrote:

> Edi Weitz <edi@...> writes:
>
>> Of course, I'd like to have thread support... :(
>
> This just happened to me, too :-/
>
> Are you running a 2.6.x kernel, or a kernel otherwise with NPTL (the
> new Posix threads implementation)?  If so, try adding :sb-futex as
> well as :sb-thread to *features* (though no guarantees, I'm afraid).

The kernel is 2.4.21 but maybe they've patched it. I have the files

  ./kernel/futex.c
  ./include/linux/futex.h

in /usr/src/linux - does that mean something?

I'll try and report to the list.

Thanks,
Edi.

On Wed, 07 Jan 2004 13:22:37 +0100, Edi Weitz <edi@...> wrote:

> I'll try and report to the list.

Unfortunately, it seems to hang at the same place:

  [building initial core file in "output/cold-sbcl.core":
  writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :READ-ONLY>
  writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :STATIC>
  writing 34848768 bytes [8508 pages] from #<SB!FASL::GSPACE :DYNAMIC>
  /(DESCRIPTOR-BITS INITIAL-FUN)=#XA3A4465
  done]
  * //testing for consistency of first and second GENESIS passes
  //header files match between first and second GENESIS -- good
  //entering make-target-2.sh
  //doing warm init
  This is SBCL 0.8.7, 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.

Edi Weitz <edi@...> writes:

> The kernel is 2.4.21 but maybe they've patched it. I have the files
>
>   ./kernel/futex.c
>   ./include/linux/futex.h
>
> in /usr/src/linux - does that mean something?

Hed Rat ships 2.4 kernels with NPTL patched in. If you're running an
RH system then you probably do have it.

-- 
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W                     Recursion 'R' Us
Anchorage, Alaska, USA, Earth            Y = \f.(\x.f(xx))(\x.f(xx))

On Wed, 07 Jan 2004 11:44:13 -0900, james@... (James A. Crippen) wrote:

> Edi Weitz <edi@...> writes:
>
>> The kernel is 2.4.21 but maybe they've patched it. I have the files
>>
>>   ./kernel/futex.c
>>   ./include/linux/futex.h
>>
>> in /usr/src/linux - does that mean something?
>
> Hed Rat ships 2.4 kernels with NPTL patched in. If you're running an
> RH system then you probably do have it.

No, as I mentioned a couple of mails ago this is SuSE 9.0.

Edi.