Skip to content
This repository was archived by the owner on Sep 5, 2025. It is now read-only.

Conversation

@dzervas
Copy link
Contributor

@dzervas dzervas commented Jun 26, 2024

first of all due to some technicalities we can no longer get_workbench - we shouldn't anyway (LoroDoc doesn't implement Clone so I can't just return a clone of the workbench itself)
it forced a long awaited fix: JS no longer duplicates the whole WASM memory
it should just hold the oplog (history) and evtree (LoroDoc) as well as a project and workbench index. that's it

so JS instead of calling Project::get_workbench now calls get_workbench_oplog and get_workbench_evtree where both require a project_index and workbench_index. both regular incremented numbers, nothing fancy
I also introduced set_workbench_evtree since we want a way for JS to update the evtree

so what changed?

  • as explained above JS no longer acts on top of the lib.rs Project struct - it can be removed completely - but calls static global functions
  • for that to be able to happen, JS has to keep track of the current project and workbench index (regular 0-based indexes)
  • each workbench now holds an instance of the EvTree struct. A thin wrapper around LoroDoc
  • the LoroDoc holds a list of step hashes. that's it. (this choice was made for us since Loro can't hold arbitrary types)
  • step hashes are now unique (they take into account the author (hardcoded for now) and timestamp in addition to the message) so that we don't fall into collisions
  • the hashes that LoroDoc holds is always a sub-group of the actual history. the lorodoc can fork or whatever but the history is always linear
  • in order to compensate for the evtree vs actual workbench state getting out of sync (e.g. checking out before a sketch line gets created won't remove the line from the isotope sketch) a new method is introduced in the project::Project struct: rebuild_workbench. It accepts a workbench index and it:
    • nukes the workbench of all the internally held geometry BUT keeps the history and evtree intact
    • iterates through all the pointed evtree hashes (remember that loro abstracts away the complexity of the actual tree and gives us back the actual used history - from the currently checked out node to the root)
    • iterate through the workbench history to find the actual steps that the evtree hashes refer to
    • iterate through the found steps and call their handler (omitting the logic that appends them to the history and evtree)
  • added methods to get the evtree and oplog
  • added method to set the evtree

but there are quite a bit to get done in the UI:

  • call the new global functions instead of wasmProject.*
  • no longer hold a $workbench state but hold $oplog, $evtree, $project_index, $workbench_index and maybe $project (for the name?) instead
  • some book-keeping is probably required for oplog and evtree (on send_message update them both)
  • introduce any required loro-releated functionality for the evtree

@ovo-Tim
Copy link

ovo-Tim commented May 10, 2025

It doesn't seem to work here.

image
image

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants