hello all,
1st, i have already searched the archives of last 12 years for this
question i am asking but did not get my answer. 2nd, i will not take
much of your precious time.
i want to start writing web-based softwares (like VIAWEB of Paul
Graham, see paulgraham.com).
so which LISP implementation i should choose out of these 3: CLISP,
CMUCL, SBCL.
personally i like SBCL as it is an ANSI CL implementation and its
error-mesages are quite informative. OTOH, CLISP runs almost everywhere
and web-server have different kinds of hardwares so it is easy to port
CLISP to such different kinds of hardwares but porting CMUCL, SBCL is
extemely difficult.
what you folks advise. any views.
thanks
--arnuld
> so which LISP implementation i should choose out of these 3: CLISP,
> CMUCL, SBCL.
>
Make sure you can compile and run your code with at least two of them.
Keep in mind that SBCL is still not of production quality and somewhat
buggy.
David
From: Marco Baringer
Subject: Re: which LISP implementation (goal explained)
Date:
Message-ID: <m2y7xn5p92.fsf@bese.it>
·············@gmail.com" <············@gmail.com> writes:
> Make sure you can compile and run your code with at least two of them.
> Keep in mind that SBCL is still not of production quality and somewhat
> buggy.
this is completly untrue, in my experience.
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
> > Make sure you can compile and run your code with at least two of them.
> > Keep in mind that SBCL is still not of production quality and somewhat
> > buggy.
>
> this is completly untrue, in my experience.
>
Hi Marco,
what is untrue, that it makes sense to make sure that the code runs
under two implementations?
or that SBCL is not yet production-quality?
David
From: Marco Baringer
Subject: Re: which LISP implementation (goal explained)
Date:
Message-ID: <m27j575kzx.fsf@bese.it>
·············@gmail.com" <············@gmail.com> writes:
> Hi Marco,
>
> what is untrue, that it makes sense to make sure that the code runs
> under two implementations?
sorry, my answer was ambiguous.
1) i agree that it's good to make sure your system runs on two
differente lisps. out of sbcl/cmucl/clisp i think it's better to
make sure it runs and sbcl (or cmucl) and clisp as opposed to sbcl
and cmucl. (just because sbcl and cmucl are fairly similar to each
other).
2) i believe sbcl is production quality, and i'm betting my, and my
client's, time and money on it. i have had issues, and there have
even been a few cases of deadlines + shop stopper bugs which caused
me major pain, but i've encountered those situations with every
piece of software i've ever used. recent versions of sbcl are no
less, and no more, reliable than all the other major software
systems i have used (this includes 'enterprise' production quality
software such as oracle and bea weblogic).
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
> 2) i believe sbcl is production quality, and i'm betting my, and my
> client's, time and money on it. i have had issues, and there have
> even been a few cases of deadlines + shop stopper bugs which caused
> me major pain, but i've encountered those situations with every
> piece of software i've ever used. recent versions of sbcl are no
> less, and no more, reliable than all the other major software
> systems i have used (this includes 'enterprise' production quality
> software such as oracle and bea weblogic).
Hi Marco,
I am not comparing SBCL to Oracle or BEA WebLogic; those are in
different category and at different level of complexity, SBCL is just a
language compiler, a much simpler job. My comparison is closer to the
ground:
I have a commercial application of about 30,000 lines of code in Common
Lisp, of which about 11,000 I've written myself. The application runs
swiftly and reliably with LispWorks, Allegro CL (I had to simplify the
code in places to bypass two bugs in their compiler), CMU CL (I had to
do tricky things with lists used as keys in hash tables, but otherwise
it was OK), CLISP and OpenMCL (both are slow but without any other
problems).
I tried a couple of timed to make it run on SBCL, that would save me
money if it worked. I failed and gave up. It compiles and starts, but
fails unpredictably in all kinds of ways imaginable, the further the
platform from Linux, the worse. The last experience has been with
0.9.11, so it is not far from being current. The platforms I need are
FreeBSD, Mac OS X/PowerPC, Mac OS X/Intel.
David
From: Marco Baringer
Subject: Re: which LISP implementation (goal explained)
Date:
Message-ID: <m2psiz45hd.fsf@bese.it>
·············@gmail.com" <············@gmail.com> writes:
> I tried a couple of timed to make it run on SBCL, that would save me
> money if it worked. I failed and gave up. It compiles and starts, but
> fails unpredictably in all kinds of ways imaginable, the further the
> platform from Linux, the worse. The last experience has been with
> 0.9.11, so it is not far from being current. The platforms I need are
> FreeBSD, Mac OS X/PowerPC, Mac OS X/Intel.
ok. i'm not going to attempt to sell you on sbcl, if it doesn't work
for you then don't use it. it just happens that on my platforms, Mac
OS X/PowerPC and Linux sbcl works fine. obviously, and maybe i should
have stated this explicitly, i don't expect from sbcl things which it
doesn't purport to offer (like threads on ppc).
i mentioned oracle and weblogic only to say that sbcl is as production
ready as those products (for some reason those two products are my
stereotypes of 'production ready'). i was not attempting to say that
sbcl is as large as oracle, my comment was on the quality of the code,
not the feature set.
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
well, between your *discussion*, i am missing the information i need.
From: Marco Baringer
Subject: Re: which LISP implementation (goal explained)
Date:
Message-ID: <m2hd4b43bv.fsf@bese.it>
"arnuld" <·······@gmail.com> writes:
> well, between your *discussion*, i am missing the information i need.
web apps have been developed, successfully, on sbcl, cmucl and
clisp. there have also been failures using all three. personally i'd
suggest to use sbcl or cmucl on linux (unlike clisp those two have
threads), however clisp runs on windows (sbcl's windows support is
still under development) if that's important to you.
if there's a particular web framework you want to use it may not
support all implementations, this should help to limit your choices.
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
> i mentioned oracle and weblogic only to say that sbcl is as production
> ready as those products (for some reason those two products are my
> stereotypes of 'production ready'). i was not attempting to say that
> sbcl is as large as oracle, my comment was on the quality of the code,
> not the feature set.
>
Both Oracle and WebLogic can be a bit shaky at obscure edges, because
they are huge and complex. SBCL is a much simpler program. And no, the
level of problems is not in threads or something like that.
The problems are in basic features of the compiler and the runtime.
I've quickly reproduced one of problems I met during my last
intercourse. Here it is.
There is a package PURI, developed by Franz, which is a URI parser. The
package contains function encode-escaped-encoding, and the functions
indirectly calls sb-kernel:shrink-vector (a public SBCL function). If
you look at the session below, you'll see that if the third argument to
encode-escaped-encoding is non-nil, shrink-vector (you can consult the
sources of PURI) does not work properly.
Please note that the third argument is NOT USED AT ALL with the other
arguments supplied, because "a" is not escaped. It just triggers
something in the compiler and spoils things.
* (puri::encode-escaped-encoding "a" puri::*reserved-path-characters*
'(#\Space))
"a
debugger invoked on a SIMPLE-CONDITION: interrupted at #X280E20B3
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Return from SB-UNIX:SIGINT.
1: [ABORT ] Exit debugger, returning to top level.
(SB-UNIX::SIGINT-HANDLER
#<unavailable argument>
#<unavailable argument>
#.(SB-SYS:INT-SAP #X28378660))
0] :a
* (puri::encode-escaped-encoding "a" puri::*reserved-path-characters*
nil)
"a"
And this is not the only problem of this kind. I went through half a
dozen of them with 0.9.11, and then decided that it is not something I
can rely in an application I am going to charge money for.
David
·············@gmail.com" <············@gmail.com> writes:
> > i mentioned oracle and weblogic only to say that sbcl is as production
> > ready as those products (for some reason those two products are my
> > stereotypes of 'production ready'). i was not attempting to say that
> > sbcl is as large as oracle, my comment was on the quality of the code,
> > not the feature set.
> >
>
> Both Oracle and WebLogic can be a bit shaky at obscure edges, because
> they are huge and complex. SBCL is a much simpler program. And no, the
> level of problems is not in threads or something like that.
>
> The problems are in basic features of the compiler and the runtime.
> I've quickly reproduced one of problems I met during my last
> intercourse. Here it is.
>
> There is a package PURI, developed by Franz, which is a URI parser. The
Not quite. It's a portable version of net.uri developed by Kevin
Rosenberg.
> package contains function encode-escaped-encoding, and the functions
> indirectly calls sb-kernel:shrink-vector (a public SBCL function). If
> you look at the session below, you'll see that if the third argument to
> encode-escaped-encoding is non-nil, shrink-vector (you can consult the
> sources of PURI) does not work properly.
>
> Please note that the third argument is NOT USED AT ALL with the other
> arguments supplied, because "a" is not escaped. It just triggers
> something in the compiler and spoils things.
What do you mean by "not used at all"? If the third arg is nil,
encode-escaped-encoding returns immediately; no wonder there's no
problem then.
>
> * (puri::encode-escaped-encoding "a" puri::*reserved-path-characters*
> '(#\Space))
>
> "a
> debugger invoked on a SIMPLE-CONDITION: interrupted at #X280E20B3
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [CONTINUE] Return from SB-UNIX:SIGINT.
> 1: [ABORT ] Exit debugger, returning to top level.
>
> (SB-UNIX::SIGINT-HANDLER
> #<unavailable argument>
> #<unavailable argument>
> #.(SB-SYS:INT-SAP #X28378660))
> 0] :a
I can't reproduce it on 0.9.11.8. I do get strange results though,
unless I change puri:shrink-vector to return the result of the call to
sb-kernel:shrink-vector. Perhaps the latter wasn't meant to be called
for side effects?
Maybe the only bug is that sb-kernel:shrink-vector is exported but
undocumented.
Andras
> I can't reproduce it on 0.9.11.8. I do get strange results though,
> unless I change puri:shrink-vector to return the result of the call to
> sb-kernel:shrink-vector. Perhaps the latter wasn't meant to be called
> for side effects?
It is not called for side effects in encode-escaped-encoding. It's
return value is returned from the function and used by the caller.
David
> It is not called for side effects in encode-escaped-encoding. It's
> return value is returned from the function and used by the caller.
Ah, I see. It is called for side-effects and probably shouldn't.
David
·············@gmail.com" <············@gmail.com> writes:
> There is a package PURI, developed by Franz, which is a URI parser. The
> package contains function encode-escaped-encoding, and the functions
> indirectly calls sb-kernel:shrink-vector (a public SBCL function).
SB-KERNEL:SHRINK-VECTOR is not and never has been a public SBCL
function. The documentation string for the package named "SB-KERNEL"
makes that clear, I hope:
* (documentation (find-package "SB-KERNEL") t)
"private: Theoretically this 'hides state and types used for package
integration' (said CMU CL architecture.tex) and that probably was and
is a good idea, but see SB-SYS re. blurring of boundaries."
to contrast with the documentation for the public extensions package:
* (documentation (find-package "SB-EXT") t)
"public: miscellaneous supported extensions to the ANSI Lisp spec"
and for the package for the symbols described in the Art of the
MetaObject Protocol:
* (documentation (find-package "SB-MOP") t)
"public: the MetaObject Protocol interface, as defined by
The Art of the Metaobject Protocol, by Kiczales, des Rivieres and Bobrow:
ISBN 0-262-61074-4, with exceptions as noted in the User Manual."
> And this is not the only problem of this kind. I went through half a
> dozen of them with 0.9.11, and then decided that it is not something I
> can rely in an application I am going to charge money for.
I'm sorry that you've had this kind of experience, and if it turns out
that you have time to generate more reports of the problems you have
encountered, it may be that they are similarly resolvable.
Christophe
Hi Christophe,
I fully compile my program, and there is no EVAL or COMPILE in its
code. When I run it for the first time, I see, amidst of normal output,
the following lines:
document xslt: CLOSE-STATE POSTPROCESS
document xslt: CLOSE-STATE FORMAT
document xslt: OPEN-STATE GENERATE
document xslt: EVENT OUTPUT-FORMAT XEPOUT
; in:
; LAMBDA (#:G2047 #:G2048
; #:G2049
; #:G2050
; #:G2051
; #:G2052
; #:G2053
; #:G2054
; #:G2055
; #:G2056
; #:G2057
; #:G2058
; ...)
; (TYPEP SB-PCL::.ARG0. 'XEP::ITEM-LEADER)
; --> SB-C::%INSTANCE-TYPEP
; ==>
; SB-PCL::.ARG0.
;
; note: deleting unreachable code
; 'XEP::ITEM-TEXT
;
; note: deleting unreachable code
;
; note: deleting unreachable code
; 'XEP::ITEM-LEADER
;
; note: deleting unreachable code
; (TYPEP SB-PCL::.ARG0. 'XEP::ITEM-TEXT)
; --> SB-C::%INSTANCE-TYPEP
; ==>
; SB-PCL::.ARG0.
;
; note: deleting unreachable code
;
; note: deleting unreachable code
;
; note: deleting unreachable code
;
; note: deleting unreachable code
;
; compilation unit finished
; printed 8 notes
document xslt: EVENT PAGE-NUMBER i
document xslt: EVENT PAGE-NUMBER ii
How can I find the cause of this diagnostics and eliminate it? There is
nothing like this in any other implementation I use.
David
·············@gmail.com" <············@gmail.com> writes:
> I fully compile my program, and there is no EVAL or COMPILE in its
> code. When I run it for the first time, I see, amidst of normal output,
> the following lines:
>
> document xslt: CLOSE-STATE POSTPROCESS
> document xslt: CLOSE-STATE FORMAT
> document xslt: OPEN-STATE GENERATE
> document xslt: EVENT OUTPUT-FORMAT XEPOUT
> ; in:
> ; LAMBDA (#:G2047 #:G2048
> ; #:G2049
> ; #:G2050
> ; #:G2051
> ; #:G2052
> ; #:G2053
> ; #:G2054
> ; #:G2055
> ; #:G2056
> ; #:G2057
> ; #:G2058
> ; ...)
> ; (TYPEP SB-PCL::.ARG0. 'XEP::ITEM-LEADER)
> ; --> SB-C::%INSTANCE-TYPEP
> ; ==>
> ; SB-PCL::.ARG0.
> ;
> ; note: deleting unreachable code
>
> ; 'XEP::ITEM-TEXT
> ;
> ; note: deleting unreachable code
> ;
> ; note: deleting unreachable code
>
> ; 'XEP::ITEM-LEADER
> ;
> ; note: deleting unreachable code
>
> ; (TYPEP SB-PCL::.ARG0. 'XEP::ITEM-TEXT)
> ; --> SB-C::%INSTANCE-TYPEP
> ; ==>
> ; SB-PCL::.ARG0.
> ;
> ; note: deleting unreachable code
> ;
> ; note: deleting unreachable code
> ;
> ; note: deleting unreachable code
> ;
> ; note: deleting unreachable code
> ;
> ; compilation unit finished
> ; printed 8 notes
> document xslt: EVENT PAGE-NUMBER i
> document xslt: EVENT PAGE-NUMBER ii
>
>
> How can I find the cause of this diagnostics and eliminate it? There is
> nothing like this in any other implementation I use.
The easiest workaround of all might be to bind *error-output*: say
(let ((*error-output* (make-broadcast-stream)))
...)
which will discard the compiler diagnostics and other warnings from
whatever compiler you happen to use.
To find out where the diagnostics are coming from, you could set
cl:*break-on-signals* to sb-ext:code-deletion-note, which will cause
the debugger to be invoked at the point that the compiler notes are
emitted. This should help to narrow down the place where the notes
are emitted: you can examine the stack at that point in the execution
of your program, inspect the application state, and so on.
(At a guess, given the package of SB-PCL::.ARG0., this is something in
the implementation of CLOS warming up an effective method cache, which
-- unless the user specifies otherwise -- happens at the first call to
the generic function with a particular set of arguments.)
Christophe
> The easiest workaround of all might be to bind *error-output*: say
> (let ((*error-output* (make-broadcast-stream)))
> ...)
> which will discard the compiler diagnostics and other warnings from
> whatever compiler you happen to use.
Hi Christophe,
but I use *error-output* for other purposes, I don't want it to be
discarded. Besides, I don't want to hide diagnostics, I want to avoid
the compiler to be invoked during execution.
> (At a guess, given the package of SB-PCL::.ARG0., this is something in
> the implementation of CLOS warming up an effective method cache, which
> -- unless the user specifies otherwise -- happens at the first call to
> the generic function with a particular set of arguments.)
>
1) Does that mean that to eliminate compiler diagnostics, I will have
to execute all branches of the program 'to warn up the cache' before
using it?
2) What is the option in SBCL to disable compiler diagnostics during
program execution?
David
·············@gmail.com" <············@gmail.com> writes:
> but I use *error-output* for other purposes, I don't want it to be
> discarded. Besides, I don't want to hide diagnostics, I want to avoid
> the compiler to be invoked during execution.
Hmmm. That might be a bit more difficult to achieve, if the libarary
you are using really wants to invoke the compiler at run time.
> > (At a guess, given the package of SB-PCL::.ARG0., this is something in
> > the implementation of CLOS warming up an effective method cache, which
> > -- unless the user specifies otherwise -- happens at the first call to
> > the generic function with a particular set of arguments.)
> >
>
> 1) Does that mean that to eliminate compiler diagnostics, I will have
> to execute all branches of the program 'to warn up the cache' before
> using it?
> 2) What is the option in SBCL to disable compiler diagnostics during
> program execution?
Well, one method I've used in other lisps which printed warnings was to
identify the particular exception thrown and then wrap an appropriate
exception binding that catches just that exception and ignores it. I
recall making use of EXCEPTION-BIND and MUFFLE-WARNING for that.
--
Thomas A. Russ, USC/Information Sciences Institute
> > but I use *error-output* for other purposes, I don't want it to be
> > discarded. Besides, I don't want to hide diagnostics, I want to avoid
> > the compiler to be invoked during execution.
>
> Hmmm. That might be a bit more difficult to achieve, if the libarary
> you are using really wants to invoke the compiler at run time.
I don't use external libraries in this part of the code. The library I
am using is CLOS.
Does CLOS implementation in SBCL use the compiler on methods at run
time (I don't use classes, just methods)?
> Well, one method I've used in other lisps which printed warnings was to
> identify the particular exception thrown and then wrap an appropriate
> exception binding that catches just that exception and ignores it. I
> recall making use of EXCEPTION-BIND and MUFFLE-WARNING for that.
But these are not exceptions or warnings, these are notes from the
compiler at a point where it should not be invoked.
wow!, my post is going in entirely different direction. so long, so
good.
for DAVID:
DAVID, i want to tell you one thing: 1st read SBCL user manual & also
lurk into CMUCL user manual & other CMUCL docsl. that way your 95% of
problems will just disappear. documentation is available @ their home
sites. why i am saying this? just listen my story:
One day i was learning through PCL and when i loaded a file in CLISP it
said;
loading file: .......
loaded file:........
T
when i loaded the same file in SBCL, it said, something like:
(99% of the message was same on my system)
; in:
; LAMBDA (#:G2047 #:G2048
; #:G2049
; #:G2050
; #:G2051
; #:G2052
; #:G2053
; #:G2054
; #:G2055
; #:G2056
; #:G2057
; #:G2058
; ...)
; (TYPEP SB-PCL::.ARG0. 'XEP::ITEM-LEADER)
; --> SB-C::%INSTANCE-TYPEP
; ==>
; SB-PCL::.ARG0.
;
; note: deleting unreachable code
; 'XEP::ITEM-TEXT
;
; note: deleting unreachable code
;
; note: deleting unreachable code
; 'XEP::ITEM-LEADER
;
; note: deleting unreachable code
; (TYPEP SB-PCL::.ARG0. 'XEP::ITEM-TEXT)
; --> SB-C::%INSTANCE-TYPEP
; ==>
; SB-PCL::.ARG0.
;
; note: deleting unreachable code
;
; note: deleting unreachable code
;
; note: deleting unreachable code
;
; note: deleting unreachable code
;
; compilation unit finished
; printed 8 notes
document xslt: EVENT PAGE-NUMBER i
document xslt: EVENT PAGE-NUMBER ii
sooooooo weird, SBCL is dangerous, oh! above my head......
i was just afraid and thought: " How can I find the cause of this
diagnostics and eliminate it? There is nothing like this in any other
implementation I use."
i quickly left SBCL and dove into CLISP. after a month, one day i was
looking into documentatios i downloaded from Internet and i found CMUCL
user manual. i read it and from that day i am using SBCL. but if their
is technical failure in regarding your special requirements of
software, then i can not say anything. BUT *do* read SBCL & CMUCL user
manual, again i say, 95% of problems will just vaporize.
thanks. i wish i could solve your full problem, unfortunately i am a
newbie to programming hence can not understand much technical details.
-- arnuld
·············@gmail.com" <············@gmail.com> writes:
>> The easiest workaround of all might be to bind *error-output*: say
>> (let ((*error-output* (make-broadcast-stream)))
>> ...)
>> which will discard the compiler diagnostics and other warnings from
>> whatever compiler you happen to use.
>
> Hi Christophe,
>
> but I use *error-output* for other purposes, I don't want it to be
> discarded. Besides, I don't want to hide diagnostics, I want to avoid
> the compiler to be invoked during execution.
That's fair enough. (I was hoping that your problem might be solved
for the simplest workaround, but that's clearly not to be).
You might have a hard time completely removing the compiler from the
execution, though I think it's possible: see below (and maybe for
background see also Kiczales and Rodruigez. "Efficient Method Dispatch
in PCL", 1990, and the chapter on discriminating functions in the SBCL
internals manual, at
<http://www.sbcl.org/sbcl-internals/Discriminating-Functions.html#Discriminating-Functions>).
>> (At a guess, given the package of SB-PCL::.ARG0., this is something in
>> the implementation of CLOS warming up an effective method cache, which
>> -- unless the user specifies otherwise -- happens at the first call to
>> the generic function with a particular set of arguments.)
>
> 1) Does that mean that to eliminate compiler diagnostics, I will have
> to execute all branches of the program 'to warn up the cache' before
> using it?
It's a bit hard to answer this question without knowing its scope.
You can warm up the generic functions' effective method caches in many
ways: one is certainly to call each generic function with all possible
classes of arguments -- either in terms of your entire class hierarchy
or in terms of all those arguments which will ever be passed in the
history of your running program.
Another way is to twiddle an undocumented knob in SBCL's CLOS. If you
know which generic functions you would like to have as warm as
possible, you can do something like
(defun warm-gf (gf)
(setf (sb-pcl::gf-precompute-dfun-and-emf-p
(sb-pcl::gf-arg-info gf)) t)
(reinitialize-instance gf))
(warm-gf #'my-gf)
and then you should get no compiler notes (or indeed compiler activity
of any sort) for calls to MY-GF. So if you can find out which generic
functions are responsible for the notes being emitted in your
application's run, you can warm the caches of those generic functions
and the runtime notes should go away.
Warming the cache, here, is essentially the same as filling it with
all possible combinations of argument classes that it could be called
with and have an effective method that isn't no-applicable-method.
This might be a bad idea if your generic function takes many
arguments, as there is a combinatorial explosion.
But even after saying all of that, I think I should make clear that
it's not by design that these compiler notes are being emitted for
non-user code; there are probably two bugs here. One is, I suspect,
that the code being generated by SBCL's CLOS implementation isn't
itself being compiled in an environment where notes are inhibited; the
other is that the heuristics for what is user code and what isn't,
used all the time in the compiler to determine whether a particular
code deletion is significant or not, are apparently being defeated.
And finally, please remember that I did explicitly say that I was
guessing as to where the compiler diagnostics were coming from; if you
want to find out precisely, you (or someone with access to your code)
will have to find out what is happening, using *break-on-signals* or
by some other means. I'm moderately confident about my guess; I think
I've seen something similar with methods with multiple EQL
specializers, but I could be wrong.
> 2) What is the option in SBCL to disable compiler diagnostics during
> program execution?
You can muffle compiler notes, with
(handler-bind (#+sbcl (sb-ext:compiler-note #'muffle-warning))
(foo))
Christophe
> more reports of the problems you have
> encountered,
I've recalled another problem and been able to reproduce it in
0.9.12/PowerPC, although I cannot provide a simple test due to the
problem's nature. I have a set of test input files. Their processing
time is mostly linear, and takes roughly the same time with CMUCL,
LispWorks and OpenMCL, and three times as much with CLISP and OpenMCL.
When I pass a file of small or moderate size to a freshly loaded image
compiled with SBCL, I get the time close to those of CMU and company.
However, when I run the batch through SBCL, it takes 10 times more time
to complete. I don't know what the problem is, I suspect that this has
something to do with hash table and hash function implementations, but
cannot confirm it.
David