From: William H. N. <wil...@ai...> - 2001-10-04 22:46:36
|
VERSION PATCH .39 MNA patch for fd-stream.lisp 2001-09-10 .39 Alexey Dejneka "Bug in EXPAND-DEFGENERIC" patch 2001-09-10 .39 Alexey Dejneka "strange behavior of DIRECTORY" bug report 2001-09-21, patch 2001-09-22 .39 Swap FunctionPointer and InstancePointer type codes for PPC convenience (dan 2001-09-22). .41 bug 126 fix Alexey Dejneka 2001-09-26 .42 Alexey Dejneka "bug 49-b*" patch 2001-09-30 .42 Alexey Dejneka "bug 81" patch 2001-09-30 .42 Alexey Dejneka "compiler/interpreter disagreement" patch 2001-10-02 (Or I *think* I'm caught up on the backlog of patches. I've been working to achieve the "two sigma, one nine" level of reliability on not dropping patches and other to-do items on the floor.:-| Ergo, since I took care of eight patches, there could easily be one (or more..) I overlooked. So please remind me if I'm missing something.) -- William Harold Newman <wil...@ai...> Where are we going and why am I in this handbasket? -- Daniel Demus <de...@so...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Daniel B. <da...@te...> - 2001-10-05 02:04:03
|
William Harold Newman <wil...@ai...> writes: > VERSION PATCH > .39 Swap FunctionPointer and InstancePointer type codes for PPC > convenience (dan 2001-09-22). Cool, thanks. Sometime this week I'll send you some endianness patches for GENESIS that both Christophe (SPARC) and I are using. I intend to forward-port the PPC backend to 0.7 (or whatever is current when it's finally done) before submitting most of it in one big lump, but there's no reason that easily separable chunks like that shouldn't go out separately in the meantime. -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources |
From: William H. N. <wil...@ai...> - 2001-10-06 15:04:33
|
I've made one recent change, and I'm planning to make a lot of other changes, which might affect people working on ports: -- deleted SYMBOL-UNUSED slot -- While I was removing dead code related to the long-gone GENGC garbage collector in 0.pre7.47 and 0.pre7.48, I noticed the UNUSED slot in SYMBOL (corresponding to the #!+X86 HASH slot) for the non-X86 ports. I'm pretty sure that the only reason to reserve that slot is to work around CMU CL bogobootstrapping/cross-compilation horrors involving layouts shared between host CMU CL and target CMU CL, so we shouldn't need it in SBCL, so I deleted it. But I don't have a non-X86 port to test it on, so there might be some problem, either for some deep reason I can't think of right now, or for some dumb reason like the old offset being hard-coded into C somewhere. -- upcoming renamings -- I still plan to rename a lot of stuff before 0.7.0, some of which will impact the interface to the Alpha, PPC, and SPARC ports. The Alpha code is in the source tree already, so when I do substitutions, I'll do them there too. But I'm not intrepid enough to hack onto your machines to do the substitutions in the PPC and SPARC code, so you'll have to do the updates yourself. My working plan is to do these renamings immediately, before deciding how much more debugging and cleanup I want to do before release as 0.7.0. (I'm considering releasing 0.7.0 with the compiler still flaky about debugging information and wimpy about inlining, since fixes for those should be incremental changes which can happen in a 0.7.x release.) My current list looks like this.. Systematize names in the Lisp code: SB-C::ENVIRONMENT and SB-C::IR2-ENVIRONMENT become SB-C::PHYSENV and SB-C::IR2-PHYSENV, to reflect what I learned in reverse engineering on the flaky5_branch Consistently use standard global abbreviations for FUN, VAR, LEXENV, ARG, INIT, INST(instruction), SEQ, OK (not OKAY), SAP, and possibly others. Consistently name things in the DEFFOO style when all one word, and DEFINE-FOO-BAR otherwise. Note that that affects some public extension names in the FFI, and we can deal with that by adding new names and deprecating the old ones.) another consistent abbreviation, this time both in Lisp and in C: PTR for POINTER (or INDEX, not POINTER or PTR, when it's actually an index) 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. some renaming for explicitness: %FUNCTION-FOO might become something like %SIMPLE-FUNCTION-FOO to distinguish from closures. (This is an old to-do item from before the removal of the byte interpreter, when there were many more ambiguities to disambiguate, and I need to look at it again now.) I would write TOPLEVEL, but CMU CL writes TOP-LEVEL. TOP-LEVEL is probably closer to the way that most people think, so rename everything that way. Reserve DO-FOO names for things which have to do with iteration (e.g. DOTIMES, DOVECTOR, DO-NODES DO-DEBUG-FUNCTION-BLOCKS). The other stuff which used to be named DO-FOO gets various other names, sometimes just dropping the DO- prefix, e.g. DO-ARG-COUNT-ERROR becomes ARG-COUNT-ERROR, sometimes using FROB-FOO instead, sometimes making less systematic changes. (I've flirted with the idea of -P suffixes to more predicate names, but I won't do it here. I don't know any automated way of hunting down predicates to find the ones to rename, and I'm not motivated to just manually review all 3000 pages of source.) Rename %PRIMITIVE to %VOP, and do the related renamings discussed in the KLUDGE/FIXME notes at the definition of DEF-IR1-TRANSLATOR %PRIMITIVE. Systematize names in the C code: redid many cpp macros as inline functions: LowtagOf, TypeOf (now tagof()), HeaderValue, Pointerp, CEILING, ALIGNED_SIZE, GET_FREE_POINTER, SET_FREE_POINTER, GET_GC_TRIGGER, SET_GC_TRIGGER, GetBSP, SetBSP, os_trunc_foo(), os_round_up_foo() removed various avoid-evaluating-C-macro-arg-twice cruft. renamed preprocessor definitions to uppercase: type_Mask, lowtag_Bits, lowtag_Mask, type_Bits (now N_TYPE_BITS). more renaming, decorating bootstrap-only stuff with #\!: DEFINE-STORAGE-CLASS DEFINE-STORAGE-BASE DEFINE-MOVE-FUNCTION DEFINE-MOVE-VOP DO-SC-PAIRS PRIMITIVE-TYPE-VOP PARSE-TEMPORARY PARSE-DEFINE-VOP PARSE-OPERAND-TYPES SET-UP-FUNCTION-TRANSLATION INHERIT-VOP-INFO SET-UP-VOP-INFO DEFINE-VOP DEF-TYPE-VOPS DEF-SIMPLE-TYPE-VOPS I might give up on some of this through impatience/exhaustion/whatever, or because I realize it's a bad idea for some other reason. And some things, like changing "pointer" to "index", aren't going to happen consistently (in this case both because it's too tedious and because Common Lisp itself is inconsistent in its terminology). If I notice myself doing anything particularly confusing along the way, I'll try to make explanatory notes. If y'all notice something confusing (or just plain stupid:-), feel free to ask about it. -- William Harold Newman <wil...@ai...> If it's not used, delete it, otherwise rename it.:-| PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Christophe R. <cs...@ca...> - 2001-10-06 15:22:47
|
On Sat, Oct 06, 2001 at 09:43:08AM -0500, William Harold Newman wrote: > I've made one recent change, and I'm planning to make a lot of other > changes, which might affect people working on ports: > > [snip] Thanks :-) There was something I noticed while grovelling in the code, though I don't know your position on this one. From seq.lisp: ;;; the deprecated functions FIND-IF-NOT and POSITION-IF-NOT. We don't ;;; bother to worry about optimizing them. ;;; ;;; FIXME: Remove uses of these deprecated functions (and of :TEST-NOT ;;; too) within the implementation of SBCL. My understanding is that while the :test-not argument is deprecated in favour of :test (complement #'foo) because of semantic difficulties (what happens if both :test and :test-not are supplied, etc) the -if-not variants, while officially deprecated, would be undeprecated were X3J13 actually to produce a revised standard, as there are perfectly legitimate idiomatic reasons for allowing the -if-not versions equal status, particularly remove-if-not (== filter). This is only an informal understanding, I grant you, but perhaps it's worth optimizing the -if-not versions in the same way as the others? Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: William H. N. <wil...@ai...> - 2001-10-06 17:07:41
|
On Sat, Oct 06, 2001 at 04:22:38PM +0100, Christophe Rhodes wrote: > There was something I noticed while grovelling in the code, though I > don't know your position on this one. From seq.lisp: > > ;;; the deprecated functions FIND-IF-NOT and POSITION-IF-NOT. We don't > ;;; bother to worry about optimizing them. > ;;; > ;;; FIXME: Remove uses of these deprecated functions (and of :TEST-NOT > ;;; too) within the implementation of SBCL. > > My understanding is that while the :test-not argument is deprecated in > favour of :test (complement #'foo) because of semantic difficulties > (what happens if both :test and :test-not are supplied, etc) the > -if-not variants, while officially deprecated, would be undeprecated > were X3J13 actually to produce a revised standard, as there are > perfectly legitimate idiomatic reasons for allowing the -if-not > versions equal status, particularly remove-if-not (== filter). > > This is only an informal understanding, I grant you, but perhaps it's > worth optimizing the -if-not versions in the same way as the others? Hmm, I didn't realize that. I do remember seeing something somewhere, perhaps in one of the X3J13 cleanup issues in the HyperSpec, someone commenting that REMOVE-IF-NOT is more idiomatic than REMOVE-IF to him, because of the FILTER issue. (I also remember agreeing wholeheartedly, because early in my Lisping days, perhaps while I was using Scheme, I wrote FILTER (calling it SUCH-THAT) and it seems more natural to me, too.) For now I won't worry much about it, since IMHO it's not too unreasonable for people who want efficiency not to use deprecated functions. But I'll paste some text from your comment in the fixme note, and a remark that someone is motivated to patch this, that's fine with me. Thanks for pointing it out. -- William Harold Newman <wil...@ai...> Where are we going and why am I in this handbasket? -- Daniel Demus <de...@so...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |