anyway to change the printed representation of a hash table?
i ask since, when i write unit tests, the printed representations
looks like this #<HASH-TABLE :TEST EQL :COUNT 5 {128F4379}> where the
numbers in the {brackets} can change. so writing regression suites to
test that old output is the same as new gets complicated
my current solution is overly-elaborate; i.e. bury my hash tables in
some other struct; e.g.
(defstruct hash
(contents (make-hash-table)))
then duplicating the hash-table interface for my hash struct then
adding a print function to "hash"
but that does seem overkill. all i need is access to the magic name of
the hash table printer then i'd tune it myself.
anyone know that magic function name?
thanks!
tim
In article
<····································@d36g2000prf.googlegroups.com>,
Tim Menzies <···········@gmail.com> wrote:
> anyway to change the printed representation of a hash table?
>
> i ask since, when i write unit tests, the printed representations
> looks like this #<HASH-TABLE :TEST EQL :COUNT 5 {128F4379}> where the
> numbers in the {brackets} can change. so writing regression suites to
> test that old output is the same as new gets complicated
>
> my current solution is overly-elaborate; i.e. bury my hash tables in
> some other struct; e.g.
>
> (defstruct hash
> (contents (make-hash-table)))
>
> then duplicating the hash-table interface for my hash struct then
> adding a print function to "hash"
>
> but that does seem overkill. all i need is access to the magic name of
> the hash table printer then i'd tune it myself.
>
> anyone know that magic function name?
>
> thanks!
>
> tim
For example:
CL-USER 54 > (make-hash-table)
#<EQL Hash Table{0} 4020002F7B>
CL-USER 55 > (type-of *)
HASH-TABLE
CL-USER 56 > (defmethod print-object ((object hash-table) stream) (format stream "#<HT>"))
Error: Defining (METHOD PRINT-OBJECT (HASH-TABLE T)) visible from packages COMMON-LISP, CLOS.
1 (continue) Define it anyway.
2 Discard the new method.
3 (abort) Return to level 0.
4 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other options.
CL-USER 57 : 1 > :c 1
#<STANDARD-METHOD PRINT-OBJECT NIL (HASH-TABLE T) 413065880B>
CL-USER 58 > (make-hash-table)
#<HT>
--
http://lispm.dyndns.org/
TM> i ask since, when i write unit tests, the printed representations
TM> looks like this #<HASH-TABLE :TEST EQL :COUNT 5 {128F4379}> where the
TM> numbers in the {brackets} can change. so writing regression suites to
TM> test that old output is the same as new gets complicated
why do you compare printed representation instead of comparing objects
themselves? EQUALP should handle hash table comparisons.
On Dec 22, 4:05 am, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> TM> i ask since, when i write unit tests, the printed representations
> TM> looks like this #<HASH-TABLE :TEST EQL :COUNT 5 {128F4379}> where the
> TM> numbers in the {brackets} can change. so writing regression suites to
> TM> test that old output is the same as new gets complicated
>
> why do you compare printed representation instead of comparing objects
> themselves? EQUALP should handle hash table comparisons.
i had some trouble with caching the results of some of my code into
unit tests, particularly with structs. so i wrapped them in strings
and compared results using "samep" (see below)
(defun whitespacep (char)
(member char '(#\Space #\Tab #\Newline #\Page) :test #'char=))
(defun whiteout (seq)
(remove-if #'whitespacep seq))
(defun samep (x y)
(string= (whiteout (format nil "~(~a~)" x))
(whiteout (format nil "~(~a~)" y))))
but your question made me nervous. i've just gone back to those
problematic unit tests and tried to reproduce the old problem i was
having. and i can't (can anyone say "d'oh!"?). so i think my
questions was some function of prior confusion
on the other hand, i'm glad i asked the question. rainer's print-
object is a _nice_ idiom.
(defmethod print-object ((object hash-table) stream) (format stream
"#<HT>"))
in any case, i'll use equalp in future, as you advise.
thanks!
tim menzies
In article
<····································@s24g2000vbp.googlegroups.com>,
Tim Menzies <···········@gmail.com> wrote:
> On Dec 22, 4:05�am, "Alex Mizrahi" <········@users.sourceforge.net>
> wrote:
> > �TM> i ask since, when i write unit tests, the printed representations
> > �TM> looks like this �#<HASH-TABLE :TEST EQL :COUNT 5 {128F4379}> where the
> > �TM> numbers in the {brackets} can change. so writing regression suites to
> > �TM> test that old output is the same as new gets complicated
> >
> > why do you compare printed representation instead of comparing objects
> > themselves? EQUALP should handle hash table comparisons.
>
> i had some trouble with caching the results of some of my code into
> unit tests, particularly with structs. so i wrapped them in strings
> and compared results using "samep" (see below)
>
> (defun whitespacep (char)
> (member char '(#\Space #\Tab #\Newline #\Page) :test #'char=))
but you know cl:whitespace-char-p ?
>
> (defun whiteout (seq)
> (remove-if #'whitespacep seq))
>
> (defun samep (x y)
> (string= (whiteout (format nil "~(~a~)" x))
> (whiteout (format nil "~(~a~)" y))))
>
> but your question made me nervous. i've just gone back to those
> problematic unit tests and tried to reproduce the old problem i was
> having. and i can't (can anyone say "d'oh!"?). so i think my
> questions was some function of prior confusion
>
> on the other hand, i'm glad i asked the question. rainer's print-
> object is a _nice_ idiom.
>
> (defmethod print-object ((object hash-table) stream) (format stream
> "#<HT>"))
>
> in any case, i'll use equalp in future, as you advise.
>
> thanks!
>
> tim menzies
--
http://lispm.dyndns.org/
In article <····························@news-europe.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@s24g2000vbp.googlegroups.com>,
> Tim Menzies <···········@gmail.com> wrote:
>
> > On Dec 22, 4:05�am, "Alex Mizrahi" <········@users.sourceforge.net>
> > wrote:
> > > �TM> i ask since, when i write unit tests, the printed representations
> > > �TM> looks like this �#<HASH-TABLE :TEST EQL :COUNT 5 {128F4379}> where the
> > > �TM> numbers in the {brackets} can change. so writing regression suites to
> > > �TM> test that old output is the same as new gets complicated
> > >
> > > why do you compare printed representation instead of comparing objects
> > > themselves? EQUALP should handle hash table comparisons.
> >
> > i had some trouble with caching the results of some of my code into
> > unit tests, particularly with structs. so i wrapped them in strings
> > and compared results using "samep" (see below)
> >
> > (defun whitespacep (char)
> > (member char '(#\Space #\Tab #\Newline #\Page) :test #'char=))
>
> but you know cl:whitespace-char-p ?
>
Oops, that's Lispworks not CL. Sorry for the confusion...
> >
> > (defun whiteout (seq)
> > (remove-if #'whitespacep seq))
> >
> > (defun samep (x y)
> > (string= (whiteout (format nil "~(~a~)" x))
> > (whiteout (format nil "~(~a~)" y))))
> >
> > but your question made me nervous. i've just gone back to those
> > problematic unit tests and tried to reproduce the old problem i was
> > having. and i can't (can anyone say "d'oh!"?). so i think my
> > questions was some function of prior confusion
> >
> > on the other hand, i'm glad i asked the question. rainer's print-
> > object is a _nice_ idiom.
> >
> > (defmethod print-object ((object hash-table) stream) (format stream
> > "#<HT>"))
> >
> > in any case, i'll use equalp in future, as you advise.
> >
> > thanks!
> >
> > tim menzies
--
http://lispm.dyndns.org/