Re: hashq values and weak references

Tom Lord <lord-1tv/[email protected]> writes:

>     > From: Andreas Rottmann <[email protected]>
>
>     > Andreas Rottmann <[email protected]> writes:
>
>     > > Since you seem quite opposed to the memchunk idea, I took
>     > > another look at the object data areas, and it seems instead
>     > > of having the data in a separate memchunk, we might as well
>     > > keep it in the hashtree items, thus avoiding the memchunk
>     > > issue.
>
>     > At the additional cost that the memory in object data area
>     > must be copied, but I guess that's neglectable unless you
>     > stick large stuff in there (would we?).
>
> I'm a little confused as to what you're talking about.
>
> I'm assuming that you're working solving the hashq problem: that with
> our copying collector an address-based HASHQ is no good -- the address
> of an object can change over time.
>
Yep, while attemting to implement object locks, I discovered a
generalization of a problem inherent to both "hashq problem" and
object lock: associate a data area with a scheme object. I thus
implemented an interface to do so, see [0].

I then implemented the solution to the hashq problem by using object
data areas. My integration branch should have a solution to the hashq
problem already, even if it's not the way you thought it should be
solved (you never commented on my mail[0]...)

I'll comment on the divergance of your proposed approach with the
current state in another mail.

[0] http://article.gmane.org/gmane.lisp.scheme.pika.devel/221

Andy
-- 
Andreas Rottmann         | [email protected]      | [email protected] | [email protected]
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

It's *GNU*/Linux dammit!