On Tue, May 10, 2005 at 11:11:12AM -0500, [EMAIL PROTECTED] wrote:
Please excuse the possible 'out of left field' (as we say) aspect of this question but I recently heard about Omniscient Debugging (ODB):
http://www.lambdacs.com/debugger/debugger.html
Sounds very powerful
This seems to require almost the same journaling capacity for STM (software transactional memory), although in STM's case we only mark updates for "shared" variables, whilst in ODB a journal is kept for all updates.
Yep
It is conceivable to build this facility into the PMCs, much like how tied objects work, but my knowledge of parrot internals is insufficient to answer whether it will be difficult or not.
I've already described in my summary http://xrl.us/f234 2.2) that we should split the vtable into various parts[1]. We should be able to switch to a read-only variant of a PMC for example.
Switching in some vtable pieces that logs set_*_* vtable calls is more or less the same thing.
vtable.tbl already has most of this information: see "[STORE]". There is an experimental feature 'pmclass SArray const_too' in the SArray PMC, where two vtables are created, switchable by setting the "_ro" property.
But this is all really rough and not a general solution.
See also "Layering PMCs" http://xrl.us/f236 for an older discussion about vtables and "roles" and "VTABLE methods and interfaces" http://xrl.us/f237.
[1] The vtable is currently almost 600 bytes (32bit system). By switching full vtables just to get a read-only variant, we'd need a lot of memory. And: a scalar PMC doesn't need nor implement the array-ish vtable slots. I prefer one more indirection for almost all of the vtable slots.
leo
