common-lisp/sbcl.sbcl
1
0
Fork 0
mirror of git://git.code.sf.net/p/sbcl/sbcl synced 2026-09-10 07:26:40 -04:00
Code Issues Actions 8 Packages Projects Releases Wiki Activity

1.0.20.29: small FIND fix & win32 build fix

Browse source 
* FIND on lists should not call the KEY function outside the
   specified subsequence.

 * Hopefully fix Win32 build: #+/#- -> #!+/#!- changes to pacify
   SHE-READER.

 * Also advice against editing version.lisp-expr in Git, and show the
   branch-version.lisp-expr hack in GIT-FOR-SBCL-HACKERS.txt.
This commit is contained in:
Nikodemus Siivola 2008-09-24 14:55:13 +00:00
parent 28b2447f27
commit fdbbe74c27
7 changed files with 105 additions and 57 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
NEWS
View file

@ -16,6 +16,8 @@
safe.
* bug fix: SB-THREAD:CONDITION-WAIT doesn't allow waits on mutexes
owned by other threads anymore.
* bug fix: FIND on lists called KEY outside the specified
subsequence. (reported by budden)
changes in sbcl-1.0.20 relative to 1.0.19:
* minor incompatible change: OPTIMIZE qualities

96
doc/GIT-FOR-SBCL-HACKERS.txt
View file

@ -16,7 +16,7 @@ clone. At the time of writing there are two Git mirrors for the CVS
history:
git://sbcl.boinkor.net/sbcl.git
and
git://repo.or.cz/sbcl.git
@ -228,7 +228,7 @@ along the lines of "My private SBCL tree. Pulls from main sbcl.git
repository, and trickles changes back to upstream CVS manually --
from where they end up in sbcl.git. Turtles, you see." in the comment
box. Then you will be directed to set up an account, which you will
then have to add as a "pusher" to your SBCL fork.
then have to add as a "pusher" to your SBCL fork.
Finally, add the following snippet (adjusting for your own name) in
~/sbcl-git/.git/config
@ -250,29 +250,44 @@ and you can publish your own hacks on it via git-push.
Since we're not (yet?) officially using Git, we want to get our
changes back into the CVS. git-cvsexport is the perfect tool for this.
This assumes that you have a developer CVS checkout in ~/sbcl-cvs, and
wish to commit the changes you have wrought on branch foo-hacks
(compared to master):
git checkout -b foo-hacks-to-cvs master
git merge --squash foo-hacks
edit version.lisp-expr to be "CVS ready"
git commit -a # edit the message to be "CVS ready"
cd ~/sbcl-cvs
GIT_DIR=~/sbcl-git/.git git cvsexportcommit -v foo-hacks-to-cvs
review, fix any problems
cvs commit -F .msg
To make things a bit easier, add eg. this stanza to ~/sbcl-git/.git/config:
First, to make things a bit easier, we add a command of our own to
Git, by adding the following to ~/sbcl-git/.git/config:
[alias]
sbcl-export = ! cd ~/sbcl-cvs && GIT_DIR=~/sbcl-git/.git git-cvsexportcommit -v
sbcl-export = cvsexportcommit -w /home/yourname/sbcl-cvs -v
Then you can just run
This assumes that you have a developer CVS checkout in ~/sbcl-cvs.
git sbcl-export foo-hacks-to-cvs
To commit the the changes you have wrought on branch foo-hacks
(compared to master):
from inside ~/sbcl-git/, and have it prepare your CVS tree for commit.
# These three steps could be replaced by any other sequence that
# ends with all the changes you want to export to CVS at the top
# of the current branch (so that the final commit introduces all
# the changes.)
#
# In practice for small changes you may eg. just want to
#
# git checkout -b wip-fix-bug-xxx master
# ...fix bug on the branch...
# git commit -a
#
git checkout -b foo-hacks-to-cvs master
git merge --squash foo-hacks
git commit -a
# This exports our stuff to the CVS tree. HEAD can be any <<commit id>>,
# so if you have a large number of commits on a branch that you want to
# commit to CVS one by one, you do that as well.
git sbcl-export HEAD
cd ../sbcl-cvs
Review, fix problems, etc. Edit version.lisp-expr, and add the
version number to .msg (which contains the commit message from Git.)
cvs commit -F .msg
git-cvsexportcommit is fairly conservative by default, and will fail
if the patch doens't apply cleanly. If that happens, you can fix the
@ -296,9 +311,36 @@ foo-hacks, naming them
...
Due to, among other things, the cvs->git synchronization lag it is
easy to get conflicts on version.lisp-expr so you may want to delay
finalizing version.lisp-expr and the .msg file that cvsexportcommit
produced by bumping the version and adding it to the commit message.
easy to get conflicts on version.lisp-expr so generally speaking you
never want to edit version-lisp.expr in Git, and only edit it (and add
the version to the commit message) just when you are about to commit
to CVS. It is, however, nice to have an idea how a given image came to
be, which you can take care of by putting the following code in
branch-version.lisp-expr:
#.(flet ((git (command &rest args)
(with-output-to-string (s)
;; Adjust for your git installation location...
(sb-ext:run-program (merge-pathnames "bin/git" (user-homedir-pathname))
(cons command args) :output s))))
(format nil "~A.~A~@[-dirty~]"
(with-input-from-string (s (git "branch"))
(loop for line = (read-line s)
when (eql #\* (char line 0))
return (subseq line 2)))
(count #\newline (git "rev-list" "HEAD...master"))
(plusp (length (git "diff" "HEAD")))))
which leads to your Git tree build to have version names like
1.0.20.28.master.0-dirty
1.0.20.28 on branch master, uncommitted changes
1.0.20.19.wip-foo.4
1.0.20.19 on branch wip-foo, 4 commits between current HEAD and
master, no uncommitted changes.
To get latest changes from the CVS Git mirror you originally cloned
from, do
@ -318,10 +360,12 @@ Reading
http://eagain.net/articles/git-for-computer-scientists/
http://www.kernel.org/pub/software/scm/git/docs/everyday.html
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
and various Git manual pages is a good idea.
One command I can in particular recommend getting familiar with is
git-rebase. git-gui, git-citool, and gitk provide graphical interfaces
for working with Git -- particularly gitk is an invaluable tool for
Two commands I can in particular recommend getting familiar with are
git-rebase and git-cherry-pick.
git-gui, git-citool, and gitk provide graphical interfaces for
working with Git -- particularly gitk is an invaluable tool for
visualizing history.

4
src/code/fd-stream.lisp
View file

@ -821,10 +821,10 @@
;;; correct on win32. However, none of the places that use it require
;;; further assurance than "may" versus "will definitely not".
(defun sysread-may-block-p (stream)
#+win32
#!+win32
;; This answers T at EOF on win32, I think.
(not (sb!win32:fd-listen (fd-stream-fd stream)))
#-win32
#!-win32
(sb!unix:with-restarted-syscall (count errno)
(sb!alien:with-alien ((read-fds (sb!alien:struct sb!unix:fd-set)))
(sb!unix:fd-zero read-fds)

8
src/code/filesys.lisp
View file

@ -702,8 +702,8 @@ or if PATHSPEC is a wild pathname."
;; SBCL_HOME isn't set for :EXECUTABLE T embedded cores
(when (and sbcl-home (not (string= sbcl-home "")))
(parse-native-namestring sbcl-home
#-win32 sb!impl::*unix-host*
#+win32 sb!impl::*win32-host*
#!-win32 sb!impl::*unix-host*
#!+win32 sb!impl::*win32-host*
*default-pathname-defaults*
:as-directory t))))
@ -727,8 +727,8 @@ system."
;; What?! -- RMK, 2007-12-31
(return-from user-homedir-pathname
(sb!win32::get-folder-pathname sb!win32::csidl_profile)))
#-win32 sb!impl::*unix-host*
#+win32 sb!impl::*win32-host*
#!-win32 sb!impl::*unix-host*
#!+win32 sb!impl::*win32-host*
*default-pathname-defaults*
:as-directory t))))

