On Sun, 30 Jan 2005, Hal Nine wrote:
> Which PCL is in SBCL? Gerd`s? If it is, is it in synch with the one in
> CMUCL?
Yes and no. AFAIK CMUCL's PCL at the time of the fork was pre-Gerd, but
most (?) of the work done by him has been ported SBCL. SB-PCL has also
gone thru evolution all it's own, and will continue to do so.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."

Pete Kazmier <pete-temp-20050120@...> writes:
> In terms of the little office bet I had going, technically I lost as
> there were no open source CL implementations that had decent READ-LINE
> performance without resorting to hand optimizing the code to take
> advantage cl-ppcre's great speed.
Because READ-LINE allocates a new string each time, you are almost
doomed to lose against environments which are free to recycle storage
(as in e.g. Perl's $_ and probably Python's equivalent.) Comparing
apples to apples is recommended -- it's certainly not cheating to read
into a buffer and do matches between start and end indices.
> By cheating, using the above macro with CMUCL, I was able to achieve
> comparable results to my original python program which is great I
> suppose, but it still leaves me wondering why the default READ-LINE
> implementations are so slow (in particular SBCL as that in my
> preferred CL). Or, am I not flipping the "turbo" switch? Does that
> profiling sample (in my first post) look about right for this
> scenario?
SBCL's READ-LINE is so slow because file IO is in flux; Unicode and
external-format support are both recently-implemented, and we're still
shaking out bugs -- performance problems only figure on the radar in
as much as they affect real applications; I'm afraid an office bet
isn't enough to interest me for now. In any case, as I say, it's
never going to be as fast as something which is allowed to share a
buffer between calls.
That said, I would expect the fastest READ-LINE available in sbcl to
be in an image built without :sb-unicode, running in an environment
where nl_langinfo(CODESET) returns "ISO-8859-1" -- both of these
factors are important. I don't know what your setup was, but maybe
that helps somewhat.
Cheers,
Christophe

As an aside, on the issue of READ-LINE I would really like to have a
READ-BUFFERED-LINE line-buffer &optional stream eof-error-p eof-value
recursive-p
that behaved like READ-LINE, but that would fill LINE-BUFFER (this
being an adjustable character array with a fill pointer - the fill
pointer being reset to 0 on each call)
Using READ-SEQUENCE for the intended use does not quite cut it IMHO.
Of course the performance issue should be dealt with at the
implementation level.
Cheers
Marco
On Jan 25, 2005, at 9:00 PM, Pete Kazmier wrote:
> Peter Denno <peter.denno@...> writes:
>>
>> I'm not an expert in the internals of SBCL, so I can't comment on
>> most of this, but I see that you are running under SLIME. I have a
>> LispWorks application that runs twice as fast standalone as it does
>> under SLIME.
>
> Thanks for the suggestion, although in this case, it did not have a
> significant impact on the times. Since my original post, I have
> tested reading the same log file in both Allegro and LW (per Edi's
> suggestion in a thread on the cl-ppcre list) to see how their
> READ-LINE speeds compare to the free CL implementations [1]. Both
> were faster of course, but LW was by far the fastest and on par with
> the equivalent python program. Of course, life would be much better
> if SBCLs READ-LINE was much faster. Any developers have any input on
> my previous post?
>
> Thanks,
> Pete
>
> [1] Speeds from LW and Allegro
>
> LispWorks:
> CL-USER 17 > (time (tester "/tmp/pgw-logs/trapd.log.ovnyc00p"))
> Timing the evaluation of (TESTER "/tmp/pgw-logs/trapd.log.ovnyc00p")
>
> user time = 0.880
> system time = 0.180
> Elapsed time = 0:00:01
> Allocation = 36822608 bytes standard / 4070 bytes conses
> 0 Page faults
> Calls to %EVAL 34
> T
>
> Allegro:
> CL-USER(7): (time (tester "/tmp/pgw-logs/trapd.log.ovnyc00p"))
> ; cpu time (non-gc) 2,730 msec user, 90 msec system
> ; cpu time (gc) 80 msec user, 0 msec system
> ; cpu time (total) 2,810 msec user, 90 msec system
> ; real time 3,493 msec
> ; space allocation:
> ; 67 cons cells, 67,825,256 other bytes, 0 static bytes
> T
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>
--
Marco Antoniotti http://bioinformatics.nyu.edu
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th FL fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.

Continuing my saga, Bulent Murtezaoglu sent me a link to a macro he
wrote to speed things up in CMUCL in terms of reading [1]. I tested
the macro under both CMUCL and SBCL. Under CMUCL, I was able to
achieve very good read times [2] (still not as fast as LW, but faster
than Allegro). I tried the macro under SBCL, but performance was
worse than before.
In terms of the little office bet I had going, technically I lost as
there were no open source CL implementations that had decent READ-LINE
performance without resorting to hand optimizing the code to take
advantage cl-ppcre's great speed. By cheating, using the above macro
with CMUCL, I was able to achieve comparable results to my original
python program which is great I suppose, but it still leaves me
wondering why the default READ-LINE implementations are so slow (in
particular SBCL as that in my preferred CL). Or, am I not flipping
the "turbo" switch? Does that profiling sample (in my first post)
look about right for this scenario?
Thanks,
Pete
[1] Macro by Bulent Murtezaoglu
http://groups-beta.google.com/group/comp.lang.lisp/msg/f22b458b22598666
[2] CMUCL Results using macro
CL-USER> (time (fast-tester "/tmp/pgw-logs/trapd.log.ovnyc00p"))
; Compiling LAMBDA NIL:
; Compiling Top-Level Form:
; Evaluation took:
; 2.63 seconds of real time
; 2.01 seconds of user run time
; 0.49 seconds of system run time
; 1,841,333,669 CPU cycles
; [Run times include 0.47 seconds GC run time]
; 0 page faults and
; 76,958,032 bytes consed.
;
T

Peter Denno <peter.denno@...> writes:
>
> I'm not an expert in the internals of SBCL, so I can't comment on
> most of this, but I see that you are running under SLIME. I have a
> LispWorks application that runs twice as fast standalone as it does
> under SLIME.
Thanks for the suggestion, although in this case, it did not have a
significant impact on the times. Since my original post, I have
tested reading the same log file in both Allegro and LW (per Edi's
suggestion in a thread on the cl-ppcre list) to see how their
READ-LINE speeds compare to the free CL implementations [1]. Both
were faster of course, but LW was by far the fastest and on par with
the equivalent python program. Of course, life would be much better
if SBCLs READ-LINE was much faster. Any developers have any input on
my previous post?
Thanks,
Pete
[1] Speeds from LW and Allegro
LispWorks:
CL-USER 17 > (time (tester "/tmp/pgw-logs/trapd.log.ovnyc00p"))
Timing the evaluation of (TESTER "/tmp/pgw-logs/trapd.log.ovnyc00p")
user time = 0.880
system time = 0.180
Elapsed time = 0:00:01
Allocation = 36822608 bytes standard / 4070 bytes conses
0 Page faults
Calls to %EVAL 34
T
Allegro:
CL-USER(7): (time (tester "/tmp/pgw-logs/trapd.log.ovnyc00p"))
; cpu time (non-gc) 2,730 msec user, 90 msec system
; cpu time (gc) 80 msec user, 0 msec system
; cpu time (total) 2,810 msec user, 90 msec system
; real time 3,493 msec
; space allocation:
; 67 cons cells, 67,825,256 other bytes, 0 static bytes
T

* (lisp-implementation-type)
"SBCL"
* (lisp-implementation-version)
"0.8.18.38"
* (describe #p"foo/")
#P"foo/" is an instance of class #<STRUCTURE-CLASS PATHNAME>.
The following slots have :INSTANCE allocation:
HOST #<SB-IMPL::UNIX-HOST {5019701}>
DEVICE NIL
DIRECTORY (:RELATIVE "foo")
NAME NIL
TYPE NIL
VERSION NIL
* (file-namestring #p"foo/")
""
CMUCL and AllegroCL both return NIL here and this is what I expected
after reading in the CLHS that "FILE-NAMESTRING returns just the name,
type, and version components" of the pathname (which are all NIL in
this case).
Is this a language lawyer thing where some deep corner of the spec
requires all implementations to return "" or is there some other
reason for this behaviour? I tend to think that returning NIL in this
case is more intuitive but who am I to judge this... :)
Cheers,
Edi.

Koenraad De Smedt writes:
> I am using SBCL on OSX under Apple's X11.
>=20
> Problem: upper-ascii characters are not being read; the reader just =
stops.
>=20
> Examples: "=E6=F8=E5" '=E6=F8=E5
>=20
> This occurs when simply running SBCL in an xterm or via Emacs,
> using iso-latin-1 characters and corresponding Emacs encoding.
>=20
> This might be an X11 implementation problem; however, other process
> communication from Emacs does handle iso-latin-1 characters. In
> Emacs, I can for example start a shell and grep such characters
> without a problem.
You can get SBCL to use Latin-1 encoding instead of the default UTF-8,
by running it in an environment where either LC_CTYPE or LANG are set
to "C".
The depressing thing is that even if they fix nl_langinfo for 10.4,
we're pretty much stuck with this mess until 10.5 comes out and it's
reasonable to stop supporting 10.3. Yuck. Maybe we can steal the
langinfo code from one of the BSDs :-)

Brian Mastenbrook wrote:
> The solution to this problem might just be to use a unicode xterm.
% xterm -u8
open ttydev: Permission denied.
Any hints on where to get a unicode xterm?
On the other hand, I got Emacs to use the proper coding by the following:
(defvar sbcl-buffer-process-coding-system 'utf-8 "UTF8 I/O for SBCL.")
(modify-coding-system-alist 'process "sbcl"
sbcl-buffer-process-coding-system)
I suspect that advanced lisp interaction packages like Slime do something similar but I didn't bother to get those.
I found surprisingly little information about character coding in the SBCL manual.
Thanks,
K

On Jan 17, 2005, at 3:25 PM, Christophe Rhodes wrote:
> Oh, my word. PAIN AND SUFFERING.
>
> OS X's terminal defaults to utf-8 input/output, so that's what SBCL
> does. How are you setting up your X11 to deal with latin-1
> input/output? (OS X doesn't provide the posix-defined nl_langinfo()
> method for querying the system ourselves for natural language
> environmental questions).
It might be slightly more painful than you think, Christophe. OS X 10.3
provides nl_langinfo, but OS X 10.2 does not. However, 10.3's version
lies: even when the terminal is set to UTF-8, it returns the equivalent
of iso latin 1. Since I couldn't figure out a good solution to this
problem, I decided that always returning UTF-8 was a good enough
solution, as most other programs on OS X expect and know how to deal
with UTF-8.
The solution to this problem might just be to use a unicode xterm.
--
Brian Mastenbrook
bmastenb@...
http://cs.indiana.edu/~bmastenb/

On Mon, Jan 17, 2005 at 07:47:35PM +0000, Christophe Rhodes wrote:
> [ delayed response... ]
>
> Eric Blossom <eb@...> writes:
>
> > It appears that compile-file is incorrectly returning a value of T for
> > error-p even though the output diagnostics indicate that the
> > compilation produced only a warning. [I'd also like to know how to
> > get rid of the warning...]
>
> The correct value for errorp given a full warning /is/ T, I'm afraid.
>
Thanks.
> I'm not intimately familiar with cl-ppcre, but what I think is
> happening is that register-groups-bind is binding CH to something like
> (if match (something with match) nil), and SBCL is warning you about
> the failure branch, which will cause a type mismatch if it's ever
> executed. To quieten the system, probably a (check-type ch string) in
> the body will work.
>
> Cheers,
>
> Christophe
Thanks for the clarification and suggestions.
Eric

Koenraad De Smedt <desmedt@...> writes:
> I am using SBCL on OSX under Apple's X11.
> Problem: upper-ascii characters are not being read; the reader just stops.
> Examples: "=C3=A6=C3=B8=C3=A5" '=C3=A6=C3=B8=C3=A5
> This occurs when simply running SBCL in an xterm or via Emacs, using
> iso-latin-1 characters and corresponding Emacs encoding.
> This might be an X11 implementation problem; however, other process
> communication from Emacs does handle iso-latin-1 characters. In
> Emacs, I can for example start a shell and grep such characters
> without a problem.
Oh, my word. PAIN AND SUFFERING.
OS X's terminal defaults to utf-8 input/output, so that's what SBCL
does. How are you setting up your X11 to deal with latin-1
input/output? (OS X doesn't provide the posix-defined nl_langinfo()
method for querying the system ourselves for natural language
environmental questions).
Cheers,
Christophe

I am using SBCL on OSX under Apple's X11.
Problem: upper-ascii characters are not being read; the reader just stops.
Examples: "æøå" 'æøå
This occurs when simply running SBCL in an xterm or via Emacs, using iso-latin-1 characters and corresponding Emacs encoding.
This might be an X11 implementation problem; however, other process communication from Emacs does handle iso-latin-1 characters. In Emacs, I can for example start a shell and grep such characters without a problem.
K

On Wed, Jan 12, 2005 at 06:18:07AM -0600, Paul F. Dietz wrote:
> Eric Blossom wrote:
> >I'm running into control stack exhaustion when trying to
> >compile a particular macro expansion (see below).
> >
> >I'm using SBCL 0.8.17 on x86 Linux 2.6.8
> >
> >Questions:
> >
> > (1) Can I increase the size of the control stack somehow?
> > I RTFM, but didn't see anything relevant. Is it a function of my
> > ram + swap or is there a (tunable) limit in SBCL?
> >
> > (2) Are there declarations, etc that I could add to the code to get it
> > to compile?
> >
> > (3) Any other suggestions for getting this to compile, including
> > idioms, restructuring, etc.
>
> Get rid of all the separate calls to EX-FLOAT and instead map across
> a list or lists of arguments. This will probably solve all the problems
> (I think you're seeing SBCL being too precise in analyzing integer
> types, which is making the size of the types explode.)
>
> Paul
Thanks, will do.
Eric

Eric Blossom wrote:
> I'm running into control stack exhaustion when trying to
> compile a particular macro expansion (see below).
>
> I'm using SBCL 0.8.17 on x86 Linux 2.6.8
>
> Questions:
>
> (1) Can I increase the size of the control stack somehow?
> I RTFM, but didn't see anything relevant. Is it a function of my
> ram + swap or is there a (tunable) limit in SBCL?
>
> (2) Are there declarations, etc that I could add to the code to get it
> to compile?
>
> (3) Any other suggestions for getting this to compile, including
> idioms, restructuring, etc.
Get rid of all the separate calls to EX-FLOAT and instead map across
a list or lists of arguments. This will probably solve all the problems
(I think you're seeing SBCL being too precise in analyzing integer
types, which is making the size of the types explode.)
Paul

Hi all,
I've recently discovered that vectors with an array-element-type
of base-char cannot be printed readably using SBCL 0.8.18.11
on x86 Linux. Although this does seem to be legal according to
CLHS, regarding the double-quote reader creating strings of type
character and array similarity requirements, it is unfortunate
since the following code
(let ((*print-readably* t))
(open "/tmp/test.out" :direction :output))
fails with a PRINT-NOT-READABLE error due to namestring returning
a simple-base-string and make-fd-stream using the ~S format-directive
in the parameter list.
I don't know what an appropriate fix is but changing make-fd-stream
to use the ~A format-directive is a fix of sorts.
Regards,
Sean.
--
"My doctor says that I have a malformed public-duty gland and a
natural deficiency in moral fibre," he muttered to himself, "and
that I am therefore excused from saving Universes."
- Life, the Universe, and Everything Douglas Adams.

Milan Zamazal <pdm@...> writes:
> When I compile and load my Lisp software and try to save it with
> save-lisp-and-die in SBCL 0.8.18 from Debian i386, I receive the
> following response:
>
> [doing purification: roots handlers stack bindings static
> debugger invoked on a SIMPLE-ERROR in thread 28799:
> segmentation violation at #XB7EEF835
> [... yuk errors of doom ... ]
>
> Is there a way to find out more about that problem so that it can be
> fixed?
Ask the debian maintainer for the unstripped sbcl binary file. Then,
start sbcl, do everything until the save-lisp-and-die call. Attach
gdb (loading the symbol table from the unstripped binary -- this is
why you need it), call save-lisp-and-die, and find out what is
segfaulting. (It looks to be something in the C code).
Also, be very very sure before you go to all of this bother that you
haven't got any stale fasls loaded.
Cheers,
Christophe

When I compile and load my Lisp software and try to save it with
save-lisp-and-die in SBCL 0.8.18 from Debian i386, I receive the
following response:
[doing purification: roots handlers stack bindings static
debugger invoked on a SIMPLE-ERROR in thread 28799:
segmentation violation at #XB7EEF835
You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel).
1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
debugger invoked on a TYPE-ERROR in thread 28799:
The value NIL is not of type SB-DI:FRAME.
[...]
debugger invoked on a TYPE-ERROR in thread 28799:
The value NIL is not of type SB-DI:FRAME.
You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel).
1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
Help! 11 nested errors. SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
*
When I compile and load the same thing with SBCL 0.8.17 on the same
machine, everything works fine.
Is there a way to find out more about that problem so that it can be
fixed?
Thanks for any help.
Milan Zamazal
--
real programmer? don't get me started. if you need to hide your
pathetic excuse for a carreer behind super-macho languages like C, C++,
and/or Perl instead of writing clean, maintainable, efficient code, you
aren't much of a real programmer in my view. -- Erik Naggum in comp.emacs