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.
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.
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.
Could such a bridge be written? A trivial one, easily. In your embedded MY-THING.REB you could write:
DO-MY-THING: FUNCTION [VALUE] [
EITHER PARSE VALUE [SOME "A" COPY X: TO "C" SOME "C"] [
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:
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.
posted by: Fork 4-Nov-2014/0:06:28-8:00
As per usual, posts you can't edit are frustrating:
EITHER PARSE VALUE [SOME "A" COPY X: TO "C" SOME "C"] [
...should have read:
EITHER PARSE VALUE [SOME "A" COPY X: TO "B" SOME "B"] [
...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
posted by: Emscripten 5-Nov-2014/0:34:45-8:00
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
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.
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?
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:
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
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