On Thu, May 12, 2005 at 06:52:15PM +0300, Nikodemus Siivola wrote:
> On Thu, 12 May 2005, R. Mattes wrote:
Sorry for the late reply - our mailbox disk filled up :-/
> Unhelpfull but true answer: those libraries are broken and should not have
> depended on internal functions in the first place. Fixing them to use
> portable code is the correct answer to the first approximation.
Helpfull - i'll file a bugreport.
> If you really really want to support obsolete SBCL's and depend on
> gone-for-good internal interfaces, then FIND-SYMBOL and FBOUNDP will
> probably tell you what you need to know.
That's what i do right now. Seems to work well enough.
> >BTW, is there a place in the sources where such changes are documented
> >(something like a ChangeLog)? Upgrading my systems without knowing a
> >priory where to expect problems sometimes quickly degrades into
> >trial-and-error ... :-) There seem to be changes/deprecations listed in
> >the NEWS file. Is this the place to check (if so, maybe someone should
> >add the bit-bash changes to the NEWS file).
> At least I'm not too wild about documenting changes to internal interfaces
> in NEWS. If you need more comprehensive coverage, then cvs2cl should get
> you a ChangeLog based on commit messages, which are often more detailed
> then NEWS. ...or you can just subscribe to sbcl-commits and/or sbcl-devel,
> and get the news hot off the keyboard. ;-)
I can see the reason behind not starting to document internal changes. I guess
it's unfortunate that some libraries need to use these functions.
Thanks for the answer
> -- Nikodemus Schemer: "Buddha is small, clean, and serious."
> Lispnik: "Buddha is big, has hairy armpits, and laughs."