"Stas Boukarev" <stassats@...> writes:
> Is it possible for that extension to determine whether it is running
> on SBCL, otherwise do not load "swank-sbcl-exts.lisp". Because I run
> not only SBCL, and I get errors when loading that file.
In CVS. Thanks for the suggestion!
-T.

SBCL developer & MIPS hacker extraordinaire Thiemo Seufer has died in
a car accident. While on these lists probably best known for his work
on SBCL's MIPS backend, he was deeply involved with several open
source projects.
http://lwn.net/Articles/313092/
I regret not having known him personally outside SBCL lists and #lisp,
but I will miss him.
A sad ending for this year,
-- Nikodemus

On Tue, Dec 30, 2008 at 11:25 PM, Josh Elsasser <josh@...> wrote:
> The room.test.sh test in 1.0.23.70 currently fails on OpenBSD/i386,
> apparently due to ROOM consing excessively. The amount of space used
> for bignum objects roughly doubles with each ROOM call until it
> exhaunts the heap during the sixth call. If I add (gc :gen 1) to the
> inner loop in room.test.sh then the bignum objects are collected each
> time, a plain (gc) won't do it. A log with an unmodified room.test.sh
> is attached.
>
> Is it worth it to try to find the revision where this first started
> occuring, or does anyone have a better suggestion?
Finding the problematic commit would be good. As a starting point,
here's a list of commits since 1.0 that have touched
src/code/room.lisp:
1.0.23.40: export page sizes to C with LU suffix
1.0.19.1: DERIVE-TYPE optimizer for %%PRIMITIVE
1.0.13.21: MAP-ALLOCATED-OBJECTS robustification
1.0.12.1: more bogus FIXNUM declarations in ROOM
1.0.11.32: fix bogus fixnum declarations in ROOM
1.0.7.2: fix potential GC errors due to bogus objects in backtraces
1.0.6.22: fix occasional UNBOUND-VARIABLE errors in MAP-REFERENCING-OBJECTS
1.0.4.90: revert 1.0.4.89 changes to ROOM
1.0.4.89: ROOM cleanups & type-declaration fixes
1.0.4.48: ROOM patch by Lutz Euler
1.0.1.28: Fix SBCL on PPC with 65k pages.
I'm not averse to sticking a #+(and bsd (not darwin)) (gc :gen 1) at
the end of ROOM as a temporary measure, though, if that fixes the
problem (along with a honking big FIXME.)
> Also, while testing I discovered that the idiot that chose the
> addresses for the spaces on x86 (me) must have had his eyes closed at
> the time. Attached is a patch to fix them, and allow heap overflows
> to be handled(?) properly.
Thanks! Merged as 1.0.23.71 despite the freeze -- overlapping spaces
are quite nasty.
We should add some code to the runtime to check that the spaces don't
overlap... :)
Apropos, FreeBSD/OpenBSD/maybe-others-as-well problem in ROOM may have
to do with the entire dynamic-space address range being bignums.
Getting MAP-ALLOCATED-OBJECTS to use modular arithmetic for addresses
would be good -- and probably fix the consing issue.
> The THROW NO-SUCH-TAG tests in debug.impure.lisp fails as well. Is
> this something that's worth fixing, or should it just be marked as
> failing?
I've marked it as failing to start with -- though it is worth fixing of course!
Cheers,
-- Nikodemus

