Steel Bank Common Lisp

> > * (require :asdf-install)
> >
> >   which seems to work, except on random occasions when it tells me :
> >
> > ; compilation unit aborted
> > ;   caught 1 fatal ERROR condition
> >
> >   and then repeats the prompt line ('* \n') until I hit Ctrl-c.=20
>
> Does this happen when you start SBCL directly from the binary, or from
a shortcut, or both?=20

It does it from the binary, and also in the Cygwin shell.


> This behaviour is a "known mystery" on my box at least, when starting
SBCL from a shortcut; a seeming workaround is to set the "Disable
Advanced Input Options" option in the shortcut properties.
>
> Does this workaround work for you?

Nope, sorry. My first try with this option on the raw .exe produced the
problem.
In fact, I manage to reproduce the bug at will: the only thing to do is
to launch sbcl.exe with the [Enter] key, not by a double-click. Isn't it
nice?


> SB-EXT:RUN-PROGRAM is still in need of more love for Windows,
unfortunately.

Is there something I could do? What kind of 'love' does it need?


> This seems very odd. The installer should create SBCL_HOME. Can you
please provide details of your installation procedure?

Sorry, my fault. I ran sbcl from cygwin and forgot to restart my shell
after installation, so the variable was not in the shell's environment.


And if I didn't say it already: thank you for the Windows port. At last
there's a free alternative to CLISP (and ABCL) on the platform. The
'free' (as in beer) ACL is far too limited in memory to be of any use.



Laurent.

This is a problem I've been having with 0.9.18 on OS X x86 and OS X  
PPC both.

I've been trying to get some of my code to go faster, and in that  
code, I make extensive (probably too extensive use!) of defgeneric.  
I'm trying to find out where that's causing me efficiency problems,  
which means that I'm SB-PROFILE:PROFILEing a bunch of generic functions.

The problem is that when I recompile a file where one of those  
functions is defined, I get an error saying:

"FOO already names an ordinary function or a macro.
	[Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]"

I'm guessing that SB-PROFILE somehow "replaces" the generic function  
with an ordinary one behind the scenes, but the error is sort of  
irritating me. Is there some way to get around it that doesn't  
require me to remember to (unprofile) before I compile every time?

Thanks,
Matt Pillsbury

Hi.

  I've just downloaded the installer for sbcl-0.9.18 on Windows, run it
and tried to play with it.

  I've done=20

* (require :asdf-install)

  which seems to work, except on random occasions when it tells me :

; compilation unit aborted
;   caught 1 fatal ERROR condition

  and then repeats the prompt line ('* \n') until I hit Ctrl-c.=20

Then I tried=20

* (asdf-install:install :cl-ppcre)

  which did not work because cliki was down or at least answering with
internal server errors (HTTP 500).

So I finally resorted to downloading cl-ppcre.tar.gz on a local disk and
do a

* (asdf-install:install "C:/tmp/download/cl-ppcre.tar.gz")

  asdf-install politely asks me where I want to install, to which I
answers politely also.
  It tells me that it is installing the package in the chosen location,
but then hangs.
  It seems that tar.exe (from my cygwin installation) is running but not
doing much (0% CPU). Maybe it's waiting from some input.

  Oh, I forgot to say that before the local file install, I tried the
HTTP install (directly from Edi Weitz's site for CL-PPCRE) and it hang
similarly, after having told me it had downloaded the file. The only
difference was that that time it was gpg that was doing nothing. My
command was:

* (asdf-install:install "http://weitz.de/files/cl-ppcre.tar.gz")


  BTW, I had to manually define the environment variable SBCL_HOME for
sbcl to find its core file. By default, it tried /usr/local/lib/sbcl,
which is not quite right.


  And thanks for this nice CL implementation and for the Windows port.


Laurent.