We should think about that and identify a good solution. Thanks for the information and discussion.
Stef > The inspector is currently used to view the object log in the development > vm...for large object logs it makes sense to filter the log before viewing. > > For external viewing I have a Seaside Component that allows one to filter and > sort the object log entries as well as delete entries from the ObjectLog ... > > Since GemStone runs with multiple vms, you can use a separate vm to look at > the shared object log ... .. > > The RCQueue (and OrderedCollections for that matter) in GemStone don't incur > performance hits as the collection grows over time (unlike growing > OrderedCollections in a normal client Smalltalk), but then GemStone was > designed with very large collections in mind:)... > > GemStone was designed to handle collections and object graphs that can be > larger than available memory, so you can forget about the object log until > start running out of repository space (basically disk space) ... > > For the Pharo, I would think that the fact that an Object log could > accumulate a whole lot of stuff is real limiting factor...there'd need to be > a process that continuously pruned objects from the object log over time .... > so a thread safe linked list might be a better choice for the Object log > collection ... > > Dale _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
