IRC channel logs
2023-07-12.log
back to list of logs
<RavenJoad>Quick question: Does goblins use any external code for the transactional heaps? I am sketching out an idea for a simulator that I think would benefit from being able to time travel. <juliana[m]>It relies on standard Guile hashmap facilities. It does some neat stuff to introduce generations and make sure things can be garbage collected properly, although I don't fully understand the mechanics at play tbh - I haven't really looked into how Guile GC works. <RavenJoad>Interesting... I would be very interested in seeing that. The time travel is really what I am looking for. <flatwhatson>my understanding is the state of every object on each turn is kept in a hash table, so you just have a list of these hash tables going back in time <flatwhatson>similar to the concept of "double buffering" except you keep as many historical buffers as you want. changes are always written into a new buffer. <RavenJoad>Then are hash tables atomic (which I don't see in the Guile reference manual), or their replacement? <flatwhatson>no, but the engine processes one turn as a transaction <RavenJoad>So a turn is: duplicate hash table, perform actor actions, store hash table as transaction? <flatwhatson>yeah, so each vat runs single-threaded, and processes one message at a time (which might synchronously send a few more messages as part of the same transaction) <flatwhatson>i'm not an authority on this though, and haven't dug through the code in a bit, so take it with a grain of salt :) <vvvvmvr[m]><flatwhatson> "yeah, so each vat runs single-..." <- Worth noting that I believe, since it uses fibers, it's not guaranteed that various things like callbacks are coming on a consistent OS thread. So, don't assume that the vat is going to all be run on a single thread and you can share state in that way. (AFAIK) <flatwhatson>right, conceptually single threaded, not necessarily pinned to an OS thread :) <vvvvmvr[m]>I have just been dusting up on fibers since cwebber suggested it ^_^ <cwebber>the "whactormap" (weak hash actormap), which is the "long-lived" version of the actormap <cwebber>this allows for garbage collection of unused actors <cwebber>and then the "transactormap", which transactionally is where actors are written to in each turn/churn. It links back to its parent, as you say, which is usually a whactormap but is sometimes another transactormap <cwebber>to "commit" a transactormap is very simple: we copy all the state changes from the transactormap to the whactormap <cwebber>since Goblins is quasi-functional and uses "bcom" to become different lambdas, effectively, as its state and behavior <cwebber>we're really just storing all the behavior procedures <RavenJoad>Ok. I think I am starting to get it now. Could these actormaps be serialized to disk somehow? That way the heaps and their transactions are persistent? <dthompson>we are working towards an object serialization layer. <RavenJoad>Ah, cool. The simulator I am thinking of is in common lisp, to make it easy to save the state of the entire sim at a point in time. But adapting the actormap method might be a good way to start with a transactional system. <cwebber>RavenJoad: yeah, the "lisp world" approach is, of course, cool <cwebber>if we had that, we'd support it additionally (and several other schemes do have it), but there's still good reasons to not rely exclusively on orthogonal persistence <cwebber>serializing and restoring is an opportunity for upgrade, since the restoration procedure can do migration. <RavenJoad>Agreed. I am tired of dealing with Tcl and non-interactive waveforms. <RavenJoad>Upgrade is not really a concern for me, as this will be a hardware simulator, so the lisp image is an artifact of an assertion violation.