From: William H. N. <wil...@ai...> - 2001-04-08 15:45:35
|
sbcl-0.7.0 will probably happen before hell freezes over, so I've been thinking about it a little bit. In particular, I've been planning a few disruptive things. If anyone has any suggestions or patches for disruptive things which need doing, or any comments about the disruptions listed below, let me know. Note that some of the planned changes (e.g. the renaming ones) will probably be really disruptive for anyone working on a separate branch (like Dan Barlow's Alpha branch, or any Windows NT branches). We could deal with this in various ways: * getting the ports stable really soon, so that they can be merged before this becomes an issue:-) * making the disruptive changes willy-nilly and just letting the porters suffer:-( * implementing any renaming-style changes by writing a script (in sed/perl/whatever) which does e.g. s/variable/var/, and running it on the main branch; then making the script available for people who are maintaining separate branches * merging the ports even if they're not stable yet, perhaps with #+/#- conditionalization and so forth to (only temporarily, please!) hide any really iffy parts from the main build * agreeing on a particular time period when the really disruptive changes will take place, and letting the porters arrange their affairs to minimize disruption (e.g. by getting ready to merge before then) * talking me out of making particularly disruptive changes at all * something else which hasn't occurred to me The disruptive changes I have in mind so far for 0.7.x, probably for small x, are: Make the incompatible changes listed in NEWS. Grep for FIXMEs with high disruptive potential and do them. E.g. * Search lists go away. * the big SB!CL repackaging in the FIXME note in DEFMACRO-MUNDANELY DEFCONSTANT * Get rid of SB-CONSTRAIN-FLOAT-TYPE, SB-PROPAGATE-FLOAT-TYPE, and SB-PROPAGATE-FUN-TYPE features; the code they control becomes unconditional. * Merge transforms and stuff from contrib/*-extras.lisp. * stems-and-flags.lisp-expr becomes src/cold/cold-stems-and-flags.lisp-expr Systematize names within the implementation: * Consistently use standard global abbreviations for FUN, VAR, LEXENV, ARG, INIT, INST(instruction), SEQ, and possibly others. (Maybe either DEF or DEFINE, but I'm not sure which. Too bad the ANSI spec itself isn't consistent here..) * Unabbreviate PRED into PREDICATE, to avoid ambiguity with the competing abbreviations PRED/SUCC. Possibly unabbreviate some other stuff too. * Things named COMPLEX for non-SIMPLE vectors/arrays become HAIRY instead. COMPLEX is reserved for numbers with potentially nonzero imaginary parts. * Perhaps add -P suffixes to more predicate names. (I like the idea, but I don't know any automated way of hunting down predicates to find the ones to rename, and I mightn't be motivated to just manually review all 3000 pages of source.) Old CMU CL documentation is no longer part of the main distribution package, but instead in a separate tarball. Redo debugger streams to try to be more standard in general, and especially to make it possible to use *DEBUG-IO* to talk with a Unix-filter-style program which has *STANDARD-INPUT* and *STANDARD-OUTPUT* bound to files, or to talk with a batch program which has *STANDARD-INPUT* bound to a script, and *STANDARD-OUTPUT* bound to a log. (Note that this is unfortunately likely to trip over lots of quirks and bugs in the old CMU CL debugger code.) * The debugger no longer rebinds *STANDARD-INPUT*, *STANDARD-OUTPUT*, or *ERROR-OUTPUT*. * The debugger does FINISH-OUTPUT *STANDARD-OUTPUT* before it starts its own output. * lots of tweaking of old CMU CL debugger code Try to remove the IR1 interpreter in favor of byte interpreter. Maybe redo the optimization-policy-dependence of various compiler stuff, to get better performance in the (>= COMPILATION-SPEED SPEED) case and perhaps for other reasons too. (I'd like to try this anyway; I dunno how well it will work.) -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Nathan F. <fr...@em...> - 2001-04-11 04:52:54
|
> * Search lists go away. Why is this? Can they just be done easier with standard logical pathnames and providing the "search list" extension simply makes things harder? > Systematize names within the implementation: > * Consistently use standard global abbreviations for > FUN, VAR, LEXENV, ARG, INIT, INST(instruction), > SEQ, and possibly others. (Maybe either DEF or > DEFINE, but I'm not sure which. Too bad the > ANSI spec itself isn't consistent here..) I think the general rule (maybe it's followed in the spec, I haven't really checked) is to use DEF when you have a single word or portion of a word (DEFCLASS, DEFSTRUCT, DEFMACRO, etc.) and use DEFINE when you have multiple words (DEFINE-METHOD-COMBINATION). > * Perhaps add -P suffixes to more predicate names. (I like > the idea, but I don't know any automated way > of hunting down predicates to find the ones > to rename, and I mightn't be motivated to just > manually review all 3000 pages of source.) Is this going to follow the general style (single word types get a P suffix, multiple word types get a -P suffix)? I might be willing to do this. -Nathan |
From: William H. N. <wil...@ai...> - 2001-04-12 00:21:14
|
On Tue, Apr 10, 2001 at 11:52:50PM -0500, Nathan Froyd wrote: > > * Search lists go away. > > Why is this? Can they just be done easier with standard logical > pathnames and providing the "search list" extension simply makes > things harder? I'm not sure they can be done with standard logical pathnames, but the functionality they provide can certainly be done with portable user-level code. > > Systematize names within the implementation: > > * Consistently use standard global abbreviations for > > FUN, VAR, LEXENV, ARG, INIT, INST(instruction), > > SEQ, and possibly others. (Maybe either DEF or > > DEFINE, but I'm not sure which. Too bad the > > ANSI spec itself isn't consistent here..) > > I think the general rule (maybe it's followed in the spec, I haven't > really checked) is to use DEF when you have a single word or portion > of a word (DEFCLASS, DEFSTRUCT, DEFMACRO, etc.) and use DEFINE when > you have multiple words (DEFINE-METHOD-COMBINATION). Hmm, you're right. I was remembering from a long time ago when I decided there's no reliable pattern, but I guess I mustn't have been looking at the ANSI spec, but at CMU CL: (defmacro def-bit-array-op (name function) (defmacro def-output-routines ((name-fmt size &rest bufferings) &body body) (defmacro def-input-routine (name (sb!xc:defmacro def-c-var-frob (lisp-fun c-var-name) (sb!xc:defmacro def-math-rtn (name num-args) (defmacro def-complex-format-directive (char lambda-list &body body) (defmacro def-format-directive (char lambda-list &body body) (defmacro def-alien-variable (name type &environment env) (defmacro def-alien-routine (name result-type &rest args &environment env) (sb!xc:defmacro def-complex-format-interpreter (char lambda-list &body body) etc. Looking at the 'D' section in the Hyperspec it appears that ANSI did follow your regular DEF/DEFINE rule. > > * Perhaps add -P suffixes to more predicate names. (I like > > the idea, but I don't know any automated way > > of hunting down predicates to find the ones > > to rename, and I mightn't be motivated to just > > manually review all 3000 pages of source.) > Is this going to follow the general style (single word types get a P > suffix, multiple word types get a -P suffix)? I might be willing to > do this. Yes, that was my intent. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Nathan F. <fr...@em...> - 2001-04-12 03:03:13
|
> On Tue, Apr 10, 2001 at 11:52:50PM -0500, Nathan Froyd wrote: > > > * Search lists go away. > > > > Why is this? Can they just be done easier with standard logical > > pathnames and providing the "search list" extension simply makes > > things harder? > > I'm not sure they can be done with standard logical pathnames, but > the functionality they provide can certainly be done with portable > user-level code. Hmmm...I guess the code from CMUCL/SBCL could just be ripped out and provided to the user. > > > Systematize names within the implementation: > > > * Consistently use standard global abbreviations for > > > FUN, VAR, LEXENV, ARG, INIT, INST(instruction), > > > SEQ, and possibly others. (Maybe either DEF or > > > DEFINE, but I'm not sure which. Too bad the > > > ANSI spec itself isn't consistent here..) I volunteer to help out here (this is one of my pet peeves when programming). Are you sure this has to wait until 0.7.x? Or can some of it start going in during 0.6.x? > > > > * Perhaps add -P suffixes to more predicate names. I volunteer myself for this, too. Or at least helping. :) -Nathan |
From: William H. N. <wil...@ai...> - 2001-04-12 14:14:34
|
On Wed, Apr 11, 2001 at 10:03:14PM -0500, Nathan Froyd wrote: > > On Tue, Apr 10, 2001 at 11:52:50PM -0500, Nathan Froyd wrote: > > > > Systematize names within the implementation: > > > > > * Consistently use standard global abbreviations for > > > > > FUN, VAR, LEXENV, ARG, INIT, INST(instruction), > > > > > SEQ, and possibly others. (Maybe either DEF or > > > > > DEFINE, but I'm not sure which. Too bad the > > > > > ANSI spec itself isn't consistent here..) > > I volunteer to help out here (this is one of my pet peeves when > programming). Are you sure this has to wait until 0.7.x? Or can some > of it start going in during 0.6.x? Actually, I'd been in the habit of doing a little of this as I went along, e.g. I actually turned all LEXICAL-ENVIRONMENT names into LEXENV some time ago. However, some time after Daniel Barlow started working on the Alpha port I started to think about minimizing pain for people working on other branches of the source. Perhaps distributing the changes as perl scripts would make that tractable, but I've never actually tried merging a big CVS branch, so I'm not sure. As long as the porters don't mind, though, or as long as they don't mind long as the changes are implemented in a branch-friendly form like sed/perl scripts, then I'd be happy to make changes like this at any time, not just in the burst of disruption around 0.7.0. Perhaps something like this (not properly tested): ----------------------------------------------------------------------- # Destructively perform various lexical transformations on every # source file in the SBCL source tree. # # Run this (as e.g. "perl /usr/tmp/foo.pl") with the current working # directory set to the SBCL distribution directory. # How shall we munge each line of the input? sub modified_line { my ($input_line) = @_; $_ = $input_line; s/def-alien-variable/define-bit-array-op/g; s/def-bit-array-op/define-bit-array-op/g; s/def-output-routines/define-output-routines/g; s/def-type-vops/define-type-vops/g; s/!def-vm-support-routine/!define-vm-support-routine/g; # etc. (and we probably also need to do some sort of magic to # handle the uppercase versions of the names found in comments) return $_; } # Munge them all, God will recognize his own. $temporary_file_name = "/usr/tmp/modify-sbcl-$$.tmp"; @source_file_names=`find . -name '*.lisp' -print`; for (@source_file_names) { $source_file_name = $_; open(ORIGINAL, "<$source_file_name") or die; open(MODIFIED, ">$temporary_file_name") or die; for (<ORIGINAL>) { print MODIFIED modified_line($_) or die; } close(ORIGINAL) or die; close(MODIFIED) or die; `mv $temporary_file_name $source_file_name`; } exit 0; ----------------------------------------------------------------------- -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Daniel B. <da...@no...> - 2001-04-12 22:07:46
|
William Harold Newman <wil...@ai...> writes: > Note that some of the planned changes (e.g. the renaming ones) will > probably be really disruptive for anyone working on a separate branch > (like Dan Barlow's Alpha branch, or any Windows NT branches). We could I've been slack on SBCL lately, having first moved house, then spent the last week on vacation (six whole days I didn't touch a computer ...) Current status is: it compiles, it rebuilds itself, it passes all tests but two (dynamic loading and "check the fasl extension is x86f") The problem is that it does this accidentally: updating from my working version (CVS of sometime in January) to current CVS makes it break, and I suspect that it is breaking for no better reasons than that GC is happening at "unlucky" times. I had similar symptoms before, which turned out to be that the var-alloc vop was putting non-descriptor values in a descriptor register without making it pseudo-atomic. So I'm _suspecting_ it's something similar but haven't yet found out if so or what. I hope there's a better (read: easier) way to find the problem than by inspecting all the vops that touch alloc-tn to see what they do with other registers. So, it works for me, but it's not ready for prime time. > * merging the ports even if they're not stable yet, perhaps with #+/#- > conditionalization and so forth to (only temporarily, please!) > hide any really iffy parts from the main build If you're amenable to this in principle, I think I could probably chop the Alpha port up into a number of patches which would make it easier to merge without destroying the x86 in the process. Off the top of my head (I haven't looked at it in a couple of weeks, so details may be iffy) you'd get 1) Alpha-specific files src/compiler/alpha/*.lisp, src/code/alpah-vm.lisp, etc - if you're not using these, their existence is unlikely to break anything 2) wrappers for "stat" syscalls, which I can test on x86 before sending you anyway 3) ugly C program to dig out values for constantcs from C header files (replaces some portion of unix.lisp) - again, can be tested on x86 4) patches to shell scripts and stuff to deal with the build mechanics 5) (if I get as far as fixing it anyway) some dynamic loading cleanups. 6) Various bits of commentary, which can probably be merged fairly easily if wanted. As far as I can see, (1) has no impact on x86 and (2) thru (5) imho will need doing anyway sooner or later. > Redo debugger streams to try to be more standard in general, > and especially to make it possible to use *DEBUG-IO* > to talk with a Unix-filter-style program which has [...] This reminds me that my hacked sbcl has the lowlevel "ldb" debugger open /dev/tty instead of using stdin, so that when make.sh stops with a GC assertion failure I have some chance to find out what happened. I'm not sure how this sits with the principle of least surprise; I think most people tend to be pretty surprised to get ldb> anyway, so perhaps it makes little difference. Anyway, I'm back now and with luck I have a bit more time to devote to this stuff. -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources |
From: Peter V. E. <pva...@de...> - 2001-04-13 21:18:17
|
On Thu, Apr 12, 2001 at 11:07:36PM +0100, Daniel Barlow wrote: > The problem is that it does this accidentally: updating from my > working version (CVS of sometime in January) to current CVS makes it > break, and I suspect that it is breaking for no better reasons than > that GC is happening at "unlucky" times. I had similar symptoms What I would do with cmucl is to do a binary search on the changes by 'time-travelling' with cvs. Use the '-D' flag I think to go to a certain date and see if it still works. It might be stupid but sometimes it is the only way... Groetjes, Peter -- It's logic Jim, but not as we know it. | pva...@de... "God, root, what is difference?" - Pitr| "God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/ |