Difference between revisions of "Bytecode for transfer"

From Apertium
Jump to navigation Jump to search
Line 1: Line 1:
{{TOCD}}
Adapt transfer to use bytecode instead of tree walking.
Adapt transfer to use bytecode instead of tree walking. This task would be write a compiler and interpreter for Apertium transfer rules into the format of an an off-the-shelf bytecode engine (e.g. Java, v8, kjs, ...).

This task would be write a compiler and interpreter for Apertium transfer rules into the format of an an off-the-shelf bytecode engine (e.g. Java, v8, kjs, ...).



This page is to list ideas and their pros and cons.
This page is to list ideas and their pros and cons.



== Java bytecode ==
== Java bytecode ==
Line 13: Line 10:
* Considering that lttoolbox is on its way to being ported to Java. If Java bytecode was chosen this might eventually make Apertium run on J2ME devices (only the tagger is missing for a full system).
* Considering that lttoolbox is on its way to being ported to Java. If Java bytecode was chosen this might eventually make Apertium run on J2ME devices (only the tagger is missing for a full system).


<pre>

<jacobEo> spectie: jimregan I don't know, but I suppose that Java byte would run fastest, as there have been extremely much work on optimize its speed, on different platforms....
<jacobEo> spectie: jimregan I don't know, but I suppose that Java byte would run fastest, as there have been extremely much work on optimize its speed, on different platforms....

<jacobEo> spectie: jimregan Also think in terms of some day get Apertium on a mobile phone.... then transfer in Java bytecode would be the easiest thing. But writing a J2ME bytecode executor.... pheh....
<jacobEo> spectie: jimregan Also think in terms of some day get Apertium on a mobile phone.... then transfer in Java bytecode would be the easiest thing. But writing a J2ME bytecode executor.... pheh....

<jacobEo> spectie: jimregan Actually, if we get lttoolbox-java to work AND have Java bytecode for transfer, then we instantly HAVE apertium running on phones! And also on Windows, all Unix varians, VAX, web pages, whatever can run Java bytecode.
<jacobEo> spectie: jimregan Actually, if we get lttoolbox-java to work AND have Java bytecode for transfer, then we instantly HAVE apertium running on phones! And also on Windows, all Unix varians, VAX, web pages, whatever can run Java bytecode.
</pre>


== Javascript bytecode ==
A Javascript engine.


== External links ==


* [http://code.google.com/apis/v8/embed.html Google v8: Embedder's documentation]
== V8 bytecode ==
A Javascript engine.
See [[http://code.google.com/apis/v8/embed.html]]

Revision as of 09:57, 30 March 2009

Adapt transfer to use bytecode instead of tree walking. This task would be write a compiler and interpreter for Apertium transfer rules into the format of an an off-the-shelf bytecode engine (e.g. Java, v8, kjs, ...).

This page is to list ideas and their pros and cons.

Java bytecode

  • Considering that lttoolbox is on its way to being ported to Java. If Java bytecode was chosen this might eventually make Apertium run on J2ME devices (only the tagger is missing for a full system).
<jacobEo> spectie: jimregan I don't know, but I suppose that Java byte would run fastest, as there have been extremely much work on optimize its speed, on different platforms....
<jacobEo> spectie: jimregan Also think in terms of some day get Apertium on a mobile phone.... then transfer in Java bytecode would be the easiest thing. But writing a J2ME bytecode executor.... pheh....
<jacobEo> spectie: jimregan Actually, if we get lttoolbox-java to work AND have Java bytecode for transfer, then we instantly HAVE apertium running on phones! And also on Windows, all Unix varians, VAX, web pages, whatever can run Java bytecode.

Javascript bytecode

A Javascript engine.

External links