twc/rudus
5
0
Fork 0
Code Issues 35 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

add a justfile, some project management

Browse Source
This commit is contained in:
Scott Richmond 2025-06-29 17:47:08 -04:00
parent 4dd47dd56c
commit de6cb5380d
2 changed files with 35 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
justfile Normal file
View File

@ -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

29
may_2025_thoughts.md
View File

@ -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. - 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. * [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) * 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: * Top priorities:
- [-] Get a node package out - [-] Get a node package out
- [x] Stand up actors + threads, etc. - [x] Stand up actors + threads, etc.
- [ ] How to model keyboard input from p5? - [ ] How to model keyboard input from p5?
* [ ] Model after the p5 keyboard input API * [ ] 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 \{, \}. * [a] Escape characters in strings: \n, \t, and \{, \}.
* [ ] `doc!` needs to print the patterns of a function. * [ ] `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. * [ ] 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 * [ ] Automate this build process
* [ ] Start testing against the cases in `ludus-test` * [ ] Start testing against the cases in `ludus-test`
* [ ] Systematically debug prelude * [ ] 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!) * [ ] Animation hooked into the web frontend (Spacewar!)
* [ ] Text input (Spacewar!) * [ ] Text input (Spacewar!)
- [ ] Makey makey for alternate input? * [ ] Makey makey for alternate input?
* [ ] Saving and loading data into Ludus (perceptrons, dissociated press) * [ ] Saving and loading data into Ludus (perceptrons, dissociated press)
* [ ] Finding corpuses for Dissociated Press * [ ] Finding corpuses for Dissociated Press
* [ ] improve validator * [ ] improve validator
@ -1145,3 +1148,21 @@ That leaves the following list:
* [ ] that suggests that we need a mapping from bytecodes to AST nodes * [ ] 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. * 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