Norns: web-based REPL

[tehn]

educating myself about websockets.

• c library: https://libwebsockets.org
• c library tutorial: https://medium.com/@martin.sikora/libwebsockets-simple-http-server-2b34c13ab540
• client side (javascript) tutorial: http://blog.teamtreehouse.com/an-introduction-to-websockets

[catfact]

consider nanomsg for websockets on norns side
http://nanomsg.org/v1.1.2/nn_ws.html
http://www.codedependant.net/2016/09/22/summer-of-sockets-part-5-node-nanomsg-and-websockets/

[tehn]

this is excellent.

if possible i'm going to try to avoid node, as it requires something like 500mb which would be nicer left for user audio storage.

that is, using nanomsg from c would be great

[catfact]

ah well, i'm not proposing to use nanomsg to build a webserver - though heck, i guess that probably wouldn't even be too hard.

i just mean the existing ipc_wrapper can be easily modified to ws_wrapper, using nanomsg to wrap stdin/stdout for crone/matron.

so as a first step, should be able to just run the janky ncurses version of maiden on remote machine, proof of concept. this should be really very easy.

in fact, looking at the c API, i don't even think it requires code changes - just give a URL argument with ws:// instead of ipc:// as argument to nn_connect / nn_bind. (nanomsg is pretty serious about being transport-agnostic!)

next step would be using some super lightweight webserver to serve the editor page, including the websocket urls (and whatever else of course). i wouldn't use node, agree it's mega overkill. mongoose is the classic solution and apparently monkey is a popular new kid.

(sorry for posting the red-herring link showing the node nanomsg API. we would only be using its C API.)

websockets are part of the standard web API, shouldn't need any special libraries to talk to them from the client
api docs
tutorial

[tehn]

@catfact you're correct that you can simply swap out ipc://... for ws://...

bunch of nice nanomsg examples: https://github.com/dysinger/nanomsg-examples

running the pub/sub example works as expected with server at ws://*:5555 and client listening to ws://localhost:5555

but running a web-client (ie http://blog.teamtreehouse.com/an-introduction-to-websockets ) just hangs on the handshake, so i'm wondering if the "upgrade" handshake is not built-in to the nanomsg lib.

edit: yep pretty sure i have to write in a little upgrade responder

edit again: having it be a pub isn't necessarily correct either, looking at the req/reply... anyway, pre-emptive github posting, sorry for the noise, lots more to do/investigate here

[catfact]

ah that makes sense. sorry :(

[tehn]

got it mostly working with pairing! (need to dissect server->client object blobs somehow)

push here: https://github.com/tehn/norns/tree/dev/ws-test

[tehn]

mostly working but there's an elusive bug that is disconcerting.

sending from the c -> js works consistently
receiving js -> c is sometimes broken, and i'm pretty sure it's the nanomsg part, not the js sending, as seem by some tcpdump investigation.

ie, sending js->c
"1234567890"
will be received fine, and c->js looks good, echo'd
but then send js->c
"abc"
and what is received is "abc4567890" so it's like there is some allocation issue.

tested with manual vs. automatic allocation, no difference. manual allocation has a very hard time understanding where message boundries are-- like there's a bunch of junk coming in afterwards and not a line ending. but that gives me an idea of something to try next...

[tehn]

feels like a bug in nn_recv() or i just can't see my own dumb typo, so i opened an issue on the nanomsg repo

https://github.com/nanomsg/nanomsg/issues/943

[tehn]

found the bug, it was the js i didn't write.

so now i just have to figure out how to hack ipc-wrapper for ws instead of ipc

edit: yep it was my fault in the end, just kidding

[tehn]

it works!

run ws-matron.sh to wrap matron is ws

copy ws-test/js-client/ to your local machine, tune the IP address in app.js for a very dumb terminal.

the js interface doesn't add newlines on send, so lua will get confused if you don't add them manually (by typing enter, then clicking the send button). this is all js ui stuff though. eventually it'll be wrapped in reactjs, but i'll attempt to polish this simple version as a starting point

[ngwese]

cool. i'll take a look this evening (hopefully) - it'll give me additional motivation to get the activity switching stuff somewhat functional.

[tehn]

added RUN button and cleaned up the display.

message sending still messed up-- something with line endings.

https://github.com/tehn/norns/tree/dev/js-client

compile ws-wrapper first and run ws-matron.sh beforehand

[ngwese]

i've proved to myself that i can connect to the ws wrapped matron process but... something somewhere in matron (i think) is printing a blank line every few ms. @tehn do you have any ideas on what that might be?

EDIT: never mind - it was the value polling being done as part of the temp_amp_poll script.

[tehn]

my only data point is running ws-matron.sh and then launching
/js-client/index.html (after tuning app.js with the right ip address)

using chrome's dev tools i don't see any incoming websocket traffic unless
there's some explicit activity with matron (ie, folder nav).

or do you mean ws-matron.sh is printing a lot of CR's to the terminal?

On Sat, Feb 3, 2018 at 8:04 PM, Greg Wuller [e-mail]
wrote:

i've proved to myself that i can connect to the ws wrapped matron process
but... something somewhere in matron (i think) is printing a blank line
every few ms. @tehn https://github.com/tehn do you have any ideas on
what that might be?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/catfact/norns/issues/52#issuecomment-362870822, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAPEcJsF6MVbwA5N6acQ6GhLjN28BD8-ks5tRQIEgaJpZM4Q9nW_
.

[ngwese]

i done experimentation with trying to use xterm.js to handle the repl ui but both the sending an receiving are problematic. which debugging things i've spent a bunch of time trying to identify precisely where in matron that input is being handled - is it in c or lua?

if i'm understanding things correctly the main thread is running the event loop (defined in c), the event loop will call into lua code - generally invoking specific functions to handle events. devices (hid, grid, midi, etc) are handled in separate threads and post events to the event queue for the main thread.

_aside: i am having trouble following the control flow / breakdown of responsibilities across the c/lua boundary but i see that is now a separate issue._

what i'm trying to track down is where in matron input is getting buffered (conceivably) before it is passed to the lua interpreter to evaluate. whatever is handling input does seem to be waiting to see a <cr> in the input stream before acting. my xterm.js experiment is sending individual characters over the wire and for some reason a final <cr> isn't triggering evaluation. given the mild sensitivity to line endings in the js-client example i want to make sure there isn't anything funky going on with input handling/buffering when matron stdio is bound to a pipe vs a terminal.

in all likelyhood i suspect i'll abandon xterm.js and just come up with my own repl widget similar to the form seen in maiden - if only to keep the command input separate from the output so that it stays on screen as output flies by.

[ngwese]

i now see that hid_run() in matron/src/hid.c is what i was after (i had incorrectly assumed that file was related to using keyboards, joysticks, etc. as input devices within the scripts - not stdin itself).

[ngwese]

it turns out this was most of my problem https://github.com/catfact/norns/pull/90

[catfact]

i had incorrectly assumed that file was related to using keyboards, joysticks, etc. as input devices within the scripts - not stdin itself

that sounds like a correct assumption to me. this module used to be called "input", referring to standard input. it appears to have been renamed by mistake...

[EDIT] yep, @tehn: 8b2333d39e0ecc0abf26d323039784f264e549a2, f916cda6c05199a4dd1fc84bbf5a9814a0e3f7d2

[EDIT] reverted in PR #91

[tehn]

booo yes that was me. one of the first things i did to the repo, ugh. many apologies.

[tehn]

closing this because maiden has its own repo.