Remove moribund declarations, add IGNORABLE. Add package comment.
Handle IGNORE declarations in a much more reasonable way.
Fix particularly nasty (but rare) bug that makes ext file generation fail under unusual circumstances.
Remove incorrect comment.
Simplify! Implement make-system-file.
Fix FSF address.
Update copyright dates.
Rename make-dist-files -> make-native-files.
Add NULL? to constant folding operators.
Rewrite dist scripts for so many reasons.
Add /pc/.
Add changelog.txt.
Update for release.
Update copyright year.
Fix problem converting negative bignums to flonums.
Fix problem converting negative bignums to flonums.
Merge in changes from release-9.0.
Remove unused variable binding.
Install Taylor's patch to fix parsing of compiled interrupt frames.
Eliminate --enable-static-libs flag.
Eliminate multiple liarc builds; just use one now that it works again.
Rename "LOG" to "changelog.txt".
Fix HEXADECIMAL->VECTOR-8B.
Now it passes
(do ((i 0 (+ i 1)))
((= i #x100))
(let* ((v (random-byte-vector #x100))
(h (vector-8b->hexadecimal v))
(v* (hexadecimal->vector-8b h)))
(do ((i 0 (+ i 1)))
((= i #x100))
(if (not (= (vector-8b-ref v i) (vector-8b-ref v* i)))
(error "Lose:" h)))))
Don't fix constant at compile time; breaks liarc build.
In microcode/makegen/makeinit.sh, delete Makefile.in on ^C.
This reduces the damage to the tree caused by an inopportune ^C
during Setup.sh which would otherwise require manual intervention
to clean up the mess.
Don't link prmcrypt.so against libltdl.
Since 2.5.5 (released nearly eight years ago), libmcrypt has
statically linked all its modules by default, unless configured with
--enable-dynamic-loading. If anyone actually uses that, we ought to
use `libmcrypt-config --libs' to get the actual list of linker flags,
but just passing -lmcrypt should do for now.
runtime/gdbm.scm has no INITIALIZE-PACKAGE!.
Typo in variable name.
Make X11 modules dynamically loadable.
Make the modules depend on `scheme' only for Mac OS X, and let that
be an option to configure, so that users can just build modules
against an already installed Scheme.
This is a step toward making every feature that currently involves a
compile-time decision instead be dynamically loadable, and compilable
separately from the microcode executable. All that is left is
termcap support.
Reorganize procedures and use dispatch vector for handling combination operators.
Fix thinko in last change to check realloc errors in tparam.c.
Tweak tparam.c and tgoto.c.
(tparam.c): Use ANSI-style declarations. Include relevant headers.
Use memcpy rather than bcopy. Check for malloc and realloc failures.
(tterm.c): Check for tparam and tgoto failures. Handle the case
where tparam and tgoto malloc their own memory. Ensure that a Scheme
interrupt/GC in char_pointer_to_string does not leak that memory.
Tweak microcode to build better on NetBSD.
Clarify termcap library selection.
Omit rpath hack -- users can specify ld rpath arguments explicitly
when configuring the microcode.
Separate global declarations from top-level declarations.
Add some interpreter entries' names to the i386 disassembler.
Fix typo in i386 disassembler.
Suppress integration of global operators shadowed by top-level integrations. Subtle bug here. This will workaround until I make the real fix.
Convert integrate/name from CPS to direct style and fix up callers.
Convert usiexp.scm from CPS to direct style. Fix callers in subst.scm.
Use notifications for noise.
Use SRFI-1 lset routines.
Move combination rewriting to combination constructor. Import constant folding operators from runtime.
Simply disjunction integration by moving disjunction construction logic to object.scm
Create constructor stubs for combination, conditional, and disjunction.
Move environment table to tables.
Add guarantees, minor cleanups.
Add KNOWN-DECLARATION guarantee.
Correctly remove runtime.com from image.
Add and export CONSTANT-PROCEDURE.
Make guarantees for objects, improve debugging.
Add IGNORABLE declaration for variables. Issue warning if variable is IGNORE, but used anyway.
Get rid of block/flags, open-block/optimized, weird optimization switches, and code for INTEGRATE-SAFELY.
Remove declarations INTEGRATE-SAFELY, AUTOMAGIC-INTEGRATIONS, ETA-SUBSTITUTION, and OPEN-BLOCK-OPTIMIZATION.
Ignore eager-integration-switch and eta-substitution-switch.
Get rid of lsets and table. Simplify emodel.
Remove strange declarations.
Add package comments.
Make sure that arch tar file is deleted prior to running tar.
Don't include "runtime.com" in the image.
Fix some bugs.
Change c32/c64 names to have common prefix with other files.
Merge doc files into binary tarballs.
Adjust for 32- and 64-bit liarc builds.
Update copyright notices for 2010.
Bump release version to 9.0.
Add ability to pass configure args to script.
Eliminate open-coding of QUOTIENT and REMAINDER.
Fix bug: weak-method:clean! removing entries whose key is #f.
Fix arg order to LSET-DIFFERENCE.
Got the (incomplete) svm1 back end to syntax.
* src/compiler/choose-machine.sh: Added a test that produces the correct
directory name (svm) for TARGET_ARCH svm1.
* src/compiler/machines/svm/.gitignore (new): Ignore generated files.
* src/compiler/machines/svm/assembler-compiler.scm: Fixed to produce
non-empty let bodies in the codecs of instructions with zero
arguments, and fewer unreferenced bindings.
* src/compiler/machines/svm/assembler-runtime.scm: Introduced a module
variable, coding-types, to hold the list of <rt-coding-type>s created
by make-rt-coding-type. The list is thus no longer required as an
argument to many procedures.
Fixed the trap:* procedures to accept trap arguments. Fixed the
interface to the interrupt test instructions, which are not (no
longer?) traps.
* src/compiler/machines/svm/compile-assembler.scm: Added a temporary
hack to define write-mit-scheme-copyright in January's snapshot.
* src/compiler/machines/svm/compiler.cbf (new): Cribbed from i386.
* src/compiler/machines/svm/compiler.pkg (new): Cribbed from i386.
* src/compiler/machines/svm/compiler.sf (new): Cribbed from i386.
Referring to compiler.pkg's declarations to get the syntax/load
environments right.
* src/compiler/machines/svm/decls.scm (new): Cribbed from i386.
Collect the list of source files from compiler.pkg, not via *.scm
globs. Punted initialize/syntax-dependencies!, getting the correct
syntax/load environments from compiler.pkg.
* src/compiler/machines/svm/lapgen.scm: Fixed some typos and
unreferenced bindings.
Fix over-long line.
Fix MD5-UPDATE and MHASH to check their index args correctly.
Minor tweak to use disjunction in conditional expansion.
Tweak patterns for windows stuff.
Tweak patterns for windows stuff.
Conditionally include documentation; right now there's none available.
Major overhaul in preparation for release.
Fix problems with file enumerations.
More updates in preparation for release.
Use recursive-lambda icon as default on windows.
Force working directory to user's home-dir when started as mac application bundle.
Add new recursive-lambda icon for use in mac and windows.
Restrict *.ico rule.
Update documentation to reflect changes concerning eq hash tables.
Document MAKE-WEAK-EQ-HASH-TABLE and MAKE-WEAK-EQV-HASH-TABLE.
Warn that MAKE-EQ-HASH-TABLE and MAKE-EQV-HASH-TABLE may become
aliases for MAKE-STRONG-EQ-HASH-TABLE and MAKE-STRONG-EQV-HASH-TABLE
instead. Suggest using MAKE-STRONG-EQ-HASH-TABLE for symbol-keyed
tables, rather than MAKE-EQ-HASH-TABLE.
Eradicate use of MAKE-EQ-HASH-TABLE.
Replace each use by a constructor with a more specific name.
Full analysis:
* Use of MAKE-EQ-HASH-TABLE in MIT Scheme, 2009-12-21 -*- outline -*-
In MIT Scheme, MAKE-EQ-HASH-TABLE yields a hash table whose keys are
held only weakly, so that they will be garbage-collected if there are
no strong references to them. To make a similar hash table whose keys
are held strongly, one must use MAKE-STRONG-EQ-HASH-TABLE explicitly.
Of the sixty-two uses of MAKE-EQ-HASH-TABLE throughout the MIT Scheme
source code, only four appear to need weak references to their keys,
and for only two more is there an obvious reason to use weak
references. This list categorizes most uses of MAKE-EQ-HASH-TABLE.
Each entry is marked by the decision that was made for it of whether
it should be strong or weak.
** Hash table must be key-weak
*** [weak] edwin/curren.scm, screen-buffer-layouts
*** [weak] edwin/eystep.scm, stepper-buffers
*** [weak] edwin/xterm.scm, display/cached-atoms-table
*** [weak] edwin/xterm.scm, display/selection-records
** Hash table should be key-weak, but will work as key-strong
*** [weak] edwin/comman.scm, permanent-local-variables
As long as Edwin variables are strongly interned, it is safe to use a
key-strong hash table for properties on Edwin variables such as the
permanent-local property, but if Edwin variables were weakly interned
then this would be a space leak.
*** [strong] sos/class.scm, built-in-class-table
Dispatch tags that are garbage-collected shouldn't accumulate space
here. These might arise, for instance, from re-evaluating
DEFINE-RECORD-TYPE forms causing the old record type's dispatch tags
to be garbage-collected. That requires key- and datum-weak hash
tables, though. Using MAKE-WEAK-EQ-HASH-TABLE here breaks the
bootstrap from the
20090107 snapshot, which doesn't have a binding for
that name. So just use a strong eq hash table for now.
** Hash table should be key-strong, but will work as key-weak
*** [strong] compiler/machines/i386/lapopt.scm, *rules*
If the compiler never generates instructions with certain symbols in
them, and hence the compiler's code has no strong references to those
symbols, then the rules for those symbols may as well be discarded.
But that's pretty sketchy.
*** [strong] compiler/machines/svm/assembler-runtime.scm, symbolic-operators
*** [strong] compiler/machines/svm/assembler-runtime.scm, pvar-type-table
*** [strong] compiler/machines/svm/lapopt.scm, *rules* (not really used)
*** [strong] compiler/machines/x86-64/lapopt.scm, *rules* (not really used)
*** [strong] edwin/nntp.scm, equivalences in build-equivalence-classes
The only reason that this works as a key-weak hash table is that every
key is also strongly referenced by the hash table's data.
*** [strong] edwin/nntp.scm, tables in convert-header-graphs-to-trees
In the only caller of CONVERT-HEADER-GRAPHS-TO-TREES, the (strong)
list of headers is still strongly referenced, so the keys of the two
hash tables in TABLES will not be garbage-collected.
*** [strong] edwin/xterm.scm, built-in-atoms-table
If the binding for BUILT-IN-ATOMS were collected while that for
BUILT-IN-ATOMS-TABLE were not, then the latter would be in trouble.
This generally doesn't happen currently.
*** [strong] microcode/os2pm.scm, type-abbreviations
*** [strong] microcode/os2pm.scm, id-external-roots
This code is probably defunct, but if it weren't, and if the
presentation manager procedure abstraction were used outside this
file, it would probably be necessary to make these two hash tables
key-strong. Another hash table, PM-PROCEDURES, is incorrectly
key-weak.
*** [strong] runtime/genio.scm, {en,de}coder/sizer/{,de}normalizer maps
Since there are maps in both directions, each hash table's keys also
have strong references in the data positions of the other hash table.
But this is pretty fragile, and in any case there is no need to use
key-weak hash tables.
*** [strong] runtime/syntax-output.scm, unmappings
*** [strong] runtime/syntax-output.scm, rename-databases' mapping-tables
*** [strong] runtime/syntax-output.scm, rename-databases' id-tables
*** [weak] ssp/xmlrpc.scm, methods in get-xmlrpc-method-handler
Since the hash table is used only in one place, and only one key is
fetched out of it, that key will be strongly referenced until it is
fetched, and the other keys don't matter. (For that matter, why use a
hash table at all?)
*** [strong] xml/turtle.scm, table in write-prefixes
** Hash table must be key-strong
*** [strong] compiler/machines/svm/assembler-runtime.scm, symbol tables
These are probably meant to be treated like the symbol tables
implemented in compiler/back/symtab.scm.
*** [strong] imail/imail-file.scm, file-folder-types
*** [strong] imail/imail-mime.scm, mime-encodings
*** [strong] microcode/os2pm.scm, pm-procedures
*** [strong] runtime/http-syntax.scm, header-value-defns
*** [strong] ssp/mod-lisp.scm, mime-handlers
*** [strong] ssp/xhtml-expander.scm, *sabbr-table*
The processing instructions are processed incrementally as the file is
parsed, so keys in the sabbr table may be garbage-collected and then
re-interned, between which times the associations would be destroyed.
*** [strong] star-parser/matcher.scm, matcher-preprocessors
*** [strong] star-parser/matcher.scm, matcher-compilers
*** [strong] star-parser/parser.scm, parser-preprocessors
*** [strong] star-parser/parser.scm, parser-compilers
*** [strong] star-parser/shared.scm, make-parser-macros
*** [strong] star-parser/shared.scm, *global-parser-macros*
*** [strong] xdoc/validate-xdoc.scm, element-checkers
*** [strong] xdoc/xdoc.scm, html-generators
*** [strong] xdoc/xdoc.scm, when-conditions
*** [strong] xdoc/xdoc.scm, xdoc-content-types
*** [strong] xdoc/xdoc.scm, xdoc-element-types
*** [strong] xdoc/xdoc.scm, xdoc-input-canonicalizers
*** [strong] xdoc/xdoc.scm, xdoc-output-definitions
*** [strong] xml/xhtml.scm, element-context-map
** Other
*** [strong] compiler/machines/C/stackify.scm, stackify count tables
It is not immediately clear to me whether these need to be strong, but
they probably should be.
*** [strong] compiler/rtlbase/rtlobj.scm, label->object maps
It's not immediately obvious to me whether LABEL->OBJECT will ever be
used after the last references to the keys of the hash tables involved
(which cause strong references to those keys to be dropped, if
COMPILER:PRESERVE-DATA-STRUCTURES? is false). A little further
analysis is required. A conservative guess would be that these should
to be strong.
*** [weak] edwin/eystep.scm, ynode-regions
What are the keys to these hash tables? I don't know how long they
persist.
Chris's answer: The keys are stepper nodes; they are stored in a text
property and consequently will be held appropriately. This should be
a weak table.
*** [weak] edwin/prompt.scm, prompt-histories
Making this key-strong is not likely to be a space leak, but if a
command is garbage-collected, then so may the symbol for its history
be garbage-collected, and its history is presumably no longer needed.
*** [strong-eqv] edwin/win32.scm, event-handlers
The keys in EVENT-HANDLERS are integers. I think this should be a
key-strong eqv hash table rather than a key-weak eq hash table.
*** [strong] edwin/xterm.scm, selection->record table in display/selection-records
I'm not sure what the domain of possible keys to this hash table is --
it may be just the symbols PRIMARY and CLIPBOARD, which will probably
be strongly referenced by the rest of the Edwin code, but on the other
hand I think this should probably be a key-strong hash table.
*** [strong] edwin/xterm.scm, symbol->x-atom table in display/cached-atoms-table
Whether this should be key-strong or key-weak depends on whether the
set of atoms that it will map is arbitrarily large.
*** [weak] imail/imail-core.scm, memoized-resources
As long as URLs are interned strongly, it doesn't matter whether
MEMOIZED-RESOURCES is key-weak or key-strong. This requires further
analysis, but leaving it weak for now (i.e. not changing it) is safe
until internment of URLs changes.
*** [strong with comment] runtime/sfile.scm, interned-mime-types
This should really be a key-strong, datum-weak hash table, which the
hash table abstraction does not presently support. (The same goes for
UNUSUAL-INTERNED-MIME-TYPES.) Barring that, INTERNED-MIME-TYPES
should be key-strong, although it happens to work as a key-weak hash
table because its data have strong references to its keys anyway.
*** [weak] xdoc/xdoc.scm, *xdoc-element-properties*
*** [weak] xdoc/xdoc.scm, *xdoc-inputs*
*** [weak] xdoc/xdoc.scm, *xdoc-outputs*
As maps from XML elements by identity to properties, these three
should probably be key-weak, but since new ones are created for each
xdoc expansion, they could probably safely be key-strong without
badly leaking memory.
*** [strong] xdoc/xdoc.scm, *xdoc-id-map*
This should be key-strong, although it doesn't matter until XML names
become weakly interned.
*** [strong-eqv] xml/xhtml-entities.scm, table in html-char->name-map
The keys in the table inside HTML-CHAR->NAME-MAP is keyed by
characters. Should this be a key-strong eqv hash table rather than a
key-weak eq hash table?
*** [strong with comment] xml/xml-names.scm
If we had datum-weak hash tables, then EXPANDED-NAMES should be
key-weak and the other two should be datum-weak. But we don't, so
instead all three should be strong, since in each one the data all
have strong references to their corresponding keys.
Reflect specification bug in definition of HASH-TABLE-UPDATE!.
We can't use HASH-TABLE/MODIFY! because the specification tacitly
permits the procedure to edit the hash table. This was a silly
oversight in the SRFI document.
Add names for hash table types with the word `weak' in them.
New global bindings:
MAKE-WEAK-EQ-HASH-TABLE
MAKE-WEAK-EQV-HASH-TABLE
WEAK-EQ-HASH-TABLE-TYPE
WEAK-EQV-HASH-TABLE-TYPE
{EQ,EQV}-HASH-TABLE-TYPE and MAKE-{EQ,EQV}-HASH-TABLE are now aliases
for WEAK-{EQ,EQV}-HASH-TABLE-TYPE and MAKE-WEAK-{EQ,EQV}-HASH-TABLE,
as are MAKE-{SYMBOL,OBJECT}-HASH-TABLE.
projects / mit-scheme.git / log