Subject: [clisp-list] weak key hash table :test choice & surviving .mem image generatio n

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Aug 12 02:24:03 2002

Hi,

how do CLISP's new weak-key tables interact with system objects, esp. the #<MACHINE xyz> or #<ADDRESS> objects?
What :test keyword would be suitable for such a thing?

I was considering putting #<encoding> objects in a weak table. The weak functionality is necessary, because there can be arbitrarily many [in EQ terms] encoding objects in history (even though the set of really different slot values [what EQUALP considers] is finite), and the table should not grow monotically. The table is wished for because of typical caching issues: I don't want to repeat some (supposedly costly) string conversions.

[15]> (describe-thing (ext:make-encoding :charset charset:iso-8859-1 :line-terminator :dos))
0. :DOS
1. :ERROR
2. :ERROR
3. CHARSET:ISO-8859-1
4. #<ADDRESS #x010DF448>
5. #<ADDRESS #x010DF68C>
6. #<ADDRESS #x010E0370>
7. #<ADDRESS #x010E0610>
8. #<ADDRESS #x010E0C48>
9. #<ADDRESS #x00651CF0>
#<ENCODING CHARSET:ISO-8859-1 :DOS>

1) Can one store encoding objects in a Lisp data structure, then to an image and hope they will be resurrected? (I.e. what happens to these #<ADDRESS> things?)

2) Do these #<ADDRESS> things survive starting from a new image when stored in a weak-table?

3) Does resurrecting lead to crashes because the addresses may point to old, now inexistant memory addresses?
The response to this is not a "try it out" issue, because the behaviour may be different depending on the underlying OS, stack size or on the number of modules loaded in this session of CLISP, or on the time of the day. "Try it out" could work for me and break on your machine.

4) what's a good :TEST predicate for retrieving things that contain such #<ADDRESS> objects?

5) how to reliably store unknown encodings so that they survive restarting from an image?

[9]> (defun describe-thing (o)
  (dotimes (i (sys::%record-length o) o)
    (format t "~&~D. ~S~%" i (sys::%record-ref o i))))

Regards,
	Jörg Höhle.

---

From: Sam Steingold <[email-masked]>
Date: Mon Aug 12 07:46:04 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] weak key hash table :test choice & surviving .mem image generatio n"
> * Sent on Mon, 12 Aug 2002 11:23:18 +0200
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
> how do CLISP's new weak-key tables interact with system objects,
> esp. the #<MACHINE xyz> or #<ADDRESS> objects?  What :test keyword
> would be suitable for such a thing?

'EQ

> I was considering putting #<encoding> objects in a weak table.

don't.

> The weak functionality is necessary, because there can be arbitrarily
> many [in EQ terms] encoding objects in history (even though the set of
> really different slot values [what EQUALP considers] is finite), and
> the table should not grow monotically. The table is wished for because
> of typical caching issues: I don't want to repeat some (supposedly
> costly) string conversions.
> 
> 1) Can one store encoding objects in a Lisp data structure, then to an
> image and hope they will be resurrected? (I.e. what happens to these
> #<ADDRESS> things?)

dunno (probably not).
Bruno?

> 2) Do these #<ADDRESS> things survive starting from a new image when

dunno (probably not).
Bruno?

> 4) what's a good :TEST predicate for retrieving things that contain

'EQ

> restarting from an image?

store them in a "lazy" way: as a list of charset,
LINE-TERMINATOR, and ERROR actions.

Part of the problem is that, depending on the machine on which the
memory image is created, the set of the available iconv encodings may be
different.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Illiterate?  Write today, for free help!