For debugging purposes, I'm trying to monitor when adjust-array does
actually return a new array rather than succeeding at expanding the
provided one.
I'm using (sxhash array) for such a purpose, but I don't think
that's entirely adequate as even though the array might not
be changed, sxhash seems to report a different number each
time I modify (add to) the array, which kind of makes sense
for a hash value.
Is there a way to get at the object identity, just for display
purpose? (ie: the fact that this value could be implementation
dependant is just irrelevant)
Something along the lines
(defun address-of (object)
( ...
The CLHS only defines the identity function as, well, something
that returns its argument (hit and miss 1) , and the word "address" is
not even in
the index ... (hit and miss 2) ... :(
Many Thanks.
--
JFB ()
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: sxhash and object identity
Date:
Message-ID: <87zmo0biwp.fsf@qrnik.zagroda>
verec <·····@mac.com> writes:
> Is there a way to get at the object identity, just for display
> purpose?
If you only want to check whether it changed, save the old object in
a variable and later compare the variable with the new object by EQ
or EQV.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In article <·························@news.aaisp.net.uk>, verec wrote:
> For debugging purposes, I'm trying to monitor when adjust-array does
> actually return a new array rather than succeeding at expanding the
> provided one.
>
> I'm using (sxhash array) for such a purpose, but I don't think
> that's entirely adequate as even though the array might not
> be changed, sxhash seems to report a different number each
> time I modify (add to) the array, which kind of makes sense
> for a hash value.
>
> Is there a way to get at the object identity, just for display
> purpose? (ie: the fact that this value could be implementation
> dependant is just irrelevant)
>
> Something along the lines
>
> (defun address-of (object)
> ( ...
>
> The CLHS only defines the identity function as, well, something
> that returns its argument (hit and miss 1) , and the word "address" is
> not even in
> the index ... (hit and miss 2) ... :(
>
> Many Thanks.
This is old, non-portable and incomplete. You might be able to extend
it using some internals from (PRINT-UNREADABLE-OBJECT :IDENTITY T).
Indeed, maybe PRINT-UNREADABLE-OBJECT is sufficient for your purpose,
and it's portable too. Note that current storage location address
isn't the same as object identity given the possibility for objects to
be relocated during GC. -- Andrew
;;;;;
;;;
;;; OBJECT-INTERNAL-POINTER
;;;
;;; Map from arbitrary objects to integers, suitable for unique ids.
;;; Note: All of the following were gleaned from Victoria Day PCL
;;; sources.
;;;
;;;;;
(defun object-internal-pointer (object)
"Given an arbitrary object, return an integer (should be fixnum in
many cases, unknown how Xerox and Gold Hill deal with this) which is
unique to that object, generally its actual pointer address"
(flet ((abut (x y)
(+ y (* x (expt 10 (1+ (floor (log y 10))))))))
#+CMU 0
#+(AND EXCL (NOT (AND ALLEGRO-VERSION>= (VERSION>= 5 0))))
(excl::pointer-to-fixnum object)
#+(AND EXCL ALLEGRO-VERSION>= (VERSION>= 5 0))
(excl::pointer-to-address object)
#+SYMBOLICS (si:%pointer object)
#+CORAL (ccl::%ptr-to-int object)
#+GOLD-HILL (multiple-value-call #'abut (sys:%pointer object))
#+HP (·····@inf object)
#+IBCL (si:address object)
#+KCL (si:address object)
#+LUCID (lucid::%pointer object)
#+PYR 0
#+TI (si:%pointer object)
#+VAXL (system::%sp-pointer->fixnum object)
#+XEROX (abut (il::\\hiloc object) (il::\\loloc object))
))
On 2005-11-21 18:06:57 +0000, Andrew Philpot <·······@isi.edu> said:
> This is old, non-portable and incomplete. You might be able to extend
> it using some internals from (PRINT-UNREADABLE-OBJECT :IDENTITY T).
> Indeed, maybe PRINT-UNREADABLE-OBJECT is sufficient for your purpose,
> and it's portable too. Note that current storage location address
> isn't the same as object identity given the possibility for objects to
> be relocated during GC. -- Andrew
>
> ;;;;;
> ;;;
> ;;; OBJECT-INTERNAL-POINTER
> ;;;
> ;;; Map from arbitrary objects to integers, suitable for unique ids.
> ;;; Note: All of the following were gleaned from Victoria Day PCL
> ;;; sources.
> ;;;
> ;;;;;
>
> (defun object-internal-pointer (object)
> "Given an arbitrary object, return an integer (should be fixnum in
> many cases, unknown how Xerox and Gold Hill deal with this) which is
> unique to that object, generally its actual pointer address"
> (flet ((abut (x y)
> (+ y (* x (expt 10 (1+ (floor (log y 10))))))))
> #+CMU 0
> #+(AND EXCL (NOT (AND ALLEGRO-VERSION>= (VERSION>= 5 0))))
> (excl::pointer-to-fixnum object)
> #+(AND EXCL ALLEGRO-VERSION>= (VERSION>= 5 0))
> (excl::pointer-to-address object)
> #+SYMBOLICS (si:%pointer object)
> #+CORAL (ccl::%ptr-to-int object)
> #+GOLD-HILL (multiple-value-call #'abut (sys:%pointer object))
> #+HP (·····@inf object)
> #+IBCL (si:address object)
> #+KCL (si:address object)
> #+LUCID (lucid::%pointer object)
> #+PYR 0
> #+TI (si:%pointer object)
> #+VAXL (system::%sp-pointer->fixnum object)
> #+XEROX (abut (il::\\hiloc object) (il::\\loloc object))
> ))
Excellent.
I'll dig and find out about the
#+LISPWORKS
case.
OTOH, it might be the case that the FFI holds (parts of) the answer ...
Many Thanks!
--
JFB ()
verec wrote:
>
> Excellent.
>
> I'll dig and find out about the
> #+LISPWORKS
> case.
>
> OTOH, it might be the case that the FFI holds (parts of) the answer ...
Try sys:object-address it should give you what you need.
Sean.
Andrew Philpot <·······@isi.edu> wrote:
+---------------
| This is old, non-portable and incomplete. ...
...
| (defun object-internal-pointer (object)
| "Given an arbitrary object, return an integer (should be fixnum in
| many cases, unknown how Xerox and Gold Hill deal with this) which is
| unique to that object, generally its actual pointer address"
| (flet ((abut (x y)
| (+ y (* x (expt 10 (1+ (floor (log y 10))))))))
| #+CMU 0
...
+---------------
You can change the CMUCL entry to this:
#+cmu (kernel:get-lisp-obj-address object)
though be advised that due to the way CMUCL handles the memory
mapping for its heap, the result will probably be a FIXNUM only
for "small immediates", e.g.:
> (mapcar #'kernel:get-lisp-obj-address '(37 #\A 23.4 foo (bar) t nil))
(148 16806 1487569263 1486380807 1487569307 671088679 671088651)
> (mapcar #'fixnump *)
(T T NIL NIL NIL NIL NIL)
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: sxhash and object identity
Date:
Message-ID: <87d5ksl8k7.fsf@qrnik.zagroda>
Andrew Philpot <·······@isi.edu> writes:
> (defun object-internal-pointer (object)
> "Given an arbitrary object, return an integer (should be fixnum in
> many cases, unknown how Xerox and Gold Hill deal with this) which is
> unique to that object, generally its actual pointer address"
> (flet ((abut (x y)
> (+ y (* x (expt 10 (1+ (floor (log y 10))))))))
Using this abut function doesn't guarantee uniqueness,
e.g. (abut 12 3) is the same as (abut 1 23).
With some implementation techniques object-internal-pointer is
unimplementable without allocating extra memory living as long
as the object. Consider a copying GC: the address is variable,
and there is no other identifying attribute.
(Hashing by object identity is solvable without an equivalent of
object-internal-pointer. It's enough to produce a hashable tag such
that the runtime can later find it again for the same object, and
the tag can be GC'd earlier than the object.)
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/