Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tag: sbcl_0_6_8
Commits on Oct 26, 2000
  1. 0.6.8: tweaked SXHASH DEFTRANSFORMs, fixed HANDLER-BIND

    William Harold Newman authored
Commits on Oct 25, 2000
  1. 0.6.7.26: fixed breakpoints on OpenBSD

    William Harold Newman authored
Commits on Oct 22, 2000
  1. 0.6.7.24: fixed some gcc warnings

    William Harold Newman authored
Commits on Oct 21, 2000
  1. 0.6.7.23: Use DEFTRANSFORM CONCATENATE for efficiency after all.

    William Harold Newman authored
Commits on Oct 20, 2000
  1. 0.6.7.22: removed CVS dollar-Header-dollar tags from sources

    William Harold Newman authored
  2. 0.6.7.21: a little less cut-and-paste programming in array.lisp

    William Harold Newman authored
  3. 0.6.7.20: removed DEFTRANSFORMs for some consing string operations

    William Harold Newman authored
  4. 0.6.7.19: added stop-compiler-crash patch from Martin Atzmueller

    William Harold Newman authored
  5. 0.6.7.18: FINISH-OUTPUT is now called more consistently on QUIT.

    William Harold Newman authored
Commits on Oct 19, 2000
  1. 0.6.7.17: revised fasl/core file version numbers

    William Harold Newman authored
Commits on Oct 18, 2000
  1. 0.6.7.15: control_stack stuff redone as Lisp/C constants

    William Harold Newman authored
  2. 0.6.7.14: Some constant C vars are now constants.

    William Harold Newman authored
Commits on Oct 17, 2000
  1. 0.6.7.13: dynamic-space simplification (only one dynamic space now)

    William Harold Newman authored
  2. 0.6.7.12: punted various multi-proc code, started cleaning up dynamic…

    William Harold Newman authored
    …-space
  3. 0.6.7.11: another step toward centralizing address map

    William Harold Newman authored
  4. a baby step where angels fear to tread.. I'm still heading for a

    William Harold Newman authored
    system where all address constants are defined in one place. I've been
    wandering around in a morass of increasingly broken systems (not just
    broken s/w -- a flaky graphics adaptor contributed h/w flakiness too)
    for quite a while. This version is starting over again with a small
    step forward from the last known working state of the system.
Commits on Oct 7, 2000
  1. a step along the way to setting address space parameters in just one …

    William Harold Newman authored
    …place
  2. a step along the way to setting address space parameters in just one …

    William Harold Newman authored
    …place
Commits on Oct 2, 2000
  1. tidied up OpenBSD-vs.-FreeBSD stuff, and src/runtime/Config.x86-*

    William Harold Newman authored
