GNU APL compiled with emscripten and given a web interface
|selfsame 4f7232bdea clean up attempts to compile other apl versions||2 years ago|
|.vscode||3 years ago|
|apl-1.3||2 years ago|
|fonts||3 years ago|
|img||3 years ago|
|.apl.history||3 years ago|
|.gitignore||2 years ago|
|README.md||2 years ago|
|apl-keyboard.js||3 years ago|
|apl.html||3 years ago|
|apl.js||2 years ago|
|apl.wasm||2 years ago|
|compile||2 years ago|
|module.js||3 years ago|
|style.css||3 years ago|
|up.sh||2 years ago|
|vs.code-workspace||3 years ago|
There's a version of this up at https://gnuapl.s3.amazonaws.com/index.html
emsdk 1.39.5, other emscripten versions didn't work
source ~/build/emsdk/emsdk_env.shif using emsdk (in apl directory)
emconfigure ./configure SECURITY_LEVEL_WANTED=2
emmake make(from outer directory)
mv apl-1.3/src/apl apl-1.3/src/apl.so
emcc -03 -s ASYNCIFY=1 -s ASYNCIFY_STACK_SIZE=300000 -s ERROR_ON_UNDEFINED_SYMBOLS=0 -s DISABLE_EXCEPTION_CATCHING=0 -s ALLOW_MEMORY_GROWTH=1 apl-1.3/src/apl.so -o apl.js(finishing up) need to allow
apl.jsto recover from errors, find the
throw e;line and replace with a
run_iteryou can just ignore it to continue but probably an emcc flag i'm not setting right
wanted to jump back in to this to try and fix the inner quad function editor loop. Was planning on trying the ASYNCIFY (https://emscripten.org/docs/porting/asyncify.html#yielding-to-main-loop) where you just stick a sleep statement in your loops (this might be an easier way for the main loop too)
UNFORTUNATELY something in my linux install had broken emscripten's ability to find a working compiler. Did a full system upgrade and it gets as far as the
emmake make command but fails with
1 error generated. shared:ERROR: '/usr/lib/emscripten-llvm/clang++ -target wasm32-unknown-emscripten -D__EMSCRIPTEN_major__=1 -D__EMSCRIPTEN_minor__=39 -D__EMSCRIPTEN_tiny__=11 -D_LIBCPP_ABI_VERSION=2 -Dunix -D__unix -D__unix__ -Werror=implicit-function-declaration -Xclang -nostdsysteminc -Xclang -isystem/usr/lib/emscripten/system/include/libcxx -Xclang -isystem/usr/lib/emscripten/system/lib/libcxxabi/include -Xclang -isystem/usr/lib/emscripten/system/lib/libunwind/include -Xclang -isystem/usr/lib/emscripten/system/include/compat -Xclang -isystem/usr/lib/emscripten/system/include -Xclang -isystem/usr/lib/emscripten/system/include/libc -Xclang -isystem/usr/lib/emscripten/system/lib/libc/musl/arch/emscripten -Xclang -isystem/usr/lib/emscripten/system/local/include -Xclang -isystem/home/selfsame/.emscripten_cache/wasm/include -DHAVE_CONFIG_H -I. -I../.. -g -O2 -MT TcpListener.lo -MD -MP -MF .deps/TcpListener.Tpo -c -fPIC -DPIC -DEMSCRIPTEN -fignore-exceptions TcpListener.cc -Xclang -isystem/usr/lib/emscripten/system/include/SDL -c -o .libs/TcpListener.o -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr' failed (1) make: *** [Makefile:423: TcpListener.lo] Error 1
I'm going to try getting the emsdk and trying a few other releases of emscripten?
need to do
source ~/build/emsdk/emsdk_env.sh to get access to the activated install
..same error, maybe this is something to do with needing 32 bit emscripten?
trying emsdk install latest-fastcomp but think i need to figure out the 32 bit thing (yeah, no)
./emsdk install sdk-upstream-master-32bit
oh god it's building from source..... didn't work
(wondering if the emscripten.h stuff I'd copied into the apl src to include needs to be updated from whatever version i'm using?)
eh, still getting that error, giving up for now, might try with a cloud ec2 instance or something later?
./emsdk install emscripten-1.38.9.. nope
needed to run
make clean when i was trying this in the windows linux subsystem, BUT that only allowed
emmake make to complete, the final js/wasm packaging was failing, complaining that
apl.so wasn't a wasm object?
Going to see if I can at least build the latest APL (1.8) with emscripten, think i was able to do that yesterday on the subsytem ubuntu. I know it comes with some extra infrastructure like maybe an erlang daemon server, but hopefully there is still a single binary
(using emsdk 1.39.14)
em++: error: '/home/selfsame/build/emsdk/upstream/bin/clang++ -target wasm32-unknown-emscripten -D__EMSCRIPTEN_major__=1 -D__EMSCRIPTEN_minor__=39 -D__EMSCRIPTEN_tiny__=14 -D_LIBCPP_ABI_VERSION=2 -Dunix -D__unix -D__unix__ -Werror=implicit-function-declaration -Xclang -nostdsysteminc -Xclang -isystem/home/selfsame/build/emsdk/upstream/emscripten/system/include/libcxx -Xclang -isystem/home/selfsame/build/emsdk/upstream/emscripten/system/lib/libcxxabi/include -Xclang -isystem/home/selfsame/build/emsdk/upstream/emscripten/system/lib/libunwind/include -Xclang -isystem/home/selfsame/build/emsdk/upstream/emscripten/system/include/compat -Xclang -isystem/home/selfsame/build/emsdk/upstream/emscripten/system/include -Xclang -isystem/home/selfsame/build/emsdk/upstream/emscripten/system/include/libc -Xclang -isystem/home/selfsame/build/emsdk/upstream/emscripten/system/lib/libc/musl/arch/emscripten -Xclang -isystem/home/selfsame/build/emsdk/upstream/emscripten/system/local/include -Xclang -isystem/home/selfsame/.emscripten_cache/wasm/include -DEMSCRIPTEN -fignore-exceptions -DHAVE_CONFIG_H -I. -I../.. -Wno-deprecated-declarations -g -O2 -MT TcpListener.lo -MD -MP -MF .deps/TcpListener.Tpo -c -fPIC -DPIC TcpListener.cc -Xclang -isystem/home/selfsame/build/emsdk/upstream/emscripten/system/include/SDL -c -o .libs/TcpListener.o -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr' failed (1
5 months ago when this worked, the latest version was 1.39.5, trying that real quick
Uh.... WTF that version completed
emcc command gives
wasm-ld: error: apl-1.3/src/apl.so: machine type must be wasm32
so maybe this is where i realize this needs be be built with 32bit emscripten
https://emscripten.org/docs/getting_started/FAQ.html#why-do-i-get-machine-type-must-be-wasm32-or-is-not-a-valid-input-file-during-linking explains that non wasm32 artifacts are in the project and it's trying to do an incremental build?
[selfsame@box:apl-1.3|master *$%]$ file src/apl.so src/apl.so: LLVM IR bitcode
[selfsame@box:src|master *$%]$ ls -l apl.so -rw-r--r-- 1 selfsame selfsame 11443440 Nov 23 00:08 apl.so
hmm lets try removing the .so file?? make should replace it I hope lol no it didn't replace it, put it back
still possible this is artifacts getting in my way
per https://groups.google.com/forum/#!topic/emscripten-discuss/a2pYLsOba5o trying:
emcc -03 -s ASYNCIFY -s ERROR_ON_UNDEFINED_SYMBOLS=0 -s DISABLE_EXCEPTION_CATCHING=2 -s ALLOW_MEMORY_GROWTH=1 -s WASM_OBJECT_FILES=0 apl-1.3/src/apl.so -o apl.js
OK throwing in the towel for the weekend, this was a miserable experience
I think my next attempt would be to download fresh apl-1.3 source and try to build with 1.39.5, which CAN build, and hope that that's where the apl.so file comes from
Oh fuck me
apl is the binary.. did I rename it to
apl.so back in November??
file apl-1.3/src/apl apl-1.3/src/apl: WebAssembly (wasm) binary module version 0x1 (MVP)
[selfsame@box:webapl|master *$%]$ emcc -03 -s ASYNCIFY -s ERROR_ON_UNDEFINED_SYMBOLS=0 -s DISABLE_EXCEPTION_CATCHING=2 -s ALLOW_MEMORY_GROWTH=1 apl-1.3/src/apl -o apl.js shared:ERROR: apl-1.3/src/apl: Input file has an unknown suffix, don't know what to do with it!
mv apl-1.3/src/apl apl-1.3/src/apl.so to readme
emcc now builds!!
OK, going to save this readme and stash back to old apl-1.3 src that had the main loop emscriptenified
ah wait quad functions are the stuff like
⎕SS, I've been barking up the completely wrong tree for this loop?
⎕ARG works, wonder where that loop comes into play
UserFunction.cc.. looks like just code to eval user defined functions?
Here we go:
case UNI_NABLA: // e.g. ∇FUN Nabla::edit_function(line); return;
Nabla.cc may be the
while (!do_close) loop that is waiting for new lines?
OK that's definitely the place, but now I'm getting a "RuntimeError: unreachable" which looks like something with ASYNCIFY
https://github.com/emscripten-core/emscripten/issues/9520 says i need to whitelist ASYNCIFY stack functions and maybe even increase the stack size..
ASYNCIFY_STACK_SIZE=100000 works, I also replaced the main loop with another
emmake make failing with
error: unknown type name '__gnuc_va_list'
https://www.tutorialfor.com/questions-130691.htm says it's because of usr/include headers
emmake make -I . .. nope
trying emsdk 1.39.14 .. nope
in windows subsystem ubuntu, emmake make had error of
<sys/fcntl.h> (after quite a few warnings about it.) changed src/Common.hh to use
<fcntl> and it's compiling
fixed error with a
(double) cast in
for the record - working compilation of apl-1.8 in ubuntu subsystem with emsdk 1.39.5 after fixing a few errors via src code
Seems like it's not accepting any input, but working in JS at least
oh forgot to add the emscripten asyncify edits, added
error: variadic templates are a C++11 extension maybe a clean/configure/make will sort that..
thinking i just have the wrong emscripten include files
ok ok just use
#include <emscripten.h> and it is getting these things from the env, i must of just shoved my includes in there, maybe this is why i was having troubles compiling with other emscripten versions yesterday??
looks like js runtime is trying to connect to a database, it's pretty much hanging maybe there are more loops to asyncify? I'm calling it for the weekend good job everybody.
apl-1.8 wasm has some sort of process that eats a shitload of memory and CPU. Tried disabling the main() call but no effect, tried compiling with
SECURITY_LEVEL_WANTED=2 no effect.
Might try some other apl versions in the future but just going to commit the working 1.3 wasm/js for now and go back to frontend work when I pick this back up.
tried compiling apl-1.6 (trying to binary test to find a working version) but it had the same massive memory/cpu usage
compiled apl-1.3 and was going to switch to front end work, but the fatal exception fix (where I just console.warn the error) wasn't working anymore. Could be the version of emsdk, or maybe the switch to the asyncify sleep. (it was 1.39.14)
^ not the emsdk version, need to revert to using set emscripten main loop.. no not working
Might be some broken compilation include?
I'm back and trying to remodify a fresh copy of the apl-1.3 source code, attempting to remedy error handling getting an unreachable code error in the wasm
01e93d66:1 Uncaught RuntimeError: unreachable at <anonymous>:wasm-function:0x1542c4 at <anonymous>:wasm-function:0x49b49d at <anonymous>:wasm-function:0x2434c3 at <anonymous>:wasm-function:0x44dadc at <anonymous>:wasm-function:0x162c71 at <anonymous>:wasm-function:0xdb3ae at <anonymous>:wasm-function:0xd4a83
I tried increasing the
ASYNCIFY_STACK_SIZE to something huge, and setting
DISABLE_EXCEPTION_CATCHING=0, not sure where to go from here other than trying different versions of emsdk
Trying a few different versions of emsdk
trying to go back to non ASYNCIFY loop again
Workspace.cc loop to the
emscripten_set_main_loop version from 3 months ago, (also reverted
Nabla.cc loop is still asyncify, it still gets that unreachable runtime error when you trigger an apl error during the function editor.