SBCL_HOME and site wide installation still needed to get correct scbl and core loaded.

229 views
Skip to first unread message

Phil Marneweck

unread,
Oct 14, 2009, 11:24:21 AM10/14/09
to cusp-dev...@googlegroups.com
Hi

I was writtng a blog on how to get eclipse 3.5 cusp and any sbcl with
its core running when I remembered that I still had the SBCL_HOME
environment variable.

So I just checked the loading of the core with out it and you still need
it to get the right core loaded.

Then I checked if the right sbcl was loaded if you unticked site wide
installation but that also does not work.

Gorsal are you still looking into those 2 issues? Do you need any moew
specifics?

Regards


Gorsal

unread,
Oct 14, 2009, 6:14:35 PM10/14/09
to Cusp Development
Sorry. I thought the issue of loading a specific sbcl with a specific
core was solved by clicking site wide implementation with the sbcl
path and the --core under the lisp executable arguments specified.
I'll look into this.

Gorsal

unread,
Oct 14, 2009, 9:12:18 PM10/14/09
to Cusp Development
Alright, so it works for me, see if it works for you. Its been
uploaded

Gorsal

unread,
Oct 14, 2009, 9:35:01 PM10/14/09
to Cusp Development
made some more small changes...

Gorsal

unread,
Oct 14, 2009, 10:05:32 PM10/14/09
to Cusp Development
K, so i fixed the Shared Library Path under lisp preferences. Its been
uploaded.
So heres the gig. Now you can have a centralized location for all of
your dlls instead of littering your Systems directory (or whatever)
with dlls.

So, this is my directory structure
C:/lisp/libs = libraries
C:/lisp/dlls = all library dlls
-C:/lisp/dlls/opengl/opengl32.dll
etc.

You can have up to two directories beneath your dll folder.

Just place C:/lisp/dlls/ under the Shared Library Path and cusp will
set the Path variable to each directory. This way, if you attempt to
load a dll which depends on another one,
the system will see where that required dll is. Without setting the
Path, this won't happen.

Phil Marneweck

unread,
Oct 17, 2009, 5:18:53 AM10/17/09
to cusp-dev...@googlegroups.com
No combination of settings works. I cant get sbcl started.

I am going to ask a stupid question. What is is the executable
environment setting for?


Dewd I know this is out of scope for you but could you put that step by
step idiots guide together on how to debug cusp. That way I could
actually help.

Here is some output, I can't even see what sbcl it tried to use if any.

phil@scatha:~/eclipse$ ./eclipse
start
!SESSION 2009-10-17 10:55:13.296
-----------------------------------------------
eclipse.buildId=I20090611-1540
java.version=1.6.0_16
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_ZA
Command-line arguments: -os linux -ws gtk -arch x86_64

!ENTRY org.eclipse.osgi 2 0 2009-10-17 10:55:23.757
!MESSAGE While loading class "jasko.tim.lisp.swank.LispNode", thread
"Thread[Secondary Swank Listener,6,main]" timed out waiting (5000ms) for
thread "Thread[main,6,main]" to finish starting bundle
"jasko.tim.lisp_1.0.414 [190]". To avoid deadlock, thread
"Thread[Secondary Swank Listener,6,main]" is proceeding but
"jasko.tim.lisp.swank.LispNode" may not be fully initialized.
!STACK 0
org.osgi.framework.BundleException: State change in progress for bundle
"reference:file:plugins/jasko.tim.lisp_1.0.414/" by thread "main".
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1073)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:278)
at
org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:408)
at
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211)
at
org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:376)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:452)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at jasko.tim.lisp.swank.SwankInterface
$DisplayListenerThread.run(SwankInterface.java:1995)
Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle
$BundleStatusException
... 14 more
Root exception:
org.eclipse.osgi.framework.internal.core.AbstractBundle
$BundleStatusException
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1073)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:278)
at
org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:408)
at
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211)
at
org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:376)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:452)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at jasko.tim.lisp.swank.SwankInterface
$DisplayListenerThread.run(SwankInterface.java:1995)
Display input pipe closed.
Display input pipe closed.
Display input pipe closed.


Gorsal

unread,
Oct 17, 2009, 11:42:13 AM10/17/09
to Cusp Development
Sorry, i should have done some instructions.
Alright, so first redownload the current-cusp. I'm not sure yet if you
downloaded it before i made some changes that fixed things. Also, it
now outputs some info.

Lisp Environment Arguments are path variables, like SBCL_HOME, that
you might need to set.
Here's what i have in lisp arguments, from top to bottom.