48
src/compiler/seqtran.lisp
View file

@ -1105,31 +1105,31 @@
(sequence-bounding-indices-bad-error
sequence start end)
(values find position)))
(let ((key-i (funcall key i)))
(when (and end (>= index end))
(return (values find position)))
(when (>= index start)
(when (and end (>= index end))
(return (values find position)))
(when (>= index start)
(let ((key-i (funcall key i)))
(,',condition (funcall predicate key-i)
;; This hack of dealing with non-NIL
;; FROM-END for list data by iterating
;; forward through the list and keeping
;; track of the last time we found a match
;; might be more screwy than what the user
;; expects, but it seems to be allowed by
;; the ANSI standard. (And if the user is
;; screwy enough to ask for FROM-END
;; behavior on list data, turnabout is
;; fair play.)
;;
;; It's also not enormously efficient,
;; calling PREDICATE and KEY more often
;; than necessary; but all the
;; alternatives seem to have their own
;; efficiency problems.
(if from-end
(setf find i
position index)
(return (values i index))))))
;; This hack of dealing with non-NIL
;; FROM-END for list data by iterating
;; forward through the list and keeping
;; track of the last time we found a
;; match might be more screwy than what
;; the user expects, but it seems to be
;; allowed by the ANSI standard. (And
;; if the user is screwy enough to ask
;; for FROM-END behavior on list data,
;; turnabout is fair play.)
;;
;; It's also not enormously efficient,
;; calling PREDICATE and KEY more often
;; than necessary; but all the
;; alternatives seem to have their own
;; efficiency problems.
(if from-end
(setf find i
position index)
(return (values i index))))))
(incf index))))))
(def %find-position-if when)
(def %find-position-if-not unless))

2
tests/list.pure.lisp
View file

@ -370,3 +370,5 @@
(test '((42)) '((42)) '((42)) :key #'car)
(test '((42)) '((42)) '((42)) :key #'car :test-not #'<))
;;; FIND on lists should not call key outside the specified subsquence.
(assert (not (find :a '(0 (:c) 1) :start 1 :end 2 :key #'car)))

2
version.lisp-expr
View file

@ -17,4 +17,4 @@
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
"1.0.20.28"
"1.0.20.29"