Steel Bank Common Lisp

On 27 Mar 2005, Xavier Maillard wrote:

I tried as Christophe said earlier:

  $ SBCL_HOME=`pwd`/contrib ./src/runtime/sbcl --core output/sbcl.core
  * (require :asdf)
  * (asdf:oos 'asdf:load-op :sb-bsd-sockets)

and here is the result:

,----
| >SBCL_HOME=`pwd`/contrib ./src/runtime/sbcl --core output/sbcl.core
| This is SBCL 0.8.21, 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.
| * (require :asdf)
| 
| ("ASDF")
| * (asdf:oos 'asdf:load-op :sb-bsd-sockets)
| 
| ; loading system definition from
| ; #P"/usr/ports/lang/sbcl/work/sbcl-0.8.21/contrib/systems/sb-bsd-sockets.asd"
| ; into #<PACKAGE "ASDF3915">
| ; registering #<SYSTEM SB-BSD-SOCKETS {489AAF81}> as SB-BSD-SOCKETS
| ; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {481519C9}> as SB-BSD-SOCKETS-TESTS
| STYLE-WARNING: Couldn't grovel for SO_NO_CHECK (unknown to the C compiler).
| NIL
| * 
`----

Is this the expected result ?
-- 
GNUSFR.ORG                       http://gnusfr.org/
EMACSFR.ORG                      http://emacsfr.org/
Xavier Maillard                  Tel: +33 6 68 04 64 37

On Mar 26, 2005, at 11:41 AM, Joshua N Pritikin wrote:

> When I try to compile KM 2-0-11,
>
> http://www.cs.utexas.edu/users/mfkb/RKF/km.html
>
> I hit the following problem:
>
> ; caught STYLE-WARNING:
> ;   defining *MULTIDEPTH-PATH-DEFAULT-SEARCHDEPTH* as a constant, even
> though the name follows
> ;   the usual naming convention (names like *FOO*) for special 
> variables
> ;
> ; compilation unit aborted
> ;   caught 1 fatal ERROR condition
> ;   caught 17 STYLE-WARNING conditions
> compilation aborted because of fatal error:
>   READ failure in COMPILE-FILE:
>     READER-ERROR at 23946 (line 622, column 5) on #<FILE-STREAM for
> "file \"/home/joshua/km/km-2-0-11.lisp\"" {9018169}>:
> no dispatch function defined for #\$
>
> ; /home/joshua/km/km-2-0-11.fasl written
> ; compilation finished in 0:00:20
> #P"/home/joshua/km/km-2-0-11.fasl"
> T
>
> Any clue whose fault this is and how to fix it?

Wow, that's a huge file. But right up at the top:

[1] *Note* you will need to load km.lisp first before compiling, so that
     the reader macro #$ is recognized by compile-file.

The maintainers of km clearly could fix this with appropriate use of 
EVAL-WHEN; they must not be aware of its existence. I suggest emailing 
them and suggesting that all code related to installing the dispatch 
macro characters be wrapped in (eval-when (:compile-toplevel 
:load-toplevel :execute) ...) so that it's available when simply doing 
compile-file.
--
Brian Mastenbrook
brian@...
http://www.iscblog.info/

On Mar 26, 2005, at 3:13 PM, Brian Mastenbrook wrote:

>> Any clue whose fault this is and how to fix it?

Actually, on further review, this file has a number of problems with 
using behavior which is not specified by ANSI Common Lisp. In 
particular, there are multiple unprotected defconstant of values which 
are not always going to be EQL across multiple evaluations. Also, 
mapcan is used on a function which returns backquoted data, which leads 
to a very strange error when compiling xmlify-internal.

I'd suggest using SBCL to do a thorough vetting of this file to 
determine what it's doing that isn't mandated by ANSI. Treat errors as 
problems in the file first and only after all options are exhausted, 
email us.

And why is this a single huge file? the authors need to learn how to 
package code and use defsystem.
--
Brian Mastenbrook
brian@...
http://www.iscblog.info/

On Sat, 2005-03-26 at 15:13 -0600, Brian Mastenbrook wrote:=20
> On Mar 26, 2005, at 11:41 AM, Joshua N Pritikin wrote:
> > Any clue whose fault this is and how to fix it?
>=20
> The maintainers of km clearly could fix this with appropriate use of=20
> EVAL-WHEN; they must not be aware of its existence.

Thanks for the hint.  I'll pass it on.

yOn Tue, 22 Mar 2005, Rajat Datta wrote:

> (defun isieve (num)
> (let ((vec (make-array num :initial-element 0))
>       (acc 0))
>   (do ((i 2 (+ i 1)))
>       ((>= i num) 'done)
>     (when (= (svref vec i) 0)
>       (do ((j (* i i) (+ j i)))
>           ((>= j num) 'done)
> ;          (format t "debug********* i ~A j ~A~%" i j)
>         (setf (svref vec j) 1))
>       (incf acc)))
>   (format t "# of primes less than ~A is ~A~%" num acc)))
>
> breaks with (isieve 46349). With the debug format statement on, I see

This works fine for me on both ppc/darwin and x86/freebsd. Does this fail 
for you with a clean sbcl, started with

  sbcl --userinit /dev/null --sysinit /dev/null

?

Cheers,

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

Yes.   The console log of my session follows at the end.  I am running on
Slackware 10.1 on a pentium 4 system .

Interesting.  I just re-installed the binary distribution of 0.8.19 for 
Linux x86,
and am getting exactly the same problem.

Rajat Datta

-----------------------------------------------------------------------------------------------------------------------
sbcl --userinit /dev/null --sysinit /dev/null
This is SBCL 0.8.20, 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.
* (compile-file "./iprime.lisp")

; compiling file "/home/rajat/learn/languages/common-lisp/iprime.lisp" 
(written 22 MAR 2005 08:34:14 PM):
; compiling (DEFUN ISIEVE ...)

; /home/rajat/learn/languages/common-lisp/./iprime.fasl written
; compilation finished in 0:00:00
#P"/home/rajat/learn/languages/common-lisp/iprime.fasl"
NIL
NIL
* (load *)

T
* (isieve 46350)

debugger invoked on a SIMPLE-TYPE-ERROR in thread 6395:
  invalid array index 2148229801 for #(0 0 0 0 1 0 1 0 1 1 1 0
                                       ...) (should be nonnegative and 
<46350)

You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT   ] Reduce debugger level (leaving debugger, returning to 
toplevel).
  1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
(ISIEVE 46350)
0] 0

* (quit)

-----------------------------------------------------------------------------------------------------------------------


Nikodemus Siivola wrote:

> yOn Tue, 22 Mar 2005, Rajat Datta wrote:
>
>> (defun isieve (num)
>> (let ((vec (make-array num :initial-element 0))
>>       (acc 0))
>>   (do ((i 2 (+ i 1)))
>>       ((>= i num) 'done)
>>     (when (= (svref vec i) 0)
>>       (do ((j (* i i) (+ j i)))
>>           ((>= j num) 'done)
>> ;          (format t "debug********* i ~A j ~A~%" i j)
>>         (setf (svref vec j) 1))
>>       (incf acc)))
>>   (format t "# of primes less than ~A is ~A~%" num acc)))
>>
>> breaks with (isieve 46349). With the debug format statement on, I see
>
>
> This works fine for me on both ppc/darwin and x86/freebsd. Does this 
> fail for you with a clean sbcl, started with
>
>  sbcl --userinit /dev/null --sysinit /dev/null
>
> ?
>
> Cheers,
>
>  -- Nikodemus              Schemer: "Buddha is small, clean, and 
> serious."
>                   Lispnik: "Buddha is big, has hairy armpits, and 
> laughs."
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: 2005 Windows Mobile Application 
> Contest
> Submit applications for Windows Mobile(tm)-based Pocket PCs or 
> Smartphones
> for the chance to win $25,000 and application distribution. Enter 
> today at
> http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

Thank you, the patch fixed the problem.

A newbie question about applying such a patch.  I've placed the patch 
file in ~/.sbcl/patches
and then loaded it from my .sbclrc file.  Obviously this has a 
(marginal) impact on startup time.
Do folks generate a core file with patches included or patch the source 
and rebuild sbcl?

Rajat Datta

Alexey Dejneka wrote:

>Hello,
>
>
>  
>
>Thank you for the report. Use the attached patch.
>
>  
>

Xavier Maillard <zedek@...> writes:

> ,----
> | ; compilation finished in 0:00:03
> | * true
> | gmake: Leaving directory `/usr/ports/lang/sbcl/work/sbcl-0.8.20/contrib/sb-sprof'
> |        77.21 real        60.94 user         2.19 sys
> |   sb-bsd-sockets
> `----
>
> It seems SB-BSD-SOCKETS contributed module won't compile.
>
> How can I fix that ?

In this answer, I am assuming that the stuff in /usr/ports/lang/sbcl
is a completely unmodified sbcl-0.8.20 tree.  If it isn't, you need to
take this up with the port maintainer.

Either the sb-bsd-sockets is failing to build, or it is failing to
pass its own tests.  You need to investigate which of these is the
problem, and fix it.

Try doing, from the sbcl directory,
  $ SBCL_HOME=`pwd`/contrib ./src/runtime/sbcl --core output/sbcl.core
  * (require :asdf)
  * (asdf:oos 'asdf:load-op :sb-bsd-sockets)

If that succeeds, then the system can be built; if it doesn't, then it
will have caused an error at some point, and that error should be
fixed.  If it has succeeded, then try

  * (asdf:oos 'asdf:test-op :sb-bsd-sockets)

and see which, if any, tests are failing.

Thanks,

Christophe

To whom it may concern:

I managed to figure a way to include the alien.so files I needed for
an sbcl app to be deployed on a system without sbcl (or the exact fasl
compatible sbcl) installed.

I don't think this is a general solution, but it Works For Me (tm). 
My app is a version of the ubiquitous "Planet" aggregation software
and is meant to be run as a command line utility with help from a
config file.

Example:

  planet.sh retrieve render --config=planet.config

The planet.sh file is a bash shell script which wraps an invocation to
the sbcl runtime and core file I include in the binary app bundle. 
The tarball looks something like:

  ./core/cl-planet.core
  ./core/usr/local/lib/sbcl/sb-bsd-sockets/alien.so
  ./core/usr/local/lib/sbcl/sb-posix/alien.so
  ./planet.sh
  ./planet.config
  ./planet-styles.css
  ./default-head.html

and so on.  As you'll see in this build script, I force the
*shared-objects* objects to use a relative path name (starting with
"./core"), which works as long as you invoke the script from within
the deployment directory.  Given that this isn't (yet) meant to be
deployed as an rpm or dep where I can count on absolute paths, this
works well enough for me.

The context for this technique is based on the helpful how-to at:

    http://www.niksula.cs.hut.fi/~tsiivola/log/3309245899.html

The following build.lisp is also at:

    http://paste.lisp.org/display/6607

Hope this helps at least someone!

Keith
----

;;;; -*- mode: lisp; syntax: common-lisp; -*-

(require 'asdf)
(require 'cl-planet)

(use-package :lib-planet)

(setf *invoke-debugger-hook*
      (lambda (condition hook)
        (declare (ignore hook))
        (format *error-output* "error: ~a~%" condition)
        (sb-ext:quit :unix-status 1 :recklessly-p t)))

(defun copy-file (source target-dir)
  (ensure-directories-exist target-dir)
  (sb-ext:run-program "/bin/cp" (list source target-dir)))

(defun save-aliens ()
  (let ((aliens sb-alien::*shared-objects*))
    (dolist (alien aliens)
      (let* ((source (sb-alien::shared-object-file alien))
	     (target (concatenate 'string "./core" source)))
	(copy-file source target)
	(setf (sb-alien::shared-object-file alien) target)))))

(defun run ()
  (cl-planet:planet-main (cdr sb-ext:*posix-argv*)))

(progn
  (save-aliens)
  (sb-ext:save-lisp-and-die "core/cl-planet.core" :toplevel #'run))




On Sat, 5 Mar 2005 10:44:11 +0200 (EET), Nikodemus Siivola
<tsiivola@...> wrote:
> On Fri, 4 Mar 2005, Keith Irwin wrote:
> 
> > SO, is there a solution to this OTHER than installing SBCL on the host
> > machine?  Could I, for instance, do something interesting just before
> > save-lisp-and-die to change that path?
> 
> Yes, though currently it involves some low-level hackamagick; I hope
> to "some day" provide a contrib module to do this bundling (unless
> someone else does it first), but not right now.
> 
> Approximately:
> 
>   Look at sb-alien::*shared-objects*; it's a list of
>   sb-alien::shared-object structures corresponding to the loaded shared
>   objects. You need to copy all of the .so-files pointed to by these into
>   your bundle, _and_ change the sb-alien::file slots of these
>   structures correspondingly (the value of the file slot should be the
>   unix-namestring of the pathname.) Don't touch the sap slot.
> 
>   If you're confused by this, looking at src/code/foreign-load.lisp in
>   the SBCL source tree may help.
> 
> Hope this helps,
> 
>   -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
>                    Lispnik: "Buddha is big, has hairy armpits, and laughs."
>

On 09 Mar 2005, at 14.10, Isaac Gouy wrote:
> We show some SBCL programs at
>    http://127.0.0.1/benchmark.php?test=all&lang=sbcl&sort=fullcpu
             ^^^^^^^^^

localhost, eh? =]

--
Denis Bueno
PGP: http://pgp.mit.edu:11371/pks/lookup?search=0xA1B51B4B&op=index
"Clothes make the man. Naked people have little or no influence on 
society." - Mark Twain

The original author of this thread unsubscribed from the mailing list,  
but, he replied to me with the correct URL:

http://shootout.alioth.debian.org/sandbox/benchmark.php? 
test=all&lang=sbcl&sort=fullcpu

On 09 Mar 2005, at 23.36, Denis Bueno wrote:

> On 09 Mar 2005, at 14.10, Isaac Gouy wrote:
>> We show some SBCL programs at
>>    http://127.0.0.1/benchmark.php?test=all&lang=sbcl&sort=fullcpu
>             ^^^^^^^^^
>
> localhost, eh? =]
--
Denis Bueno
PGP: http://pgp.mit.edu:11371/pks/lookup?search=0xA1B51B4B&op=index
My other car is a cdr.

On 06 Mar 2005 23:05:47 +0100, "Tim Daly Jr." <tim@...> wrote:
> 
> There's something I don't quite understand going on here.  When I
> delete a package and re-create it, generic functions seem to get
> screwed up.

I'm mostly clueless about the area you've hit, but I daresay someone
will jump on in if I get it /too/ wrong.

> Now we load it, run the test, delete the package :foockage, load it
> again, and the generic function FLOT will signal an error (please
> pardon the verbosity):

But you're /not/ doing this!  You're compiling it first:

>     * (load (compile-file "/tmp/test.lisp"))

If you /don't/ compile, but just load the file, you'll get the
behaviour you expect.
The compiler is substituting the make-instance call with a direct call
to the constructor, that is, without going through the class symbol
indirection.  This means that when the file is loaded the second time,
the constructor call returns an instance of #:FOOASS (i.e. the /first/
FOOASS symbol, now uninterned), /not/ the current FOOASS class.  Since
FLOT is defined for the second, but not the former, you get a no
applicable method error.

Declaring make-instance as notinline should get you the semantics you
want wrt delete-package interaction.

Hope this helps,

--Tony

Antonio Martinez <antonio.martinez.shotton@...> writes:

> On 06 Mar 2005 23:05:47 +0100, "Tim Daly Jr." <tim@...> wrote:
...
> > Now we load it, run the test, delete the package :foockage, load it
> > again, and the generic function FLOT will signal an error (please
> > pardon the verbosity):
> 
> But you're /not/ doing this!  You're compiling it first:
> 
> >     * (load (compile-file "/tmp/test.lisp"))
> 
> If you /don't/ compile, but just load the file, you'll get the
> behaviour you expect.

If I start a fresh lisp, load the fasl, delete the package, load the
fasl again, and run the test, I get the same error.  If I remove the
fasl, start a fresh lisp, and just load from source both times, I also
get the same error.  So I don't think that explicitly calling
COMPILE-FILE matters.

> The compiler is substituting the make-instance call with a direct call
> to the constructor, that is, without going through the class symbol
> indirection.  This means that when the file is loaded the second time,
> the constructor call returns an instance of #:FOOASS (i.e. the /first/
> FOOASS symbol, now uninterned), /not/ the current FOOASS class.  Since
> FLOT is defined for the second, but not the former, you get a no
> applicable method error.
> 
> Declaring make-instance as notinline should get you the semantics you
> want wrt delete-package interaction.

Issuing a (declaim (notinline make-instance)) before compiling does
indeed work around the problem.  Thanks.

-- 
-Tim

> If I start a fresh lisp, load the fasl, delete the package, load the
> fasl again, and run the test, I get the same error.  If I remove the
> fasl, start a fresh lisp, and just load from source both times, I also
> get the same error.  So I don't think that explicitly calling
> COMPILE-FILE matters.

Yes, the problem isn't in the call to compile-file, but in the
"loading compiled code after deleting the package".  Since SBCL
compiles when loading source, even loading the source instead of the
FASL triggers the no applicable method condition, but it wouldn't if
SBCL interpreted source files instead of compiling them on load, say.

> Issuing a (declaim (notinline make-instance)) before compiling does
> indeed work around the problem.

Just DECLAREing should be enough to make this interaction with
delete-package not cause pain, and lets the compiler go wild
everywhere else.

Cheers,

--Tony

Christophe Rhodes <csr21@...> writes:

> 
> Thanks for the test case.  Can you try the attached patch on whatever
> it was that prompted this in the first place, if you have a more
> extended problem?  (If it was just interactive redefinition, checking
> that the attached works for you would be good).
> 

Your patch fixes my test case, as well as what prompted it.  

Thank you!

-- 
-Tim