On Tue, Dec 30, 2008 at 8:31 PM, Tobias C. Rittweiler <tcr@...> wrote:
>
> To all IR2 hackers,
>
> I just committed a new contrib `slime-sbcl-exts' to Slime which is
> supposed to contain SBCL specific extensions and customization.
Is it possible for that extension to determine whether it is running
on SBCL, otherwise do not load "swank-sbcl-exts.lisp". Because I run
not only SBCL, and I get errors when loading that file.
--
With Best Regards, Stas.

The room.test.sh test in 1.0.23.70 currently fails on OpenBSD/i386,
apparently due to ROOM consing excessively. The amount of space used
for bignum objects roughly doubles with each ROOM call until it
exhaunts the heap during the sixth call. If I add (gc :gen 1) to the
inner loop in room.test.sh then the bignum objects are collected each
time, a plain (gc) won't do it. A log with an unmodified room.test.sh
is attached.
Is it worth it to try to find the revision where this first started
occuring, or does anyone have a better suggestion?
Also, while testing I discovered that the idiot that chose the
addresses for the spaces on x86 (me) must have had his eyes closed at
the time. Attached is a patch to fix them, and allow heap overflows
to be handled(?) properly.
The THROW NO-SUCH-TAG tests in debug.impure.lisp fails as well. Is
this something that's worth fixing, or should it just be marked as
failing?

To all IR2 hackers,
I just committed a new contrib `slime-sbcl-exts' to Slime which is
supposed to contain SBCL specific extensions and customization.
For a start, it'll make arglists of instructions be displayed, in e.g.
(sb-assem:inst mov
I shortly glanced at hacking up arglist display vor VOPs, too, but I
declined because of their complex arg definition scheme. If anyone got
some clue how to best present their argument information, do not
hesitate to comment.
-T.
PS: Make sure you use the `slime-fancy' contrib, too. I.e. place
(slime-stup '(slime-fancy slime-asdf slime-sbcl-exts))
into you ~/.emacs.

> ARRAY-IN-BOUNDS-P is only used by SBCL in an out of line PCL
> function. The reason ARRAY-IN-BOUNDS-P isn't optimized at all is
> simply that it's not used (internally) by anything that's expected to
> be efficient (e.g. inline array access), and it seems no one yet has
> complained about its performance. The transformation probably makes
> sense for arrays of small rank, if only to save space, but is there a
> practical reason you want ARRAY-IN-BOUNDS-P to be fast? There might be
> a better way.
Not an _entirely_ practical reason. I was mainly curious about how SBCL
compares to GCC, and whether CL might be an option for future projects
involving extensive calculations and backtracking searches; so I wrote a
simple netwalk-puzzle-solving algorithm in C++ and Lisp. This involves storing
both the puzzle and candidate solutions in rank 2 arrays of known sizes and
doing lots of bounds checks on them. Possibly the algorithm and/or data
representation could be improved; and certainly all occurences of array-in-
bounds-p could be substituted with (and (< -1 i size) (< -1 j size)) by hand,
but even if you (defconstant size ...) I feel that this is less readable and
harder to maintain (assuming something similar crops up in production code)
than a declaration plus compiler optimization. I appreciate this is partially
a matter of personal preference, though; and in any case not a huge issue.
Anyway, I've achieved what I wanted (having run GCC- and SBCL-generated code
at comparable speeds and found out how to tweak SBCL's compiler if need be),
and if I ever happen to need an efficient array-in-bounds-p for real
calculations, I can just include the transformation in my .sbclrc (which is
way cool btw - how many compilers can you hack so easily? ;-). I just thought
that this idiom might be common enough for other users to profit from including
the transformation (possibly adding some dependency on optimization settings
and/or array rank).
Knut

On 29-Dec-08, at 8:40 AM, Knut Franke wrote:
> I.e., using array-in-bounds-p in a tight loop on an array of known
> dimensions.
> Disassembling #'test shows that it contains a dynamic call to
> #'array-in-
> bounds-p, that I think can and should be optimized away in this case.
ARRAY-IN-BOUNDS-P is only used by SBCL in an out of line PCL
function. The reason ARRAY-IN-BOUNDS-P isn't optimized at all is
simply that it's not used (internally) by anything that's expected to
be efficient (e.g. inline array access), and it seems no one yet has
complained about its performance. The transformation probably makes
sense for arrays of small rank, if only to save space, but is there a
practical reason you want ARRAY-IN-BOUNDS-P to be fast? There might be
a better way.
Paul Khuong

[ Ooops - hit reply without noticing I was sending only to Erik, not the list.
Sorry. ]
> > I.e., using array-in-bounds-p in a tight loop on an array of known
> > dimensions. Disassembling #'test shows that it contains a dynamic call to
> > #'array-in- bounds-p, that I think can and should be optimized away in
> > this case.
>
> I don't see any declarations w.r.t. speed, safety, etc. Does a
> declaration for maximum speed (and minimum of the others) not achieve
> the same?
No. Even with these aggressive settings, there's still the dynamic call to
#'array-in-bounds-p; and timings are exactly the same (which is why I left out
the declaration).
Knut

On Mon, Dec 29, 2008 at 2:40 PM, Knut Franke <Knut.Franke@...> wrote:
> Hi,
>
> I was a bit curious after reading the claim somewhere that SBCL-compiled code
> could compete with gcc in terms of speed; and after playing around with it a
> bit I must say that I'm impressed. Congratulations. :-)
>
> However, here's a case I found to be handled sub-optimally:
>
> (defun test (i j)
> (declare (fixnum i j))
> (let ((a (make-array '(10 10))))
> (declare (type (simple-array * (10 10)) a))
> (dotimes (n 10000000)
> (unless (array-in-bounds-p a i j)
> ; need to do something with the result, so that the compiler
> ; doesn't optimize the call away altogether
> (return)))))
>
> I.e., using array-in-bounds-p in a tight loop on an array of known dimensions.
> Disassembling #'test shows that it contains a dynamic call to #'array-in-
> bounds-p, that I think can and should be optimized away in this case.
I don't see any declarations w.r.t. speed, safety, etc. Does a
declaration for maximum speed (and minimum of the others) not achieve
the same?
> After browsing through the SBCL source a bit, I came up with an automatic
> translation rule (see attached file bounds-p-tran.lisp). I successfully tested
> this with SBCL 1.0.22 and 1.0.23, measuring roughly a 56-76x (sic) speed-up of
> the above test case (which is then compiled with no dynamic function calls
> left at all). Given my limited knowledge of Lisp and SBCL internals, it could
> do with some review, but I think it may be eligible for inclusion into
> src/compiler/array-tran.lisp (or possibly something like contrib/compiler-
> extras.lisp if there are issues).
Bye,
Erik.

Hi,
I was a bit curious after reading the claim somewhere that SBCL-compiled code
could compete with gcc in terms of speed; and after playing around with it a
bit I must say that I'm impressed. Congratulations. :-)
However, here's a case I found to be handled sub-optimally:
(defun test (i j)
(declare (fixnum i j))
(let ((a (make-array '(10 10))))
(declare (type (simple-array * (10 10)) a))
(dotimes (n 10000000)
(unless (array-in-bounds-p a i j)
; need to do something with the result, so that the compiler
; doesn't optimize the call away altogether
(return)))))
I.e., using array-in-bounds-p in a tight loop on an array of known dimensions.
Disassembling #'test shows that it contains a dynamic call to #'array-in-
bounds-p, that I think can and should be optimized away in this case.
After browsing through the SBCL source a bit, I came up with an automatic
translation rule (see attached file bounds-p-tran.lisp). I successfully tested
this with SBCL 1.0.22 and 1.0.23, measuring roughly a 56-76x (sic) speed-up of
the above test case (which is then compiled with no dynamic function calls
left at all). Given my limited knowledge of Lisp and SBCL internals, it could
do with some review, but I think it may be eligible for inclusion into
src/compiler/array-tran.lisp (or possibly something like contrib/compiler-
extras.lisp if there are issues).
Knut

"Bruce O'Neel" <ecl@...> writes:
> Hi,
> Um, I think this change has to be undone for Sparc.
>
> Both Linux Sparc and NetBSD sparc won't build a running
> sbcl with the below. Sparcs are very picky about unaligned
> memory access, perfering to bus error rather than doing the
> unaligned access slowly.
>
> If one undoes this change than 1.0.23.70 builds and runs seemingly
> just fine.
Instead of reverting, does it help to use the patch as-is but change:
> > (inst andn ndescr 4)
to:
(inst andn ndescr lowtag-mask)
--
Juho Snellman

1. Under SBCL 1.0.14:
(defun foo (x)
(declare (type (and simple-bit-vector (satisfies bar)) x)
(elt x 5))
Under high speed policy, the compiler treats x as an hairy vector, so
it's slow. Without 'satisfies, it works fine of course. This could be
related to bug 408
2. I have Ubuntu 8.04, AMD64. I'd like to put a maximum size to the
program so that it doesn't hit the virtual memory, so I start with
sbcl --dynamic-space-size 200
When I get close to the 200 MB limit, SBCL gets into an endless loop,
printing the following message over and over again:
"Reached maximum space size during garbage collection; requested 32
bytes, got 0"
(the message is quoted from foggy memory, sorry, I can get the right
one if necessary, but it was clearly from SBCL, and it mentionned the
GC).
The process is then unkillable, which is another semi-frequent issue.
I don't know if that's a bug in Ubuntu, SBCL, or just my Unix skills
being insufficient.
Thanks!
Cédric

On Sun, Dec 28, 2008 at 01:05:32AM -0500, Daniel Herring wrote:
> Until someone else fetches your branch, you are free to rewrite
> history.
> You can even rewrite history after they fetch; but its generally poor
> ettiquette and they may have to do extra work to accept your change.
>
> * If you want to fix your last commit, `git commit --amend`
> ("Amend last commit" radio button in git-citool)
>
> * If you want to fix an earlier commit, here are some tools.
> # gitk --all& # update frequently to avoid confusion
> # git checkout -b tmp <last-good-hash>
> # git cherry-pick <single-commit> # good for reordering patches
> # git merge --squash <several-commits-to-merge>
And "git rebase --interactive", it's invaluable.
> # ...
> # git branch -D master # Delete the old master
> # git branch -m master # Call this branch master
> # git push --force <somewhere> master
>
> * If you botch your repository, `git fsck --lost-found` and browse the
> objects left in .git/lost-found/commit until you find your old
> master.
> In a long-lived repository, it is good to run git-gc occasionally
> (during safe times) to reduce the # of lost-found items.
Use "git log -g master" to see in the reflogs where your master has
been. (Or "git log -g HEAD" if you weren't working on a branch by
chance, but this is usually pretty messy.)
-bcd

On Sat, 27 Dec 2008, Tobias C. Rittweiler wrote:
> "Nikodemus Siivola" <nikodemus@...> writes:
>
>> * This branch is not a clean line of development: things like "Forgot
>> to change INTERN* in package-data-list." don't belong on a Git branch
>> proposed for merging. Sometimes things like that end up in CVS since
>> we're human and screw up occasionally, but as long as the branch is in
>> Git the mistake can be fixed and history left cleaner.
>
> How, BTW.?
Until someone else fetches your branch, you are free to rewrite history.
You can even rewrite history after they fetch; but its generally poor
ettiquette and they may have to do extra work to accept your change.
* If you want to fix your last commit, `git commit --amend`
("Amend last commit" radio button in git-citool)
* If you want to fix an earlier commit, here are some tools.
# gitk --all& # update frequently to avoid confusion
# git checkout -b tmp <last-good-hash>
# git cherry-pick <single-commit> # good for reordering patches
# git merge --squash <several-commits-to-merge>
# ...
# git branch -D master # Delete the old master
# git branch -m master # Call this branch master
# git push --force <somewhere> master
* If you botch your repository, `git fsck --lost-found` and browse the
objects left in .git/lost-found/commit until you find your old master.
In a long-lived repository, it is good to run git-gc occasionally
(during safe times) to reduce the # of lost-found items.
HTH,
Daniel

Hi,
I plan to release sbcl 1.0.24 on New Year's Eve. Until then, where
there are regressions, let there be fixes; where there are bugs, let
there be fixes; where there are obscure platforms, let there be
attempts to build the software.
Best,
Christophe

"Nikodemus Siivola" <nikodemus@...> writes:
> * This branch is not a clean line of development: things like "Forgot
> to change INTERN* in package-data-list." don't belong on a Git branch
> proposed for merging. Sometimes things like that end up in CVS since
> we're human and screw up occasionally, but as long as the branch is in
> Git the mistake can be fixed and history left cleaner.
How, BTW.?
-T.

"Nikodemus Siivola" <nikodemus@...> writes:
>
> * Unless there is a specific reason why it is not feasible, *please*
> send the relevant patches as attachments, each separate patch leaving
> the tree in a working state. If you think the work is easiest to
> understand in hindsight as a single patch, that's the way to go. If
> you think it's best split into a few separate patches, than so.
The branch was not supposed to be merged in directly. (I don't know how
that should ever work out as you're bumping the version with each
changeset, something that I cannot do in my tree.)
I thought using gitweb may be your preferred way of looking at patches.
I'll send seperate patches in a followup.
-T.

On Sat, Dec 27, 2008 at 6:22 PM, Tobias C. Rittweiler <tcr@...> wrote:
> I've worked towards fixing this bug. To fix it properly, some
> refactoring is needed because currently there is no way to determine the
> kind of token (symbol, or number) under consideration.
>
> While refactoring I found out that the refactoring could nicely address
> an old FIXME. Currently, for each explicitly given package qualifier, a
> new string is constructed.
>
> This consing is avoided in the following branch of my git repository:
>
> http://repo.or.cz/w/sbcl/tcr.git?a=shortlog;h=refs/heads/bug-310062
Thanks!
I gave the branch a *very* quick look. A few things:
* Commit message formatting: please use a style with a
one-line-summary followed by an empty line and the body.
Conterexample: http://repo.or.cz/w/sbcl/tcr.git?a=commit;h=e3d314b11ad5a32726bd31f4a386c041344f9475
. Also, please label whitespace changes as such, starting the first
line of the commit message with "whitespace" or something like that
for easy eyeballing of commit messages.
* This branch is not a clean line of development: things like "Forgot
to change INTERN* in package-data-list." don't belong on a Git branch
proposed for merging. Sometimes things like that end up in CVS since
we're human and screw up occasionally, but as long as the branch is in
Git the mistake can be fixed and history left cleaner.
* Unless there is a specific reason why it is not feasible, *please*
send the relevant patches as attachments, each separate patch leaving
the tree in a working state. If you think the work is easiest to
understand in hindsight as a single patch, that's the way to go. If
you think it's best split into a few separate patches, than so.
Sorry to be so stuck up about this, but patches in email are *really*
preferred for my workflow at least, and having things in email in
easy-to-review chunks that can be applied is much faster for me than
working against your tree directly. (From your Git tree I cannot tell
which revisions are expected to work on their own, and which are not.
In a directly mergeable branch I would expect all to be, but the
aformentioned "oops" commit makes it clear this is not the case.)
> PS: A few notes on what I did in the patches:
These are best made commit messages on the changes. (If you have a
clean line of development to pull the patches from, git format-patch
handles it rigth, if you're manually juggling the patches, adding the
relevant notes to the emails with the patches is fine as well.)
Cheers,
-- Nikodemus

"Tobias C. Rittweiler" <tcr@...> writes:
> While pursuing to fix [Bug #310062], I encountered the following border
> case I'd like to ask for your opinion: ...
I've worked towards fixing this bug. To fix it properly, some
refactoring is needed because currently there is no way to determine the
kind of token (symbol, or number) under consideration.
While refactoring I found out that the refactoring could nicely address
an old FIXME. Currently, for each explicitly given package qualifier, a
new string is constructed.
This consing is avoided in the following branch of my git repository:
http://repo.or.cz/w/sbcl/tcr.git?a=shortlog;h=refs/heads/bug-310062
I'll wait until this is merged before addressing Bug #310062 itself.
-T.
PS: A few notes on what I did in the patches:
* Split the automaton that validates and differentiates tokens into
its own function PARSE-TOKEN-FROM-STREAM. It's not called
PARSE-TOKEN because I'll later add a function PARSE-TOKEN that can
be used publically.
* READ-TOKEN is now built on top of PARSE-TOKEN-FROM-STREAM.
(The dispatch macro char for #: will later also be based on it.)
* To fix the package qualifier consing I had to write a function
FIND-PACKAGE* that works like FIND-SYMBOL*, i.e. that takes the
whole read-buffer and a length argument. For this:
- I renamed FIND-SYMBOL* and INTERN* to
FIND-SYMBOL-FROM-SUBSTRING and INTERN-FROM-SUBSTRING.
I also made these function take a START and an END, not just an
END argument as before.
- I implemented FIND-PACKAGE-FROM-SUBSTRING by using a customized
hash-table which is used to map package names to packageoids.
It is possible to use (LIST STRING START END) as key in that
hash-table to mean the same as (SUBSEQ STRING START END) but
without the consing. (Idea due to jsnell)
- I made what was previously a macro WITH-SYMBOL an inlined
function LOOKUP-SYMBOL, because I had to change this
functionality to also take a START into account. Making it a
function makes it more readable because previously the
definition was drowning in commata.
* For the customized hash-table, I also had to make
DEFINE-HASH-TABLE-TEST be available during cold init.

TC-Rucho writes:
> On Sat, 2008-12-13 at 09:01 -0500, Richard M Kreuter wrote:
> > TC-Rucho writes:
> >
> > > I was checking some weird test cases with broken links for the
> > > RESOLVE-SYMLINKS extention for CL:DIRECTORY and I found a minor
> > > inconsistency in it's behavior, also found that the extension was making
> > > an unnecessary call to SB-UNIX:UNIX-REALPATH so I took that out. I'm
> > > sending the complete unified diff for filesys.lisp Revision 1.75. I hope
> > > I found this and fixed it in time.
Thanks, committed in 1.0.23.70 (with a slight change for dangling or
self-referring symlinks).
--
Richard

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details