Update README

This commit is contained in:
2026-03-18 14:36:47 +00:00
parent 0a52388030
commit 191ad9a35e

View File

@@ -1,31 +1,24 @@
# Wipforth # Wipforth
Wipforth is a simple Forth implementation that runs in the WebAssembly Wipforth is a Forth implementation that runs in the WebAssembly
virtual machine. It does I/O via memory-mapped peripherals, which are virtual machine. The system is bootstrapped from source on page load:
emulated in JavaScript. the only non-text file is the favicon :)
- For the Forth kernel, see [wipforth.wat](./wipforth.wat) I/O is done via memory-mapped peripherals, which are emulated in
- For the JavaScript emulator, see [emu.js](./emu.js) JavaScript.
- For the Forth prelude, which is loaded at start-up, see
[prelude.f](./prelude.f) - For the Forth kernel, see [wipforth.ws](./wipforth.ws)
- For the emulator, see [emu.js](./emu.js)
- For the assembler, see [asm.js](./asm.js)
- For the prelude (Forth code loaded right after the kernel boots),
see [prelude.f](./prelude.f)
- For a description of the peripherals, see the - For a description of the peripherals, see the
[Peripherals](#peripherals) section below. [Peripherals](#peripherals) section below.
## Building and Running Locally ## Building and Running Locally
You'll need: There's a [Guile](https://www.gnu.org/software/guile/) script in the
repo you can use for this:
- [WABT](https://github.com/WebAssembly/wabt) (not for long mwahaha)
- [Guile](https://www.gnu.org/software/guile/) (or bring your own HTTP
server -- see note below)
To run, first compile the WebAssembly module:
```
wat2wasm --enable-threads wipforth.wat
```
Then run the development server:
``` ```
guile server.scm guile server.scm
@@ -34,14 +27,19 @@ guile server.scm
You should then be able to open <http://localhost:8080> in a browser You should then be able to open <http://localhost:8080> in a browser
and use the system from there. and use the system from there.
**NOTE**: The server is very simple and just serves the files with the However, since everything is bootstrapped on the client, you only
cross-origin isolation headers required for `SharedMemoryBuffer` use. *need* an appropriate HTTP server, so if you don't have Guile on your
You could use any HTTP server that sets these headers. system you can use something else like Python's `http.server`. The
only requirement is that it sets the cross-origin isolation headers
required for `SharedMemoryBuffer` use:
You should **definitely not** use the development server to serve the - `Cross-Origin-Opener-Policy: same-origin`
application on the open internet; I just hacked it together for - `Cross-Origin-Embedder-Policy: require-corp`
testing on localhost during development and it's probably hilariously
insecure. You should **definitely not** use `server.scm` to serve the
application on the open internet or anything like that; I just hacked
it together for testing on localhost during development and it's
probably hilariously insecure.
## End-to-End Tests ## End-to-End Tests
@@ -62,16 +60,13 @@ Given that's all sorted, you should be able to run:
guile tests.scm guile tests.scm
``` ```
It will print a JUnit XML report to standard out, you can pretty-print It will print a JUnit XML report to standard out. You can
it with: pretty-print it with `xmllint` if you have it installed:
``` ```
guile tests.scm | xmllint --format - guile tests.scm | xmllint --format -
``` ```
Though, of course, this will require that you have `xmllint` on your
system.
## Peripherals ## Peripherals
### Terminal ### Terminal