Lisp HUG Maillist Archive

Same (uninterned) symbol, two different identities in delivered app?


It's a long story basically, a lot of macros, and a hashtable that maps
from symbol to string.

I'm in a situation where the program is searching for the symbol -
generated by a gensym/containing the number in its name; but not finding
a match.   Upon not finding a match, a dump of the hashtable's contents
reveal that the symbol (by name) is there; but at a different
system:object-address.

It happens only in a deployed app, not when running my code from the IDE.

The example spans multiple modules/FASLs.

Before trying to isolate it or correct it - could someone explain to me
how, in any way, the emission of a gensym call, a symbol of a certain
string/number, can end up being represented as 2 different identities? 
This would help me track down what's going on.

Thanks,
Matt


Re: Same (uninterned) symbol, two different identities in delivered app?

Matt Lamari wrote:

> Before trying to isolate it or correct it - could someone explain to me
> how, in any way, the emission of a gensym call, a symbol of a certain
> string/number, can end up being represented as 2 different identities?

Using GENSYM it is possible to generate two different symbols with the
same name.  For example:

CL-USER 4 > (let ((a (gensym 1))
                   (b (gensym 1)))
               (list (eq a b)
                     (equal (symbol-name a) (symbol-name b))))
(NIL T)

Maybe this is related to your problem?

Arthur


Re: Same (uninterned) symbol, two different identities in delivered app?

Matt Lamari <matt.lamari@gmail.com> writes:

> It's a long story basically, a lot of macros, and a hashtable that maps
> from symbol to string.
>
> I'm in a situation where the program is searching for the symbol -
> generated by a gensym/containing the number in its name; but not finding
> a match.   Upon not finding a match, a dump of the hashtable's contents
> reveal that the symbol (by name) is there; but at a different
> system:object-address.
>
> It happens only in a deployed app, not when running my code from the IDE.
>
> The example spans multiple modules/FASLs.
>
> Before trying to isolate it or correct it - could someone explain to me
> how, in any way, the emission of a gensym call, a symbol of a certain
> string/number, can end up being represented as 2 different identities? 
> This would help me track down what's going on.

Perhaps you are filling the table at compilation time, and you are
using it at run-time, and you call gensym twice too?

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/


Re: Same (uninterned) symbol, two different identities in delivered app?

Unable to parse email body. Email id is 10509

Re: Same (uninterned) symbol, two different identities in delivered app?

Hi Matt,

On Sun, Aug 29, 2010 at 2:37 PM, Matt Lamari <matt.lamari@gmail.com> wrote:



Thanks, I tested for 2 gensym calls but that is not what's happening.

At the point of "gensym" call it actually uses this (name being a string)

(registered-symbol (gensym (format nil "Symbol_~A_~S_" (if name name "G") (get-internal-real-time))))

This encodes the current time in, AND uses the gensym's counter.  Note - "registered-symbol" is what puts it in the hashtable and returns it.

At point of search (all values displayed as (cons key (object-address key)))

At failure point:
(#:|Symbol_CREATE-RESULT-CONTINUATION_56824_1447894| . 557240340)
not found, in hash table containing (amongst others):

(#:|Symbol_CREATE-RESULT-CONTINUATION_56824_1447894| . 557262316)


I want to find out what makes such a thing possible so that I either isolate some activity or desist.  Is there a case across FASLs that would cause a symbol to be cloned?

 
You're running into the issue that two symbols with the same name don't need to be the same symbol:

 (eq #:x #:x)
--> NIL

but:

 (eq #1=#:x #1#)
--> T

Now, if you have two fasls, both of which cointain an uninterned symbol #:x, how should the reader know it's the same symbol? After all, *all* uninterned symbols are unique?

The problem here is probably in your attempt to store the same (uninterned) symbol in different places and accross sessions.


Bye,

Erik.

Updated at: 2020-12-10 08:38 UTC