--core "C:\Program Files\Steel Bank Common Lisp\1.0.29\asdf\sbcl.core"
SBCL_HOME="C:\Program Files\Steel Bank Common Lisp\1.0.29\"
C:\Program Files\Steel Bank Common Lisp\1.0.29\sbcl.exe

Also, I have lisp type = sbcl selected. If SBCL_HOME is the parent
folder of the sbcl executable, then you don't need to specify it.
Else, you do
I really appreciate all of this, btw. I'm create a github location and
downloading the code right now. Once i'm done, i'll direct you to some
instructions on how to run and get the code.

Thanks! I really appreciate all of this, btw. I hope downloading these
zip files isn't tooo much of a hastle.

Gorsal

unread,
Oct 17, 2009, 1:31:15 PM10/17/09
to Cusp Development
I have posted instructions on
http://wiki.github.com/Eyaro/ejasko.tim.lisp
However, right now, it appears the public cloning isn't working,
perhaps a bug in egit? I've posted a question on this.

Gorsal

unread,
Oct 17, 2009, 1:59:41 PM10/17/09
to Cusp Development
Alright I have now finished the sections i'm going to add right now in
the wiki. Feedback is welcome!

Phil Marneweck

unread,
Oct 19, 2009, 4:56:54 AM10/19/09
to cusp-dev...@googlegroups.com
I can still not get sbcl loaded at all.

I am pretty sure that the patch 01 version is not using the specified
SBCL but the one in /usr/bin/. Look at the out put "Attempting to find
SBCL lispSBCLLisp". To be a hundred percent sure about this I need the
console output from sbcl that comes before and after the "fatal error
encountered in SBCL pid 30435(tid 140737353979632):". The bit before
will show the version of sbcl being loaded and the bit after will say if
it is a core miss match.

I suspect this is what we will see if you give the full output:
*****
This is SBCL 1.0.18.debian, 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.
fatal error encountered in SBCL pid 31583(tid 140687014491888):
can't load .core for different runtime, sorry

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>
*****

I am also pretty sure that it is applying the correct excecutable
arguments resulting in miss match between the sbcl version and the core
version.


Here is the complete output:


phil@scatha:~/eclipse$ ./eclipse
SiteWideImplementation: Searching for Implementation
Lisp Executable is /home/phil/lisp/clbuild/target/bin/sbcl
Attempting to find SBCL lispSBCLLisp
start
Setting Environment for Libraries
Setting Lisp Environment
Parsing Lisp Executable Arguments
Executable Arguments are
--core /home/phil/lisp/clbuild/target/lib/sbcl/sbcl.core
Starting Lisp
!SESSION 2009-10-19 10:30:06.115
-----------------------------------------------
eclipse.buildId=I20090611-1540
java.version=1.6.0_16
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_ZA
Command-line arguments: -os linux -ws gtk -arch x86_64

!ENTRY org.eclipse.osgi 2 0 2009-10-19 10:30:16.464
]fatal error encountered in SBCL pid 30435(tid 140737353979632):
*disconnect
Display input pipe closed.
Display input pipe closed.
Display input pipe closed.



Seth Burleigh

unread,
Oct 19, 2009, 11:14:17 AM10/19/09
to cusp-dev...@googlegroups.com
Oh, and you need to put in the right sbcl home path. If theh sbcl folder
contains an asdf folder, then you should do something like
SBCL_HOME="/home/phil/....". That should fix it. Cusp, by default if you
don't specify it, will assume the SBCL_HOME is
/home/phil/lisp/clbuild/target/bin/

Phil Marneweck

unread,
Oct 19, 2009, 9:56:21 AM10/19/09
to cusp-dev...@googlegroups.com
Ok thanx I got it working with
SBCL_HOME=/home/phil/lisp/clbuild/target/lib/sbcl/

But I still don't understand why I should have an environment variable
if the complete path to the sbcl executable is set and the --core has
the correct path to the core.

Gorsal

unread,
Oct 19, 2009, 10:05:31 AM10/19/09
to Cusp Development
The reason is that when you load swank it uses (require 'some-inbuilt-
library). If you look under your sbcl folder, you will see stuff like
asdf, sb-bsd-sockets, etc. Since swank doesn't like external
dependencies, it uses the ones that come with your lisp. All libraries
that are loaded using (require) must be located under SBCL_HOME. In
order to find the libraries, SBCL_HOME must be loaded. I'm not quite
sure why you were getting a fatal pid error, however, i certainly do
not i simply get an error. Perhaps on your platform sbcl_home is used
for something more? But whatever it is used for, it is most definitely
required for loading swank.
Reply all
Reply to author
Forward
0 new messages