Commits on Sep 28, 2000
  1. cleanup of previous CVS-check-in mistakes

    William Harold Newman authored
    I did "cvs add" for files which I'd overlooked in previous checkins.
    I miss pcl-cvs.:-(
Commits on Sep 27, 2000
  1. cleanup related to RAW's port of RUN-PROGRAM:

    William Harold Newman authored
    comment fixes
    
    resurrected SB-UNIX:UNIX-DUP, SB-UNIX:UNIX-IOCTL, and
    SB-UNIX:UNIX-PIPE from old cmucl-2.4.8 sources (They'd been
    deleted before 'cause nothing used them, but now RUN-PROGRAM
    uses them.)
    
    wrote simple regression test for RUN-PROGRAM
    
    fixed dumb bug in QUIT :UNIX-STATUS (which had been exercised by
    RUN-PROGRAM regression test)
    
    made the "--noprint" option bind *LOAD-VERBOSE* to NIL (to help write
    friendly-to-Unix-pipeline test programs, to help write regression
    tests)
Commits on Sep 25, 2000
  1. integrated Raymond Wiker's patches to port RUN-PROGRAM from CMU CL and

    William Harold Newman authored
    to generalize dlopen()-ish stuff from Linux to FreeBSD
Commits on Sep 22, 2000
  1. primarily intending to integrate Colin Walter's O(N) map code and

    William Harold Newman authored
    fixing BUTLAST (but doing some other stuff too, since achieving the
    primary objective involved a lot of inspecting other code):
    
    another revision of MAP stuff, part I:
      * I switched over to code inspired by Colin Walters' O(N) MAP
        code (from the cmucl-imp mailing list 2000 Sep 02) for the
        general non-DEFTRANSFORM case.
      * HIGH-SECURITY-SUPPORT error checking logic goes away, pending
        part II
      * I made some  miscellaneous cleanups of old arity-1 code too.
      * The old MAP-FOR-EFFECT, MAP-TO-LIST, and MAP-TO-SIMPLE macros,
        and the old functions MAP-WITHOUT-ERRORCHECKING, and
        GET-MINIMUM-LENGTH-SEQUENCES go away.
      * The old #+!HIGH-SECURITY length-checking logic goes
        away, to be replaced by stuff in part II.
      * New O(N) functions %MAP-FOR-EFFECT, %MAP-TO-LIST, and
        %MAP-TO-VECTOR are added, and MAP is redefined in terms of them.
      * Add a note pointing out that since MAP-INTO has not been
        rewritten to take advantage of all the new mapping technology,
        it's still slow.
      * Delete no-longer-used ELT-SLICE macro.
    
    another revision of MAP stuff, part II: Peter Van Eynde might go into
    a killing frenzy, or at least his ansi-test suite will gnaw SBCL to
    death, unless we raise type errors on length mismatches like
      (MAP '(SIMPLE-VECTOR 128) #'+ #(1 2) #(1 1)).
    How to do this without clobbering efficiency? More DEFTRANSFORMs, I
    think..
      * MAP becomes a wrapper around %MAP. %MAP doesn't do this
        kind of length checking, MAP does. The old DEFUN MAP,
        DEFKNOWN MAP, and DEFTRANSFORM MAP stuff all turns into
        corresponding definitions for %MAP. The wrapper is
        implemented both as a DEFUN MAP and a DEFTRANSFORM MAP.
      * Now make DEFTRANSFORM MAP smarter:
        ** If necessary, check at runtime that ARRAY-DIMENSION
           matches what we pull out of SPECIFIER-TYPE.
        ** No test is done when SPEED > SAFETY.
        ** No test is needed when we can tell at compile time that
           the result type doesn't specify the length of the result.
      * Also add the same kind of ARRAY-DIMENSION/SPECIFIER-TYPE runtime
        check to DEFUN MAP.
      * While I'm at it, since DEFTRANSFORM MAP needs to think hard about
        the type of the result anyway, it might as well declare what
        it's figured out (TRULY-THE) to benefit any code downstream.
    
    Start playing with MAP regression tests. Add tests/assertoid.lisp to
    support future regression tests.
    
    Once I started using the QUIT :UNIX-CODE keyword argument in my test
    cases, I could see that it isn't very mnemonic. So I changed it to the
    more-descriptive name :UNIX-STATUS, leaving the old name supported but
    deprecated.
    
    Oops! The old DEFTRANSFORM MAP (now DEFTRANSFORM %MAP) should really
    only be done when (>= SPEED SPACE), but it wasn't declared that way.
    
    While looking for an example of a DEFTRANSFORM with &REST arguments
    to use as a model for the code in the new DEFTRANSFORM from MAP to
    %MAP, I noticed that the problem of taking a list of names and
    generating a corresponding list of gensyms is solved in many different
    places in the code, in several ways. Also, the related problem of just
    creating a list of N gensyms is solved in several places in in the
    code. This seems unnecessarily error-prone and wasteful, so I went
    looking for such cases and turned them into calls to MAKE-GENSYM-LIST.
    
    another revision of MAP stuff, part III:
      * Search for 'map' in the output from clocc ansi-tests/tests.lisp,
        to check that the new MAP code isn't too obviously broken.
      * Add some regression tests in test/map.impure.lisp.
    
    Oops! The various %MAP-..-ARITY-1 helper functions expect a function
    argument, but DEFTRANSFORM MAP can call them passing them a function
    name instead.
      * Change the helper functions so that they can handle
        function names as arguments.
      * Define %COERCE-CALLABLE-TO-FUNCTION to help with this. Note that
        this seems to be what %COERCE-NAME-TO-FUNCTION meant long ago,
        judging from DEFTRANSFORM %COERCE-NAME-TO-FUNCTION; so
        appropriate that DEFTRANSFORM for %COERCE-CALLABLE-TO-FUNCTION.
      * Use %COERCE-CALLABLE-TO-FUNCTION elsewhere that expressions
        involving %COERCE-NAME-TO-FUNCTION were used previously.
    
    deleted the old commented-out version of DEFMACRO HANDLER-CASE
    (since it was marked "Delete this when the system is stable.":-)
    
    deleted the old commented-out version of GEN-FORMAT-DEF-FORM,
    since it was supposed to be safe to do so after sbcl-0.6.4
    
    I removed the apology for not using PRINT-OBJECT everywhere in the
    printer from the bugs list in the man page, since it seems to be
    rather tricky to construct a test case which exposes the system's
    non-PRINT-OBJECT-ness without the test case itself violating the ANSI
    spec.
    
    I updated, cleaned up, or removed outright some other outdated or
    confusing entries in the BUGS file and from the bugs list on the man
    page.
    
    Now that BUTLAST no longer blows up on the new problem cases a la
    (BUTLAST NIL -1), I wonder whether I could stop it from blowing
    up on the old problem cases a la (BUTLAST NIL)? It looks like
    a compiler problem, since the interpreted definition of BUTLAST works,
    even though the compiled one doesn't. In fact, it's a declaration
    problem, since LENGTH is set to -1 when LIST=NIL, but is declared
    as an INDEX. (Of course it's likely also a compiler problem, since
    the compiler is supposed to signal type errors for this kind of
    declaration error.) I fixed the misdeclaration, and noted the
    possible compiler bug in BUGS.
    
    After writing the new revised weird type declarations for the
    not-necessarily positive LENGTH, and writing explanatory comments,
      ;; (Despite the name, LENGTH can be -1 when when LIST is an ATOM.)
    for each of the cut-and-pasted (LET ((LENGTH ..)) ..) forms in BUTLAST
    and NBUTLAST, I said "screw it" -- no, that's not it, I quoted Martin
    Fowler and Kent Beck: "If you see the same code structure in more than
    one place, you can be sure that your program will be better if you
    find a way to unify them," and "It's surprising how often you look at
    thickly commented code and notice that the comments are there because
    the code is bad." So I just rewrote BUTLAST and NBUTLAST. Hopefully
    the new versions will be better-behaved than the old ones.
    
    Now that the INDEX type is used in DEFUN MAKE-GENSYM-LIST, which
    belongs in early-extensions.lisp, INDEX should be defined before
    early-extensions.lisp, i.e. earlier than its current definition in
    early-c.lisp. Move it to early-extensions.lisp. Then to make that
    work, since DEF!TYPE is used to define INDEX, defbangtype.lisp needs
    to precede early-extensions.lisp in stems-and-flags.lisp-expr; so move
    it. Also, INDEX is defined in terms of SB!XC:ARRAY-DIMENSION-LIMIT, so
    early-array.lisp needs to move before the new location of
    defbangtype.lisp. And then early-vm.lisp needs to move before that, so
    I might as well move the rest of the early-vm-ish stuff back too. And
    then DEFTYPE is used before deftype.lisp, so I need to change DEFMACRO
    DEF!TYPE to DEF!MACRO DEF!TYPE, so I need to move defbangmacro.lisp
    before deftype.lisp. (This is like a trip down memory lane to the
    endless tweaks and recompiles it took me to find and unravel the
    twisted order dependencies which make CMU CL unbootstrappable. Ah,
    those were the days..:-)
    
    The DEFTYPEs for INDEX and POSN in early-assem.lisp duplicate
    the functionality of the SB-KERNEL:INDEX type.
      * Change uses of the SB-ASSEM::POSN type to uses of the INDEX type.
      * Delete the SB-ASSEM::POSN type and the SB-ASSEM::MAX-POSN constant.
      * Move SB-KERNEL:INDEX into SB-INT, since it's not really
        just a kernel-level thing, but makes sense for implementing
        user-level stuff in SB-INT and SB-EXT and SB-C (and SB-ASSEM).
      * Grep for all '[a-z]:+index[^-a-z]' and rename them (or just
        remove prefixes) to match new SB-INT-ness of INDEX.
      * Make the SB-ASSEM package use the SB-INT package; delete
        the SB-ASSEM::INDEX type and SB-ASSEM::MAX-INDEX constant.
        And since as a rule anything which can see SB-INT deserves
        to see SB-EXT too, make SB-ASSEM use SB-EXT as well.
  2. primarily intending to integrate Colin Walter's O(N) map code and

    William Harold Newman authored
    fixing BUTLAST (but doing some other stuff too, since achieving the
    primary objective involved a lot of inspecting other code):
    
    another revision of MAP stuff, part I:
      * I switched over to code inspired by Colin Walters' O(N) MAP
        code (from the cmucl-imp mailing list 2000 Sep 02) for the
        general non-DEFTRANSFORM case.
      * HIGH-SECURITY-SUPPORT error checking logic goes away, pending
        part II
      * I made some  miscellaneous cleanups of old arity-1 code too.
      * The old MAP-FOR-EFFECT, MAP-TO-LIST, and MAP-TO-SIMPLE macros,
        and the old functions MAP-WITHOUT-ERRORCHECKING, and
        GET-MINIMUM-LENGTH-SEQUENCES go away.
      * The old #+!HIGH-SECURITY length-checking logic goes
        away, to be replaced by stuff in part II.
      * New O(N) functions %MAP-FOR-EFFECT, %MAP-TO-LIST, and
        %MAP-TO-VECTOR are added, and MAP is redefined in terms of them.
      * Add a note pointing out that since MAP-INTO has not been
        rewritten to take advantage of all the new mapping technology,
        it's still slow.
      * Delete no-longer-used ELT-SLICE macro.
    
    another revision of MAP stuff, part II: Peter Van Eynde might go into
    a killing frenzy, or at least his ansi-test suite will gnaw SBCL to
    death, unless we raise type errors on length mismatches like
      (MAP '(SIMPLE-VECTOR 128) #'+ #(1 2) #(1 1)).
    How to do this without clobbering efficiency? More DEFTRANSFORMs, I
    think..
      * MAP becomes a wrapper around %MAP. %MAP doesn't do this
        kind of length checking, MAP does. The old DEFUN MAP,
        DEFKNOWN MAP, and DEFTRANSFORM MAP stuff all turns into
        corresponding definitions for %MAP. The wrapper is
        implemented both as a DEFUN MAP and a DEFTRANSFORM MAP.
      * Now make DEFTRANSFORM MAP smarter:
        ** If necessary, check at runtime that ARRAY-DIMENSION
           matches what we pull out of SPECIFIER-TYPE.
        ** No test is done when SPEED > SAFETY.
        ** No test is needed when we can tell at compile time that
           the result type doesn't specify the length of the result.
      * Also add the same kind of ARRAY-DIMENSION/SPECIFIER-TYPE runtime
        check to DEFUN MAP.
      * While I'm at it, since DEFTRANSFORM MAP needs to think hard about
        the type of the result anyway, it might as well declare what
        it's figured out (TRULY-THE) to benefit any code downstream.
    
    Start playing with MAP regression tests. Add tests/assertoid.lisp to
    support future regression tests.
    
    Once I started using the QUIT :UNIX-CODE keyword argument in my test
    cases, I could see that it isn't very mnemonic. So I changed it to the
    more-descriptive name :UNIX-STATUS, leaving the old name supported but
    deprecated.
    
    Oops! The old DEFTRANSFORM MAP (now DEFTRANSFORM %MAP) should really
    only be done when (>= SPEED SPACE), but it wasn't declared that way.
    
    While looking for an example of a DEFTRANSFORM with &REST arguments
    to use as a model for the code in the new DEFTRANSFORM from MAP to
    %MAP, I noticed that the problem of taking a list of names and
    generating a corresponding list of gensyms is solved in many different
    places in the code, in several ways. Also, the related problem of just
    creating a list of N gensyms is solved in several places in in the
    code. This seems unnecessarily error-prone and wasteful, so I went
    looking for such cases and turned them into calls to MAKE-GENSYM-LIST.
    
    another revision of MAP stuff, part III:
      * Search for 'map' in the output from clocc ansi-tests/tests.lisp,
        to check that the new MAP code isn't too obviously broken.
      * Add some regression tests in test/map.impure.lisp.
    
    Oops! The various %MAP-..-ARITY-1 helper functions expect a function
    argument, but DEFTRANSFORM MAP can call them passing them a function
    name instead.
      * Change the helper functions so that they can handle
        function names as arguments.
      * Define %COERCE-CALLABLE-TO-FUNCTION to help with this. Note that
        this seems to be what %COERCE-NAME-TO-FUNCTION meant long ago,
        judging from DEFTRANSFORM %COERCE-NAME-TO-FUNCTION; so
        appropriate that DEFTRANSFORM for %COERCE-CALLABLE-TO-FUNCTION.
      * Use %COERCE-CALLABLE-TO-FUNCTION elsewhere that expressions
        involving %COERCE-NAME-TO-FUNCTION were used previously.
    
    deleted the old commented-out version of DEFMACRO HANDLER-CASE
    (since it was marked "Delete this when the system is stable.":-)
    
    deleted the old commented-out version of GEN-FORMAT-DEF-FORM,
    since it was supposed to be safe to do so after sbcl-0.6.4
    
    I removed the apology for not using PRINT-OBJECT everywhere in the
    printer from the bugs list in the man page, since it seems to be
    rather tricky to construct a test case which exposes the system's
    non-PRINT-OBJECT-ness without the test case itself violating the ANSI
    spec.
    
    I updated, cleaned up, or removed outright some other outdated or
    confusing entries in the BUGS file and from the bugs list on the man
    page.
    
    Now that BUTLAST no longer blows up on the new problem cases a la
    (BUTLAST NIL -1), I wonder whether I could stop it from blowing
    up on the old problem cases a la (BUTLAST NIL)? It looks like
    a compiler problem, since the interpreted definition of BUTLAST works,
    even though the compiled one doesn't. In fact, it's a declaration
    problem, since LENGTH is set to -1 when LIST=NIL, but is declared
    as an INDEX. (Of course it's likely also a compiler problem, since
    the compiler is supposed to signal type errors for this kind of
    declaration error.) I fixed the misdeclaration, and noted the
    possible compiler bug in BUGS.
    
    After writing the new revised weird type declarations for the
    not-necessarily positive LENGTH, and writing explanatory comments,
      ;; (Despite the name, LENGTH can be -1 when when LIST is an ATOM.)
    for each of the cut-and-pasted (LET ((LENGTH ..)) ..) forms in BUTLAST
    and NBUTLAST, I said "screw it" -- no, that's not it, I quoted Martin
    Fowler and Kent Beck: "If you see the same code structure in more than
    one place, you can be sure that your program will be better if you
    find a way to unify them," and "It's surprising how often you look at
    thickly commented code and notice that the comments are there because
    the code is bad." So I just rewrote BUTLAST and NBUTLAST. Hopefully
    the new versions will be better-behaved than the old ones.
    
    Now that the INDEX type is used in DEFUN MAKE-GENSYM-LIST, which
    belongs in early-extensions.lisp, INDEX should be defined before
    early-extensions.lisp, i.e. earlier than its current definition in
    early-c.lisp. Move it to early-extensions.lisp. Then to make that
    work, since DEF!TYPE is used to define INDEX, defbangtype.lisp needs
    to precede early-extensions.lisp in stems-and-flags.lisp-expr; so move
    it. Also, INDEX is defined in terms of SB!XC:ARRAY-DIMENSION-LIMIT, so
    early-array.lisp needs to move before the new location of
    defbangtype.lisp. And then early-vm.lisp needs to move before that, so
    I might as well move the rest of the early-vm-ish stuff back too. And
    then DEFTYPE is used before deftype.lisp, so I need to change DEFMACRO
    DEF!TYPE to DEF!MACRO DEF!TYPE, so I need to move defbangmacro.lisp
    before deftype.lisp. (This is like a trip down memory lane to the
    endless tweaks and recompiles it took me to find and unravel the
    twisted order dependencies which make CMU CL unbootstrappable. Ah,
    those were the days..:-)
    
    The DEFTYPEs for INDEX and POSN in early-assem.lisp duplicate
    the functionality of the SB-KERNEL:INDEX type.
      * Change uses of the SB-ASSEM::POSN type to uses of the INDEX type.
      * Delete the SB-ASSEM::POSN type and the SB-ASSEM::MAX-POSN constant.
      * Move SB-KERNEL:INDEX into SB-INT, since it's not really
        just a kernel-level thing, but makes sense for implementing
        user-level stuff in SB-INT and SB-EXT and SB-C (and SB-ASSEM).
      * Grep for all '[a-z]:+index[^-a-z]' and rename them (or just
        remove prefixes) to match new SB-INT-ness of INDEX.
      * Make the SB-ASSEM package use the SB-INT package; delete
        the SB-ASSEM::INDEX type and SB-ASSEM::MAX-INDEX constant.
        And since as a rule anything which can see SB-INT deserves
        to see SB-EXT too, make SB-ASSEM use SB-EXT as well.
  3. primarily intending to integrate Colin Walter's O(N) map code and

    William Harold Newman authored
    fixing BUTLAST (but doing some other stuff too, since achieving the
    primary objective involved a lot of inspecting other code):
    
    another revision of MAP stuff, part I:
      * I switched over to code inspired by Colin Walters' O(N) MAP
        code (from the cmucl-imp mailing list 2000 Sep 02) for the
        general non-DEFTRANSFORM case.
      * HIGH-SECURITY-SUPPORT error checking logic goes away, pending
        part II
      * I made some  miscellaneous cleanups of old arity-1 code too.
      * The old MAP-FOR-EFFECT, MAP-TO-LIST, and MAP-TO-SIMPLE macros,
        and the old functions MAP-WITHOUT-ERRORCHECKING, and
        GET-MINIMUM-LENGTH-SEQUENCES go away.
      * The old #+!HIGH-SECURITY length-checking logic goes
        away, to be replaced by stuff in part II.
      * New O(N) functions %MAP-FOR-EFFECT, %MAP-TO-LIST, and
        %MAP-TO-VECTOR are added, and MAP is redefined in terms of them.
      * Add a note pointing out that since MAP-INTO has not been
        rewritten to take advantage of all the new mapping technology,
        it's still slow.
      * Delete no-longer-used ELT-SLICE macro.
    
    another revision of MAP stuff, part II: Peter Van Eynde might go into
    a killing frenzy, or at least his ansi-test suite will gnaw SBCL to
    death, unless we raise type errors on length mismatches like
      (MAP '(SIMPLE-VECTOR 128) #'+ #(1 2) #(1 1)).
    How to do this without clobbering efficiency? More DEFTRANSFORMs, I
    think..
      * MAP becomes a wrapper around %MAP. %MAP doesn't do this
        kind of length checking, MAP does. The old DEFUN MAP,
        DEFKNOWN MAP, and DEFTRANSFORM MAP stuff all turns into
        corresponding definitions for %MAP. The wrapper is
        implemented both as a DEFUN MAP and a DEFTRANSFORM MAP.
      * Now make DEFTRANSFORM MAP smarter:
        ** If necessary, check at runtime that ARRAY-DIMENSION
           matches what we pull out of SPECIFIER-TYPE.
        ** No test is done when SPEED > SAFETY.
        ** No test is needed when we can tell at compile time that
           the result type doesn't specify the length of the result.
      * Also add the same kind of ARRAY-DIMENSION/SPECIFIER-TYPE runtime
        check to DEFUN MAP.
      * While I'm at it, since DEFTRANSFORM MAP needs to think hard about
        the type of the result anyway, it might as well declare what
        it's figured out (TRULY-THE) to benefit any code downstream.
    
    Start playing with MAP regression tests. Add tests/assertoid.lisp to
    support future regression tests.
    
    Once I started using the QUIT :UNIX-CODE keyword argument in my test
    cases, I could see that it isn't very mnemonic. So I changed it to the
    more-descriptive name :UNIX-STATUS, leaving the old name supported but
    deprecated.
    
    Oops! The old DEFTRANSFORM MAP (now DEFTRANSFORM %MAP) should really
    only be done when (>= SPEED SPACE), but it wasn't declared that way.
    
    While looking for an example of a DEFTRANSFORM with &REST arguments
    to use as a model for the code in the new DEFTRANSFORM from MAP to
    %MAP, I noticed that the problem of taking a list of names and
    generating a corresponding list of gensyms is solved in many different
    places in the code, in several ways. Also, the related problem of just
    creating a list of N gensyms is solved in several places in in the
    code. This seems unnecessarily error-prone and wasteful, so I went
    looking for such cases and turned them into calls to MAKE-GENSYM-LIST.
    
    another revision of MAP stuff, part III:
      * Search for 'map' in the output from clocc ansi-tests/tests.lisp,
        to check that the new MAP code isn't too obviously broken.
      * Add some regression tests in test/map.impure.lisp.
    
    Oops! The various %MAP-..-ARITY-1 helper functions expect a function
    argument, but DEFTRANSFORM MAP can call them passing them a function
    name instead.
      * Change the helper functions so that they can handle
        function names as arguments.
      * Define %COERCE-CALLABLE-TO-FUNCTION to help with this. Note that
        this seems to be what %COERCE-NAME-TO-FUNCTION meant long ago,
        judging from DEFTRANSFORM %COERCE-NAME-TO-FUNCTION; so
        appropriate that DEFTRANSFORM for %COERCE-CALLABLE-TO-FUNCTION.
      * Use %COERCE-CALLABLE-TO-FUNCTION elsewhere that expressions
        involving %COERCE-NAME-TO-FUNCTION were used previously.
    
    deleted the old commented-out version of DEFMACRO HANDLER-CASE
    (since it was marked "Delete this when the system is stable.":-)
    
    deleted the old commented-out version of GEN-FORMAT-DEF-FORM,
    since it was supposed to be safe to do so after sbcl-0.6.4
    
    I removed the apology for not using PRINT-OBJECT everywhere in the
    printer from the bugs list in the man page, since it seems to be
    rather tricky to construct a test case which exposes the system's
    non-PRINT-OBJECT-ness without the test case itself violating the ANSI
    spec.
    
    I updated, cleaned up, or removed outright some other outdated or
    confusing entries in the BUGS file and from the bugs list on the man
    page.
    
    Now that BUTLAST no longer blows up on the new problem cases a la
    (BUTLAST NIL -1), I wonder whether I could stop it from blowing
    up on the old problem cases a la (BUTLAST NIL)? It looks like
    a compiler problem, since the interpreted definition of BUTLAST works,
    even though the compiled one doesn't. In fact, it's a declaration
    problem, since LENGTH is set to -1 when LIST=NIL, but is declared
    as an INDEX. (Of course it's likely also a compiler problem, since
    the compiler is supposed to signal type errors for this kind of
    declaration error.) I fixed the misdeclaration, and noted the
    possible compiler bug in BUGS.
    
    After writing the new revised weird type declarations for the
    not-necessarily positive LENGTH, and writing explanatory comments,
      ;; (Despite the name, LENGTH can be -1 when when LIST is an ATOM.)
    for each of the cut-and-pasted (LET ((LENGTH ..)) ..) forms in BUTLAST
    and NBUTLAST, I said "screw it" -- no, that's not it, I quoted Martin
    Fowler and Kent Beck: "If you see the same code structure in more than
    one place, you can be sure that your program will be better if you
    find a way to unify them," and "It's surprising how often you look at
    thickly commented code and notice that the comments are there because
    the code is bad." So I just rewrote BUTLAST and NBUTLAST. Hopefully
    the new versions will be better-behaved than the old ones.
    
    Now that the INDEX type is used in DEFUN MAKE-GENSYM-LIST, which
    belongs in early-extensions.lisp, INDEX should be defined before
    early-extensions.lisp, i.e. earlier than its current definition in
    early-c.lisp. Move it to early-extensions.lisp. Then to make that
    work, since DEF!TYPE is used to define INDEX, defbangtype.lisp needs
    to precede early-extensions.lisp in stems-and-flags.lisp-expr; so move
    it. Also, INDEX is defined in terms of SB!XC:ARRAY-DIMENSION-LIMIT, so
    early-array.lisp needs to move before the new location of
    defbangtype.lisp. And then early-vm.lisp needs to move before that, so
    I might as well move the rest of the early-vm-ish stuff back too. And
    then DEFTYPE is used before deftype.lisp, so I need to change DEFMACRO
    DEF!TYPE to DEF!MACRO DEF!TYPE, so I need to move defbangmacro.lisp
    before deftype.lisp. (This is like a trip down memory lane to the
    endless tweaks and recompiles it took me to find and unravel the
    twisted order dependencies which make CMU CL unbootstrappable. Ah,
    those were the days..:-)
    
    The DEFTYPEs for INDEX and POSN in early-assem.lisp duplicate
    the functionality of the SB-KERNEL:INDEX type.
      * Change uses of the SB-ASSEM::POSN type to uses of the INDEX type.
      * Delete the SB-ASSEM::POSN type and the SB-ASSEM::MAX-POSN constant.
      * Move SB-KERNEL:INDEX into SB-INT, since it's not really
        just a kernel-level thing, but makes sense for implementing
        user-level stuff in SB-INT and SB-EXT and SB-C (and SB-ASSEM).
      * Grep for all '[a-z]:+index[^-a-z]' and rename them (or just
        remove prefixes) to match new SB-INT-ness of INDEX.
      * Make the SB-ASSEM package use the SB-INT package; delete
        the SB-ASSEM::INDEX type and SB-ASSEM::MAX-INDEX constant.
        And since as a rule anything which can see SB-INT deserves
        to see SB-EXT too, make SB-ASSEM use SB-EXT as well.
  4. primarily intending to integrate Colin Walter's O(N) map code and

    William Harold Newman authored
    fixing BUTLAST (but doing some other stuff too, since achieving the
    primary objective involved a lot of inspecting other code):
    
    another revision of MAP stuff, part I:
      * I switched over to code inspired by Colin Walters' O(N) MAP
        code (from the cmucl-imp mailing list 2000 Sep 02) for the
        general non-DEFTRANSFORM case.
      * HIGH-SECURITY-SUPPORT error checking logic goes away, pending
        part II
      * I made some  miscellaneous cleanups of old arity-1 code too.
      * The old MAP-FOR-EFFECT, MAP-TO-LIST, and MAP-TO-SIMPLE macros,
        and the old functions MAP-WITHOUT-ERRORCHECKING, and
        GET-MINIMUM-LENGTH-SEQUENCES go away.
      * The old #+!HIGH-SECURITY length-checking logic goes
        away, to be replaced by stuff in part II.
      * New O(N) functions %MAP-FOR-EFFECT, %MAP-TO-LIST, and
        %MAP-TO-VECTOR are added, and MAP is redefined in terms of them.
      * Add a note pointing out that since MAP-INTO has not been
        rewritten to take advantage of all the new mapping technology,
        it's still slow.
      * Delete no-longer-used ELT-SLICE macro.
    
    another revision of MAP stuff, part II: Peter Van Eynde might go into
    a killing frenzy, or at least his ansi-test suite will gnaw SBCL to
    death, unless we raise type errors on length mismatches like
      (MAP '(SIMPLE-VECTOR 128) #'+ #(1 2) #(1 1)).
    How to do this without clobbering efficiency? More DEFTRANSFORMs, I
    think..
      * MAP becomes a wrapper around %MAP. %MAP doesn't do this
        kind of length checking, MAP does. The old DEFUN MAP,
        DEFKNOWN MAP, and DEFTRANSFORM MAP stuff all turns into
        corresponding definitions for %MAP. The wrapper is
        implemented both as a DEFUN MAP and a DEFTRANSFORM MAP.
      * Now make DEFTRANSFORM MAP smarter:
        ** If necessary, check at runtime that ARRAY-DIMENSION
           matches what we pull out of SPECIFIER-TYPE.
        ** No test is done when SPEED > SAFETY.
        ** No test is needed when we can tell at compile time that
           the result type doesn't specify the length of the result.
      * Also add the same kind of ARRAY-DIMENSION/SPECIFIER-TYPE runtime
        check to DEFUN MAP.
      * While I'm at it, since DEFTRANSFORM MAP needs to think hard about
        the type of the result anyway, it might as well declare what
        it's figured out (TRULY-THE) to benefit any code downstream.
    
    Start playing with MAP regression tests. Add tests/assertoid.lisp to
    support future regression tests.
    
    Once I started using the QUIT :UNIX-CODE keyword argument in my test
    cases, I could see that it isn't very mnemonic. So I changed it to the
    more-descriptive name :UNIX-STATUS, leaving the old name supported but
    deprecated.
    
    Oops! The old DEFTRANSFORM MAP (now DEFTRANSFORM %MAP) should really
    only be done when (>= SPEED SPACE), but it wasn't declared that way.
    
    While looking for an example of a DEFTRANSFORM with &REST arguments
    to use as a model for the code in the new DEFTRANSFORM from MAP to
    %MAP, I noticed that the problem of taking a list of names and
    generating a corresponding list of gensyms is solved in many different
    places in the code, in several ways. Also, the related problem of just
    creating a list of N gensyms is solved in several places in in the
    code. This seems unnecessarily error-prone and wasteful, so I went
    looking for such cases and turned them into calls to MAKE-GENSYM-LIST.
    
    another revision of MAP stuff, part III:
      * Search for 'map' in the output from clocc ansi-tests/tests.lisp,
        to check that the new MAP code isn't too obviously broken.
      * Add some regression tests in test/map.impure.lisp.
    
    Oops! The various %MAP-..-ARITY-1 helper functions expect a function
    argument, but DEFTRANSFORM MAP can call them passing them a function
    name instead.
      * Change the helper functions so that they can handle
        function names as arguments.
      * Define %COERCE-CALLABLE-TO-FUNCTION to help with this. Note that
        this seems to be what %COERCE-NAME-TO-FUNCTION meant long ago,
        judging from DEFTRANSFORM %COERCE-NAME-TO-FUNCTION; so
        appropriate that DEFTRANSFORM for %COERCE-CALLABLE-TO-FUNCTION.
      * Use %COERCE-CALLABLE-TO-FUNCTION elsewhere that expressions
        involving %COERCE-NAME-TO-FUNCTION were used previously.
    
    deleted the old commented-out version of DEFMACRO HANDLER-CASE
    (since it was marked "Delete this when the system is stable.":-)
    
    deleted the old commented-out version of GEN-FORMAT-DEF-FORM,
    since it was supposed to be safe to do so after sbcl-0.6.4
    
    I removed the apology for not using PRINT-OBJECT everywhere in the
    printer from the bugs list in the man page, since it seems to be
    rather tricky to construct a test case which exposes the system's
    non-PRINT-OBJECT-ness without the test case itself violating the ANSI
    spec.
    
    I updated, cleaned up, or removed outright some other outdated or
    confusing entries in the BUGS file and from the bugs list on the man
    page.
    
    Now that BUTLAST no longer blows up on the new problem cases a la
    (BUTLAST NIL -1), I wonder whether I could stop it from blowing
    up on the old problem cases a la (BUTLAST NIL)? It looks like
    a compiler problem, since the interpreted definition of BUTLAST works,
    even though the compiled one doesn't. In fact, it's a declaration
    problem, since LENGTH is set to -1 when LIST=NIL, but is declared
    as an INDEX. (Of course it's likely also a compiler problem, since
    the compiler is supposed to signal type errors for this kind of
    declaration error.) I fixed the misdeclaration, and noted the
    possible compiler bug in BUGS.
    
    After writing the new revised weird type declarations for the
    not-necessarily positive LENGTH, and writing explanatory comments,
      ;; (Despite the name, LENGTH can be -1 when when LIST is an ATOM.)
    for each of the cut-and-pasted (LET ((LENGTH ..)) ..) forms in BUTLAST
    and NBUTLAST, I said "screw it" -- no, that's not it, I quoted Martin
    Fowler and Kent Beck: "If you see the same code structure in more than
    one place, you can be sure that your program will be better if you
    find a way to unify them," and "It's surprising how often you look at
    thickly commented code and notice that the comments are there because
    the code is bad." So I just rewrote BUTLAST and NBUTLAST. Hopefully
    the new versions will be better-behaved than the old ones.
    
    Now that the INDEX type is used in DEFUN MAKE-GENSYM-LIST, which
    belongs in early-extensions.lisp, INDEX should be defined before
    early-extensions.lisp, i.e. earlier than its current definition in
    early-c.lisp. Move it to early-extensions.lisp. Then to make that
    work, since DEF!TYPE is used to define INDEX, defbangtype.lisp needs
    to precede early-extensions.lisp in stems-and-flags.lisp-expr; so move
    it. Also, INDEX is defined in terms of SB!XC:ARRAY-DIMENSION-LIMIT, so
    early-array.lisp needs to move before the new location of
    defbangtype.lisp. And then early-vm.lisp needs to move before that, so
    I might as well move the rest of the early-vm-ish stuff back too. And
    then DEFTYPE is used before deftype.lisp, so I need to change DEFMACRO
    DEF!TYPE to DEF!MACRO DEF!TYPE, so I need to move defbangmacro.lisp
    before deftype.lisp. (This is like a trip down memory lane to the
    endless tweaks and recompiles it took me to find and unravel the
    twisted order dependencies which make CMU CL unbootstrappable. Ah,
    those were the days..:-)
    
    The DEFTYPEs for INDEX and POSN in early-assem.lisp duplicate
    the functionality of the SB-KERNEL:INDEX type.
      * Change uses of the SB-ASSEM::POSN type to uses of the INDEX type.
      * Delete the SB-ASSEM::POSN type and the SB-ASSEM::MAX-POSN constant.
      * Move SB-KERNEL:INDEX into SB-INT, since it's not really
        just a kernel-level thing, but makes sense for implementing
        user-level stuff in SB-INT and SB-EXT and SB-C (and SB-ASSEM).
      * Grep for all '[a-z]:+index[^-a-z]' and rename them (or just
        remove prefixes) to match new SB-INT-ness of INDEX.
      * Make the SB-ASSEM package use the SB-INT package; delete
        the SB-ASSEM::INDEX type and SB-ASSEM::MAX-INDEX constant.
        And since as a rule anything which can see SB-INT deserves
        to see SB-EXT too, make SB-ASSEM use SB-EXT as well.
  5. primarily intending to integrate Colin Walter's O(N) map code and

    William Harold Newman authored
    fixing BUTLAST (but doing some other stuff too, since achieving the
    primary objective involved a lot of inspecting other code):
    
    another revision of MAP stuff, part I:
      * I switched over to code inspired by Colin Walters' O(N) MAP
        code (from the cmucl-imp mailing list 2000 Sep 02) for the
        general non-DEFTRANSFORM case.
      * HIGH-SECURITY-SUPPORT error checking logic goes away, pending
        part II
      * I made some  miscellaneous cleanups of old arity-1 code too.
      * The old MAP-FOR-EFFECT, MAP-TO-LIST, and MAP-TO-SIMPLE macros,
        and the old functions MAP-WITHOUT-ERRORCHECKING, and
        GET-MINIMUM-LENGTH-SEQUENCES go away.
      * The old #+!HIGH-SECURITY length-checking logic goes
        away, to be replaced by stuff in part II.
      * New O(N) functions %MAP-FOR-EFFECT, %MAP-TO-LIST, and
        %MAP-TO-VECTOR are added, and MAP is redefined in terms of them.
      * Add a note pointing out that since MAP-INTO has not been
        rewritten to take advantage of all the new mapping technology,
        it's still slow.
      * Delete no-longer-used ELT-SLICE macro.
    
    another revision of MAP stuff, part II: Peter Van Eynde might go into
    a killing frenzy, or at least his ansi-test suite will gnaw SBCL to
    death, unless we raise type errors on length mismatches like
      (MAP '(SIMPLE-VECTOR 128) #'+ #(1 2) #(1 1)).
    How to do this without clobbering efficiency? More DEFTRANSFORMs, I
    think..
      * MAP becomes a wrapper around %MAP. %MAP doesn't do this
        kind of length checking, MAP does. The old DEFUN MAP,
        DEFKNOWN MAP, and DEFTRANSFORM MAP stuff all turns into
        corresponding definitions for %MAP. The wrapper is
        implemented both as a DEFUN MAP and a DEFTRANSFORM MAP.
      * Now make DEFTRANSFORM MAP smarter:
        ** If necessary, check at runtime that ARRAY-DIMENSION
           matches what we pull out of SPECIFIER-TYPE.
        ** No test is done when SPEED > SAFETY.
        ** No test is needed when we can tell at compile time that
           the result type doesn't specify the length of the result.
      * Also add the same kind of ARRAY-DIMENSION/SPECIFIER-TYPE runtime
        check to DEFUN MAP.
      * While I'm at it, since DEFTRANSFORM MAP needs to think hard about
        the type of the result anyway, it might as well declare what
        it's figured out (TRULY-THE) to benefit any code downstream.
    
    Start playing with MAP regression tests. Add tests/assertoid.lisp to
    support future regression tests.
    
    Once I started using the QUIT :UNIX-CODE keyword argument in my test
    cases, I could see that it isn't very mnemonic. So I changed it to the
    more-descriptive name :UNIX-STATUS, leaving the old name supported but
    deprecated.
    
    Oops! The old DEFTRANSFORM MAP (now DEFTRANSFORM %MAP) should really
    only be done when (>= SPEED SPACE), but it wasn't declared that way.
    
    While looking for an example of a DEFTRANSFORM with &REST arguments
    to use as a model for the code in the new DEFTRANSFORM from MAP to
    %MAP, I noticed that the problem of taking a list of names and
    generating a corresponding list of gensyms is solved in many different
    places in the code, in several ways. Also, the related problem of just
    creating a list of N gensyms is solved in several places in in the
    code. This seems unnecessarily error-prone and wasteful, so I went
    looking for such cases and turned them into calls to MAKE-GENSYM-LIST.
    
    another revision of MAP stuff, part III:
      * Search for 'map' in the output from clocc ansi-tests/tests.lisp,
        to check that the new MAP code isn't too obviously broken.
      * Add some regression tests in test/map.impure.lisp.
    
    Oops! The various %MAP-..-ARITY-1 helper functions expect a function
    argument, but DEFTRANSFORM MAP can call them passing them a function
    name instead.
      * Change the helper functions so that they can handle
        function names as arguments.
      * Define %COERCE-CALLABLE-TO-FUNCTION to help with this. Note that
        this seems to be what %COERCE-NAME-TO-FUNCTION meant long ago,
        judging from DEFTRANSFORM %COERCE-NAME-TO-FUNCTION; so
        appropriate that DEFTRANSFORM for %COERCE-CALLABLE-TO-FUNCTION.
      * Use %COERCE-CALLABLE-TO-FUNCTION elsewhere that expressions
        involving %COERCE-NAME-TO-FUNCTION were used previously.
    
    deleted the old commented-out version of DEFMACRO HANDLER-CASE
    (since it was marked "Delete this when the system is stable.":-)
    
    deleted the old commented-out version of GEN-FORMAT-DEF-FORM,
    since it was supposed to be safe to do so after sbcl-0.6.4
    
    I removed the apology for not using PRINT-OBJECT everywhere in the
    printer from the bugs list in the man page, since it seems to be
    rather tricky to construct a test case which exposes the system's
    non-PRINT-OBJECT-ness without the test case itself violating the ANSI
    spec.
    
    I updated, cleaned up, or removed outright some other outdated or
    confusing entries in the BUGS file and from the bugs list on the man
    page.
    
    Now that BUTLAST no longer blows up on the new problem cases a la
    (BUTLAST NIL -1), I wonder whether I could stop it from blowing
    up on the old problem cases a la (BUTLAST NIL)? It looks like
    a compiler problem, since the interpreted definition of BUTLAST works,
    even though the compiled one doesn't. In fact, it's a declaration
    problem, since LENGTH is set to -1 when LIST=NIL, but is declared
    as an INDEX. (Of course it's likely also a compiler problem, since
    the compiler is supposed to signal type errors for this kind of
    declaration error.) I fixed the misdeclaration, and noted the
    possible compiler bug in BUGS.
    
    After writing the new revised weird type declarations for the
    not-necessarily positive LENGTH, and writing explanatory comments,
      ;; (Despite the name, LENGTH can be -1 when when LIST is an ATOM.)
    for each of the cut-and-pasted (LET ((LENGTH ..)) ..) forms in BUTLAST
    and NBUTLAST, I said "screw it" -- no, that's not it, I quoted Martin
    Fowler and Kent Beck: "If you see the same code structure in more than
    one place, you can be sure that your program will be better if you
    find a way to unify them," and "It's surprising how often you look at
    thickly commented code and notice that the comments are there because
    the code is bad." So I just rewrote BUTLAST and NBUTLAST. Hopefully
    the new versions will be better-behaved than the old ones.
    
    Now that the INDEX type is used in DEFUN MAKE-GENSYM-LIST, which
    belongs in early-extensions.lisp, INDEX should be defined before
    early-extensions.lisp, i.e. earlier than its current definition in
    early-c.lisp. Move it to early-extensions.lisp. Then to make that
    work, since DEF!TYPE is used to define INDEX, defbangtype.lisp needs
    to precede early-extensions.lisp in stems-and-flags.lisp-expr; so move
    it. Also, INDEX is defined in terms of SB!XC:ARRAY-DIMENSION-LIMIT, so
    early-array.lisp needs to move before the new location of
    defbangtype.lisp. And then early-vm.lisp needs to move before that, so
    I might as well move the rest of the early-vm-ish stuff back too. And
    then DEFTYPE is used before deftype.lisp, so I need to change DEFMACRO
    DEF!TYPE to DEF!MACRO DEF!TYPE, so I need to move defbangmacro.lisp
    before deftype.lisp. (This is like a trip down memory lane to the
    endless tweaks and recompiles it took me to find and unravel the
    twisted order dependencies which make CMU CL unbootstrappable. Ah,
    those were the days..:-)
    
    The DEFTYPEs for INDEX and POSN in early-assem.lisp duplicate
    the functionality of the SB-KERNEL:INDEX type.
      * Change uses of the SB-ASSEM::POSN type to uses of the INDEX type.
      * Delete the SB-ASSEM::POSN type and the SB-ASSEM::MAX-POSN constant.
      * Move SB-KERNEL:INDEX into SB-INT, since it's not really
        just a kernel-level thing, but makes sense for implementing
        user-level stuff in SB-INT and SB-EXT and SB-C (and SB-ASSEM).
      * Grep for all '[a-z]:+index[^-a-z]' and rename them (or just
        remove prefixes) to match new SB-INT-ness of INDEX.
      * Make the SB-ASSEM package use the SB-INT package; delete
        the SB-ASSEM::INDEX type and SB-ASSEM::MAX-INDEX constant.
        And since as a rule anything which can see SB-INT deserves
        to see SB-EXT too, make SB-ASSEM use SB-EXT as well.
Commits on Sep 20, 2000
  1. added various /SHOW0-ish statements to help when debugging internal

    William Harold Newman authored
    error handling
    
    The MAKE-SPECIALIZABLE-ARRAY call in DEFUN INTERNAL-ERROR-ARGUMENTS
    can become MAKE-ARRAY, since M-S-A is something to make it easier to
    build parts of the cross-compiler under the cross-compilation host,
    and DEFUN INTERNAL-ERROR-ARGUMENTS is in x86-vm.lisp, which is not
    part of the cross-compiler, and so is never compiled by the
    cross-compilation host.
    
    changed MAKE-VALID-LISP-OBJ from a MACROLET macro to a global
    function, for clarity and easier debugging
    
    deleted unused SET-VALUE macro from MACROLET in DEFERR
    
    deleted code marked REMOVEME, accidentally left over from previous
    debugging exercises
    
    changed CONTEXT-PC-ADDR, CONTEXT-PC, CONTEXT-REGISTER-ADDR, and
    CONTEXT-REGISTER functions to use unsigned representations instead of
    signed representations, to conform to implicit assumptions in the
    debug-int code inherited from CMU CL. (Without this, new type errors
    are generated in infinite regress when we try to handle errors
    involving negative fixnums, e.g. (BUTLAST NIL -1).)
    
    tweaked stuff in test/ directory a little bit in anticipation of
    setting up real regression tests
Commits on Sep 18, 2000
  1. Initial revision

    William Harold Newman authored
Something went wrong with that request. Please try again.