Thank you for answering,
Yes, I was quite offended by your message :-) and I can explain it by
the fact that you said - with also christophe Rhodes - that I couldn't
do it when, as I remember, I did it. This is one part of *why*; the
other part, more or less "hidden" is, as you can imagine, that I have
difficulties to imagine why it's so difficult to make several
simultaneous threads in sbcl when it was so easy in OpenMCL for years
and, at least in Python. Since last year I was believing that it was
possible (for ppc, x86 and/or x86-64) because I needed it for a
performance, I had the chance that linux kernel was moving from 2.4 to
2.6 just at time for the performance to make multithreading possible.
So, it was "hot" (because I also needed sockets in and out, ready in
sbcl at the same time with some patch). And, finally, more hiddenly, I
really like (love) LISP and I choosed SBCL to move myself to opensource
community... and had already question to myself about this strategy
(moving to sbcl) for music production.
About ppc, may be something is misunderstood about my version of sbcl
(as Christophe Rhodes mail suggests) : I actually do not use Mac OS
anyway (since it's not GNU). My powerpc mac is a Mac just from outside,
it's a debian (more or less ubuntu) inside (2.6.17-11 actually), as my
And I remember having doing multiprocesses on both (and some other Sun
servers on a cluster) since april 2006 (sbcl 0.9.11), with sb-thread
(and sockets) enabled, and using bordeaux-mp package with fresh kernel
2.6. If there is no doubt at all about x86 and x86-64 linux machines (I
used different processes for several (and simultaneous) UDP server and
processes - neuro - on each machine), I remember that I did it also on
my debian ppc since it's my laptop on which I use to write the code (and
then copy it to other machines...), so that I have many difficulties to
imagine that I didn't write on my linux-mac (and I remember it was hot !).
May be, as said Chirstophe Rhodes, that I had the impression that it was
when it was not, at the end, the code written and tested (with not so
bad performances) on my ppc was playing on x86 and x86-64... May be I
should have a look in the details if it's relevant.
So, it's late tonight, if you need more info about my experience on
linux ppc and x86-64 with threads, I should compile back to sbcl 0.9.11
and send you some output ? (but may be it's not a so good idea since ppc
is no more supported, since Apple moved to Intel there is no difference
? and no more multi-arch tests ?). And, ok, if I'm the last one, I'm
going to be an outsider I know... I apologize for the stress.
Anyway, I will study first the problem first for x86-64 with actual
sbcl, why files are missing... (I just installed binary version - 1.0.3
- for x86-64 and then make.sh from cvs), I'm afraid I won't do some
other tests before friday.
Juho Snellman a écrit :
> fred voisin <fred@...> writes:
>> So, even if I did run multi-threads on ppc and other arch a year ago,
>> may be using some "magic" way even if it was experimental or not
> If I understand correctly, you were offended by my message. I don't
> quite understand *why*, but it certainly was not my intent to do
> that. Sorry.
> As far as I know, SBCL/ppc has never had any kind of thread support.
> Absolutely none. Not even "experimental, this might not work
> correctly" support, but "none, won't even compile with :sb-thread
> enabled without major changes". So it honestly is a total mystery to
> me how it could've worked in sbcl 0.9.11. The results you posted
> certainly show just the kind of error I would expect to see when
> trying to compile SBCL with threads on an unsupported platform.
> It's up to you to provide sufficient details on how you made it work
> before. Otherwise I really can't help you. And I expect that neither
> can anyone else on this list.
>> (I did
>> a public music performance using this - in real-time), this doesn't
>> explain why I can not compile sbcl from actual cvs on ppc or x86-64 from
>> 0.9.17or18.xx or from sbcl 1.0 - for ppc - or sbcl 1.0.3 - for x86-64)
>> with OR without sb-thread enabled in customize-target-features.lisp...
>> (see output below when compiling on x86-64 without any
> True, it doesn't. But then again, you hadn't mentioned these x86-64
> problems before this message, so I hope that you can excuse my failure
> to explain them.
> Anyway, thanks for the report. Unfortunately I'm not seeing that
> problem, and some of those errors look very strange ("signal.h"
> missing?). What's the latest version that you know worked on that
> computer? Can you still successfully compile that same version?