Changes between Version 3 and Version 4 of ReleaseNotes


Ignore:
Timestamp:
Nov 9, 2007, 1:46:03 AM (12 years ago)
Author:
gb
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ReleaseNotes

    v3 v4  
    22
    33* This will hopefully be the last set of snapshots whose version number contains the string "pre-"; whether or not the last 20 months worth of "1.1-pre-yymmdd" snapshot releases are more or less stable than something without "pre-" in its name doesn't have too much to do much to do with whether or not "pre-" is in the version number (and has lots to do with other things.)
    4   I'd like to move to a model that's mostly similar to how things
    5   have been (new version every month or two, old versions become
    6   obsolete soon after, sometimes changes introduce binary incompatiblity)
    7   but drop the "prerelease" designation and change the name of the
    8   "testing" directory to something like "current".
     4I'd like to move to a model that's mostly similar to how things
     5have been (new version every month or two, old versions become
     6obsolete soon after, sometimes changes introduce binary incompatiblity)
     7but drop the "prerelease" designation and change the name of the
     8testing" directory to something like "current".
    99* The FASL version didn't change (for the first time in a long time.)
    10   It's probably a lot easier to bootstrap new sources with a new
    11   lisp and it's probably desirable to recompile your own source
    12   code with the new lisp, but there shouldn't be any user-visible
    13   low-level ABI changes that make that mandatory.
     10It's probably a lot easier to bootstrap new sources with a new
     11lisp and it's probably desirable to recompile your own source
     12code with the new lisp, but there shouldn't be any user-visible
     13low-level ABI changes that make that mandatory.
    1414* CCL::WITH-ENCODED-CSTRS (which has been unexported and somewhat
    15   broken) is now exported and somewhat less broken.
     15broken) is now exported and somewhat less broken.
    1616
    1717{{{
     
    1919}}}
    2020
    21   where ENCODING-NAME is a keyword constant that names a character
    22   encoding executes BODY in an environment where each variable varI
    23   is bound to a nul-terminated, dynamic-extent foreign pointer to
    24   an encoded version of the corresponding stringI.
     21where ENCODING-NAME is a keyword constant that names a character
     22encoding executes BODY in an environment where each variable varI
     23is bound to a nul-terminated, dynamic-extent foreign pointer to
     24an encoded version of the corresponding stringI.
    2525
    2626{{{
     
    2828}}}
    2929
    30   is functionally equivalent to:
     30is functionally equivalent to:
    3131
    3232{{{
     
    3535
    3636
    37   CCL:WITH-ENCODED-CSTRS doesn't automatically prepend byte-order-marks
    38   to its output; the size of the terminating #\NUL depends on the
    39   number of octets-per-code-unit in the encoding.
    40 
    41   There are certainly lots of other conventions for expressing
    42   the length of foreign strings besides NUL-termination (length in
    43   code units, length in octets.)  I'm not sure if it's better to
    44   try to come up with high-level interfaces that support those
    45   conventions ("with-encoded-string-and-length-in-octets ...")
    46   or to try to support mid-level primitives ("number of octets
    47   in encoded version of lisp string in specified encoding", etc.)
    48 
    49 - STREAM-ERRORs (and their subclasses, including READER-ERROR)
    50   try to describe the context in which they occur a little better
    51   (e.g., by referencing the file position if available and
    52   by trying to show a few surrounding characters when possible.)
    53   Since streams are usually buffered, this context information
    54   may be incomplete, but it's often much better than nothing.
    55 
    56 - Hashing (where some objects are hashed by address) and OpenMCL's
    57   GC (which often changes the addresses of lisp objects, possibly
    58   invalidating hash tables in which those objects are used as keys)
    59   have never interacted well; to minimize the negative effects of
    60   this interaction, most primitive functions which access hash
    61   tables has disabled the GC while performing that access, secure
    62   in the knowledge that hash table keys won't be moving around
    63   (because of GC activity in other threads) while the hash table
    64   lookup is being performed.
    65 
    66   Disabling and reenabling the GC can be somewhat expensive, both
    67   directly (in terms of the primitive operations used to do so)
    68   and indirectly (in terms of the cost of - temporarily - not being
    69   able to GC when otherwise desirable.)  If the GC runs (and possibly
    70   moves a hash-table key) very rarely relative to the frequency of
    71   hash-table access - and that's probably true, much of the time -
    72   then it seems like it'd be desirable to avoid the overhead of
    73   disabling/reenabling the GC on every hash table access, and it'd
    74   be correct to do this as long as we're careful about it.
    75 
    76   I was going to try to change all hash-table primitives to try
    77   to make them avoid inhibiting/enabling the GC for as long as
    78   possible, but wimped out and only did that for GETHASH.  (If
    79   another thread could GC while we're accessing a hash table, there
    80   can still be weird intercations between things like the GC's
    81   handling of weak objects and code which looks at the hash table,
    82   and that weirdness seemed easier to deal with in the GETHASH case
    83   than in some others.)
    84 
    85   If GETHASH's performance has improved without loss of correctness,
    86   then it'd likely be worth trying to make similar changes to
    87   REMHASH and CCL::PUTHASH (which implements (SETF (GETHASH ...) ...).
    88   If problems are observed or performance still hasn't improved, it'd
    89   probably be worth re-thinking some of this.
    90 
    91 - Leading tilde (~) characters in physical pathname namestrings
    92   are expanded in the way that most shells do:
     37CCL:WITH-ENCODED-CSTRS doesn't automatically prepend byte-order-marks
     38to its output; the size of the terminating #\NUL depends on the
     39number of octets-per-code-unit in the encoding.
     40
     41There are certainly lots of other conventions for expressing
     42the length of foreign strings besides NUL-termination (length in
     43code units, length in octets.)  I'm not sure if it's better to
     44try to come up with high-level interfaces that support those
     45conventions ("with-encoded-string-and-length-in-octets ...")
     46or to try to support mid-level primitives ("number of octets
     47in encoded version of lisp string in specified encoding", etc.)
     48
     49* STREAM-ERRORs (and their subclasses, including READER-ERROR)
     50try to describe the context in which they occur a little better
     51(e.g., by referencing the file position if available and
     52by trying to show a few surrounding characters when possible.)
     53Since streams are usually buffered, this context information
     54may be incomplete, but it's often much better than nothing.
     55
     56* Hashing (where some objects are hashed by address) and OpenMCL's
     57GC (which often changes the addresses of lisp objects, possibly
     58invalidating hash tables in which those objects are used as keys)
     59have never interacted well; to minimize the negative effects of
     60this interaction, most primitive functions which access hash
     61tables has disabled the GC while performing that access, secure
     62in the knowledge that hash table keys won't be moving around
     63(because of GC activity in other threads) while the hash table
     64lookup is being performed.
     65
     66Disabling and reenabling the GC can be somewhat expensive, both
     67directly (in terms of the primitive operations used to do so)
     68and indirectly (in terms of the cost of - temporarily - not being
     69able to GC when otherwise desirable.)  If the GC runs (and possibly
     70moves a hash-table key) very rarely relative to the frequency of
     71hash-table access - and that's probably true, much of the time -
     72then it seems like it'd be desirable to avoid the overhead of
     73disabling/reenabling the GC on every hash table access, and it'd
     74be correct to do this as long as we're careful about it.
     75
     76I was going to try to change all hash-table primitives to try
     77to make them avoid inhibiting/enabling the GC for as long as
     78possible, but wimped out and only did that for GETHASH.  (If
     79another thread could GC while we're accessing a hash table, there
     80can still be weird intercations between things like the GC's
     81handling of weak objects and code which looks at the hash table,
     82and that weirdness seemed easier to deal with in the GETHASH case
     83than in some others.)
     84
     85If GETHASH's performance has improved without loss of correctness,
     86then it'd likely be worth trying to make similar changes to
     87REMHASH and CCL::PUTHASH (which implements (SETF (GETHASH ...) ...).
     88If problems are observed or performance still hasn't improved, it'd
     89probably be worth re-thinking some of this.
     90
     91* Leading tilde (~) characters in physical pathname namestrings
     92are expanded in the way that most shells do:
    9393
    9494  "~user/...." can be used to refer to an absolute pathname rooted