No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Re: serialize usage
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 29 Mar 2005 16:41:19 +0200
ben,
performing the mapping in a single step as in your mail is certainly
possible,
with the restriction that one needs a heuristic to locate object references.
A pretty simple approach is the following, but objects references might
contain
spaces, the references might be embedded in strings or composed on
the fly.
proc references o {
set refs [list]
foreach v [$o info vars] {
foreach val [split [$o set $v]] {
if {[string match ::* $val] && [::xotcl::Object isobject $val]} {
lappend refs $val
}
}
}
return $refs
}
Another approch is to locate references to autonamed objects
with the an regexp containing "::__#" .
The more complicated issue is when one implements a persistent
object store that tries to maintain references to autonamed objects,
where some references are to autonamed persistent objects and others
are to non-persistent objects. In this case, multiple serialized strings
are maintained in a database and recreated on the fly. Say:
===============================
set n0 [Object new]
set n1 [Object new]
set n2 [Object new]
$n0 set x $n1
$n1 set x $n2
$n2 set x $n0
set s1 [Serializer deepSerialize $n0]
set s2 [Serializer deepSerialize $n1]
set s3 [Serializer deepSerialize $n2]
===============================
where $n0 and $n2 are in the persistent store, the user creates in his
program arbitrary new objects and wants to recreate $n0 and $n2
at some arbitray time in some arbitrary order. Here the mapping table
from "persistent autonames" to actual autonames has to be maintained
in some variables.
A suitable approach could be to follow Zoran's ttrace: One could
map object references to some special persistent autonames and usr
an unknown handler to create these instances on demand on the fly.
To create these persistent autonames, one would not need some
heuristics, but could use a tailored "new" method for persistent
objects. This "new" can already maintain the mapping dictionary.
-gustaf
PS: indepent from this, we need a "new" that does not overwrite
existing autonamed objects.
Ben Thomasson schrieb:
>Gustaf,
>
>It is possible to handle autogenerated names, but maybe not in an
>efficient way. The serializer can walk the object-graph of
>associations and build a list of objects that exist in that graph.
>With this list you can provide a mapping from one "reference-space" to
>another. I have written a prototype serializer that handles
>associations in this fashion. It uses an intermediate
>reference-space. Ex.
>
>original -> intermediate -> new reference-space
>::xotcl::__#0 -> ::xoserialize::serial0 -> ::xotcl::__#5
>
>However walking the object graph is somewhat inefficient as I am
>looking through the
>data for references to objects. It would be much faster if Object provided an
>info associations, but I am not sure how this could be implemented.
>
>Because Tcl lacks explicit pointers or references and instead uses
>handles which are just strings, serializiation using associations will
>be very inefficient. However can the included serializer which
>supports composition handle an arbitrary object graph? Or am I
>restricted to tree structures?
>
>Thanks,
>
>Ben
>
>
>On Tue, 29 Mar 2005 11:36:24 +0200, Gustaf Neumann
><neumann_at_wu-wien.ac.at> wrote:
>
>
>>Dear Aamer,
>>
>>the general problem is quite tricky, when one serializes and saves some
>>objects
>>(e.g. containing ::xotcl::__#0), ends and restarts xotcl, creates again
>>global
>>objects with 'new' and restores the saved state containing the object
>>mentioned
>>above. 'Serialize all' does not save objects from the ::xotcl namespace,
>>but certainly
>>people can use -childof...
>>
>>The most simple solution is to remember the highest allocated id with the
>>saved state in serialize all, to provide a function to reset it and
>>leave the problem
>>to the programmer. But still, this is no good solution, if multiple save
>>states are
>>used and loaded in arbitary order.
>>
>>A better solution is to
>> a) check in 'new', whether an object with the generated autoname
>>exists already, and
>> b) provide a wrapper for loading the serialized code that extracts all
>>patterns
>> of autonames, and remaps some or all symbols if necessary (for
>>handling preexisting
>> objects with autonames). This could be done by searching for
>>autoname patterns
>> during serialization and using similar to the -map option of the
>>Serializer....;
>> but still, this only works, when the autonamed objects are
>>serialzed; for references
>> in variables we would need a global map table, which is still
>>depending on the
>> restore order of the serialized code if multiple pieces are saved.....
>>
>> What are you trying? would (a) be sufficient for you? It is slightly
>>slower than the
>> current version, but i don't think it is worth adding another option to
>>new for checking
>> on demand...
>>
>>best regards
>>-gustaf neumann
>>Aamer Akhter schrieb:
>>
>>
>>
>>>I just tried this with 1.3.6 and it appears to be working. Sort of
>>>related question, how do people handle the swizzling/unswizzling of
>>>autogenerated object names (eg ::xotcl__#0) when restoring an object?
>>>
>>>
>>>
>>>
>>_______________________________________________
>>Xotcl mailing list
>>Xotcl_at_alice.wu-wien.ac.at
>>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>>
>>
>>
Date: Tue, 29 Mar 2005 16:41:19 +0200
ben,
performing the mapping in a single step as in your mail is certainly
possible,
with the restriction that one needs a heuristic to locate object references.
A pretty simple approach is the following, but objects references might
contain
spaces, the references might be embedded in strings or composed on
the fly.
proc references o {
set refs [list]
foreach v [$o info vars] {
foreach val [split [$o set $v]] {
if {[string match ::* $val] && [::xotcl::Object isobject $val]} {
lappend refs $val
}
}
}
return $refs
}
Another approch is to locate references to autonamed objects
with the an regexp containing "::__#" .
The more complicated issue is when one implements a persistent
object store that tries to maintain references to autonamed objects,
where some references are to autonamed persistent objects and others
are to non-persistent objects. In this case, multiple serialized strings
are maintained in a database and recreated on the fly. Say:
===============================
set n0 [Object new]
set n1 [Object new]
set n2 [Object new]
$n0 set x $n1
$n1 set x $n2
$n2 set x $n0
set s1 [Serializer deepSerialize $n0]
set s2 [Serializer deepSerialize $n1]
set s3 [Serializer deepSerialize $n2]
===============================
where $n0 and $n2 are in the persistent store, the user creates in his
program arbitrary new objects and wants to recreate $n0 and $n2
at some arbitray time in some arbitrary order. Here the mapping table
from "persistent autonames" to actual autonames has to be maintained
in some variables.
A suitable approach could be to follow Zoran's ttrace: One could
map object references to some special persistent autonames and usr
an unknown handler to create these instances on demand on the fly.
To create these persistent autonames, one would not need some
heuristics, but could use a tailored "new" method for persistent
objects. This "new" can already maintain the mapping dictionary.
-gustaf
PS: indepent from this, we need a "new" that does not overwrite
existing autonamed objects.
Ben Thomasson schrieb:
>Gustaf,
>
>It is possible to handle autogenerated names, but maybe not in an
>efficient way. The serializer can walk the object-graph of
>associations and build a list of objects that exist in that graph.
>With this list you can provide a mapping from one "reference-space" to
>another. I have written a prototype serializer that handles
>associations in this fashion. It uses an intermediate
>reference-space. Ex.
>
>original -> intermediate -> new reference-space
>::xotcl::__#0 -> ::xoserialize::serial0 -> ::xotcl::__#5
>
>However walking the object graph is somewhat inefficient as I am
>looking through the
>data for references to objects. It would be much faster if Object provided an
>info associations, but I am not sure how this could be implemented.
>
>Because Tcl lacks explicit pointers or references and instead uses
>handles which are just strings, serializiation using associations will
>be very inefficient. However can the included serializer which
>supports composition handle an arbitrary object graph? Or am I
>restricted to tree structures?
>
>Thanks,
>
>Ben
>
>
>On Tue, 29 Mar 2005 11:36:24 +0200, Gustaf Neumann
><neumann_at_wu-wien.ac.at> wrote:
>
>
>>Dear Aamer,
>>
>>the general problem is quite tricky, when one serializes and saves some
>>objects
>>(e.g. containing ::xotcl::__#0), ends and restarts xotcl, creates again
>>global
>>objects with 'new' and restores the saved state containing the object
>>mentioned
>>above. 'Serialize all' does not save objects from the ::xotcl namespace,
>>but certainly
>>people can use -childof...
>>
>>The most simple solution is to remember the highest allocated id with the
>>saved state in serialize all, to provide a function to reset it and
>>leave the problem
>>to the programmer. But still, this is no good solution, if multiple save
>>states are
>>used and loaded in arbitary order.
>>
>>A better solution is to
>> a) check in 'new', whether an object with the generated autoname
>>exists already, and
>> b) provide a wrapper for loading the serialized code that extracts all
>>patterns
>> of autonames, and remaps some or all symbols if necessary (for
>>handling preexisting
>> objects with autonames). This could be done by searching for
>>autoname patterns
>> during serialization and using similar to the -map option of the
>>Serializer....;
>> but still, this only works, when the autonamed objects are
>>serialzed; for references
>> in variables we would need a global map table, which is still
>>depending on the
>> restore order of the serialized code if multiple pieces are saved.....
>>
>> What are you trying? would (a) be sufficient for you? It is slightly
>>slower than the
>> current version, but i don't think it is worth adding another option to
>>new for checking
>> on demand...
>>
>>best regards
>>-gustaf neumann
>>Aamer Akhter schrieb:
>>
>>
>>
>>>I just tried this with 1.3.6 and it appears to be working. Sort of
>>>related question, how do people handle the swizzling/unswizzling of
>>>autogenerated object names (eg ::xotcl__#0) when restoring an object?
>>>
>>>
>>>
>>>
>>_______________________________________________
>>Xotcl mailing list
>>Xotcl_at_alice.wu-wien.ac.at
>>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>>
>>
>>