alien.so / distributing a standalone SBCL app

Folks--

I've built an application I'd like to deploy on a server that doesn't
have SBCL installed.  To do this, I have a build script which loads
the code, saves an image, creates a tarball containing the image core,
the sbcl binary runtime, some config files and a bash script for
properly invoking sbcl to run the app.  (It's a command-line app.)

Thing is, the app uses sb-bsd-sockets.  Works really well when I run
it on my development machine where SBCL (.8.20) is installed.

HOWEVER, I get this error on the non-sbcl machine:

----

error: Could not open shared object #S(SB-ALIEN::SHARED-OBJECT
                                       :FILE
"/usr/local/lib/sbcl/sb-bsd-sockets/alien.so"
                                       :SAP NIL):
/usr/local/lib/sbcl/sb-bsd-sockets/alien.so: cannot open shared object
file: No such file or directory

----

Seems clear to me that the socket libs depend on a foreign lib.  In
other words, I understand the prob, here.  I tried including alien.so
with the distribution, and I tried setting SBCL_HOME to the directory
where I want my code to find the alien.so file, but no go.  The above
/usr/local path seems hard coded in.

Re: alien.so / distributing a standalone SBCL app

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."

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.

generic functions broken after deleting package?

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.  Let me demonstrate:

We have a file called /tmp/test.lisp:

    (defpackage :foockage
      (:use :cl)
      (:export #:test))

    (in-package :foockage)

    (defclass fooass ()
      ((flot :initarg :flot :reader flot)))

    (defun test ()
      (format t "We expect 3: ~A~%"
              (flot (make-instance 'fooass :flot 3))))

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):

    tim <at> beer:~$ sbcl
    This is SBCL 0.8.19.39, 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

Re: generic functions broken after deleting package?

On 06 Mar 2005 23:05:47 +0100, "Tim Daly Jr." <tim <at> tenkan.org> 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.

Re: generic functions broken after deleting package?

Antonio Martinez <antonio.martinez.shotton <at> gmail.com> writes:

> On 06 Mar 2005 23:05:47 +0100, "Tim Daly Jr." <tim <at> tenkan.org> 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

Re: generic functions broken after deleting package?

> 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

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: generic functions broken after deleting package?

tim <at> tenkan.org (Tim Daly Jr.) writes:

> 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.

This is caused by PCL believing it can identify functions from print
names of classes, which of course isn't true if the package system
changes underneath it.

>  Let me demonstrate:
>
> We have a file called /tmp/test.lisp:

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).

Index: src/pcl/compiler-support.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/pcl/compiler-support.lisp,v
retrieving revision 1.11
diff -u -r1.11 compiler-support.lisp
--- src/pcl/compiler-support.lisp	13 Jan 2005 10:12:19 -0000	1.11
+++ src/pcl/compiler-support.lisp	8 Mar 2005 10:46:11 -0000
 <at>  <at>  -85,6 +85,9  <at>  <at> 
 (define-internal-pcl-function-name-syntax sb-pcl::slow-method (list)

Re: generic functions broken after deleting package?

Christophe Rhodes <csr21 <at> cam.ac.uk> 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

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

fyi Computer Language Shootout

We show some SBCL programs at 
   http://127.0.0.1/benchmark.php?test=all&lang=sbcl&sort=fullcpu

Please contribute SBCL implementations if you have the time and skill.

best wishes, Isaac

	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: fyi Computer Language Shootout

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

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click