From de6cb5380d42ac55f949d3ff82a791960380e511 Mon Sep 17 00:00:00 2001 From: Scott Richmond Date: Sun, 29 Jun 2025 17:47:08 -0400 Subject: [PATCH] add a justfile, some project management --- justfile | 10 ++++++++++ may_2025_thoughts.md | 29 +++++++++++++++++++++++++---- 2 files changed, 35 insertions(+), 4 deletions(-) create mode 100644 justfile diff --git a/justfile b/justfile new file mode 100644 index 0000000..7a56278 --- /dev/null +++ b/justfile @@ -0,0 +1,10 @@ +wasm: + wasm-pack build --target web + rm pkg/.gitignore + cp pkg/rudus.js pkg/rudus.js.backup + echo 'import {io} from "../worker.js"' > rudus.js + cat rudus.js.backup | tail -n+2>> rudus.js + rm rudus.js.backup + +default: + @just --list diff --git a/may_2025_thoughts.md b/may_2025_thoughts.md index 323f00a..34abce4 100644 --- a/may_2025_thoughts.md +++ b/may_2025_thoughts.md @@ -1113,23 +1113,26 @@ That leaves the following list: - Original version of `update` also had this same problem with `assoc`; fixed it by calling the Ludus, rather than Rust, function. * [a] `loop`/`recur` is still giving me a very headache. It breaks stack discipline to avoid packing tuples into a heap-allocated vec. There may be a way to fix this in the current compiler scheme around how I do and don't handle arguments--make recur stupider and don't bother loading anything. A different solution would be to desugar loop into an anonymous function call. A final solution would be just to use a heap-allocated tuple. * My javascript wrapper needs to execute WASM in its own thread (ugh) - - [ ] is this a thing that can be done easily in a platform-independent way (node vs. bun vs. browser)? + - [x] is this a thing that can be done easily in a platform-independent way (node vs. bun vs. browser)? + - No, no it is not. I will need to build a separate node version for using at the command line (and, like, for testing with our test harness.) * Top priorities: - [-] Get a node package out - [x] Stand up actors + threads, etc. - [ ] How to model keyboard input from p5? * [ ] Model after the p5 keyboard input API - * [ ] ludus keyboard API: `key_is_down(), key_pressed(), key_released()`, key code values (use a dict) + * [ ] ludus keyboard API: `key_down?(), key_pressed?(), key_released?()`, key code values (use a dict) * [a] Escape characters in strings: \n, \t, and \{, \}. * [ ] `doc!` needs to print the patterns of a function. * [ ] 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 * [ ] Start testing against the cases in `ludus-test` * [ ] Systematically debug prelude - - [ ] Bring it in function by function, testing each in turn +* [ ] 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 @@ -1145,3 +1148,21 @@ That leaves the following list: * [ ] that suggests that we need a mapping from bytecodes to AST nodes * The way I had been planning on doing this is having a vec that moves in lockstep with bytecode that's just references to ast nodes, which are `'static`, so that shouldn't be too bad. But this is per-chunk, which means we need a reference to that vec in the VM. My sense is that what we want is actually a separate data structure that holds the AST nodes--we'll only need them in the sad path, which can be slow. +### 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` +* [ ] 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) + * We also then don't have to have prelude run in the vm; that's good + - [ ] start with ludus->rust->js pipeline + * [ ] console + * [ ] turtle graphics + * [ ] completion + - [ ] then js->rust->ludus + * [ ] kill + * [ ] text input + * [ ] keypresses + - [ ] then ludus->rust->js->rust->ludus + * [ ] slurp