Hi Cyrus, Thank you for your reply. I did manage to get cl-opengl running
satisfactorily with my own program and the glut examples with a single
thread build sbcl on darwin64. I did have numerous package build issues
where things didn't quite work right out of the box, but I was either able
to get around them or it turned out that the cl-opengl didn't actually need
the problematic packages.
The problems started when I started using a threaded build with sb-thread
feature turned in the custom build .lisp script when sbcl was compiled).
So, why do I need threads ? I'm building an interactive graphics
environment in cl-opengl to for computer vision research. The real beauty
of a lisp environment is to be able to be able to issue lisp commands or
function calls in the repl to change the state of your running program while
it's mainl-oop continues to run and accept user and window events. The only
OTHER way I can think of doing this is to write the environment in C/C++ and
call an embedded lisp interpreter from the main loop. this is a really
different kind of design - once in which the implementation is really done
in C++ with a foreign embedded language (like the way AutoCAD or EMAC
implements it). If I went this route, I'm not sure I would choose an
embeddable lisp though, it would probably be either scheme or lua - but
that's a different topic.
If I had additional time (iin addition to the deadline I set for myself to
write the actual system), I would be happy to chip in and help try to fix
all of this or at least be a good tester for the folks working on it, but if
I do that I will be spending all my time hacking sbcl and I won't get
anything done :-) (or maybe switch back to a linux system)..- but I do
understand and appreciate the complexity of getting all of this to work on
multiple platforms with the open source volunteers working on this. It's
pretty impressive to see what has been done already - I'm definitely not
On Sat, Jul 3, 2010 at 12:41 AM, Cyrus Harmon <ch-sbcl@...> wrote:
> Hi Kevin,
> I think there are a couple of issues here. First, threads have been around
> for a while on x86/darwin and, more recently, x86-64/darwin. There are still
> some nagging unresolved issues that show up under the various threads tests.
> The upshot seems to be that threads work reasonably well on darwin, but
> aren't as reliable as they are on linux, for which threads were originally
> built (using futexes, unavailable on darwin).
> As for the problems with cl-opengl, I think this is another issue. I made
> some efforts to try to get this to work not too long ago, but didn't come
> away happy. The first problem was that loading shared libraries was rather
> problematic due to the so-called darwin-dlshim. This has been resolved by
> removing the shim and using dlopen/dlsym.
> The second problem is that loading shared libraries seemed to cause a
> Trace/BPT exception when the dlopen call was coming from a thread other than
> the initial thread. I think I managed to get around this by linking the SBCL
> executable against -framework CoreFoundation.
> After those fixes, I was able top asdf:oos 'asdf:load-op cl-opengl, cl-glu
> and cl-glut, but I'm still unable to get a proper window up and running, I'd
> try using the 1.0.40 sources and build your own version with threads that is
> linked against -framework CoreFoundation.
> good luck,
> On Jul 2, 2010, at 2:56 PM, Kevin Smith wrote:
> > Are sb-threads on darwin intel platform still "experimental" I have
> 1.0.39 and I and experiencing weird hangup problems when running under
> slime. doesn't happen when built without threads and doesn't do it when
> running the program directly from the repl. I did try to build version
> 1.0.40, but unsuccessfully because the sb-posix contribution (whatever that
> is) didn't build and I needed to compile my packages.
> > I'd be interested in where I can find any tips on building a workable
> sbcl platform on the mac (intel) with cl-opengl and a gui library (cl-gtk2
> was suggested by another subscriber because it supports some things I'd like
> to do with a threaded system). I have bits and pieces working - but - man
> this is an uphill battle for me btw, I've tried other lisp systems (like
> closure cl) and actually ran into -MORE- problems (but a different set of
> them). maybe it's just me :-)
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first --
> > Sbcl-help mailing list
> > Sbcl-help@...
> > https://lists.sourceforge.net/lists/listinfo/sbcl-help