CMUCL has a large, fast, pre-compiled image, right?
SBCL has a self-compiling image with more built-ins, right?
Other than that, what are the deciding factors between deciding between
one and the other?
Jonathon
On 8 Jun 2005 21:51:52 -0700, <···········@bigfoot.com> wrote:
>
> CMUCL has a large, fast, pre-compiled image, right?
> SBCL has a self-compiling image with more built-ins, right?
Nope.
> Other than that, what are the deciding factors between deciding between
> one and the other?
Tons, but YMMV. The SBCL folkes will be along to speak up soon, but
they are missing callbacks, some part of MOP and some other stuff.
I prefer to look at it as CMUCL is the slow-paced member of the pair.
--
With sufficient thrust, pigs fly fine.
One main design goal of SBCL is a simplified build process. And
they've succeeded enormously: You can build SBCL from sources given a
C compiler and any reasonably standards compliant Lisp, whereas
building CMUCL from sources is not for the faint of heart.
In order to achieve this goal, however, they had to rip some bits out
of CMUCL. They're now in the process of adding some of them back.
SBCL runs on more architectures. CMUCL has better threading support.
SBCL comes with ASDF and various other handy utilities already
included. CMUCL is stable with a long interval between releases.
SBCL is not exactly unstable, but new releases occur monthly. There
will be lots of other little differences between the two, but until
you get to the point where those differences really count, there is
little reason to choose one over the other. It's very easy to switch
between them once you find a reason to do so. I run CMUCL at the
office and (mostly) SBCL at home, and I hardly notice which one I'm
in.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen wrote:
> CMUCL has better threading support.
Does it? CMUCL's threading is more stable, but SBCL uses native
threads, which is sometimes what you want. It's a tradeoff, and I don't
think it's safe to call one of them "better" for every purpose.
That said, for *most* purposes, I'd probably trust CMUCL's threading
more---but SBCL's threading hasn't given me any problems.
-Peter
From: Robert Uhl
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <m3psuve4ww.fsf@4dv.net>
"Peter Scott" <·········@gmail.com> writes:
>
> That said, for *most* purposes, I'd probably trust CMUCL's threading
> more---but SBCL's threading hasn't given me any problems.
FWIW I've recently had...issues with SBCL+sbthreads. I don't know if
it's my code, or one of the libraries I'm using, or SBCL itself,
though. My gut instinct is that it's my code, save for the fact that I
don't really do any thread-unsafe things (that I know of, of course).
I'll track it down eventually, but for the moment SBCL seizes up rather
frequently for me.
I'm still keen on it, though.
<#secure method=pgpmime mode=sign>
--
Robert Uhl <http://public.xdi.org/=ruhl>
Es is nicht gasagt das es besser wird wenn es anders wirt. Wenn es
aber besser werden soll muss es anders werden. --G. Ch. Lichtenberg
+ "Peter Scott" <·········@gmail.com>:
| Harald Hanche-Olsen wrote:
| > CMUCL has better threading support.
|
| Does it? CMUCL's threading is more stable, but SBCL uses native
| threads, which is sometimes what you want.
Well, my statement was probably coloured by the fact that I run on
FreeBSD, and AFAICT threading with SBCL on FreeBSD is nonexistent.
You might argue that CMUCL's threading, which at least does exist on
this platform, is superior. But obviously life is different on Linux.
To quote the SBCL threading page:
This requires x86 and Linux kernel 2.6 or systems with NPTL backports.
I am not sure how to parse this. Does "and" bind closer than "or"?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen wrote:
> Well, my statement was probably coloured by the fact that I run on
> FreeBSD, and AFAICT threading with SBCL on FreeBSD is nonexistent.
> You might argue that CMUCL's threading, which at least does exist on
> this platform, is superior. But obviously life is different on Linux.
Yes, that would explain it. :-)
> To quote the SBCL threading page:
>
> This requires x86 and Linux kernel 2.6 or systems with NPTL backports.
>
> I am not sure how to parse this. Does "and" bind closer than "or"?
I'm pretty sure it should be read like this: "This requires x86 AND
{Linux kernel 2.6 OR systems with NPTL backports.}"
Linux 2.6 has more advanced threading than 2.4, but some of that has
been backported to 2.4 for some reason.
-Peter
On 9 Jun 2005 12:48:26 -0700, <·········@gmail.com> wrote:
> Harald Hanche-Olsen wrote:
>
>> To quote the SBCL threading page:
>>
>> This requires x86 and Linux kernel 2.6 or systems with NPTL backports.
>>
>> I am not sure how to parse this. Does "and" bind closer than "or"?
>
> I'm pretty sure it should be read like this: "This requires x86 AND
> {Linux kernel 2.6 OR systems with NPTL backports.}"
Actually it's not NPTL but some kernel feature apparently. I had some
recent discussions with DanB (probably on SBCL mailing-list) where he
stated that the NPTL statement was used because someone felt that the
kernel option was obscure and NPTL meant that the kernel feature would
be present. I wanted the correct statement present on that webpage,
with a followup about NPTL, since NPTL causes other changes (in glibc
and others) and drops you thru a trapdoor into 2.6 kernels (at least
on Gentoo). Not a big issue nowdays, but 6 months ago....
--
With sufficient thrust, pigs fly fine.
From: James Graves
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <d8aa8b$kph$1@new7.xnet.com>
Peter Scott <·········@gmail.com> wrote:
>I'm pretty sure it should be read like this: "This requires x86 AND
>{Linux kernel 2.6 OR systems with NPTL backports.}"
>
>Linux 2.6 has more advanced threading than 2.4, but some of that has
>been backported to 2.4 for some reason.
Just to clarify slightly, Linux 2.6 has NPTL built in by default.
Various Linux distributions will include a port of NPTL to their custom
2.4 kernels.
James Graves
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + "Peter Scott" <·········@gmail.com>:
>
> | Harald Hanche-Olsen wrote:
> | > CMUCL has better threading support.
> |
> | Does it? CMUCL's threading is more stable, but SBCL uses native
> | threads, which is sometimes what you want.
>
> Well, my statement was probably coloured by the fact that I run on
> FreeBSD, and AFAICT threading with SBCL on FreeBSD is nonexistent.
> You might argue that CMUCL's threading, which at least does exist on
> this platform, is superior. But obviously life is different on Linux.
>
> To quote the SBCL threading page:
>
> This requires x86 and Linux kernel 2.6 or systems with NPTL backports.
>
Hi --
I run OpenBSD and Debian, but I try my best to avoid Linux, if I can.
There's a package of SBCL that runs on OpenBSD, but I haven't tried
to build the newest versions, since I'm so short on time.
Do you think this new development of SBCL will mean this will turn
out to be a Linux-only Common Lisp? Any hope for POSIX?
This would be unfortunate, as it represents a step away from
portability. If you can't port among Unixes, what can you port to?
I personally don't regard Linux as a good choice security-wise
(well, maybe I've raised my standards too high after OpenBSD, but C programming sucks and BSD people are better
at it than Linux hackers...)
Henry
Don't worry, SBCL isn't going to be Linux-only any time soon; there are
too many people using it on other platforms for that, and other ports
are in progress. SBCL runs on Linux, the three major BSDs, Mac OS X,
and Solaris. The threading support is still fairly young, and it
depends on some Linux features, but I don't see any reason why it would
be impossible to add CMUCL-style green threads as a portable option.
-Peter
Peter Scott wrote:
> Don't worry, SBCL isn't going to be Linux-only any time soon; there are
> too many people using it on other platforms for that, and other ports
> are in progress. SBCL runs on Linux, the three major BSDs, Mac OS X,
> and Solaris. The threading support is still fairly young, and it
> depends on some Linux features, but I don't see any reason why it would
> be impossible to add CMUCL-style green threads as a portable option.
What threading features are present on Linux NPTL and not on
pthreads (Mac OS, *BSD, probably Solaris)? I think using the most
widely used implementation as a base for threads would have been
best, but then I'm not too much into threads myself...
--
Don't let school interfere with your education. -- Mark Twain
In article <··············@individual.net>,
Ulrich Hobelmann <···········@web.de> wrote:
> What threading features are present on Linux NPTL and not on
> pthreads (Mac OS, *BSD, probably Solaris)? I think using the most
> widely used implementation as a base for threads would have been
> best, but then I'm not too much into threads myself...
http://www.sbcl.org/manual/Implementation--Linux-x86-.html
NPTL is an implementation of pthreads, as was the old LinuxThreads. One
reason SBCL rolled its own threads on top of Linux's clone() is because
the LinuxThreads implementation was so incredibly bad. Eventually SBCL
used one facet of the NPTL implementation (kernel futexes) to get
locking to work properly.
There's a branch (amd64-pthread-branch) that had partially-working
pthread-based SBCL threads. According to
http://ww.telent.net/diary/2005/3/#4.51904, Dan Barlow was able to do
everything but removing the use of raw futexes (as described above); all
of the pthread/POSIX replacements are defined as unmovable in the spec,
which kills GCability.
Since it appears that Dan is on indefinite hiatus from SBCL hacking, I
suspect volunteers to work on solving these problems would be welcome.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Brian Downing wrote:
> NPTL is an implementation of pthreads, as was the old LinuxThreads. One
> reason SBCL rolled its own threads on top of Linux's clone() is because
> the LinuxThreads implementation was so incredibly bad. Eventually SBCL
> used one facet of the NPTL implementation (kernel futexes) to get
> locking to work properly.
Ah, ok.
> There's a branch (amd64-pthread-branch) that had partially-working
> pthread-based SBCL threads. According to
> http://ww.telent.net/diary/2005/3/#4.51904, Dan Barlow was able to do
> everything but removing the use of raw futexes (as described above); all
> of the pthread/POSIX replacements are defined as unmovable in the spec,
> which kills GCability.
Hm, I wouldn't move/gc C stuff at all, just use finalization
techniques; that complicates GC, though.
> Since it appears that Dan is on indefinite hiatus from SBCL hacking, I
> suspect volunteers to work on solving these problems would be welcome.
I have neither time, not the thread skills, I'm afraid (not to
mention never having looked at SBCL source). What we need is some
company investing into Lisp, like Apple supports GCC... ;)
--
Don't let school interfere with your education. -- Mark Twain
On 09 Jun 2005 22:39:20 -0300, <·······@but.reply.to.newsgroup.org> wrote:
>
> I run OpenBSD and Debian, but I try my best to avoid Linux, if I can.
^ |
^ |
^ |
------------------------------------
?!
--
With sufficient thrust, pigs fly fine.
GP lisper <········@CloudDancer.com> writes:
> On 09 Jun 2005 22:39:20 -0300, <·······@but.reply.to.newsgroup.org> wrote:
>>
>> I run OpenBSD and Debian, but I try my best to avoid Linux, if I can.
> ^ |
> ^ |
> ^ |
> ------------------------------------
>
> ?!
assuming:
trying one's best to avoid something
<=> one can avoid ==> ! something
Then:
( ca ==> !d ) & o & d
<=> ( !ca | !d ) & o & d
<=> ( !ca | !d ) & o & d
<=> !ca & o & d | !d & o & d
<=> !ca & o & d | False
<=> !ca & o & d
So, it clearly means that he uses OpenBSD and Debian and he cannot avoid it.
You know, this stuff of logic was not invented by your computer
science teachers to bug you in the exams. It was started a long long
time ago, by people living in Greece who had too much time on their
hand and who just spent it speaking, philosophing, and politicizing,
and they were so confused (as you are), that they came with this
science of the speach, the logo, and they called it the logic.
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
On Fri, 10 Jun 2005 05:08:23 +0200, <···@informatimago.com> wrote:
>
>
> GP lisper <········@CloudDancer.com> writes:
>
>> On 09 Jun 2005 22:39:20 -0300, <·······@but.reply.to.newsgroup.org> wrote:
>>>
>>> I run OpenBSD and Debian, but I try my best to avoid Linux, if I can.
>> ^ |
>> ^ |
>> ^ |
>> ------------------------------------
>>
>> ?!
>
> assuming:
>
> trying one's best to avoid something
><=> one can avoid ==> ! something
>
> So, it clearly means that he uses OpenBSD and Debian and he cannot avoid it.
Must be something missing in OpenBSD...and if you cannot avoid
something, it's smarter to enjoy it.
> You know, this stuff of logic was not invented by your computer
> science teachers to bug you in the exams. It was started a long long
> time ago, by people living in Greece who had too much time on their
They also have the first known examples of parody and irony.
--
With sufficient thrust, pigs fly fine.
Pascal Bourguignon wrote:
> GP lisper <········@CloudDancer.com> writes:
>
>
>>On 09 Jun 2005 22:39:20 -0300, <·······@but.reply.to.newsgroup.org> wrote:
>>
>>> I run OpenBSD and Debian, but I try my best to avoid Linux, if I can.
>>
>> ^ |
>> ^ |
>> ^ |
>> ------------------------------------
>>
>> ?!
>
>
> assuming:
>
> trying one's best to avoid something
> <=> one can avoid ==> ! something
>
> Then:
>
> ( ca ==> !d ) & o & d
> <=> ( !ca | !d ) & o & d
> <=> ( !ca | !d ) & o & d
> <=> !ca & o & d | !d & o & d
> <=> !ca & o & d | False
> <=> !ca & o & d
>
> So, it clearly means that he uses OpenBSD and Debian and he cannot avoid it.
>
> You know, this stuff of logic was not invented by your computer
> science teachers to bug you in the exams. It was started a long long
> time ago, by people living in Greece who had too much time on their
> hand and who just spent it speaking, philosophing, and politicizing,
> and they were so confused (as you are), that they came with this
> science of the speach, the logo, and they called it the logic.
>
Well, yeah. But where are they *now*? <g,d&r>
--ag
--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays
Artie Gold <·········@austin.rr.com> writes:
> Well, yeah. But where are they *now*? <g,d&r>
They first invaded culturally the romans. Then the whole Europe,
building the Greco-Romano-Judeo-Christian civilisation that we ended
naming the Occidental civilisation, and went on colonizing Africa,
North and South America, and today, they're still going abroad, in
such places as Afganistan or Irak to continue their civilizing and
democratizing labor.
--
__Pascal Bourguignon__ http://www.informatimago.com/
From: Joe Marshall
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <fyv5hxoj.fsf@comcast.net>
Pascal Bourguignon <···@informatimago.com> writes:
> You know, this stuff of logic was not invented by your computer
> science teachers to bug you in the exams. It was started a long long
> time ago, by people living in Greece who had too much time on their
> hand and who just spent it speaking, philosophing, and politicizing,
> and they were so confused (as you are), that they came with this
> science of the speach, the logo, and they called it the logic.
Heh, imagine if they had the Internet....
--
~jrm
Harald Hanche-Olsen wrote:
> One main design goal of SBCL is a simplified build process. And
> they've succeeded enormously: You can build SBCL from sources given a
> C compiler and any reasonably standards compliant Lisp, whereas
> building CMUCL from sources is not for the faint of heart.
>
> In order to achieve this goal, however, they had to rip some bits out
> of CMUCL. They're now in the process of adding some of them back.
>
> SBCL runs on more architectures. CMUCL has better threading support.
> SBCL comes with ASDF and various other handy utilities already
> included. CMUCL is stable with a long interval between releases.
> SBCL is not exactly unstable, but new releases occur monthly. There
> will be lots of other little differences between the two, but until
> you get to the point where those differences really count, there is
> little reason to choose one over the other. It's very easy to switch
> between them once you find a reason to do so. I run CMUCL at the
> office and (mostly) SBCL at home, and I hardly notice which one I'm
> in.
I suggest though that one peeks at the mailing lists of the libs they
foresee wanting to use. So for example, if you want TBNL (a handy
webapp framework), you may run into problems running tbnl-test with
SBCL at this moment.
(I can't access the mailing list right now, but I recall bivalent
streams were the issue, which I recall SBCL plans to include in its
upcoming 1.0 release.)
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> included. CMUCL is stable with a long interval between releases.
But the monthly CMUCL snapshots are sufficiently stable.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> SBCL runs on more architectures. CMUCL has better threading support.
Hi --
I would like to point out some differences in Unix-like OSs.
SBCL runs on OpenBSD (although a recent build hasn't been done),
FreeBSD and NetBSD (I think), as well as Linux distros. CMUCL does run on
FreeBSD, and Linux, but not on OpenBSD. NetBSD wrt CMUCL I don't
know, but IIRC, it doesn't.
This might influence your choice, as it will impact wether you can
run certain software (e.g., Cl-HTTP) or not.
Cheers.
Henry
> CMUCL has better threading support.
Not really, they've got completely different threading packages.
SBCL uses native, preemptively scheduled threads. This has some nice
consequences, such as allowing you to use blocking system calls
without having other threads block, and using multiple processors.
It's also very difficult to make reliable -- I'd be very surprised if
they were able to deal with simultaneous execution of multiple DEFCLASS.
CMUCL uses cooperatively scheduled user-space threads (sometimes known
as ``green'' threads). While this doesn't allow using multiple CPUs
and requires wrapping all blocking primitives, it can be made
reliable. Unfortunately, the current implementation is somewhat
inefficient -- which is not difficult to fix, but hasn't been done yet.
Juliusz
From: Christophe Rhodes
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <sqhdg2gf0j.fsf@cam.ac.uk>
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> SBCL uses native, preemptively scheduled threads. This has some nice
> consequences, such as allowing you to use blocking system calls
> without having other threads block, and using multiple processors.
> It's also very difficult to make reliable -- I'd be very surprised if
> they were able to deal with simultaneous execution of multiple DEFCLASS.
Well, I think this is dealt with by having a lock around the critical
sections of PCL, such that (effectively) only one thread executes the
interesting parts of DEFCLASS at once. (This is only a theoretical
rationalization; I haven't tested this, or even looked at the source
code to see what WITH-PCL-LOCK expands to. Complain if this actually
cramps your style :-).
If I'm right about the locking, this is probably a reasonable tradeoff
because I wouldn't expect class creation at runtime to be an important
time-critical part of an application. Again, if there are real-world
use-cases of this, it's worth knowing.
Christophe
>> SBCL uses native, preemptively scheduled threads. This has some nice
>> consequences, such as allowing you to use blocking system calls
>> without having other threads block, and using multiple processors.
>> It's also very difficult to make reliable -- I'd be very surprised if
>> they were able to deal with simultaneous execution of multiple DEFCLASS.
> Well, I think this is dealt with by having a lock around the critical
> sections of PCL, such that (effectively) only one thread executes the
> interesting parts of DEFCLASS at once.
Sorry, my example was badly chosen. How do you deal with funcalling a
generic function at the same time as you change the class hierarchy?
Taking a lock on every generic dispatch would be prohibitively expensive.
I'm not claiming here that SBCL does any of the above incorrectly;
what I'm saying is that a Lisp image is a large, complex, shared data
structure, and that implementing preemptively scheduled Lisp threads
is difficult if not impossible. My claim is therefore that cooperative
threads are in principle preferable for Lisp.
Oh, and before you read too much into the above: CMUCL's threads are
very nice in principle, but they are not ready for prime time yet. (I
volunteered to complete the implementation once, but then other things
came up.)
Juliusz
On Tue, 14 Jun 2005 21:02:30 +0200, <···@pps.jussieu.fr> wrote:
>
> I'm not claiming here that SBCL does any of the above incorrectly;
> what I'm saying is that a Lisp image is a large, complex, shared data
> structure, and that implementing preemptively scheduled Lisp threads
> is difficult if not impossible. My claim is therefore that cooperative
> threads are in principle preferable for Lisp.
There is suppose to be a SCL, Scieneer Common Lisp that is suppose to
handle this problem (and like SBCL is apparently a CMUCL fork).
Anyone know if they are still alive?
I'd say history is probably against preemptive lisp threads. Are you
really going to claim that the current generation is far smarter than
the devs for the last 20 years? Chances are very good that doing
threads totally right will completely wipeout the gains possible in
preemptive threads, or someone would have beaten this problem some
time ago. With one of the initial SBCL crowd fading away, current
events are supporting this viewpoint. There are plenty of other
problems in CL that are solvable, and it would be better to spend time
on them before more creative developers are lost.
--
The LOOP construct is really neat, it's got a lot of knobs to turn!
Don't push the yellow one on the bottom.
From: Edi Weitz
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <uis0gr1an.fsf@agharta.de>
On Tue, 14 Jun 2005 15:29:11 -0700, GP lisper <········@CloudDancer.com> wrote:
> I'd say history is probably against preemptive lisp threads. Are
> you really going to claim that the current generation is far smarter
> than the devs for the last 20 years? Chances are very good that
> doing threads totally right will completely wipeout the gains
> possible in preemptive threads, or someone would have beaten this
> problem some time ago. With one of the initial SBCL crowd fading
> away, current events are supporting this viewpoint. There are
> plenty of other problems in CL that are solvable, and it would be
> better to spend time on them before more creative developers are
> lost.
There are at least two arguments in favor of preemptive threads that
come to mind:
1. Moore's Law will be history sooner or later. Instead, performance
gains will be achieved by other means which include hyperthreading
and multicores. See for example this interesting article:
<http://www.gotw.ca/publications/concurrency-ddj.htm>
This is a tendency Lispers shouldn't ignore.
2. As long as you're using FFI calls to external libraries (and many
of us have to do that for various reasons) one thread calling out
to C can potentially block all others if you're using "green"
threads. Not so with OS threads.
Luckily, the Lisp vendors don't seem to agree with you. AllegroCL has
OS threads on Windows and maybe on other platforms, LispWorks has OS
threads on Windows and has announced them[1] for Linux, Corman Lisp
has OS threads on Windows, I think OpenMCL has OS threads on OS X, and
you already mentioned SCL which offers native threads for Linux and
various Unix variants.
Cheers,
Edi.
[1] <ftp://ftp.lispworks.com/pub/software_tools/downloads/Amsterdam2005/LW.pdf>
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Wed, 15 Jun 2005 01:01:04 +0200, <········@agharta.de> wrote:
>
> There are at least two arguments in favor of preemptive threads that
> come to mind:
>
> 1. Moore's Law will be history sooner or later.
Huh? The introduction of new technology will not change this at all.
Once a breakthru really exists, it will be exploited in the same
fashion.
> Luckily, the Lisp vendors don't seem to agree with you. AllegroCL has
> OS threads on Windows and maybe on other platforms, LispWorks has OS
Windows?? Try doing something else while formatting a floppy disk.
Windows has never show the same ability to run multiple processes as
even DesqView had decades ago (but it always has people making claims
for it). As for the vendors, they Don't Have A Choice, they follow
the same "threading" as anyone that uses Windows, and get all the same
drawbacks.
> 2. As long as you're using FFI calls to external libraries (and many
> of us have to do that for various reasons) one thread calling out
> to C can potentially block all others if you're using "green"
> threads. Not so with OS threads.
Windows does _not_ have complete OS threads, based on this measure.
Hey, I'm not happy over the thread situation, just pragmatic. I'd
like to believe that "someday will come". In the meantime, I'd like
to get some other stuff working.
--
The LOOP construct is really neat, it's got a lot of knobs to turn!
Don't push the yellow one on the bottom.
From: Edi Weitz
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <uslzkcads.fsf@agharta.de>
On Tue, 14 Jun 2005 17:46:57 -0700, GP lisper <········@CloudDancer.com> wrote:
> Huh? The introduction of new technology will not change this at
> all. Once a breakthru really exists, it will be exploited in the
> same fashion.
That was exactly my argument. Yours was to avoid certain
technological advances because the current generation of Lisp hackers
is not smarter than earlier ones or somesuch.
> Windows?? Try doing something else while formatting a floppy disk.
> Windows has never show the same ability to run multiple processes
>
> [...]
>
> Windows does _not_ have complete OS threads, based on this measure.
Could you explain this claim in more detail or is this just another
anti-Windows rant?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Tue, 14 Jun 2005 17:46:57 -0700, GP lisper <········@CloudDancer.com> wrote:
> > Windows?? Try doing something else while formatting a floppy disk.
> > Windows has never show the same ability to run multiple processes
> >
> > [...]
> >
> > Windows does _not_ have complete OS threads, based on this measure.
>
> Could you explain this claim in more detail or is this just another
> anti-Windows rant?
>
> Cheers,
> Edi.
Last time I tried running "realtime" priority threads in Windows, their
scheduling was disrupted simply by scrolling a web-browser window. I
don't think this or the floppy example indicate a lack of "complete OS
threads"- whatever they are- but it does indicate too many mutexes and
critical sections down in the OS that reduce concurrency. It also has
the side effect of fundamentally limiting the useful scalability into
larger multi-cpu systems.
Gregm
From: Edi Weitz
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <u1x73iyl4.fsf@agharta.de>
On 15 Jun 2005 08:06:36 -0400, Greg Menke <············@toadmail.com> wrote:
> Last time I tried running "realtime" priority threads in Windows,
> their scheduling was disrupted simply by scrolling a web-browser
> window.
Really? If I set the priority of one process to "realtime" (24) here
I can hardly do anything else anymore.
> I don't think this or the floppy example indicate a lack of
> "complete OS threads"- whatever they are- but it does indicate too
> many mutexes and critical sections down in the OS that reduce
> concurrency. It also has the side effect of fundamentally limiting
> the useful scalability into larger multi-cpu systems.
I'm certainly not an expert in this area but it looks as if the
visible GUI tasks are somehow prioritized in order to increase the
/perceived/ responsiveness of the OS. From what I've read my layman
understanding is that the changes in the Linux scheduler from 2.4 to
2.6 are based on the same goals.
Anyway, I'm not trying to defend Windows. My point just was that I
see no reason why one should avoid OS threads in Lisp.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On 15 Jun 2005 08:06:36 -0400, Greg Menke <············@toadmail.com> wrote:
>
> > Last time I tried running "realtime" priority threads in Windows,
> > their scheduling was disrupted simply by scrolling a web-browser
> > window.
>
> Really? If I set the priority of one process to "realtime" (24) here
> I can hardly do anything else anymore.
Yes- I had a realtime max priority thread servicing the control lines on
the pc's serial port, doing the signalling protocol to emulate an Atari
floppy drive, so I could copy my old Atari floppies off onto hard disk.
The thread worked fine until I scrolled a webpage, which distrupted the
scheduling timing enough to screw up the signalling protocol- which is
no especially fussy- the scheduling experienced by the thread was
probably bouncing around out to 50 to 100ms instead of 10 to 20 if I
interpret the protocol errors properly.
The whole point of realtime threads is to ensure well-defined latency,
which doesn't necesarily mean minimum- just a well-defined maximum.
When you switch a task to realtime the consequences are essentially
dependent on how much cpu time the task wants to use. If its programmed
to sleep, then things won't look much different except the task will
always wake up on time. OTOH, if the task just keeps on running,
expecting the OS to timeslice away from it to other work, then it will
just consume all the cpu- and worse, may end up jamming itself into a
race condition since the OS will never have the opportunity to clear
buffers and do housekeeping stuff.
My task slept at reasonable places so it never consumed the entire cpu.
However because of unrelated userspace activity, the scheduler failed to
deliver the maximum latency figure that the task class & priority
indicated.
> > I don't think this or the floppy example indicate a lack of
> > "complete OS threads"- whatever they are- but it does indicate too
> > many mutexes and critical sections down in the OS that reduce
> > concurrency. It also has the side effect of fundamentally limiting
> > the useful scalability into larger multi-cpu systems.
>
> I'm certainly not an expert in this area but it looks as if the
> visible GUI tasks are somehow prioritized in order to increase the
> /perceived/ responsiveness of the OS. From what I've read my layman
> understanding is that the changes in the Linux scheduler from 2.4 to
> 2.6 are based on the same goals.
Theres no reason why foreground "user" tasks shouldn't have elevated
priority- I do the same thing on my Sun box- using the fair-share
scheduler to give my user tasks a scheduling advantage over the rest of
the system, but not to the point of screwing up realtime scheduling.
The issue comes from kernel architecture which imposes
mutexes/semaphores/critical sections as kludges to prevent poor design
and implementation from blowing things up. Presumably the Windows
kernel has some critical sections that jam up the OS when IO is
occuring- since the floppy is so slow, they really interfere with the
rest of the OS. You can see similar behavior in some Windows versions
when doing filesystem work over the network. Linux. *bsd and Solaris
for instance don't share that particular design issue, so their floppy
IO doesn't bog down the the system.
> Anyway, I'm not trying to defend Windows. My point just was that I
> see no reason why one should avoid OS threads in Lisp.
>
Me either. OTOH app threading can be accomplished much more easily- and
its potentially lots easier to port. I think the big win of moving to
OS threads would be taking advantage of SMP.
Gregm
From: Edi Weitz
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <u64wfdi7n.fsf@agharta.de>
On Tue, 14 Jun 2005 17:46:57 -0700, GP lisper <········@CloudDancer.com> wrote:
> On Wed, 15 Jun 2005 01:01:04 +0200, <········@agharta.de> wrote:
>
>> 2. As long as you're using FFI calls to external libraries (and
>> many of us have to do that for various reasons) one thread calling
>> out to C can potentially block all others if you're using "green"
>> threads. Not so with OS threads.
>
> Windows does _not_ have complete OS threads, based on this measure.
So, just to make sure we're talking about the same thing, I've done
the following:
1. Create a simple database table (using SQLite which is easy to
install):
create table foo (bar integer);
2. Populate this table with 100,000 entries.
3. Use CLSQL to connect to this database.
4. Define a function FOO that uses the FFI to call out to C and takes
some time:
(defun foo ()
(clsql:execute-command "update foo set bar = bar + 1"))
Executing FOO takes approximately two seconds on my laptop.
5. Define a function BAR like this:
(defun bar ()
(loop with process = (mp:process-run-function "foo" nil 'foo)
for previous-time = nil then current-time
for current-time = (get-internal-real-time)
for diff = (and previous-time
(/ (- current-time previous-time)
internal-time-units-per-second))
while (mp:process-alive-p process)
when (and diff (> diff .1))
collect (float diff)))
Using LispWorks 4.4.5 (which has "green" threads on Linux and "native"
threads on Windows) I get results like
CL-USER> (bar)
(1.782)
on Linux and
CL-USER> (bar)
(0.13 0.13 0.13 0.151 0.13 0.13 0.13 0.131 0.13 0.2)
on Windows XP.
To me this looks like on Linux BAR's thread has to wait until FOO's
thread is done while on Windows it can carry on doing other things. I
certainly prefer the latter behaviour.
So, what exactly were you trying to say? I mean, I know Windows is
junk, Microsoft is evil, and all that, but what was you point
technically?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de>:
> There are at least two arguments in favor of preemptive threads that
> come to mind:
> 1. [...] performance gains will be achieved by [...] multicores.
> 2. [...] one thread calling out to C can potentially block all
> others if you're using "green" threads.
Good points, both of them. I'll start with (2).
First of all, C interfaces are evolving. They started off using
global data (gethostbyname), they've moved on to being thread-safe
(getaddrinfo), and they're moving towards being non-blocking and
asynch. As time passes, it will become possible to access basically
all C functionality from green threads.
But even with blocking C interfaces, this particular problem has been
solved for a long time. The abstraction that I'm most familiar with
is that of ``detaching'' a thread from the green scheduler so that it
becomes an OS-scheduled thread, and ``attaching'' a native thread to
the green scheduler. So invoking a C function becomes something like
detach
call out into C
attach
How do you implement this? Detaching is very simple -- you set up
(nonatomically) a closure to execute by the native thread, get
yourself a native thread (either by creating it or going through a
thread pool), and then atomically pass it the pointer to the closure.
Reattaching is no more difficult -- the native thread (atomically)
inserts a closure into the green scheduler's queue, and then commits
hara-kiri (or returns to the thread pool).
Of course, the thread must be careful not to execute any
non-thread-safe operations while it is native. But since
detaching/attaching is just a context switch triggered by a condition
variable (in the thread pool implementation), you can switch between
native and green fairly often -- on every I/O should be reasonable.
(locally
(declare advertising)
(google "Fair Threads"))
Now to your point (1): the same technique can be used for computationally
intensive code. But of course you must be able to structure your code
so that it cleanly separates computation from calls to non-thread-safe
code, which might not be possible for some applications.
In many cases, however, I believe that it might be more reasonable to
structure your application not as a set of threads communicating
through ``shared-by-default'' memory, but as a set of independent
processes communicating by other means, including of course explicitly
shared memory.
On a side note, I am actually very much excited by the forthcoming
cheap multicores. I am very much looking forward to seeing what kind
of new programming language constructs we're going to get as
multiprocessor machines find their way to the desks of people doing
research in programming languages (academics, for the most part).
Juliusz Chroboczek
From: Edi Weitz
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <uoea8ca89.fsf@agharta.de>
On Wed, 15 Jun 2005 05:25:34 +0200, Juliusz Chroboczek <···@pps.jussieu.fr> wrote:
> First of all, C interfaces are evolving. They started off using
> global data (gethostbyname), they've moved on to being thread-safe
> (getaddrinfo), and they're moving towards being non-blocking and
> asynch. As time passes, it will become possible to access basically
> all C functionality from green threads.
At the cost of more complexity on the calling side, I suppose. Or am
I missing something?
> But even with blocking C interfaces, this particular problem has
> been solved for a long time. The abstraction that I'm most familiar
> with is that of ``detaching'' a thread from the green scheduler so
> that it becomes an OS-scheduled thread, and ``attaching'' a native
> thread to the green scheduler. [...]
That's interesting but I suppose you're talking about implementation
details here. Or do you think the user should do it in his Lisp
programs?
Thanks,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
>> First of all, C interfaces are evolving. They started off using
>> global data (gethostbyname), they've moved on to being thread-safe
>> (getaddrinfo), and they're moving towards being non-blocking and
>> asynch.
> At the cost of more complexity on the calling side, I suppose.
Yes. Nothing prevents you from having convenient wrappers around
complex interfaces, of course.
>> The abstraction that I'm most familiar with is that of
>> ``detaching'' a thread from the green scheduler so that it becomes
>> an OS-scheduled thread, and ``attaching'' a native thread to the
>> green scheduler. [...]
> That's interesting but I suppose you're talking about implementation
> details here. Or do you think the user should do it in his Lisp
> programs?
Both could be available, I guess. I can imagine a FFI that allows the
user to specify whether the call happens in the Lisp scheduler's
context or whether it is done from a native thread.
(I think that the Glasgow Haskell FFI might work like that under
Windows, but I'd have to check.)
Juliusz
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <873brghhr4.fsf@qrnik.zagroda>
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> How do you implement this? Detaching is very simple -- you set up
> (nonatomically) a closure to execute by the native thread, get
> yourself a native thread (either by creating it or going through a
> thread pool), and then atomically pass it the pointer to the closure.
> Reattaching is no more difficult -- the native thread (atomically)
> inserts a closure into the green scheduler's queue, and then commits
> hara-kiri (or returns to the thread pool).
The design I mentioned is a bit different: instead of delegating the
work to another thread, we find another thread to access the runtime,
and we perform the work in the current thread. This allows to pass
data on the system stack, without having to pack them in a closure.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <877jgshi5v.fsf@qrnik.zagroda>
Edi Weitz <········@agharta.de> writes:
> 2. As long as you're using FFI calls to external libraries (and many
> of us have to do that for various reasons) one thread calling out
> to C can potentially block all others if you're using "green"
> threads. Not so with OS threads.
There is a smart design which allows to overcome that even if the
implementation uses mostly green threads:
Simon Marlow, Simon Peyton Jones, Wolfgang Thaller
"Extending the Haskell Foreign Function Interface with Concurrency"
http://research.microsoft.com/Users/simonpj/Papers/conc-ffi/
I implemented a similar scheme for my language Kogut.
A drawback is that entering and finishing such calls may introduce
extra context switches (only when more than one thread is running),
so it's bad when we don't know in advance whether it will take long
time or not, and we want to call it very often if not.
An ideal C API would provide a function which responds either "I was
able to obtain the result very quickly, here it is" or "this might
take a long time, please call another function and do your work in
other threads". For example Unix non-blocking I/O for pipes and
sockets has this property.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Christophe Rhodes
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <sqll5cf2jt.fsf@cam.ac.uk>
GP lisper <········@CloudDancer.com> writes:
> I'd say history is probably against preemptive lisp threads.
How brave. What about with fewer conditionals? (History is generally
against everything before it's achieved the first time.)
> Are you really going to claim that the current generation is far
> smarter than the devs for the last 20 years?
Far smarter? Probably not; empirically, it would seem that the range
of human intelligence is roughly constant. On the other hand, the
current generation has access to 20 more years of research results,
empirical studies, development reports and the like than the
generation of 20 years ago.
> Chances are very good that doing threads totally right will
> completely wipeout the gains possible in preemptive threads, or
> someone would have beaten this problem some time ago.
Is your only basis for this assertion the fact that no-one has
"beaten" this problem? Or do you have any non-circumstantial
evidence?
> With one of the initial SBCL crowd fading away, current events are
> supporting this viewpoint.
I worry about some people's habit to make assertions from ignorance.
Back when Daniel Barlow implemented threads for SBCL, in the first
half of 2003, there were four 'official' SBCL developers (where that's
defined as the ability to scribble over the master source repository),
and of the four, and indeed the wider SBCL community, he was the only
one thinking about threads and concurrency.
There are now eighteen people with commit access, including two or
three who use SBCL threads in production, and who are therefore
motivated to deal with at least those problems which affect them and
their work directly. That Daniel now has a full-time job rather than
a consultancy, and has reevaluated the relative merits of free Lisp
hacking and inline skating, bears little relevance to the technical
issues involved, or indeed the practical situation.
> There are plenty of other problems in CL that are solvable, and it
> would be better to spend time on them before more creative
> developers are lost.
By all means, please do; it would be a shame if creative developers
are dissuaded from doing things they want to do simply because some
person spent their time expressing their negativity on a public forum.
Christophe
Christophe Rhodes wrote:
> GP lisper <········@CloudDancer.com> writes:
>>Are you really going to claim that the current generation is far
>>smarter than the devs for the last 20 years?
>
>
> Far smarter? Probably not; empirically, it would seem that the range
> of human intelligence is roughly constant. On the other hand, the
> current generation has access to 20 more years of research results,
> empirical studies, development reports and the like than the
> generation of 20 years ago.
The current generation also has access to much faster hardware.
This has at least two effects: it's much faster to rebuild the system,
so you can play with new ideas more easily, and it's much faster to
test the system once you've built it. Don't dismiss the power of
brute force automated testing in exposing subtle bugs.
[/beating-own-drum]
Paul
Juliusz Chroboczek wrote:
>>>SBCL uses native, preemptively scheduled threads. This has some nice
>>>consequences, such as allowing you to use blocking system calls
>>>without having other threads block, and using multiple processors.
>>>It's also very difficult to make reliable -- I'd be very surprised if
>>>they were able to deal with simultaneous execution of multiple DEFCLASS.
>
>
>>Well, I think this is dealt with by having a lock around the critical
>>sections of PCL, such that (effectively) only one thread executes the
>>interesting parts of DEFCLASS at once.
>
> Sorry, my example was badly chosen. How do you deal with funcalling a
> generic function at the same time as you change the class hierarchy?
> Taking a lock on every generic dispatch would be prohibitively expensive.
By making the mutations atomic operations. If instead of mutating the
dispatching table in place, you create a copy and modify that copy, then
update the global pointer, there's no way for a reader to get caught in
the middle of an update.
-- MJF
From: Bruno Haible
Subject: Re: multithreading (was: CMUCL versus SBCL: big differences?)
Date:
Message-ID: <d8nfc5$nvd$1@laposte.ilog.fr>
Juliusz Chroboczek wrote:
> How do you deal with funcalling a
> generic function at the same time as you change the class hierarchy?
> Taking a lock on every generic dispatch would be prohibitively expensive.
This is an excellent example.
I imagine a good implementation would look up the effective method from
a hash table stored in the generic function, and then funcall this
effective method if one was found. In the frequently executed path,
the following indirections can be executed atomically:
- from the generic function to its hash table of effective methods,
- from this hash table to a particular hash table entry.
When the found effective method is NIL, then there is a need for locking
the entire CLOS and computing the effective method the lengthy way.
Note that this unveils some subtle points:
1) Before accessing a particular hash table entry, the dispatch code
usually needs to access the hash table's size. Therefore the code
which updates this hash table needs to be careful when resizing this
hash table.
2) In SMP systems, cache coherence between different CPUs are only
guaranteed through special instructions. Since these are missing
here on the fast path of a generic function call, it is possible
for one CPU to still use the old hash table's contents while
another CPU has already modified the contents on its side, while
installing a new effective method or while clearing the table.
Is this worrisome or not?
Bruno
Bruno Haible wrote:
> Juliusz Chroboczek wrote:
>
>>How do you deal with funcalling a
>>generic function at the same time as you change the class hierarchy?
>>Taking a lock on every generic dispatch would be prohibitively expensive.
>
>
> This is an excellent example.
Sounds like a good application for RCU (Read-Copy-Update).
Paul
GP lisper wrote:
> Tons, but YMMV. The SBCL folkes will be along to speak up soon, but
> they are missing callbacks, some part of MOP and some other stuff.
I noticed that several projects either don't have support for SBCL or
have more complicated workarounds to accomodate the callbacks.
> I prefer to look at it as CMUCL is the slow-paced member of the pair.
Even though it has callbacks and SBCL does not?
jonathon wrote:
> > I prefer to look at it as CMUCL is the slow-paced member of the pair.
>
> Even though it has callbacks and SBCL does not?
And SBCL has Unicode support and CMUCL does not. How is a single
feature a valid method of comparing the paces of development of CMUCL
and SBCL?
-Peter
Peter Scott wrote:
> jonathon wrote:
> > > I prefer to look at it as CMUCL is the slow-paced member of the pair.
> >
> > Even though it has callbacks and SBCL does not?
>
> And SBCL has Unicode support and CMUCL does not. How is a single
> feature a valid method of comparing the paces of development of CMUCL
> and SBCL?
Well, it's just that it seems to require more effort to get anything
needing callbacks (like GUI frameworks).
Yes, GUI stuff tends to be nasty with SBCL due to lack of callbacks. I
remember that there was some third-party package that added some kind
of callback support to SBCL, but presumably there are good reasons why
it doesn't quite work in current SBCL versions.
If you want GUI stuff in any Lisp without worrying about FFI issues,
here are three choices that should work:
1. McCLIM uses CLX and not much else (this doesn't apply to the Beagle
or Cairo backends). There are plenty of issues here, though, so I don't
know how much I can recommend it. I think it's worth getting just for
the Clouseau graphical object inspector, but I'm biased since I did a
lot of development work on it.
2. Ltk communicates with Wish using some kind of stream-based IPC. If
Tk is enough, Ltk is a good choice.
3. I haven't used gtk-server, but it looks like a decent choice for GTK
apps. Like Ltk, it uses stream-based IPC and doesn't require any FFI.
-Peter
On 10 Jun 2005 14:42:30 -0700, <·········@gmail.com> wrote:
>
> If you want GUI stuff in any Lisp without worrying about FFI issues,
> here are three choices that should work:
>
> 1. McCLIM uses CLX and not much else (this doesn't apply to the Beagle
> or Cairo backends). There are plenty of issues here, though, so I don't
> know how much I can recommend it. I think it's worth getting just for
> the Clouseau graphical object inspector, but I'm biased since I did a
> lot of development work on it.
Can you say how it differs from the graphical inspector built in to
CMUCL (part of the clm extra)?
cliki doesn't have a search term for "Clouseau", and
http://www.unmutual.info/images/Inspector.png looks rather similar to
the Motif Inspector (except motif has more dropdown options and works
off of mouse clicks, if that .png is current).
--
With sufficient thrust, pigs fly fine.
From: Christophe Rhodes
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <sqk6l18gkp.fsf@cam.ac.uk>
GP lisper <········@CloudDancer.com> writes:
> cliki doesn't have a search term for "Clouseau", and
> http://www.unmutual.info/images/Inspector.png looks rather similar
> to the Motif Inspector (except motif has more dropdown options and
> works off of mouse clicks, if that .png is current).
Why do you think you can guess what the interaction mode is from a
static image?
Christophe
On Sat, 11 Jun 2005 09:04:38 +0100, <·····@cam.ac.uk> wrote:
> GP lisper <········@CloudDancer.com> writes:
>
>> cliki doesn't have a search term for "Clouseau", and
>> http://www.unmutual.info/images/Inspector.png looks rather similar
>> to the Motif Inspector (except motif has more dropdown options and
>> works off of mouse clicks, if that .png is current).
>
> Why do you think you can guess what the interaction mode is from a
> static image?
The area at the bottom of the image is what then? Are those echoed
commands or typed commands?
--
With sufficient thrust, pigs fly fine.
From: Christophe Rhodes
Subject: Re: CMUCL versus SBCL: big differences?
Date:
Message-ID: <sqbr6d84e8.fsf@cam.ac.uk>
GP lisper <········@CloudDancer.com> writes:
> On Sat, 11 Jun 2005 09:04:38 +0100, <·····@cam.ac.uk> wrote:
>> GP lisper <········@CloudDancer.com> writes:
>>
>>> cliki doesn't have a search term for "Clouseau", and
>>> http://www.unmutual.info/images/Inspector.png looks rather similar
>>> to the Motif Inspector (except motif has more dropdown options and
>>> works off of mouse clicks, if that .png is current).
>>
>> Why do you think you can guess what the interaction mode is from a
>> static image?
>
> The area at the bottom of the image is what then?
An interactor pane.
> Are those echoed commands or typed commands?
They could be either. Essentially everything on that screenshot is
mousable, including the previously typed-or-echoed commands.
I ask again, why do you think you can guess what the interaction mode
is from a static image?
Christophe
GP lisper <········@CloudDancer.com> writes:
> cliki doesn't have a search term for "Clouseau", and
You may see:
McCLIM changes: Lisp inspector, default right-click menu
http://www.paoloamoroso.it/log/050130.html
McCLIM changes: cleaned up demos, more Lisps supported by inspector
http://www.paoloamoroso.it/log/050202.html
McCLIM Lisp inspector: from cool demo to useful tool
http://www.paoloamoroso.it/log/050311.html
McCLIM changes: inspection of integers/pathnames, fixed text copy/paste
[typo: Closure -> Clouseau]
http://www.paoloamoroso.it/log/050323.html
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
On Sat, 11 Jun 2005 11:50:07 +0200, <·······@mclink.it> wrote:
> GP lisper <········@CloudDancer.com> writes:
>
>> cliki doesn't have a search term for "Clouseau", and
>
> You may see:
>
> McCLIM changes: Lisp inspector, default right-click menu
> http://www.paoloamoroso.it/log/050130.html
>
> McCLIM changes: cleaned up demos, more Lisps supported by inspector
> http://www.paoloamoroso.it/log/050202.html
>
> McCLIM Lisp inspector: from cool demo to useful tool
> http://www.paoloamoroso.it/log/050311.html
>
> McCLIM changes: inspection of integers/pathnames, fixed text copy/paste
> [typo: Closure -> Clouseau]
> http://www.paoloamoroso.it/log/050323.html
Thanks. I should give it a spin ASAP...which means more CVS fetchers
I suppose. Perhaps you could add the above (with a few more comments
about the Inspector) to cliki? I considered doing it, but it seems
someone who has used Clouseau would be best at that.
--
With sufficient thrust, pigs fly fine.
GP lisper <········@CloudDancer.com> writes:
> I suppose. Perhaps you could add the above (with a few more comments
> about the Inspector) to cliki? I considered doing it, but it seems
Done:
http://mcclim.cliki.net/Examples
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
> Tons, but YMMV. The SBCL folkes will be along to speak up soon, but
> they are missing callbacks, some part of MOP and some other stuff.
What (in this context) are callbacks?
joelh
On 10 Jun 2005 16:13:52 -0700, <·····@juniper.net> wrote:
>
>
>> Tons, but YMMV. The SBCL folkes will be along to speak up soon, but
>> they are missing callbacks, some part of MOP and some other stuff.
>
> What (in this context) are callbacks?
The detailed answer is easy to find in the CMUCL Manual, which is also
easy to find.
--
With sufficient thrust, pigs fly fine.
On 2005-06-11 21:11:39, Massimiliano Campagnoli wrote:
> In my experience I had to move from SBCL to CMUCL because TBNL was not
> compiling on SBCL version 0.9 (and 0.9.1).
Have you tried sbcl without sb-unicode?