@gchiu (or anybody ) I do web applications for my day job and was dreaming of the possibility of Ren-C running r3-gui apps in the browser...
Do you have any thoughts about how close/distant this emscripten branch would be to truly being able to do that?
I assume the first step would be to get that little REPL console working. I found this talking about how to read from stdin (writing to stdout seems straightforward the reading less so I think):
But in terms of the Ren-C codebase otherwise do you think there's a lot of underlying platform dependencies/#ifdefs etc. that will require a lot of changes for the webassembly output to really be able to work in the browser?
Otherwise regarding the technical feasibility of the GUI stuff, looking at some of these emscripten demos I'm impressed with a lot of them - i.e. I feel the draw/gui stuff seems within the realm of possibility.
In terms of overall strategy it looks to me the r3-gui stuff is pure Rebol code correct?
So am I right the first thing would be to get the Draw dialect working?
And do I understand that sits atop OpenGL?
I see some help about doing OpenGL from emscripten here:
Mostly I'm just wondering how big a job you think this is and whether I'm being overly optimistic...
(I did a lot of C years ago though more recently I do javascript exclusively so I do have some background to help me work on this if it's not complete a waste of time... )
Yes, the aim would be to get a working GUI dialect that creates Javascript. There is a demo around that @rgchris and @giuliolunati each have of a working emscripten build. Perhaps they can tell us where they are so that you can play. But they're just consoles to evaluate rebol code so far.
that would be cool I'd love to play with it or see if I could help get graphics going in it.
(I was in the process of building the emscripten branch you pointed to right now but I'd hate to waste time trying to fix things they've already addressed)
me I just got the emscripten branch to build the r3.js file but I haven't tried to do anything more yet.
what you're running in your "facelift" I assume is more than just that? or is yours truly just the build of that branch with some pretty html/css you've put around it?
Just saw your reply - before that I'd actually bit the bullet and pulled down your Try Ren/C files to see if me just replacing your ren-c.js/ren-c.mem files with my builds of r3.js/r3.js.mem would work as yours does.
It doesn't - though I think it's trying...
It's erroring on startup saying:
Assertion failed: Cannot call unknown function Host_Repl (perhaps LLVM optimizations or closure removed it?)
fwiw I see my r3.js is similar to your ren-c.js (though mine is bigger so they're not identical).
And in fact I don't see this Host_Repl function in my r3.js file though I do see it in your ren-c.js and I do see it down under src of the repo...
(so maybe the error is correct when it says optimizations removed it?)
Is your stuff including the exact build command you used by chance somewhere I could see it?
(me I was trying to follow the steps here btw - right now it's all I've found to go on)
Happy to see you're interested in emscripten build. Time ago I got it working, now I'm trying to reproduce it. First we need to cut off the REPL stuff.
Here's a link to an uber massive code dump. It would seem to me that you would have to equate SVG to draw and the rest would be Canvas calls in JavaScript.
I'm sure this would be a lot of work. In favor of the whole thing is that the AGG library is low level stuff so it would limit the number of functions that would have to be translated from Rebol to JavaScript.(I'm making an assumption here and don't know for sure.).
Basically go through Nick's rebol tutorials and every graphic element you see find a JavaScript function to replace with and spit that from a server to the browser. Yes I know that saying it is easy but the doing would be hard. I'm just thinking out loud.
Some time has passed, and while emscripten hasn't been a laser focus it has remained glued on the year's priority list. Just defining the API for C interoperability has been a lot of work, but JavaScript has been kept in mind so that it would one day be able to come out swinging.
We now have a proof-of-concept means of integrating JavaScript and Rebol in a natural way, through functions whose specs are blocks and whose bodies are strings of JavaScript code. The JS-NATIVE offers conventional run-and-return--when the body of the code finishes, it considers the operation over. The JS-AWAITER sandboxes asynchronous operations to appear synchronous, not returning when the body is finished but keeping the caller waiting until an implicit resolve() function is called.
I assume the first step would be to get that little REPL console working.
The links above are to the source for the current iteration of the REPL, which embraces this technique. There is a very long way to go in terms of error handling, exceptions, and being truly easy-to-use for a casual scripter...really it was just a proof-of-concept to get the model out the door.
It tries to attack the basic problems, while trying to throw in a couple of Ren-Garden-isms. Do shift-enter for multi-line input, and you can try something that does a loop containing an INPUT and a PRINT. Cancellation still needs work (the previous iteration of the demo handled it, but it hasn't been accomodated by this one yet). There are some attempts at undo-ability across evaluations.
(Note: For anyone concerned about the current size of the download, there's a lot that can be done about it. If we were willing to rely on browsers with SharedArrayBuffer and WebAssembly threading enabled, we could build directly to webassembly and avoid the bloat and performance hit of using the "emterpreter". Not to mention how much stuff is built into the EXE that is not needed for JavaScript. Anyone planning on using GOB!? Not to mention all the support for file ports and other things that the HTTP model would not use in that form...)
The codebase tries to stay within the realms of defined behavior at the abstraction level of C, and so it has mechanically been able to compile with emscripten for some time. But when it comes down to making it work in a way that is favorable, code tends not to design or write itself.
For some of the reasoning of why it works like it does, see "On giving libRebol JS more powers than JavaScript". It should probably be easy enough to grok if you do JavaScript for a living, and hopefully you can critique or suggest improvements. There's also a fair amount of design to consider in terms of the bridging, so feedback would be valuable on things like "How to bridge arguments to user natives / JS natives"
(I did a lot of C years ago though more recently I do javascript exclusively so I do have some background to help me work on this if it’s not complete a waste of time… )
I think now is the time at which someone who doesn't practice C but has a lot of JavaScript knowledge can start making a real, interesting thing! While being able to compile Rebol on bare metal remains an imperative, I think the web delivery vehicle is probably the best first chance at getting people exposed to the ideas.
Would be great if brave early adopters want to try seeing what they might accomplish. I think my time is probably best used fixing infrastructure things, in particular working on things like exception handling / error reporting / cancellation -- as opposed to writing JavaScript.
) I do web applications for my day job and was dreaming of the possibility of Ren-C running r3-gui apps in the browser...
)