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.
> 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.
> 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:
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!
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.
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.
> 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.
> 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.
On Tue, Nov 18, 2008 at 06:14:45PM +0900, Burgisser Francois wrote: > Good idea but maybe a browser plugin to manipulate DOM would be much more > efficient.
> 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.
> 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:
> 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.
> 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.
I'd like to see a plugin that makes available to JS a function to execute ocaml bytecode. There could be a standard way to check for support, and the pure javascript interpreter could be loaded if it is missing (for those browsers/computers on which performance is reasonable).
--- On Tue, 11/18/08, Vincent Balat <vincent.ba...@pps.jussieu.fr> wrote:
> From: Vincent Balat <vincent.ba...@pps.jussieu.fr> > Subject: Re: [Caml-list] [announce] O'Browser : OCaml on browsers > To: caml-l...@yquem.inria.fr > Cc: caml-l...@inria.fr > Date: Tuesday, November 18, 2008, 10:32 AM > Hi,
> 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.
>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).
> >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).
|
