Compare commits

..

2 Commits

Author SHA1 Message Date
Scott Richmond
991705e734 add thoughts 2025-07-01 11:10:50 -04:00
Scott Richmond
989e217917 stash changes 2025-07-01 10:42:34 -04:00

View File

@ -1126,13 +1126,13 @@ That leaves the following list:
* [ ] I need to return to the question of whether/how strings are ordered; do we use `at`, or do we want `char_at`? etc.
- MNL and I decided: yes, stings are indexable
- [ ] implement `slice` and `at` and others for strings
* [ ] Automate this build process
* [x] Automate this build process
* [ ] Start testing against the cases in `ludus-test`
* [ ] Systematically debug prelude
* [ ] Bring it in function by function, testing each in turn
* [ ] Animation hooked into the web frontend (Spacewar!)
* [ ] Text input (Spacewar!)
* [ ] Makey makey for alternate input?
* [ ] ~Makey makey for alternate input?~
* [ ] Saving and loading data into Ludus (perceptrons, dissociated press)
* [ ] Finding corpuses for Dissociated Press
* [ ] improve validator
@ -1150,21 +1150,21 @@ That leaves the following list:
### Next steps in integration hell
#### 2025-06-29
* [ ] improve build process for rudus+wasm_pack
- [ ] delete generated .gitignore
- [ ] edit first line of rudus.js to import the local `ludus.js`
* [x] improve build process for rudus+wasm_pack
- [x] delete generated .gitignore
- [x] edit first line of rudus.js to import the local `ludus.js`
- On this, made a justfile, but I needed to like actually try the build and figure out what happens. I got carried away touching the js. Too many things at once.
* [ ] design & implement asynchronous i/o+runtime
- [ ] use `box`es for i/o: they can be reified in rust: making actors available is rather more complex (i.e. require message passing between the ludus and rust)
- [x] use `box`es for i/o: they can be reified in rust: making actors available is rather more complex (i.e. require message passing between the ludus and rust)
* We also then don't have to have prelude run in the vm; that's good
* We... maybe or maybe don't need processes in prelude, since we need to read and write from the boxes; we might be able to do that with closures and functions that call `spawn!` themselves
- [ ] start with ludus->rust->js pipeline
* [ ] console
- [x] start with ludus->rust->js pipeline
* [x] console
* [ ] turtle graphics
* [ ] completion
* [x] completion
- [ ] then js->rust->ludus
* [ ] kill
* [ ] text input
* [x] kill
* [?] text input
* [ ] keypresses
- [ ] then ludus->rust->js->rust->ludus
* [ ] slurp
@ -1174,5 +1174,30 @@ That leaves the following list:
* No need to send a run event: we'll just start things with with a call to `run`, which we expose to JS.
* One thing I hadn't quite grokked before is that we need to have a way of running the i/o events. Perhaps the simplest way to do this is to just to do it every so often, regardless of how long the ludus event loop is taking. That way even if things are getting weird in the VM, i/o still happens regularly.
* The return to a `slurp` call is interesting.
* I think the thing to do is to write to a slurp buffer/box as well.
* I think the thing to do is to write to a slurp buffer/box as well.
### Finishing integration?
#### 2025-07-01
Happy Canada day!
After a really rough evening, I seem to have the actor model not only working in Ludus, but reasonably debugged in Rust.
We've got one bug to address in Firefox before I continue:
* [ ] the event loop isn't returning once something is done, which makes no sense
After that:
* [ ] implement other verbs beside `console`:
- [ ] `command`
- [ ] `input`
* [ ] js->rust->ludus buffer (in Rust code)
* [ ] ludus abstractions around this buffer (in Ludus code)
- [ ] `fetch`--request & response
* [ ] request: ludus->rust->js->net
* [ ] response: js->rust->ludus
- [ ] `keyboard`
* [ ] still working on how to represent this
* [ ] hook this up to `web.ludus.dev`
* [ ] do some integration testing
- [ ] do synchronous programs still work?
- [ ] animations?
- [ ] read inputs?