[erlang-questions] Erlang in the browser

Witold Baryluk <>
Mon Nov 28 16:32:14 CET 2011


On 11-27 16:12, Yurii Rashkovskii wrote:
> Hi Witold,
> 
> This is very interesting. When do you think you will be publishing it?
> 
> Yurii.

In fact I just pushed it to github

https://github.com/baryluk/erljs

It is mess however, and I will work in next week on it.
Just doing few other small Erlang related projects,
and want to finish them before cleaning up.

I just decided it is better to do git commit -a
and push it, than perform multiple commits
of changes code base accumulated. It is better sure
for historical reasons, but I will probably not done it in sensible time.
(anyway git doesn't track modification times, so it even
doesn't have historical value).

Most important files are

client side:
  erljs.jss
  erljs_datatypes.js
  erljs_scheduler.js
  erljs_vm.js
  erljs_control.js

server side:
  erljs.erl

Few changes (XHR+websocket communication with server processes,
and BEAM verifier for example, which isn't really needed,
it just helps me figure out,
if my assumptions about BEAM are correct in actual BEAM code,
but it maybe be also helpful, if would like to for example
load untrusted modules from outside) are queued to be pushed soon.

I will first move files to proper subdirectories,
and clean up testsing infrastructure (there are currently
2 separate testing systems, and common_test is not yet supported
properly).

Then I will implement fully binaries, because this is one of the most missing
feature, which needs to be done, to have most of stdlib, compiler,
etc. modules to work (most of them works on lists, but sometimes
binaries are used, and for completnes it must be done first).
Binaries are hard to implement mainly because of lots of
opcodes involving them, as well lack of built-in float<->binary
conversion in JS (I needed to build IEEE754 conforming parser/generator
for this, cool but awfull).

Then I will fix exception handling (it works, but stacktrace
is slightly different than in BEAM VM, but I would
like to have them exactly same, so I could be sure
that all functions behaves in same way both in BEAM and in erljs).

After that I will try to put all code into managable
namespace, to not polute global symbol table in JS,
(this will also simplify running multiple copies of Virtual Machine).

After that probably on-demand module loading will be done.

I will also look at Joe trick with parsing distributed binary terms
using JavaScript.

There is many things to be done on horizon, for example
utilizing WebWorkers transparently to use multiple cores
automatically.

My approch (direct interpretation of opcodes)
have some overhead, but considering how it simplifies
writing of non-blocking code in browser, and how composable it is
comparing to JavaScript or hack which tries to solve problem
(like yield, continuations, events, etc. etc), we can just use
multiple processes, and block on receive, or perform computations
without worring about webbrowser getting freezed, or
some events being queued (like button press, or delivery of
server response for other requests).

In the future, if erljs_vm.js will be complete, I would like
to squeeze beam code and big-switch over opcodes,
to make it more space efficient, and do some research on JIT compilation
from BEAM to JS (it is possible, but quite hard mainly due tail-recursion,
and non-blockignes, being both contradicting in JS and Erlang,
lack of goto in JS makes it even harder ;D - however as I said it is possible,
and will provide substantial performance gain in the future).

When developing whole erljs I do not use any BEAM machine
internals, so I do not need to use EPL license,
or whetever. I just guess how BEAM works by inspecting it output,
and correlating it with BEAM decompiler listings.
Unfortunetly it is needed because BEAM code have no official documentation,
as well Erlang have not strictly and formally defined semantics.
However, doing reverse enginering is possible, and I have
substantial progress (even phash which looks to be giving
random values, have been somehow been done).


Before rushing into code, you should wait slightly,
as I want to really clean up it first,
and clarify licensing issues of all code.

Thanks for your interest.

I have a small presentation about erljs in pdf,
and will publish it soon.

You can try some really old version (not in sync with what
is in github now), http://smp.if.uj.edu.pl/~baryluk/erljs/erljs.html

You can run there some unit tests, event tracing, do some event handling
on DOM as well use simple REPL, i.e. lists:merge([2,7,11],[1,5,13])
(expression must be of the form, module:function(literal1, literal2, ...),
it is restriction, because I do not have yet full parser on client side,
but allows lot of fun).


> 
> I have working BEAM to JS translator and small VM In JS to run erlang 
> > programs.
> > It have a scheduler and everything, but few things are still missing.
> > Especially obsucre opcodes, like binary handling.
> >
> > About your example I have built a small framework with very similar
> > syntax, which allows handling DOM from erlang running in this VM.
> >
> > There is many other advantages of this model, and because I have some
> > time to finish this project I will publish it shortly.
> >
> > Feel free to contact me.
> >
> >

-- 
Witold Baryluk



More information about the erlang-questions mailing list