Home   Archive   Permalink

Emscripten? Why does it matter?

Could anyone specify the benefits of porting Rebol 3 to Emscripten? Recently there seems to be lots of discussions on the future of Rebol 3, and Nick believes that porting R3 to Emscripten would be a good idea. But the benefits are not that easy to see for those who are not familiar with the complier. So I am wondering if anyone could type a few lines about the benefits of supporting that project.

posted by:   Emscripten     3-Nov-2014/20:56:25-8:00

I'll paint a picture.
Imagine a SCRIPT tag with SRC="MYREBOL.JS" in your HTML page. MYREBOL.JS is a Rebol interpreter that has been compiled into unreadable JavaScript gibberish that is effectively the "machine language" target to which the compiled C files of Rebol has been built. (You're not supposed to read it, in any case.)
You are using MYREBOL.JS instead of just using the hosted REBOL.JS off of rebolsource.net (or wherever). The reason you're not using the default distribution is because you have told emscripten to bundle in a filesystem with the interpreter that has a bunch of .REB files in it. Let us say one such file called MY-THING.REB contains a function called DO-MY-THING.
In your page load handler you run $REBOL.DO("load %my-thing.reb"). Then when someone clicks a button in your JavaScript page you can write something like RESULT = $REBOL.DO("DO-MY-THING " + ARGS);, where args is some information you picked up from edit controls, or other information on the web page. RESULT comes back. Perhaps there is a way to capture the standard output as well, but we'll focus on just the evaluative result for now.
Perhaps the Emscripten'd JavaScript is dumb, and is just "string in, string out". Maybe it's a little clever that it doesn't turn everything into a string but gives back INTEGER! as a JavaScript integer, DATE! as a JavaScript date, etc. But ideally both the input and output would be in a JavaScript framing of REN, if someone had made that:
But let's say the version of Emscripten would just be string in, string out, with some optional files available. In fact...the odds are very good of that. Because at Adrian's urging, I got involved in helping to build that shortly after the Montreal conference.
And it "worked". An embedded Rebol engine exists today at your service. As that's now a year and a half ago, I don't remember the byte count of the JS file...but it was in the half-megabyte-or-so range; maybe less.
But remember that JavaScript is still in the driver's seat. There's no way from inside of this Rebol to go rearranging the DIVs on your HTML page because there's no DOM. Features that JavaScript is roped off from...like cross-domain scripting protection...will keep you from reading data from URLs. There'd need to be some kind of "bridge" to allow you to make JavaScript calls from inside that Rebol interpreter.
Could such a bridge be written? A trivial one, easily. In your embedded MY-THING.REB you could write:
             JAVASCRIPT [{alert("} x {");}]
             RETURN "YAY!"
         ] [
             RETURN "NAY!"
Then to invoke it you might try $REBOL.DO("do-my-thing {AAAHELLOBBB}"); and get it to alert you with "HELLO". JAVASCRIPT just needs to be a native that calls emscripten_run_script()...though enable it only in an #ifdef for Emscripten builds:
That's today-or-tomorrow-realism.
Now when you start talking about GUI dialects, you have varying levels of insanity and orders of magnitude more work. What if your DO-MY-THING could take an HTML5 canvas, and you actually used HTML5 drawing routines and mouse events to power a R3GUI-in-the-browser? Sound completely nuts? Well, people do lots of nutty things:
(For that matter, a NaCL build would run in Chrome and avoid the JavaScript...but only Google supports it. I digress.)
Anyway, you could take the R3GUI and have it painting its own scroll bars and list boxes inside the browser. The hard bit there is not the drawing itself, but mapping the event model. But people testify that retargeting is not so difficult and the design is actually good. So maybe it's more feasible than I'd think offhand.
Red is not pursuing the idea of "we grab a buffer and paint our foreign interface" but that any VID-like thing "speak native". In the browser that would mean your buttons are not custom bitmaps drawn on an HTML5 canvas but actual HTML buttons...you don't draw scroll bars yourself, etc. And that is yet another order of magnitude more work. But it's not just a matter of the work--but an imprecise mapping that is likely to be very frustrating for developers and users alike.
Hope that adds some clarity.
BUT if a baseline interpreter in the browser that can remote control JavaScript calls is actually of great value to anyone, then the person to talk to is Andreas. Because the real work here is support...making the builds, hosting, documentation...and hopefully getting Emscriptened Rebol on the map at http://repl.it (or at http://rebolsource.net/repl if we can't swing that). There was some question about the sincerity of whether money was actually on the table for this, or if one should just sit back with popcorn and watch the comment thread. Either way, I disavowed any stake in the claim because I don't want to deal with any of that.

posted by:   Fork     4-Nov-2014/0:06:28-8:00

As per usual, posts you can't edit are frustrating:
...should have read:
...but hopefully the point was apparent. (I switched from AAABBBCCC to AAAHELLOBBB in mid-edit, for some reason.)

posted by:   Fork     4-Nov-2014/0:22:02-8:00

A rebol.js is an interesting project BUT i would prefer some energy/time/money spent on porting R3/View to some other OSes like Android/Mac/iOS/...
I'd like R3 to be the ChromeOS, not an App running an App on top of JS.
As of today, I would donate for an Android port (source code released) but not for a JS port.

posted by:   GregP     4-Nov-2014/4:28:17-8:00

The point is to allow you to run R3 and R3-GUI apps in any browser or web app platform. This would allow us to run Rebol apps immediately, not just on web pages on the net, but as applications which could be easily deployed to any modern platform, including all modern mobile OSs, such as iOS, Android, Windows, etc. Most people in the Rebol community have seen Rebol as a potential replacement for web, and even OSs. I just want to be able to run Rebol code on mainstream modern platforms, and the web. Like it or not, web is the most common denominator of all modern operating systems and platforms.

posted by:   Nick     4-Nov-2014/19:48:04-8:00

Then is it possible to make local applications (say .exe in windows) with Emscripten? Does this mean that we have to learn other languages such as Javascript? Besides, will the programs become slow if they are run on "an App running on top of JS" ? And what if there are incompatibility between Rebol, JS and the platform?

posted by:   Emscripten     5-Nov-2014/0:34:45-8:00

There is already an .exe encapper for Windows and other OSs (Shixen released one this week). Emscripten just allows us to compile the /Core part of Rebol (i.e., like the binary .exe that runs natively on Windows and other OSs) so that it runs in a browser, so that it can execute Rebol code just like the native binary .exes, but entirely in a browser, "on a web page". The /View part of Rebol will be adjusted so that it operates using WebGL, instead of AGG. That way, the whole Core and View stack, and everything that runs on it (i.e., R3-GUI, and any code which Rebol coders create to make use of it) can run directly on a web page - so that no .exe will be needed to run Rebol code. Just a modern browser, on any modern OS, mobile, desktop, or otherwise. Users of the Javascript port will simply be able to run their complete Rebol apps, as-is, as web pages, or package them as web apps for popular OSs. You won't need to learn Javascript. We'll have to see how fast it is, and the engineers who work on creating the port will have to learn how to make it perform as fast as possible. The idea is to make this port as capable and as compatible as possible with existing native implementations of R3 and R3-GUI.

posted by:   Nick     5-Nov-2014/2:08:15-8:00

But what about browser limitations regarding I/O for example? I'm thinking about read and write to hard disk or even from/to HTTP ?
Since a prototype has been made some times ago, can we just check the performance of a pure /core code?

posted by:   GregP     5-Nov-2014/4:56:55-8:00

Is the .exe encapper available now? I haven't found it on the Atronix's website.

posted by:   Rex     5-Nov-2014/6:47:06-8:00

Andreas already has a file system created for his core port (I think using Localstorage), and he's looking at implementing other features.
The encapper is a script which runs on the newest dev version of Atronix R3. I'll post a link later, I'm on mobile now and can't get into AltMe.

posted by:   Nick     5-Nov-2014/9:30:35-8:00

Copied from AltMe Announce group:
Prebuilt R3 capable of encapping is available at http://atronixengineering.com/downloads.html as development releases. Together with the encap.r from https://raw.githubusercontent.com/zsx/r3/atronix/make/encap.r, it can be used to encap the REBOL script into the interpreter and run as a standalone program

posted by:   Brock     5-Nov-2014/9:59:55-8:00

Here's a bit more of a technical overview about porting with Emscripten, for anyone interested:

posted by:   Nick     5-Nov-2014/17:35:01-8:00

I'm maybe going to say something stupid but I don't get this. Why port to Rebol 3 to Emscripten? Maybe I don't understand the goal. The goal here if I understand correctly is to use the browser to display rebol programs. The display will be made up of SVG and/or Canvas elements that will be displayed. So use XMLHTTPRequest. Ajax. A quote from
"The XMLHTTPRequest object, which is accessible from JavaScript, is a browser API/object that enables JavaScript code to send HTTP commands directly to a server. Asynchronous means that the functions in the XMLHTTPRequest object do not block."
XMLHTTPRequest is just a statement or command. The JavaScript is in the browser already. So you send a web page to the browser with the XMLHTTPRequest looping back to the Rebol program.
So what has to be done is to make a VID to Canvas or SVG converter. So that a the server sends out Canvas or SVG to the client browser. Data can be fed back with XMLHTTPRequest. Do I know how to do this...uh...hangs head down...no...but I think the general idea is sound. You could run the program on your own computer and have it serve and be the client at the same time. The rebol program on your computer would be the server. The browser on your computer would be the client. It would seem that translating or making a dialect that sent out canvas and/or SVG directions to the browser would be a lot easier than writing all of Rebol in JavaScript. Rebol could remain Rebol. All the older programs could be the same if you just added the new VID to Canvas or SVG converter to substitute for VID. Instead of a AGG based VID it would be a canvas and/or SVG based VID. It could also be done in little pieces. Make say a box. Then add grids. Add check box. Each time testing in a browser. I know this is little wordy but I want to make myself clear. Of course it could be that you can't do what I've said but if so I have no idea why.

posted by:   Sam     4-Jan-2015/18:01:04-8:00

Ok here's what I'm talking about. You have half of it already here already. When you run the Saphirion R3 that's linked from bottom of this page,
and type in docs it opens your browser and a web page. Instead of the R3 help page let's say the web page is this.
The Rebol desktop. Nice! But let the page be served from the same computer. Now by using XMLHTTPRequest you feed JavaScript commands to the browser. In turn these commands can be a GUI based on Canvas, WebGL or SVG. With XMLHTTPRequest you can feed and return info. Change the display etc. My understanding is all Ajax is based on XMLHTTPRequest and they've just jammed it full of all kind of complexity but the basis is a information pipe through this request. I think there's also another way but I can't remember it at this time. The basic way is XMLHTTPRequest though.
I'll say it another way to make sure I'm understood. A dialect that sends WebGL to a browser. The dialect will have the same diction or programming commands as VID but will output to the browser in WebGL through XMLHTTPRequest. That way whatever you've learned already will carry over. It wouldn't have to look exactly like the operating system used as long as it was reasonably attractive. People are getting used to different interfaces because of the web. Everyone has different kinds of displays on their pages that are interactive. The Rebol desktop looks great. That's the ticket!

posted by:   Sam     4-Jan-2015/20:16:34-8:00

My apologies I meant to add this url also. It's the Rebol desktop forum link.
Could viewtop1200 be extended to include WebGL?
If what I've posted is complete nonsense because of something I misunderstand. My apologies. I do realize that it will take a LOT of work to convert all the VID commands to WebGL or Canvas or SVG commands. It seems that if the whole thing is converted to JavaScript that you will have to do some of the same converting anyways.
It might be good to note that you have to keep track of the position of elements in Canvas. Click on one and you have to know where it is. SVG supposedly can keep track and tells you when an element has been clicked on. WebGL I have no idea.

posted by:   Sam     4-Jan-2015/21:21:16-8:00

Thanks for the viewtop 1200 link.
I changed all script #include to do and commented out these lines:
;do %../sdk/source/view.r
;do %../sdk/source/prot.r
This was interesting. It seems that the viewtop 1200 skin can easily be changed. Once I looked at the regular viewtop script by accessing it from the console. I thought that version of the viewtop to be somewhat complicated, perhaps unduly so. Hope I'm not looking at the same script presented in a different way!

posted by:   Oscar     6-Jan-2015/18:23:40-8:00

Nick said,"...Users of the Javascript port will simply be able to run their complete Rebol apps, as-is, as web pages, or package them as web apps for popular OSs..."
I finally get it. (Hangs head in shame)After reading the same post over and over. Part of what I said about converting all the VID commands to WebGL or Canvas or SVG commands would be part of the project but what Nicks talking about is much much bigger. I wasn't looking for that so it just went over my head. I just wasn't thinking big enough. Duhhhh...
I would think the hardest part would be VID. Making the interfaces align would be a lot of tricky work. Figuring when to use canvas or WebGL or SVG. Any could be combined and might need to be to make everything work.

posted by:   Sam     8-Feb-2015/17:58:22-8:00

VID sits on top of View. The only thing that needs to be ported for anything above View to work, out of the box, is the renderer. R3-GUI, draw commands, everything will just work, if the rendering port is completed (of course, along with /Core). That's one of the great things about the design. In the browser, View will likely use WebGL as the rendering engine (R2 used AGG). Cyphre has already done the work of porting the rendering on Android. He's the most likely candidate to get that work done, and I'm still talking with him about it. It will get done at some point, it's just a matter of when and at what cost.

posted by:   Nick     8-Feb-2015/21:48:14-8:00