webapl

There's a version of this up at https://gnuapl.s3.amazonaws.com/index.html

build commands

using emsdk 1.39.5, other emscripten versions didn't work

• source ~/build/emsdk/emsdk_env.sh if 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.js to recover from errors, find the throw e; line and replace with a console.warn(e)

TODO

• handle loop that happens in function editing mode
  • believe this is in QuadFunction.cc
• catch errors, in run_iter you can just ignore it to continue but probably an emcc flag i'm not setting right
• input with history (up/down arrow to navigate)
• APL on screen keyboard
• get console.warn errors to print to terminal nicely
• attempt to emscripten apl-1.8 (i've seen this build so this might pan out)
• make js bindings that APL can access, have a target that can run <script type="apl">

journal

5/2/2020

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[3]: *** [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)

trying ./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?

trying ./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?

5/3/2020

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)

No:

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 emmake make???

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

NOPE

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!

ahh.. right

adding 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

inner loop fixing

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

looking at UserFunction.cc.. looks like just code to eval user defined functions?

Here we go: Command.cc in Command::process_line

         case UNI_NABLA:               // e.g. ∇FUN
              Nabla::edit_function(line);
              return;

yeah 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 emscripten_sleep(100)

building apl-1.8

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

trying with 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 NumericCell.cc

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.. (didn't work)

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.

5/6/2020

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.

5/9/2020

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?

6/14/2020

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

same error:

01e93d66:1 Uncaught RuntimeError: unreachable
    at <anonymous>:wasm-function[498]:0x1542c4
    at <anonymous>:wasm-function[1699]:0x49b49d
    at <anonymous>:wasm-function[865]:0x2434c3
    at <anonymous>:wasm-function[1417]:0x44dadc
    at <anonymous>:wasm-function[510]:0x162c71
    at <anonymous>:wasm-function[384]:0xdb3ae
    at <anonymous>:wasm-function[383]: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

6/15/2020

Trying a few different versions of emsdk

• 1.39.5 - no
• 1.38.48 - doesn't do ASYNCIFY (said something about the fastcomp branch)
• 1.39.0 - no

trying to go back to non ASYNCIFY loop again

GOT IT?

changed Workspace.cc loop to the emscripten_set_main_loop version from 3 months ago, (also reverted Workspace.hh)

The Nabla.cc loop is still asyncify, it still gets that unreachable runtime error when you trigger an apl error during the function editor.