On Wed, 11 Jan 2006 at 23:49:16 -0500, Alan Ruttenberg wrote:
> Can't quite see how this would fix things. The thing is that the
> symptom is that once all the keys are in the table, even with this
> change, how would a duplicate key be added?
When you call SETF GEHASH, you're really calling EqualpHashTable.put(),
which checks to see if there is already a key in the table that matches
according to the test. If a match is found, the new value replaces the
old value associated with the existing key, and the table does not grow.
However, if the test is Object.equals(), which amounts to EQ, the match
will only happen if you're using the same exact object as the key. This
won't be the case, since SUBSTRING always returns a freshly allocated
string. So a new entry will be created in the table for the "new" key,
and the table grows.
Changing Object.equals() to LispObject.equalp() is, in effect, changing
the test from EQ to EQUALP. With this change, the existing key will be
identified correctly as matching the key passed in, and the entry will
The waters were muddied a bit more because put() and remove() had the
equals() bug, but get() did not; it used equalp() from the beginning,
so retrievals worked correctly.