tag:old.nabble.com,2006:forum-1752Nabble - Gnu - MIT Scheme2009-12-23T14:33:31ZMIT/GNU Scheme is an implementation of the Scheme programming language, providing an interpreter, compiler, source-code debugger, integrated Emacs-like editor, and a large runtime library. MIT/GNU Scheme is best suited to programming large applications with a rapid development cycle. Gnu - MIT Scheme home is <a href="http://savannah.gnu.org/projects/mit-scheme/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26908369Re: Complexity2009-12-23T14:33:31Z2009-12-23T14:33:31ZJoe MarshallThis list is for discussion of the development of MIT Scheme.
<br>I think you'll have more success if you ask your instructor.
<br><br><br>--
<br>~jrm
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26908369&i=0" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26893993Complexity2009-12-22T12:37:28Z2009-12-22T12:37:28ZjohngaltHi,
<br>I wrote the nwxt codes:
<br><br>(define (prefix k lst)
<br> (cond ( (= k 0) '())
<br> ( (null? lst) '())
<br> (else (cons (car lst) (prefix (- k 1) (cdr lst))))))
<br><br>(define (runs k lst)
<br> (let ((p (prefix k lst)))
<br> (if (> k (length p)) '()
<br> (cons p (runs k (cdr lst))))))
<br><br>-------------
<br><br><br><br>(define (accumulate op initial sequence)
<br> (if (null? sequence)
<br> initial
<br> (op (car sequence)
<br> (accumulate op initial (cdr sequence)))))
<br><br>(define (accumulate-runs k op init lst)
<br> (map (lambda (x) (accumulate op init x))
<br> (runs k lst)))
<br>----------------
<br><br><br><br><br><br>I'm not very familiar with this subject, so I need to ask. What is the complexity of the two codes above?
<br>Thanks for any kind of help.<p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26888810Re: weak hash table data2009-12-22T05:59:04Z2009-12-22T05:59:04ZTaylor R Campbell Date: Tue, 22 Dec 2009 02:04:03 -0800
<br> From: Chris Hanson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26888810&i=0" target="_top" rel="nofollow">cph@...</a>>
<br><br> This is incorrect. GC marks every table as needing rehash; the next
<br> access to that table forces a rehash, which cleans the table.
<br><br>Right, although HASH-TABLE/DATUM-LIST and friends don't count as
<br>`access'. Still, weak hash tables that are not in frequent use will
<br>not be cleaned, nor will weak hash tables that are not GC-sensitive.
<br>For example, a weak hash table keyed by symbols with SYMBOL-HASH as
<br>its hash function rather than EQ-HASH (or one keyed by URIs with
<br>(COMPOSE STRING-HASH URI->STRING) as its hash function, since interned
<br>symbols are now held strongly as keys).
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26888810&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26886064Re: weak hash table data2009-12-22T02:04:03Z2009-12-22T02:04:03ZChris Hanson-6This is incorrect. GC marks every table as needing rehash; the next
<br>access to that table forces a rehash, which cleans the table.
<br><br>On Mon, Dec 21, 2009 at 10:09 PM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26886064&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<div class='shrinkable-quote'><br>> Key-weak hash tables are never cleaned automatically, not even in a
<br>> secondary GC daemon; unless you call HASH-TABLE/CLEAN! or cause them
<br>> to be rehashed, broken entries will retain their data (but not their
<br>> keys) strongly.
<br>>
<br>> (let ((a (make-eq-hash-table))
<br>> (b (make-eq-hash-table)))
<br>> (let ((p (list 'p))
<br>> (q (list 'q))
<br>> (r (list 'r)))
<br>> (hash-table/put! a p q)
<br>> (hash-table/put! b q r))
<br>> (gc-flip)
<br>> (list (hash-table/datum-list a)
<br>> (hash-table/datum-list b)))
<br>> ;Value: (() ((r)))
<br>>
<br>> The manual doesn't claim that *associations* are deleted from weak
<br>> hash tables if their keys are reclaimed -- it says only that the hash
<br>> table holds its keys weakly --, but this is not the behaviour I expect
<br>> for an object called a `weak hash table'. Does this behaviour worry
<br>> anyone else?
<br>>
<br>>
<br>> _______________________________________________
<br>> MIT-Scheme-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26886064&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br>> <a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br>>
</div><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26886064&i=2" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26884398weak hash table data2009-12-21T22:09:09Z2009-12-21T22:09:09ZTaylor R CampbellKey-weak hash tables are never cleaned automatically, not even in a
<br>secondary GC daemon; unless you call HASH-TABLE/CLEAN! or cause them
<br>to be rehashed, broken entries will retain their data (but not their
<br>keys) strongly.
<br><br>(let ((a (make-eq-hash-table))
<br> (b (make-eq-hash-table)))
<br> (let ((p (list 'p))
<br> (q (list 'q))
<br> (r (list 'r)))
<br> (hash-table/put! a p q)
<br> (hash-table/put! b q r))
<br> (gc-flip)
<br> (list (hash-table/datum-list a)
<br> (hash-table/datum-list b)))
<br>;Value: (() ((r)))
<br><br>The manual doesn't claim that *associations* are deleted from weak
<br>hash tables if their keys are reclaimed -- it says only that the hash
<br>table holds its keys weakly --, but this is not the behaviour I expect
<br>for an object called a `weak hash table'. Does this behaviour worry
<br>anyone else?
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26884398&i=0" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26881177Re: make-eq-hash-table2009-12-21T14:35:04Z2009-12-21T14:35:04ZTaylor R Campbell Date: Mon, 21 Dec 2009 14:03:50 -0800
<br> From: Chris Hanson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26881177&i=0" target="_top" rel="nofollow">cph@...</a>>
<br><br> Actually, they want to be both key-weak and datum-weak.
<br><br>EXPANDED-NAMES needs to be key-weak and datum-strong (its data are
<br>hash tables that are not likely to be referenced, strongly or weakly,
<br>from anywhere else), but for the other two hash tables, while they
<br>ought to be datum-weak, I don't think it matters whether they are
<br>key-weak or key-strong: their data have strong references to their
<br>keys, so as long as their data are strongly referenced, the keys will
<br>be too.
<br><br>But this is all moot until we have datum-weak hash tables. I've just
<br>left a comment by %MAKE-XML-NAME explaining this. I'll commit my
<br>changes once I have finished a LIARC build.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26881177&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26880760Re: make-eq-hash-table2009-12-21T14:03:50Z2009-12-21T14:03:50ZChris Hanson-6Actually, they want to be both key-weak and datum-weak.
<br><br>On Mon, Dec 21, 2009 at 9:12 AM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26880760&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<div class='shrinkable-quote'><br>> Date: Sun, 20 Dec 2009 21:49:38 -0800
<br>> From: Chris Hanson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26880760&i=1" target="_top" rel="nofollow">cph@...</a>>
<br>>
<br>> I agree with most of your analysis.
<br>>
<br>> OK, I'll start making the changes.
<br>>
<br>> *** xml/xml-names.scm
<br>>
<br>> This is hairy: part of it looks like it needs to be datum-weak, but we
<br>> don't have that now. But someone more familiar with the XML name
<br>> abstraction should review this.
<br>>
<br>> ****************
<br>> All three tables should be weak.
<br>>
<br>> Making them weak will do nothing, actually, because every datum in
<br>> them has a strong reference to its key. These want to be datum-weak
<br>> hash tables, not key-weak hash tables. So I think that for now, since
<br>> we don't have datum-weak hash tables, these should all be strong,
<br>> perhaps with a comment about what the state of affairs should be.
<br>>
</div><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26880760&i=2" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26877037Re: make-eq-hash-table2009-12-21T09:12:33Z2009-12-21T09:12:33ZTaylor R Campbell Date: Sun, 20 Dec 2009 21:49:38 -0800
<br> From: Chris Hanson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26877037&i=0" target="_top" rel="nofollow">cph@...</a>>
<br><br> I agree with most of your analysis.
<br><br>OK, I'll start making the changes.
<br><br> *** xml/xml-names.scm
<br><br> This is hairy: part of it looks like it needs to be datum-weak, but we
<br> don't have that now. But someone more familiar with the XML name
<br> abstraction should review this.
<br><br> ****************
<br> All three tables should be weak.
<br><br>Making them weak will do nothing, actually, because every datum in
<br>them has a strong reference to its key. These want to be datum-weak
<br>hash tables, not key-weak hash tables. So I think that for now, since
<br>we don't have datum-weak hash tables, these should all be strong,
<br>perhaps with a comment about what the state of affairs should be.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26877037&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26870168Re: make-eq-hash-table2009-12-20T21:49:38Z2009-12-20T21:49:38ZChris Hanson-6I agree with most of your analysis. Here are my comments:
<br><br>*** edwin/eystep.scm, ynode-regions
<br><br>What are the keys to these hash tables? I don't know how long they
<br>persist.
<br><br>****************
<br>The keys are stepper nodes; they are stored in a text property and
<br>consequently will be held appropriately. This should be a weak table.
<br><br>*** edwin/win32.scm, event-handlers
<br><br>The keys in EVENT-HANDLERS are integers. I think this should be a
<br>key-strong eqv hash table rather than a key-weak eq hash table.
<br><br>****************
<br>For numbers, it doesn't matter, but strong is slightly lower overhead.
<br><br>*** edwin/xterm.scm, symbol->x-atom table in display/cached-atom-tables
<br><br>Whether this should be key-strong or key-weak depends on whether the
<br>set of atoms that it will map is arbitrarily large.
<br><br>****************
<br>This table should be strong.
<br><br>*** xml/xhtml-entities.scm, table in html-char->name-map
<br><br>The keys in the table inside HTML-CHAR->NAME-MAP is keyed by
<br>characters. Should this be a key-strong eqv hash table rather than a
<br>key-weak eq hash table?
<br><br>****************
<br>Again, it doesn't matter, but strong is lower overhead.
<br><br>*** xml/xml-names.scm
<br><br>This is hairy: part of it looks like it needs to be datum-weak, but we
<br>don't have that now. But someone more familiar with the XML name
<br>abstraction should review this.
<br><br>****************
<br>All three tables should be weak.
<br><br><br>On Sun, Dec 20, 2009 at 5:29 PM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26870168&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<div class='shrinkable-quote'><br>> Date: Sun, 20 Dec 2009 15:21:20 -0800
<br>> From: Chris Hanson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26870168&i=1" target="_top" rel="nofollow">cph@...</a>>
<br>>
<br>> The documentation clearly states that make-eq-hash-table returns a
<br>> weak table, and has so stated for a long time. So it's not reasonable
<br>> to change the semantics overnight. Here's what I propose:
<br>>
<br>> [...]
<br>>
<br>> OK?
<br>>
<br>> Sounds good to me. I have gone through the list I made earlier and
<br>> updated some of my analysis. Since there were so many cases and my
<br>> analysis was very shallow, I am not yet comfortable committing changes
<br>> reflecting the analysis. Would anyone care to review the list, the
<br>> updated version of which I have attached?
<br>>
</div><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26870168&i=2" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26869078Re: make-eq-hash-table2009-12-20T17:46:08Z2009-12-20T17:46:08ZTaylor R Campbell Date: Mon, 21 Dec 2009 00:37:10 +0000
<br> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26869078&i=0" target="_top" rel="nofollow">eval.apply@...</a>
<br><br> Of course the response to this is that the obarray isn't intended
<br> to be used in this manner. It is not guaranteed to retain symbols
<br> and that it was simply an implementation detail that it happened to
<br> retain them. And user code should not assume that calling intern on
<br> a symbol will cause it to appear in the obarray.
<br><br> I argue the same is true of hash tables. User code should not
<br> assume that inserting a key/value pair in the table will cause the
<br> key to appear in the key-list.
<br><br>Your last sentence is not the documented intent, and would severely
<br>restrict the applicability of the hash table abstraction. There are
<br>cases in which that assumption is valid, and there are cases in which
<br>that assumption is not valid. In the case of the obarray (which is
<br>not expressible using the runtime's hash table abstraction, of course,
<br>because the hash table abstraction does not support key-strong,
<br>datum-weak hash tables, which is what the obarray is), the assumption
<br>is not valid.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26869078&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26868991Re: make-eq-hash-table2009-12-20T17:29:20Z2009-12-20T17:29:20ZTaylor R Campbell Date: Sun, 20 Dec 2009 15:21:20 -0800
<br> From: Chris Hanson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868991&i=0" target="_top" rel="nofollow">cph@...</a>>
<br><br> The documentation clearly states that make-eq-hash-table returns a
<br> weak table, and has so stated for a long time. So it's not reasonable
<br> to change the semantics overnight. Here's what I propose:
<br><br> [...]
<br><br> OK?
<br><br>Sounds good to me. I have gone through the list I made earlier and
<br>updated some of my analysis. Since there were so many cases and my
<br>analysis was very shallow, I am not yet comfortable committing changes
<br>reflecting the analysis. Would anyone care to review the list, the
<br>updated version of which I have attached?
<br><br />* Use of MAKE-EQ-HASH-TABLE in MIT Scheme, 2009-12-20 -*- outline -*-
<br><br>In MIT Scheme, MAKE-EQ-HASH-TABLE yields a hash table whose keys are
<br>held only weakly, so that they will be garbage-collected if there are
<br>no strong references to them. To make a similar hash table whose keys
<br>are held strongly, one must use MAKE-STRONG-EQ-HASH-TABLE explicitly.
<br>Of the sixty-two uses of MAKE-EQ-HASH-TABLE throughout the MIT Scheme
<br>source code, only four appear to need weak references to their keys,
<br>and for only two more is there an obvious reason to use weak
<br>references. This list categorizes most uses of MAKE-EQ-HASH-TABLE.
<br><br>** Hash table must be key-weak
<br><br>*** edwin/curren.scm, screen-buffer-layouts
<br>*** edwin/eystep.scm, stepper-buffers
<br>*** edwin/xterm.scm, display/cached-atoms-table
<br>*** edwin/xterm.scm, display/selection-records
<br><br>** Hash table should be key-weak, but will work as key-strong
<br><br>*** edwin/comman.scm, permanent-local-variables
<br><br>As long as Edwin variables are strongly interned, it is safe to use a
<br>key-strong hash table for properties on Edwin variables such as the
<br>permanent-local property, but if Edwin variables were weakly interned
<br>then this would be a space leak.
<br><br>*** sos/class.scm, built-in-class-table
<br><br>Dispatch tags that are garbage-collected shouldn't accumulate space
<br>here. These might arise, for instance, from re-evaluating
<br>DEFINE-RECORD-TYPE forms causing the old record type's dispatch tags
<br>to be garbage-collected. But this is not likely to be a big problem.
<br><br>** Hash table should be key-strong, but will work as key-weak
<br><br>*** compiler/machines/i386/lapopt.scm, *rules*
<br><br>If the compiler never generates instructions with certain symbols in
<br>them, and hence the compiler's code has no strong references to those
<br>symbols, then the rules for those symbols may as well be discarded.
<br>But that's pretty sketchy.
<br><br>*** compiler/machines/svm/assembler-runtime.scm, symbolic-operators
<br>*** compiler/machines/svm/assembler-runtime.scm, pvar-type-table
<br>*** compiler/machines/svm/lapopt.scm, *rules* (not really used)
<br>*** compiler/machines/x86-64/lapopt.scm, *rules* (not really used)
<br>*** edwin/nntp.scm, equivalences in build-equivalence-classes
<br><br>The only reason that this works as a key-weak hash table is that every
<br>key is also strongly referenced by the hash table's data.
<br><br>*** edwin/nntp.scm, tables in convert-header-graphs-to-trees
<br><br>In the only caller of CONVERT-HEADER-GRAPHS-TO-TREES, the (strong)
<br>list of headers is still strongly referenced, so the keys of the two
<br>hash tables in TABLES will not be garbage-collected.
<br><br>*** edwin/xterm.scm, built-in-atoms-table
<br><br>If the binding for BUILT-IN-ATOMS were collected while that for
<br>BUILT-IN-ATOMS-TABLE were not, then the latter would be in trouble.
<br>This generally doesn't happen currently.
<br><br>*** imail/imail-core.scm, memoized-resources
<br><br>As long as URLs are interned strongly, it doesn't matter whether
<br>MEMOIZED-RESOURCES is key-weak or key-strong. However, if URLs were
<br>interned weakly, then this table would need to be key-strong in order
<br>to avoid losing entries for resources that are still referenced but
<br>whose locators are not still referenced.
<br><br>*** microcode/os2pm.scm, type-abbreviations
<br>*** microcode/os2pm.scm, id-external-roots
<br><br>This code is probably defunct, but if it weren't, and if the
<br>presentation manager procedure abstraction were used outside this
<br>file, it would probably be necessary to make these two hash tables
<br>key-strong. Another hash table, PM-PROCEDURES, is incorrectly
<br>key-weak.
<br><br>*** runtime/genio.scm, {en,de}coder/sizer/{,de}normalizer maps
<br><br>Since there are maps in both directions, each hash table's keys also
<br>have strong references in the data positions of the other hash table.
<br>But this is pretty fragile, and in any case there is no need to use
<br>key-weak hash tables.
<br><br>*** runtime/sfile.scm, interned-mime-types
<br><br>This should really be a key-strong, datum-weak hash table, which the
<br>hash table abstraction does not presently support. (The same goes for
<br>UNUSUAL-INTERNED-MIME-TYPES.) Barring that, INTERNED-MIME-TYPES
<br>should be key-strong, although it happens to work as a key-weak hash
<br>table because its data have strong references to its keys anyway.
<br><br>*** runtime/syntax-output.scm, unmappings
<br>*** runtime/syntax-output.scm, rename-databases' mapping-tables
<br>*** runtime/syntax-output.scm, rename-databases' id-tables
<br>*** ssp/xmlrpc.scm, methods in get-xmlrpc-method-handler
<br><br>Since the hash table is used only in one place, and only one key is
<br>fetched out of it, that key will be strongly referenced until it is
<br>fetched, and the other keys don't matter.
<br><br>*** xml/turtle.scm, table in write-prefixes
<br><br>** Hash table must be key-strong
<br><br>*** compiler/machines/svm/assembler-runtime.scm, symbol tables
<br><br>These are probably meant to be treated like the symbol tables
<br>implemented in compiler/back/symtab.scm.
<br><br>*** imail/imail-file.scm, file-folder-types
<br>*** imail/imail-mime.scm, mime-encodings
<br>*** microcode/os2pm.scm, pm-procedures
<br>*** runtime/http-syntax.scm, header-value-defns
<br>*** ssp/mod-lisp.scm, mime-handlers
<br>*** ssp/xhtml-expander.scm, *sabbr-table*
<br><br>The processing instructions are processed incrementally as the file is
<br>parsed, so keys in the sabbr table may be garbage-collected and then
<br>re-interned, between which times the associations would be destroyed.
<br><br>*** star-parser/matcher.scm, matcher-preprocessors
<br>*** star-parser/matcher.scm, matcher-compilers
<br>*** star-parser/parser.scm, parser-preprocessors
<br>*** star-parser/parser.scm, parser-compilers
<br>*** star-parser/shared.scm, make-parser-macros
<br>*** star-parser/shared.scm, *global-parser-macros*
<br>*** xdoc/validate-xdoc.scm, element-checkers
<br>*** xdoc/xdoc.scm, html-generators
<br>*** xdoc/xdoc.scm, when-conditions
<br>*** xdoc/xdoc.scm, xdoc-content-types
<br>*** xdoc/xdoc.scm, xdoc-element-types
<br>*** xdoc/xdoc.scm, xdoc-input-canonicalizers
<br>*** xdoc/xdoc.scm, xdoc-output-definitions
<br>*** xml/xhtml.scm, element-context-map
<br><br>** Other
<br><br>*** compiler/machines/C/stackify.scm, stackify count tables
<br><br>It is not immediately clear to me whether these need to be strong, but
<br>they probably should be.
<br><br>*** compiler/rtlbase/rtlobj.scm, label->object maps
<br><br>It's not immediately obvious to me whether LABEL->OBJECT will ever be
<br>used after the last references to the keys of the hash tables involved
<br>(which cause strong references to those keys to be dropped, if
<br>COMPILER:PRESERVE-DATA-STRUCTURES? is false). A little further
<br>analysis is required. A conservative guess would be that these should
<br>to be strong.
<br><br>*** edwin/eystep.scm, ynode-regions
<br><br>What are the keys to these hash tables? I don't know how long they
<br>persist.
<br><br>*** edwin/prompt.scm, prompt-histories
<br><br>Making this key-strong is not likely to be a space leak, but if a
<br>command is garbage-collected, then so may the symbol for its history
<br>be garbage-collected, and its history is presumably no longer needed.
<br><br>*** edwin/win32.scm, event-handlers
<br><br>The keys in EVENT-HANDLERS are integers. I think this should be a
<br>key-strong eqv hash table rather than a key-weak eq hash table.
<br><br>*** edwin/xterm.scm, selection->record table in display/selection-records
<br><br>I'm not sure what the domain of possible keys to this hash table is --
<br>it may be just the symbols PRIMARY and CLIPBOARD, which will probably
<br>be strongly referenced by the rest of the Edwin code, but on the other
<br>hand I think this should probably be a key-strong hash table.
<br><br>*** edwin/xterm.scm, symbol->x-atom table in display/cached-atom-tables
<br><br>Whether this should be key-strong or key-weak depends on whether the
<br>set of atoms that it will map is arbitrarily large.
<br><br>*** xdoc/xdoc.scm, *xdoc-element-properties*
<br>*** xdoc/xdoc.scm, *xdoc-inputs*
<br>*** xdoc/xdoc.scm, *xdoc-outputs*
<br><br>As maps from XML elements by identity to properties, these three
<br>should probably be key-weak, but since new ones are created for each
<br>xdoc expansion, they could probably safely be key-strong without
<br>badly leaking memory.
<br><br>*** xdoc/xdoc.scm, *xdoc-id-map*
<br><br>This should be key-strong, although it doesn't matter until XML names
<br>become weakly interned.
<br><br>*** xml/xhtml-entities.scm, table in html-char->name-map
<br><br>The keys in the table inside HTML-CHAR->NAME-MAP is keyed by
<br>characters. Should this be a key-strong eqv hash table rather than a
<br>key-weak eq hash table?
<br><br>*** xml/xml-names.scm
<br><br>This is hairy: part of it looks like it needs to be datum-weak, but we
<br>don't have that now. But someone more familiar with the XML name
<br>abstraction should review this.<br />_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868991&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26889268Re: Re: make-eq-hash-table2009-12-20T16:37:10Z2009-12-20T16:37:10ZJoe Marshall-2On Dec 20, 2009 2:54pm, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26889268&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<br />>
<br />> It is very surprising for hash tables to be weak by
<br />> default: that causes parts of data structures to apparently randomly
<br />> vanish.
<br />
<br />I could argue that it is very surprising for *symbols* to be weak
<br />by default. It causes parts of data structures (in particular, the obarray)
<br />to apparently randomly vanish.
<br />
<br />Suppose someone had written some code that interns
<br />strings with the intent of retrieving them later from the obarray. The change
<br />you made to make weak symbols will cause this code to break. Someone
<br />might be pretty upset that parts of the data structure are randomly
<br />vanishing.
<br />
<br />Of course the response to this is that the obarray isn't intended to be
<br />used in this manner. It is not guaranteed
<br />to retain symbols and that it was simply an implementation detail that
<br />it happened to retain them. And user code should not assume that
<br />calling intern on a symbol will cause it to appear in the obarray.
<br />
<br />I argue the same is true of hash tables. User code should not assume
<br />that inserting a key/value pair in the table will cause the key to appear
<br />in the key-list.
<br />
<br />Basically, if I do this:
<br />
<br /> (hash-table/put! my-eq-table (cons 'a 'b) 'hello)
<br />
<br />There is no possible way for me to retrieve the value from this table
<br />with hash-table/get because I cannot regenerate the key. Therefore,
<br />the entry itself is useless because no one can access it. So it need
<br />not be in the table.
<br />
<br />If you are writing code that assumes the key list
<br />*will* retain the mapping even if no one else will, then you are doing
<br />the equivalent thing to using the obarray to retain symbols that no one
<br />is using. (You're relying on an accident of implementation that would
<br />be better served by simply consing a list!)
<br />
<br />> Now what would happen if I made URIs weakly interned? You would need
<br />> to change the code again, to handle URIs similarly. Next, what about
<br />> MIME types?
<br />
<br />This has been an issue in lisp for close to 50 years
<br />(see http://home.pipeline.com/~hbaker1/ObjectIdentity.html )
<br />I think the solution is probably to differentiate between the weak links to
<br />hash-table values and the weak links to hash-table keys and make the GC
<br />smarter about them. You could then write your URI's to be weakly interned
<br />(as hash table values) and this would protect them from dropping out of weak
<br />keyed tables.<br />_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26889268&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26868368Re: make-eq-hash-table2009-12-20T15:39:22Z2009-12-20T15:39:22ZArthur A. Gleckler-3> OK?
<br><br>That's an excellent plan.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868368&i=0" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26868232Re: make-eq-hash-table2009-12-20T15:21:20Z2009-12-20T15:21:20ZChris Hanson-6Now that Joe has "fixed" the handling of interned symbols, we should
<br>address the more general problem that Taylor is concerned with.
<br><br>The documentation clearly states that make-eq-hash-table returns a
<br>weak table, and has so stated for a long time. So it's not reasonable
<br>to change the semantics overnight. Here's what I propose:
<br><br>* Add a new binding make-weak-eq-hash-table (and
<br>make-weak-eqv-hash-table, which you haven't mentioned but which should
<br>also be done).
<br><br>* Change the documentation to recommend that programmers use the
<br>explicit name to guarantee a particular semantics, and to warn that
<br>make-eq-hash-table may change its semantics from weak to strong in the
<br>future.
<br><br>* Change our code base to use the explicit names in all cases.
<br><br>* File a bug report, referring to or attaching this discussion.
<br><br>* Optionally, add a compiler warning when make-eq-hash-table is used.
<br><br>* Sometime down the road, in a couple of years, close the bug report
<br>by making appropriate changes.
<br><br>OK?
<br><br>On Sun, Dec 20, 2009 at 2:54 PM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868232&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<div class='shrinkable-quote'><br>> Date: Sun, 20 Dec 2009 13:48:59 -0800
<br>> From: Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868232&i=1" target="_top" rel="nofollow">jmarshall@...</a>>
<br>>
<br>> On Sun, Dec 20, 2009 at 8:46 AM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868232&i=2" target="_top" rel="nofollow">campbell@...</a>> wrote:
<br>> > Â What I observed in MIT Scheme is that, of
<br>> > the sixty-two uses of MAKE-EQ-HASH-TABLE, more of them are incorrect,
<br>> > and need key-strong hash tables, than actally need key-weak hash
<br>> > tables.
<br>>
<br>> This is what I disagree with. If they were correct when symbols were
<br>> strongly interned, the behavior shouldn't change when symbols are
<br>> weakly interned.
<br>>
<br>> In other words, the *use* of MAKE-EQ-HASH-TABLE isn't the bug, it
<br>> is the *behavior* of MAKE-EQ-HASH-TABLE that is buggy. It should
<br>> retain symbols and numbers the same as it used to.
<br>>
<br>> Although changing symbols to be interned weakly exhibited several
<br>> problems related to eq hash tables, those cover only a subset of the
<br>> problems with using weak hash tables, only some of which are keyed by
<br>> interned symbols. It is very surprising for hash tables to be weak by
<br>> default: that causes parts of data structures to apparently randomly
<br>> vanish. I am not aware of any other system in which one gets a weak
<br>> hash table by asking for a hash table without explicitly requesting
<br>> that it be weak.
<br>>
<br>> BTW, the fix for this was trivial and I checked it in this morning.
<br>> you need these two changes:
<br>>
<br>> 77c8301526fc3a8f420c2922eefad215bd8d8dba (patch)
<br>> 097a3ee6c70d396a3277fb96374abbfc2da86e51 (patch)
<br>>
<br>> and now entries keyed by interned symbols will not drop out of EQ
<br>> hash tables. Otherwise, the behavior is as before.
<br>>
<br>> Now what would happen if I made URIs weakly interned? You would need
<br>> to change the code again, to handle URIs similarly. Next, what about
<br>> MIME types? That doesn't scale, and that makes every use of hash
<br>> tables harder to understand and control, because the behaviour of the
<br>> hash table on different data types is built into the abstraction, not
<br>> a part of its parameters.
<br>>
<br>>
<br>> _______________________________________________
<br>> MIT-Scheme-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868232&i=3" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br>> <a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br>>
</div><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868232&i=4" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26868037Re: make-eq-hash-table2009-12-20T14:54:47Z2009-12-20T14:54:47ZTaylor R Campbell Date: Sun, 20 Dec 2009 13:48:59 -0800
<br> From: Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868037&i=0" target="_top" rel="nofollow">jmarshall@...</a>>
<br><br> On Sun, Dec 20, 2009 at 8:46 AM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868037&i=1" target="_top" rel="nofollow">campbell@...</a>> wrote:
<br> > Â What I observed in MIT Scheme is that, of
<br> > the sixty-two uses of MAKE-EQ-HASH-TABLE, more of them are incorrect,
<br> > and need key-strong hash tables, than actally need key-weak hash
<br> > tables.
<br><br> This is what I disagree with. If they were correct when symbols were
<br> strongly interned, the behavior shouldn't change when symbols are
<br> weakly interned.
<br><br> In other words, the *use* of MAKE-EQ-HASH-TABLE isn't the bug, it
<br> is the *behavior* of MAKE-EQ-HASH-TABLE that is buggy. It should
<br> retain symbols and numbers the same as it used to.
<br><br>Although changing symbols to be interned weakly exhibited several
<br>problems related to eq hash tables, those cover only a subset of the
<br>problems with using weak hash tables, only some of which are keyed by
<br>interned symbols. It is very surprising for hash tables to be weak by
<br>default: that causes parts of data structures to apparently randomly
<br>vanish. I am not aware of any other system in which one gets a weak
<br>hash table by asking for a hash table without explicitly requesting
<br>that it be weak.
<br><br> BTW, the fix for this was trivial and I checked it in this morning.
<br> you need these two changes:
<br><br> 77c8301526fc3a8f420c2922eefad215bd8d8dba (patch)
<br> 097a3ee6c70d396a3277fb96374abbfc2da86e51 (patch)
<br><br> and now entries keyed by interned symbols will not drop out of EQ
<br> hash tables. Otherwise, the behavior is as before.
<br><br>Now what would happen if I made URIs weakly interned? You would need
<br>to change the code again, to handle URIs similarly. Next, what about
<br>MIME types? That doesn't scale, and that makes every use of hash
<br>tables harder to understand and control, because the behaviour of the
<br>hash table on different data types is built into the abstraction, not
<br>a part of its parameters.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26868037&i=2" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26867566Re: make-eq-hash-table2009-12-20T13:48:59Z2009-12-20T13:48:59ZJoe MarshallOn Sun, Dec 20, 2009 at 8:46 AM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26867566&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<br>> What I observed in MIT Scheme is that, of
<br>> the sixty-two uses of MAKE-EQ-HASH-TABLE, more of them are incorrect,
<br>> and need key-strong hash tables, than actally need key-weak hash
<br>> tables.
<br><br>This is what I disagree with. If they were correct when symbols were
<br>strongly interned, the behavior shouldn't change when symbols are
<br>weakly interned.
<br><br>In other words, the *use* of MAKE-EQ-HASH-TABLE isn't the bug, it
<br>is the *behavior* of MAKE-EQ-HASH-TABLE that is buggy. It should
<br>retain symbols and numbers the same as it used to.
<br><br>BTW, the fix for this was trivial and I checked it in this morning. you need
<br>these two changes:
<br>77c8301526fc3a8f420c2922eefad215bd8d8dba (patch)
<br>097a3ee6c70d396a3277fb96374abbfc2da86e51 (patch)
<br><br>and now entries keyed by interned symbols will not drop out of EQ hash tables.
<br>Otherwise, the behavior is as before.
<br><br><br>--
<br>~jrm
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26867566&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26865063Re: make-eq-hash-table2009-12-20T08:46:50Z2009-12-20T08:46:50ZTaylor R Campbell Date: Sun, 20 Dec 2009 07:55:07 -0800
<br> From: Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26865063&i=0" target="_top" rel="nofollow">jmarshall@...</a>>
<br><br> It seems to me that a weak internment scheme should not be
<br> observably different from a strong one in any way. It should only
<br> be (potentially) more memory efficient. This implies that if
<br> weakly interned objects are used as keys in a hash table, then the
<br> entries they map to must be preserved under all circumstances.
<br><br>Generally, unless I explicitly request weak references, I expect the
<br>parts of my data structures -- whether they be hash tables, weight-
<br>balanced trees, lists, &c. -- not to vanish automatically under any
<br>circumstances, irrespective of what objects I put in them. Whether
<br>programs that use weak references can observe a difference between a
<br>weak internment scheme and a strong internment scheme -- which is
<br>something that programs using only strong references, of course, can't
<br>observe -- is a separate issue.
<br><br> A weak-key EQ hash table should not be observably different from a
<br> strong one with regard to the put and get operations. It may be
<br> observably different in the count and key-list operations, that is,
<br> inaccessible entries would be allowed to drop out. If the user
<br> doesn't want this, he should use an EQUAL hash table.
<br><br>I agree with every sentence in this paragraph except for the last one.
<br>There already is a way to make a key-strong eq hash table, called
<br>MAKE-STRONG-EQ-HASH-TABLE. What I observed in MIT Scheme is that, of
<br>the sixty-two uses of MAKE-EQ-HASH-TABLE, more of them are incorrect,
<br>and need key-strong hash tables, than actally need key-weak hash
<br>tables. (There is a large number for which it doesn't really matter,
<br>or for which a key-weak hash table pretty much only accidentally
<br>works.) This led me to the conclusion that MAKE-EQ-HASH-TABLE is a
<br>confusing name.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26865063&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26864736Re: make-eq-hash-table2009-12-20T07:55:07Z2009-12-20T07:55:07ZJoe MarshallOn Sun, Dec 20, 2009 at 12:59 AM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26864736&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<br>>
<br>> The only reason that this may not have bitten anyone before is that
<br>> nobody has implemented any weak internment scheme for objects that are
<br>> ever used as keys in eq hash tables -- and the other cases are highly
<br>> unlikely to be encountered.
<br><br>I think this is the place where we disagree.
<br><br>It seems to me that a weak internment scheme should not be observably
<br>different from a strong one in any way. It should only be (potentially) more
<br>memory efficient. This implies that if weakly interned objects are used
<br>as keys in a hash table, then the entries they map to must be preserved
<br>under all circumstances.
<br><br>A weak-key EQ hash table should not be observably different from a strong
<br>one with regard to the put and get operations. It may be observably different
<br>in the count and key-list operations, that is, inaccessible entries would be
<br>allowed to drop out. If the user doesn't want this, he should
<br>use an EQUAL hash table.
<br><br><br>--
<br>~jrm
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26864736&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861872Re: make-eq-hash-table2009-12-20T00:59:44Z2009-12-20T00:59:44ZTaylor R Campbell Date: Sun, 20 Dec 2009 00:43:25 -0800
<br> From: Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861872&i=0" target="_top" rel="nofollow">jmarshall@...</a>>
<br><br> On Sun, Dec 20, 2009 at 12:25 AM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861872&i=1" target="_top" rel="nofollow">campbell@...</a>> wrote:
<br> > I don't buy `they shouldn't' unless we're prepared to eliminate
<br> > HASH-TABLE/KEY-LIST, HASH-TABLE/DATUM-LIST, HASH-TABLE/FOR-EACH, &c.,
<br> > and then rewrite everything that uses them to use a different
<br> > abstraction.
<br><br> I don't think so. If a hash table is a mapping from key to value, then the
<br> key list need only contain those items that could conceivably be looked up.
<br> It *doesn't* need to contain keys that cannot appear as arguments to
<br> hash-table/get (a subtle difference)
<br><br>There is indeed a subtle difference here, but it is one that the hash
<br>table abstraction should present clearly as a choice to the user. The
<br>hash table abstraction does provide this choice, but I contend that
<br>the name MAKE-EQ-HASH-TABLE inadequately, and dangerously, conveys the
<br>option its current implementation implies in this choice.
<br><br>The only reason that this may not have bitten anyone before is that
<br>nobody has implemented any weak internment scheme for objects that are
<br>ever used as keys in eq hash tables -- and the other cases are highly
<br>unlikely to be encountered. For example, the threading algorithm in
<br>edwin/nntp.scm will break, I believe, if the garbage collector runs
<br>some time between the evaluation of the last FOR-EACH call and the
<br>evalution of the last MAP call in BUILD-EQUIVALENCE-CLASSES. That's
<br>highly unlikely to happen, though, especially since very few people
<br>use Edwin's newsreader, and those who do only very infrequently call
<br>BUILD-EQUIVALENCE-CLASSES.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861872&i=2" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861852Re: make-eq-hash-table2009-12-20T00:43:25Z2009-12-20T00:43:25ZJoe MarshallOn Sun, Dec 20, 2009 at 12:25 AM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861852&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<div class='shrinkable-quote'><br>> Date: Sun, 20 Dec 2009 00:07:17 -0800
<br>> From: Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861852&i=1" target="_top" rel="nofollow">jmarshall@...</a>>
<br>>
<br>> Ignoring the issue of weak symbols for the moment, there is no need
<br>> to have strong references to the keys *unless* someone is depending
<br>> upon walking the hash table to find them. (and they shouldn't)
<br>>
<br>> I don't buy `they shouldn't' unless we're prepared to eliminate
<br>> HASH-TABLE/KEY-LIST, HASH-TABLE/DATUM-LIST, HASH-TABLE/FOR-EACH, &c.,
<br>> and then rewrite everything that uses them to use a different
<br>> abstraction.
</div><br>I don't think so. If a hash table is a mapping from key to value, then the
<br>key list need only contain those items that could conceivably be looked up.
<br>It *doesn't* need to contain keys that cannot appear as arguments to
<br>hash-table/get (a subtle difference)
<br><br><br>--
<br>~jrm
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861852&i=2" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861834Re: hash-table/modify!2009-12-20T00:39:41Z2009-12-20T00:39:41ZTaylor R Campbell Date: Sun, 20 Dec 2009 03:34:53 -0500
<br> From: Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861834&i=0" target="_top" rel="nofollow">campbell@...</a>>
<br><br> Date: Sun, 20 Dec 2009 00:30:22 -0800
<br> From: Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861834&i=1" target="_top" rel="nofollow">jmarshall@...</a>>
<br><br> What would happen if the modifier procedure added or deleted an element
<br> from the table? I'm thinking about the case where we've found the cell
<br> pointing at the entry, but the modifier code causes a rehash and the
<br> bucket links are rethreaded while we're trying to walk them.
<br><br> That's a screw case that blocking interrupts doesn't change. The
<br> modifier procedure is not supposed to update the table.
<br><br>It occurs to me, though, that while HASH-TABLE/MODIFY! is not
<br>documented, HASH-TABLE-UPDATE! is, and as a consequence of what I said
<br>above, our implementation of it does not conform to the specification
<br>of HASH-TABLE-UPDATE! in SRFI 69, which does not prohibit editing the
<br>hash table in <procedure> and says that
<br><br>(HASH-TABLE-UPDATE! <hash-table> <key> <procedure> <default>)
<br><br>is semantically equivalent to
<br><br>(HASH-TABLE-SET!
<br> <hash-table>
<br> <key>
<br> (<procedure> (HASH-TABLE-REF <hash-table> <key> <default>))),
<br><br>modulo duplicate evaluation of arguments. So maybe we need to change
<br>our definition of HASH-TABLE-UPDATE!, too.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861834&i=2" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861770Re: hash-table/modify!2009-12-20T00:34:53Z2009-12-20T00:34:53ZTaylor R Campbell Date: Sun, 20 Dec 2009 00:30:22 -0800
<br> From: Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861770&i=0" target="_top" rel="nofollow">jmarshall@...</a>>
<br><br> What would happen if the modifier procedure added or deleted an element
<br> from the table? I'm thinking about the case where we've found the cell
<br> pointing at the entry, but the modifier code causes a rehash and the
<br> bucket links are rethreaded while we're trying to walk them.
<br><br>That's a screw case that blocking interrupts doesn't change. The
<br>modifier procedure is not supposed to update the table.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861770&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861745Re: hash-table/modify!2009-12-20T00:30:22Z2009-12-20T00:30:22ZJoe MarshallOn Sat, Dec 19, 2009 at 11:53 PM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861745&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<div class='shrinkable-quote'><br>> Date: Sat, 19 Dec 2009 23:48:12 -0800
<br>> From: Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861745&i=1" target="_top" rel="nofollow">jmarshall@...</a>>
<br>>
<br>> You need to avoid a race between two processes trying to modify
<br>> the cell at the same time.
<br>>
<br>> None of the hash table implementation is safe for concurrent update.
<br>> It is protected only against interruption during updates. If you want
<br>> to make concurrent updates to a hash table safe, you must synchronize
<br>> them yourself, for instance with a mutex.
</div><br>What would happen if the modifier procedure added or deleted an element
<br>from the table? I'm thinking about the case where we've found the cell
<br>pointing at the entry, but the modifier code causes a rehash and the
<br>bucket links are rethreaded while we're trying to walk them.
<br><br>--
<br>~jrm
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861745&i=2" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861716Re: make-eq-hash-table2009-12-20T00:25:09Z2009-12-20T00:25:09ZTaylor R Campbell Date: Sun, 20 Dec 2009 00:07:17 -0800
<br> From: Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861716&i=0" target="_top" rel="nofollow">jmarshall@...</a>>
<br><br> Ignoring the issue of weak symbols for the moment, there is no need
<br> to have strong references to the keys *unless* someone is depending
<br> upon walking the hash table to find them. (and they shouldn't)
<br><br>I don't buy `they shouldn't' unless we're prepared to eliminate
<br>HASH-TABLE/KEY-LIST, HASH-TABLE/DATUM-LIST, HASH-TABLE/FOR-EACH, &c.,
<br>and then rewrite everything that uses them to use a different
<br>abstraction.
<br><br> Interned objects that can be recreated from their print names (that
<br> is symbols, numbers, and other symbol-like things such as hostnames
<br> and/or URLs) should be treated as strong keys, but other objects
<br> that cannot be re-created (like cons cells) should not be strong.
<br><br>How do I make new types of interned objects? For example, suppose I
<br>want to implement a hash consing scheme for expressions in a certain
<br>symbolic algebra system to speed up my job as a celestial mechanic.
<br>The hash table abstraction as is doesn't provide any way for me to
<br>tell it what types of keys should be weakly held and what types of
<br>keys should be strongly held for key-weak hash tables.
<br><br>Of course, in order to make new types of interned objects the right
<br>way, I really need a datum-weak, not key-weak, association collection,
<br>which the current hash table abstraction doesn't provide -- although I
<br>think it should. And I'd much rather implement that than implement
<br>some hook into the hash table abstraction for instructing it what to
<br>automatically treat with strong references and what to automatically
<br>treat with weak references -- such a hook would make the abstraction
<br>harder to understand and probably still more error-prone.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861716&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861679Re: make-eq-hash-table2009-12-20T00:12:38Z2009-12-20T00:12:38ZJoe MarshallOn Sat, Dec 19, 2009 at 11:04 PM, Arthur A. Gleckler <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861679&i=0" target="_top" rel="nofollow">aag@...</a>> wrote:
<div class='shrinkable-quote'><br>>
<br>> On a related note, in a recent build, I noticed some of my code
<br>> failing sporadically to find certain values in EQ hash tables.
<br>> Depending on the order in which the code was loaded, one particular
<br>> symbol value would be missing from one such table, which was used to
<br>> represent a set of symbols. I haven't had a chance to track that
<br>> down. I did spend a few hours trying to create a reproducible test
<br>> case, but failed. Could this have been caused by the keys being held
<br>> weakly? In this hash table, the keys are symbols and the values are
<br>> always #t.
</div><br>That's almost certainly what the problem was.
<br><br>I was wondering if the symbol GC change was going to affect hash tables,
<br>but I guess I didn't worry hard enough.
<br><br>--
<br>~jrm
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861679&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861650Re: make-eq-hash-table2009-12-20T00:07:17Z2009-12-20T00:07:17ZJoe MarshallOn Sat, Dec 19, 2009 at 9:50 PM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861650&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<br>> After I changed the microcode to hold only weak references to interned
<br>> symbols without global bindings, I noticed a number of problems with
<br>> weak hash tables keyed by symbols. The procedure MAKE-EQ-HASH-TABLE,
<br>> counterintuitively to me, yields hash tables with only weak references
<br>> to their keys.
<br><br>If the only reference to a key is from within the hash table itself,
<br>there is no need
<br>to keep the entry in the table (no one can generate a new reference).
<br><br>The exception is, of course, symbols. Someone can always re-create a
<br>symbol by interning a string. You probably want to handle this by
<br>strengthening symbols that happen to
<br>be used as keys in hash tables.
<br><div class='shrinkable-quote'><br>> Many uses of MAKE-EQ-HASH-TABLE in MIT Scheme actually
<br>> need key-strong hash tables, not key-weak hash tables, and after going
<br>> through all the uses, I see that the problem is worse than I expected.
<br>> Attached to this message is a summary of all sixty-two uses; here are
<br>> two noteworthy statistics:
<br>>
<br>> - Only eleven, i.e. 17%, of the uses are obviously legitimate uses for
<br>> key-weak tables.
<br>>
<br>> - Thirteen of the uses are obviously incorrect and require key-strong
<br>> hash tables. That is, more than 20% of the uses are bugs.
<br>>
<br>> At the very least, we should make sure that every use of hash tables
<br>> correctly uses key-strong or key-weak hash tables. However, I'd like
<br>> to go a step further and change the semantics of MAKE-EQ-HASH-TABLE to
<br>> yield strong hash tables, and add a separate MAKE-WEAK-EQ-HASH-TABLE
<br>> which would behave as MAKE-EQ-HASH-TABLE does currently.
<br>>
<br>> I realize that MAKE-EQ-HASH-TABLE has yielded weak hash tables since
<br>> 1993, and that its predecessor MAKE-OBJECT-HASH-TABLE has done so for
<br>> even longer than that, but since even in MIT Scheme itself there are
<br>> more incorrect uses of MAKE-EQ-HASH-TABLE than correct uses (and many
<br>> more ambiguous uses where the intent is not clear), I think that it is
<br>> dangerous to use the name MAKE-EQ-HASH-TABLE, or any name without the
<br>> word `weak' in it, for a constructor of weak hash tables.
<br>>
<br>> If we made this change, existing code using MAKE-EQ-HASH-TABLE
<br>> legitimately would exhibit space leaks only on new versions of Scheme.
<br>> On the other hand, if we don't make this change, I think that more and
<br>> more code will be written that accidentally uses weak hash tables
<br>> where strong ones are at best intended or at worst needed, with subtle
<br>> heisenbugs that show up depending on when garbage collection happens.
<br>>
<br>> Comments?
</div><br>I think you should re-analyze things.
<br><br>Ignoring the issue of weak symbols for the moment, there is no need to
<br>have strong
<br>references to the keys *unless* someone is depending upon walking the hash table
<br>to find them. (and they shouldn't)
<br><br>Interned objects that can be recreated from their print names (that is symbols,
<br>numbers, and other symbol-like things such as hostnames and/or URLs)
<br>should be treated
<br>as strong keys, but other objects that cannot be re-created (like cons
<br>cells) should
<br>not be strong.
<br><br>The issues here are subtle, and they have been been gotten wrong many
<br>times before. However, I seem to recall talking about this with CPH and GJR
<br>many years ago and I know they've given it some hard thought.
<br><br>--
<br>~jrm
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861650&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861600Re: hash-table/modify!2009-12-19T23:53:03Z2009-12-19T23:53:03ZTaylor R Campbell Date: Sat, 19 Dec 2009 23:48:12 -0800
<br> From: Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861600&i=0" target="_top" rel="nofollow">jmarshall@...</a>>
<br><br> You need to avoid a race between two processes trying to modify
<br> the cell at the same time.
<br><br>None of the hash table implementation is safe for concurrent update.
<br>It is protected only against interruption during updates. If you want
<br>to make concurrent updates to a hash table safe, you must synchronize
<br>them yourself, for instance with a mutex.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861600&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861588Re: hash-table/modify!2009-12-19T23:48:12Z2009-12-19T23:48:12ZJoe MarshallYou need to avoid a race between two processes trying to modify
<br>the cell at the same time.
<br><br>On Sat, Dec 19, 2009 at 10:49 PM, Taylor R Campbell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861588&i=0" target="_top" rel="nofollow">campbell@...</a>> wrote:
<div class='shrinkable-quote'><br>> (HASH-TABLE/MODIFY! <hash-table> <key> <modifier> [<default>]) may
<br>> call <modifier> with interrupts blocked, or with the same mask as in
<br>> the caller of HASH-TABLE/MODIFY!. I can't think of any reason to
<br>> block interrupts during the call to <modifier>, and it seems confusing
<br>> to me to call it in one of two very different states; does it seem
<br>> sensible to pull the call to it outside WITH-TABLE-LOCKED! in the body
<br>> of MAKE-METHOD:MODIFY!'s lambda in hashtb.scm? And if we made that
<br>> change, would it b necessary to lock the table at all (i.e., to block
<br>> interrupts) for the single write that SET-ENTRY-DATUM! incurs?
<br>>
<br>>
<br>> _______________________________________________
<br>> MIT-Scheme-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861588&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br>> <a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br>>
</div><br><br><br>--
<br>~jrm
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861588&i=2" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861525Re: make-eq-hash-table2009-12-19T23:30:05Z2009-12-19T23:30:05ZTaylor R Campbell Date: Sat, 19 Dec 2009 23:04:29 -0800
<br> From: "Arthur A. Gleckler" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861525&i=0" target="_top" rel="nofollow">aag@...</a>>
<br><br> On a related note, in a recent build, I noticed some of my code
<br> failing sporadically to find certain values in EQ hash tables.
<br> Depending on the order in which the code was loaded, one particular
<br> symbol value would be missing from one such table, which was used to
<br> represent a set of symbols. I haven't had a chance to track that
<br> down. I did spend a few hours trying to create a reproducible test
<br> case, but failed. Could this have been caused by the keys being held
<br> weakly? In this hash table, the keys are symbols and the values are
<br> always #t.
<br><br>If you were using MAKE-EQ-HASH-TABLE to make a hash table keyed by
<br>symbols, then this is probably caused by my 2009-12-02 change, commit
<br>056bfc369b57df0864fd88f40ce26cd0e5da75ed, which enables garbage
<br>collection of interned symbols without global bindings. If so, try
<br>using MAKE-STRONG-EQ-HASH-TABLE rather than MAKE-EQ-HASH-TABLE.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861525&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861460Re: make-eq-hash-table2009-12-19T23:04:29Z2009-12-19T23:04:29ZArthur A. Gleckler-3> Comments?
<br><br>I agree with your recommendation.
<br><br>On a related note, in a recent build, I noticed some of my code
<br>failing sporadically to find certain values in EQ hash tables.
<br>Depending on the order in which the code was loaded, one particular
<br>symbol value would be missing from one such table, which was used to
<br>represent a set of symbols. I haven't had a chance to track that
<br>down. I did spend a few hours trying to create a reproducible test
<br>case, but failed. Could this have been caused by the keys being held
<br>weakly? In this hash table, the keys are symbols and the values are
<br>always #t.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861460&i=0" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861415hash-table/modify!2009-12-19T22:49:39Z2009-12-19T22:49:39ZTaylor R Campbell(HASH-TABLE/MODIFY! <hash-table> <key> <modifier> [<default>]) may
<br>call <modifier> with interrupts blocked, or with the same mask as in
<br>the caller of HASH-TABLE/MODIFY!. I can't think of any reason to
<br>block interrupts during the call to <modifier>, and it seems confusing
<br>to me to call it in one of two very different states; does it seem
<br>sensible to pull the call to it outside WITH-TABLE-LOCKED! in the body
<br>of MAKE-METHOD:MODIFY!'s lambda in hashtb.scm? And if we made that
<br>change, would it b necessary to lock the table at all (i.e., to block
<br>interrupts) for the single write that SET-ENTRY-DATUM! incurs?
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861415&i=0" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26861209make-eq-hash-table2009-12-19T21:50:31Z2009-12-19T21:50:31ZTaylor R CampbellAfter I changed the microcode to hold only weak references to interned
<br>symbols without global bindings, I noticed a number of problems with
<br>weak hash tables keyed by symbols. The procedure MAKE-EQ-HASH-TABLE,
<br>counterintuitively to me, yields hash tables with only weak references
<br>to their keys. Many uses of MAKE-EQ-HASH-TABLE in MIT Scheme actually
<br>need key-strong hash tables, not key-weak hash tables, and after going
<br>through all the uses, I see that the problem is worse than I expected.
<br>Attached to this message is a summary of all sixty-two uses; here are
<br>two noteworthy statistics:
<br><br>- Only eleven, i.e. 17%, of the uses are obviously legitimate uses for
<br> key-weak tables.
<br><br>- Thirteen of the uses are obviously incorrect and require key-strong
<br> hash tables. That is, more than 20% of the uses are bugs.
<br><br>At the very least, we should make sure that every use of hash tables
<br>correctly uses key-strong or key-weak hash tables. However, I'd like
<br>to go a step further and change the semantics of MAKE-EQ-HASH-TABLE to
<br>yield strong hash tables, and add a separate MAKE-WEAK-EQ-HASH-TABLE
<br>which would behave as MAKE-EQ-HASH-TABLE does currently.
<br><br>I realize that MAKE-EQ-HASH-TABLE has yielded weak hash tables since
<br>1993, and that its predecessor MAKE-OBJECT-HASH-TABLE has done so for
<br>even longer than that, but since even in MIT Scheme itself there are
<br>more incorrect uses of MAKE-EQ-HASH-TABLE than correct uses (and many
<br>more ambiguous uses where the intent is not clear), I think that it is
<br>dangerous to use the name MAKE-EQ-HASH-TABLE, or any name without the
<br>word `weak' in it, for a constructor of weak hash tables.
<br><br>If we made this change, existing code using MAKE-EQ-HASH-TABLE
<br>legitimately would exhibit space leaks only on new versions of Scheme.
<br>On the other hand, if we don't make this change, I think that more and
<br>more code will be written that accidentally uses weak hash tables
<br>where strong ones are at best intended or at worst needed, with subtle
<br>heisenbugs that show up depending on when garbage collection happens.
<br><br>Comments?
<br><br />* Use of MAKE-EQ-HASH-TABLE in MIT Scheme, 2009-12-19 -*- outline -*-
<br><br>In MIT Scheme, MAKE-EQ-HASH-TABLE yields a hash table whose keys are
<br>held only weakly, so that they will be garbage-collected if there are
<br>no strong references to them. To make a similar hash table whose keys
<br>are held strongly, one must use MAKE-STRONG-EQ-HASH-TABLE explicitly.
<br>Of the sixty-two uses of MAKE-EQ-HASH-TABLE throughout the MIT Scheme
<br>source code, only seven appear to need weak references to their keys,
<br>and for only four more is there an obvious reason to use weak
<br>references. This list categorizes most uses of MAKE-EQ-HASH-TABLE. I
<br>have not analyzed the complicated uses of MAKE-EQ-HASH-TABLE in
<br>xdoc/xdoc.scm and xml/xml-names.scm.
<br><br>** Hash table must be key-weak
<br><br>*** edwin/comman.scm, permanent-local-variables
<br>*** edwin/curren.scm, screen-buffer-layouts
<br>*** edwin/eystep.scm, stepper-buffers
<br>*** edwin/xterm.scm, display/cached-atoms-table
<br>*** edwin/xterm.scm, display/selection-records
<br>*** imail/imail-core.scm, memoized-resources
<br>*** runtime/sfile.scm, interned-mime-types
<br><br>** Hash table should probably be key-weak
<br><br>*** edwin/prompt.scm, prompt-histories
<br>*** edwin/xterm.scm, symbol->atom table in display/cached-atom-tables
<br>*** imail/imail-file.scm, file-folder-types
<br>*** sos/class.scm, built-in-class-table
<br><br>** Hash table could be key-strong; not sure whether it should be
<br><br>*** compiler/machines/i386/lapopt.scm, *rules*
<br><br>If the compiler never generates instructions with certain symbols in
<br>them, and hence the compiler's code has no strong references to those
<br>symbols, then the rules for those symbols may as well be discarded.
<br>But that's pretty sketchy.
<br><br>*** compiler/machines/svm/assembler-runtime.scm, symbol tables
<br>*** compiler/machines/svm/assembler-runtime.scm, symbolic-operators
<br>*** compiler/machines/svm/assembler-runtime.scm, pvar-type-table
<br>*** compiler/machines/svm/lapopt.scm, *rules* (not really used)
<br>*** compiler/machines/x86-64/lapopt.scm, *rules* (not really used)
<br>*** edwin/nntp.scm, tables in convert-header-graphs-to-trees
<br><br>In the only caller of CONVERT-HEADER-GRAPHS-TO-TREES, the (strong)
<br>list of headers is still strongly referenced, so the keys of the two
<br>hash tables in TABLES will not be garbage-collected. But this is
<br>still sketchy (and see below on BUILD-EQUIVALENCE-CLASSES in the same
<br>file).
<br><br>*** edwin/xterm.scm, built-in-atoms-table
<br><br>If the binding for BUILT-IN-ATOMS were collected while that for
<br>BUILT-IN-ATOMS-TABLE were not, then the latter would be in trouble.
<br>But this doesn't happen currently.
<br><br>*** microcode/os2pm.scm, type-abbreviations
<br>*** microcode/os2pm.scm, id-external-roots
<br>*** microcode/os2pm.scm, pm-procedures
<br><br>This code is probably defunct, but if it weren't, and if the
<br>presentation manager procedure abstraction were used outside this
<br>file, it would probably be necessary to make these three hash tables
<br>key-strong. It's not clear to me that PM-PROCEDURES is safe as is,
<br>too.
<br><br>*** runtime/genio.scm, {en,de}coder/sizer/{,de}normalizer maps
<br><br>Since there are maps in both directions, each hash table's keys also
<br>have strong references in the data positions of the other hash table.
<br>But this is pretty fragile, and in any case there is no need to use
<br>key-weak hash tables.
<br><br>*** runtime/syntax-output.scm, unmappings
<br>*** runtime/syntax-output.scm, rename-databases' mapping-tables
<br>*** runtime/syntax-output.scm, rename-databases' id-tables
<br>*** ssp/xmlrpc.scm, methods
<br><br>Since the hash table is used only in one place, and only one key is
<br>fetched out of it, that key will be strongly referenced until it is
<br>fetched, and the other keys don't matter.
<br><br>*** xml/turtle.scm, table in write-prefixes
<br><br>** Hash table must be key-strong
<br><br>*** edwin/nntp.scm, equivalences in build-equivalence-classes
<br><br>In the expression for the call to MAP at the end of
<br>BUILD-EQUIVALENCE-CLASSES, there are no extant references to the
<br>threads except in the keys of the hash table. (SUBJECT-ALIST, and the
<br>caller's THREADS in ORGANIZE-HEADERS-INTO-THREADS, are no longer
<br>referenced at this point.) Hence the garbage collector may reclaim
<br>some (or in fact all) of the hash table's associations.
<br><br>*** imail/imail-mime.scm, mime-encodings
<br>*** runtime/http-syntax.scm, header-value-defns
<br>*** ssp/mod-lisp.scm, mime-handlers
<br>*** ssp/xhtml-expander.scm, *sabbr-table*
<br><br>The processing instructions are processed incrementally as the file is
<br>parsed, so keys in the sabbr table may be garbage-collected and then
<br>re-interned, between which times the associations will be destroyed.
<br><br>*** star-parser/matcher.scm, matcher-preprocessors
<br>*** star-parser/matcher.scm, matcher-compilers
<br>*** star-parser/parser.scm, parser-preprocessors
<br>*** star-parser/parser.scm, parser-compilers
<br>*** star-parser/shared.scm, make-parser-macros
<br>*** star-parser/shared.scm, *global-parser-macros*
<br>*** xdoc/validate-xdoc.scm, element-checkers
<br>*** xml/xhtml.scm, element-context-map
<br><br>** Unsure
<br><br>*** compiler/machines/C/stackify.scm, stackify count tables
<br>*** compiler/rtlbase/rtlobj.scm, label->object maps
<br><br>It's not immediately obvious to me whether LABEL->OBJECT will ever be
<br>used after the last references to the keys of the hash tables involved
<br>(which cause strong references to those keys to be dropped, if
<br>COMPILER:PRESERVE-DATA-STRUCTURES? is false). A little further
<br>analysis is required.
<br><br>*** edwin/eystep.scm, ynode-regions
<br><br>What are the keys to these hash tables? I don't know how long they
<br>persist.
<br><br>*** edwin/win32.scm, event-handlers
<br><br>The keys in EVENT-HANDLERS are integers. Should the table be a strong
<br>eqv hash table rather than a weak eq hash table?
<br><br>*** edwin/xterm.scm, selection->record table in display/selection-records
<br><br>I'm not sure what the domain of possible keys to this hash table is --
<br>it may be just the symbols PRIMARY and CLIPBOARD, which will probably
<br>be strongly referenced by the rest of the Edwin code, but on the other
<br>hand I think this should probably be a key-strong hash table.
<br><br>*** xml/xhtml-entities.scm, table in html-char->name-map
<br><br>The keys in the table inside HTML-CHAR->NAME-MAP is keyed by
<br>characters. Should this be a strong eqv hash table rather than a weak
<br>eq hash table?
<br><br>** Complicated
<br><br>*** xdoc/xdoc.scm
<br>*** xml/xml-names.scm
<br><br />_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26861209&i=0" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26852529implementing OS-dependent primitives on Windows2009-12-18T19:41:34Z2009-12-18T19:41:34ZTaylor R CampbellOver the past couple of years I have added some microcode primitives
<br>that have OS-dependent interfaces without (more than stubs of)
<br>implementations on Windows, which would probably be worth implementing
<br>before we make a new snapshot, if someone who knows about the Windows
<br>API and can test them is up for that. Two such interfaces that come
<br>to mind are OS_channel_synchronize and OS_open_exclusive_output_file;
<br>there may be others that I don't remember.
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26852529&i=0" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26849109Re: Jumping the gun?2009-12-18T12:11:07Z2009-12-18T12:11:07ZJoe MarshallOn Fri, Dec 18, 2009 at 11:26 AM, Chris Hanson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26849109&i=0" target="_top" rel="nofollow">cph@...</a>> wrote:
<br>> Unfortunately you also need to define an environment variable:
<br>>
<br>> NT_INCLUDE=C:\WATCOM\H\NT
<br>>
<br>> Maybe it would make sense to just hard-code that value instead of
<br>> using a variable.
<br><br>Woohoo! It worked!!!! I now have a brand new microcode and a runtime band.
<br>I'll figure out how to get the compiler bootstrapped this weekend.
<br><br>Thanks Chris!
<br><br>--
<br>~jrm
<br><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26849109&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>tag:old.nabble.com,2006:post-26848458Re: Jumping the gun?2009-12-18T11:26:22Z2009-12-18T11:26:22ZChris Hanson-6Unfortunately you also need to define an environment variable:
<br><br> NT_INCLUDE=C:\WATCOM\H\NT
<br><br>Maybe it would make sense to just hard-code that value instead of
<br>using a variable.
<br><br>On Fri, Dec 18, 2009 at 8:32 AM, Joe Marshall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26848458&i=0" target="_top" rel="nofollow">jmarshall@...</a>> wrote:
<div class='shrinkable-quote'><br>> So I tried the new compile scripts, but compile-prepare.bat errors out
<br>> after compiling a lot of stuff:
<br>>
<br>> Open Watcom Make Version 1.8
<br>> Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
<br>> Source code is available under the Sybase Open Watcom Public License.
<br>> See <a href="http://www.openwatcom.org/" target="_top" rel="nofollow">http://www.openwatcom.org/</a> for details.
<br>> wrc /q /ad /bt=nt /r /x /D__WATCOMC__ /i= ntgui.rc
<br>> ntgui.rc(2): Fatal Error! 62: Unable to open 'windows.h'
<br>> Error(E14): Cannot execute (wrc): No error
<br>> Error(E42): Last command making (ntgui.res) returned a bad status
<br>> Error(E02): Make execution terminated
<br>> 1 file(s) copied.
<br>> Open Watcom Make Version 1.8
<br>> Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
<br>> Source code is available under the Sybase Open Watcom Public License.
<br>> See <a href="http://www.openwatcom.org/" target="_top" rel="nofollow">http://www.openwatcom.org/</a> for details.
<br>> wrc /q /ad /bt=nt /r /x /D__WATCOMC__ /i= dibutils.rc
<br>> dibutils.rc(3): Fatal Error! 62: Unable to open 'winver.h'
<br>> Error(E14): Cannot execute (wrc): No error
<br>> Error(E42): Last command making (dibutils.res) returned a bad status
<br>> Error(E02): Make execution terminated
<br>> machines\i386\compiler.cbf
<br>> machines\i386\compiler.pkg
<br>> machines\i386\compiler.sf
<br>> 3 file(s) copied.
<br>> -------------------------------------
<br>>
<br>> Am I doing it wrong? Am I jumping the gun?
<br>>
<br>> --
<br>> ~jrm
<br>>
<br>>
<br>> _______________________________________________
<br>> MIT-Scheme-devel mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26848458&i=1" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br>> <a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br>>
</div><br><br>_______________________________________________
<br>MIT-Scheme-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26848458&i=2" target="_top" rel="nofollow">MIT-Scheme-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/mit-scheme-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/mit-scheme-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---MIT-Scheme---Dev-f1755.html" embed="fixTarget[1755]" target="_top" rel="nofollow">Gnu - MIT Scheme - Dev</a></p>