Update README
This commit is contained in:
58
README.md
58
README.md
@@ -1,31 +1,24 @@
|
||||
# Wipforth
|
||||
|
||||
Wipforth is a simple Forth implementation that runs in the WebAssembly
|
||||
virtual machine. It does I/O via memory-mapped peripherals, which are
|
||||
emulated in JavaScript.
|
||||
Wipforth is a Forth implementation that runs in the WebAssembly
|
||||
virtual machine. The system is bootstrapped from source on page load:
|
||||
the only binary file is the favicon :)
|
||||
|
||||
- For the Forth kernel, see [wipforth.wat](./wipforth.wat)
|
||||
- For the JavaScript emulator, see [emu.js](./emu.js)
|
||||
- For the Forth prelude, which is loaded at start-up, see
|
||||
[prelude.f](./prelude.f)
|
||||
I/O is done via memory-mapped peripherals, which are emulated in
|
||||
JavaScript.
|
||||
|
||||
- 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
|
||||
[Peripherals](#peripherals) section below.
|
||||
|
||||
## Building and Running Locally
|
||||
|
||||
You'll need:
|
||||
|
||||
- [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:
|
||||
There is simple [Guile](https://www.gnu.org/software/guile/) script
|
||||
you can use for this:
|
||||
|
||||
```
|
||||
guile server.scm
|
||||
@@ -34,14 +27,18 @@ guile server.scm
|
||||
You should then be able to open <http://localhost:8080> in a browser
|
||||
and use the system from there.
|
||||
|
||||
**NOTE**: The server is very simple and just serves the files with the
|
||||
cross-origin isolation headers required for `SharedMemoryBuffer` use.
|
||||
You could use any HTTP server that sets these headers.
|
||||
Since everything is bootstrapped on the client, you only need an HTTP
|
||||
server, so if you don't have Guile on your system you can bring your
|
||||
own. 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
|
||||
application on the open internet; I just hacked it together for
|
||||
testing on localhost during development and it's probably hilariously
|
||||
insecure.
|
||||
- `Cross-Origin-Opener-Policy: same-origin`
|
||||
- `Cross-Origin-Embedder-Policy: require-corp`
|
||||
|
||||
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
|
||||
|
||||
@@ -62,16 +59,13 @@ Given that's all sorted, you should be able to run:
|
||||
guile tests.scm
|
||||
```
|
||||
|
||||
It will print a JUnit XML report to standard out, you can pretty-print
|
||||
it with:
|
||||
It will print a JUnit XML report to standard out. You can
|
||||
pretty-print it with `xmllint` if you have it installed:
|
||||
|
||||
```
|
||||
guile tests.scm | xmllint --format -
|
||||
```
|
||||
|
||||
Though, of course, this will require that you have `xmllint` on your
|
||||
system.
|
||||
|
||||
## Peripherals
|
||||
|
||||
### Terminal
|
||||
|
||||
Reference in New Issue
Block a user