Hello,
I seem to be missing something basic in the usage of Serializer:
package require XOTcl namespace import ::xotcl::* package require xotcl::serializer set a [Object new] $a set b hello Serializer deepSerialize $a
the last command doesn't seem to return anything. I had expected the creation and config code for $a. What am I missing?
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?
On Sun, 27 Mar 2005 02:17:43 -0500, Aamer Akhter aakhter@gmail.com wrote:
Hello,
I seem to be missing something basic in the usage of Serializer:
package require XOTcl namespace import ::xotcl::* package require xotcl::serializer set a [Object new] $a set b hello Serializer deepSerialize $a
the last command doesn't seem to return anything. I had expected the creation and config code for $a. What am I missing?
-- Aamer Akhter / aakhter@gmail.com
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?
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@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@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
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@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@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
Gustaf,
inline
On Mar 29, 2005 5:36 AM, Gustaf Neumann neumann@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...
hmm. for my current uses i've basically started keeping a string variable and kept on appending to it the properties i wanted in my object. at the time of creating the object, i do an md5 on the string, and get a unique key that summarizes my needed properties. I name the object the result of the md5. so across script runs the object (if it has the same properties) has the same name). for the time being this seems sufficient as i'm only serializing at specific checkpoints, and at the time of these checkpoints none of the data in the object refrences other objects.
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?
-
Aamer Akhter -
Ben Thomasson -
Gustaf Neumann