[Caml-list] [announce] O'Browser : OCaml on browsers
Benjamin Canou
O'Browser is an implementation of the OCaml virtual machine in
JavaScript, designed to run in web browsers.
It features a runtime library compatible with OCaml's standard one
(including OOP and concurrent threads) and bindings of some JavaScript
functions to manipulate the DOM primitives.
The distribution is available at [1] and an online version of the
tutorial is reachable at [2].
Please note that this is an early version, in particular the DOM
interface module is neither pretty nor well typed.
However, it can already be used to create little applets or scripts (as
in the tutorial [2], the examples of the distribution [3] or my webpage
[4]) and we'll be glad to receive your comments or bug reports.
Have fun.
Benjamin Canou.
[1] http://www.pps.jussieu.fr/~canou/obrowser-0.1.tar.bz2
[2] http://www.pps.jussieu.fr/~canou/obrowser/tutorial
[3] http://www.pps.jussieu.fr/~canou/obrowser/examples.html
[4] http://www.pps.jussieu.fr/~canou/
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Kuba Ober
> O'Browser is an implementation of the OCaml virtual machine in
> JavaScript, designed to run in web browsers.
> It features a runtime library compatible with OCaml's standard one
> (including OOP and concurrent threads) and bindings of some JavaScript
> functions to manipulate the DOM primitives.
[...]
> Please note that this is an early version, in particular the DOM
> interface module is neither pretty nor well typed.
> However, it can already be used to create little applets or scripts (as
> in the tutorial [2], the examples of the distribution [3] or my webpage
> [4]) and we'll be glad to receive your comments or bug reports.
And the reason is?....
Pardon the question, but is this meant to be "useful" in the future,
or is it just a fun experiment (in which case the next target should
be brainfuck).
My question (why and what for?) is serious, though.
Cheers, Kuba
Jon Harrop
> Hi,
>
> O'Browser is an implementation of the OCaml virtual machine in
> JavaScript, designed to run in web browsers.
> It features a runtime library compatible with OCaml's standard one
> (including OOP and concurrent threads) and bindings of some JavaScript
> functions to manipulate the DOM primitives.
>
> The distribution is available at [1] and an online version of the
> tutorial is reachable at [2].
>
> Please note that this is an early version, in particular the DOM
> interface module is neither pretty nor well typed.
> However, it can already be used to create little applets or scripts (as
> in the tutorial [2], the examples of the distribution [3] or my webpage
> [4]) and we'll be glad to receive your comments or bug reports.
This is a really awesome project! Performance is fine on a decent browser.
Times taken to highlight syntax_common.ml on this machine:
Chrome: 0.5s
Firefox: 1.1s
IE7: 5.7s
Konqueror: 17.5s
Looks like you've got an OCaml bytecode interpreter written in Javascript.
Could you write a compiler and call eval to get better performance?
I've been thinking about run-time generating code using LLVM that runs in
OCaml's VM recently. Using that to implement Javascript on top of OCaml's VM
would be interesting...
Anyway, I think that's a really great piece of work!
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
David Teller
> > Please note that this is an early version, in particular the DOM
> > interface module is neither pretty nor well typed.
> > However, it can already be used to create little applets or scripts (as
> > in the tutorial [2], the examples of the distribution [3] or my webpage
> > [4]) and we'll be glad to receive your comments or bug reports.
>
> And the reason is?....
To me, the fact that you can write portable lightweight applets sounds
like a good enough reason. That and the fact that I can see this being
used by stuff like Ocsigen to make for (even) richer client-server
applications.
Just my two cents,
David
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings liquidations.
Florian Hars
> Please note that this is an early version, in particular the DOM
> interface module is neither pretty nor well typed.
If you enhance these APIs, you should probably try to coordinate it
with whatever might happen in http://code.google.com/p/ocamljs/
so that source code will be as compatible as possible.
Yours, Florian.
Paolo Donadeo
> designed to run in web browsers.
What can I say? WOW, great idea!
--
Paolo
~
~
:wq
Burgisser Francois
Good idea but maybe a browser plugin to manipulate DOM would be much more
efficient.
Still pretty instructive.
Franz
Gabriel Kerneis
> Good idea but maybe a browser plugin to manipulate DOM would be much more
> efficient.
But, sadly, much less portable.
--
Gabriel
Kuba Ober
> On Mon, 2008-11-17 at 22:43 -0500, Kuba Ober wrote:
> > > Please note that this is an early version, in particular the DOM
> > > interface module is neither pretty nor well typed.
> > > However, it can already be used to create little applets or scripts (as
> > > in the tutorial [2], the examples of the distribution [3] or my webpage
> > > [4]) and we'll be glad to receive your comments or bug reports.
> >
> > And the reason is?....
>
> To me, the fact that you can write portable lightweight applets sounds
> like a good enough reason. That and the fact that I can see this being
> used by stuff like Ocsigen to make for (even) richer client-server
> applications.
I presume that one can have some Javascript library to abstract out platform
differences, but to have a whole new language? Well, of course what works
works, the question is if the performance is any good.
Cheers, Kuba
Kuba Ober
> On Monday 17 November 2008 16:20:50 Benjamin Canou wrote:
> > Hi,
> >
> > O'Browser is an implementation of the OCaml virtual machine in
> > JavaScript, designed to run in web browsers.
> > It features a runtime library compatible with OCaml's standard one
> > (including OOP and concurrent threads) and bindings of some JavaScript
> > functions to manipulate the DOM primitives.
> >
> > The distribution is available at [1] and an online version of the
> > tutorial is reachable at [2].
> >
> > Please note that this is an early version, in particular the DOM
> > interface module is neither pretty nor well typed.
> > However, it can already be used to create little applets or scripts (as
> > in the tutorial [2], the examples of the distribution [3] or my webpage
> > [4]) and we'll be glad to receive your comments or bug reports.
>
> This is a really awesome project! Performance is fine on a decent browser.
> Times taken to highlight syntax_common.ml on this machine:
>
> Chrome: 0.5s
> Firefox: 1.1s
> IE7: 5.7s
> Konqueror: 17.5s
>
> Looks like you've got an OCaml bytecode interpreter written in Javascript.
> Could you write a compiler and call eval to get better performance?
That's what I was gonna suggest: if one could sorta-kinda macro-expand
bytecode interpreter running on some bytecode, then JIT platforms such
as tracemonkey could dramatically improve the performance of such code.
Cheers, Kuba
Vincent Balat
On Tuesday 18 November 2008 19:15:28 Kuba Ober wrote:
> On Tuesday 18 November 2008, you wrote:
> > On Mon, 2008-11-17 at 22:43 -0500, Kuba Ober wrote:
> > > > Please note that this is an early version, in particular the DOM
> > > > interface module is neither pretty nor well typed.
> > > > However, it can already be used to create little applets or scripts
> > > > (as in the tutorial [2], the examples of the distribution [3] or my
> > > > webpage [4]) and we'll be glad to receive your comments or bug
> > > > reports.
> > >
> > > And the reason is?....
> >
> > To me, the fact that you can write portable lightweight applets sounds
> > like a good enough reason. That and the fact that I can see this being
> > used by stuff like Ocsigen to make for (even) richer client-server
> > applications.
>
> I presume that one can have some Javascript library to abstract out
> platform differences, but to have a whole new language? Well, of course
> what works works, the question is if the performance is any good.
Our final goal is of course to write the whole Web application in OCaml (both
server and client sides). And thus to get the same static guarantees for the
code beeing executed on the browser as we have on server side with Ocsigen
(for example valid xhtml, etc).
To run OCaml on a browser, there are several solutions:
For example you can use a compiler to js (see for example ocamljs), or a
plugin. O'Browser is an alternative. It seems to be efficient enough for most
uses. For tasks requiring very high efficiency, the only solution is a plugin
_and_ a very efficient xhtml/css rendering engine.
Cheers,
Vincent Balat
David Thomas
--- On Tue, 11/18/08, Vincent Balat <vincen...@pps.jussieu.fr> wrote:
Benjamin Canou
>From Kuba Ober:
> Pardon the question, but is this meant to be "useful" in the future,
> or is it just a fun experiment (in which case the next target should
> be brainfuck).
Coming soon: the OCaml VM on a turing machine !
>From Burgisser Francois :
> Good idea but maybe a browser plugin to manipulate DOM would be much
> more efficient.
>From Gabriel Kerneis:
> But, sadly, much less portable.
>From Jon Harrop:
> Could you write a compiler and call eval to get better performance?
>From David Thomas:
> I'd like to see a plugin that makes available to JS a function to
> execute ocaml bytecode.
Our plan is to achieve efficiency with a (not yet available) browser
plug-in (the original bytecode interpreter or the native compiler) while
remaining portable by using the JavaScript VM where the plug-in is not
available. So we don't currently focus on optimizing (and complexifying)
too much the JavaScript version.
>From David Teller:
> To me, the fact that you can write portable lightweight applets sounds
> like a good enough reason. That and the fact that I can see this being
> used by stuff like Ocsigen to make for (even) richer client-server
> applications.
Indeed, as Vincent wrote, even if O'Browser is at this point only a
client-side scripting core, it takes place into the Ocsigen project and
will be used to interact with (OCaml) server code (in its current form
or not).
Benjamin Canou.
William Le Ferrand
Thank you for this amazing work !
I'm rewriting large parts of my website using this tool, and I may have
found two little bugs :
* get_attribute (in rtjs.js)
when get_attribute "toto" returns a boolean, value_from_string returns the
empty string (this is nasty ..)
(temporary) solution : in rtjs.js, just cast on line 33 with something like
return value_from_string (v == null ? "" : (v+""));
* input (in js.ml)
it seems that the editable function
editable = (
function
true -> (try Node.remove_attribute node "disabled" with _ -> ())
| false -> Node.set_attribute node "disabled" "disabled"
);
works better. (at least it works with buttons, check boxes and so on)
Thank you again !
All best,
William Le Ferrand
2008/11/21 Benjamin Canou <benjami...@gmail.com>
--
William Le Ferrand
E-mail : wil...@beouifi.org
Mobile : +33 6 84 01 52 92