I have been working on a demo of the universal backend and specifically of the task migration between target languages.
The demo is a reversi game where a human plays against the computer. The game is constantly searching for the best replies to the user’s legal moves, so it is never idle while the human is thinking. This has the advantage that the user gets an immediate response by the computer to the move he makes. The game runs in the user’s web browser, and it is possible to migrate the game to another device, for example another browser on the same computer or another browser on a different computer (desktop, cell phone, tablet, etc). It is also possible to migrate the app from the web browser to the web server for 10 seconds (to offload the search to the web server). This is possible even though the web browser is running a JavaScript version of the code, and the web server is running a PHP version of the code.
You can try it out at: http://gambitscheme.org/reversi.php
Please report any problems you might encounter.
Marc
Afficher les réponses par date
When explaining this to Maureen, it sounded like the ultimate worm.
Can you migrate it from a browser to a gambit-c interpreter running on some server (not php on Apache)?
Brad
On Oct 20, 2015, at 5:41 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
I have been working on a demo of the universal backend and specifically of the task migration between target languages.
The demo is a reversi game where a human plays against the computer. The game is constantly searching for the best replies to the user’s legal moves, so it is never idle while the human is thinking. This has the advantage that the user gets an immediate response by the computer to the move he makes. The game runs in the user’s web browser, and it is possible to migrate the game to another device, for example another browser on the same computer or another browser on a different computer (desktop, cell phone, tablet, etc). It is also possible to migrate the app from the web browser to the web server for 10 seconds (to offload the search to the web server). This is possible even though the web browser is running a JavaScript version of the code, and the web server is running a PHP version of the code.
You can try it out at: http://gambitscheme.org/reversi.php
Please report any problems you might encounter.
Marc
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
2015-10-21 11:45 GMT+08:00 Bradley Lucier lucier@math.purdue.edu:
When explaining this to Maureen, it sounded like the ultimate worm.
Can you migrate it from a browser to a gambit-c interpreter running on some server (not php on Apache)?
JS, PHP and Java all have overheads in respect of running Gambit code, and their sandboxing is also not optimal. For typical client device use this is fine.
For a server, could a "sandbox VM" be implemented in Scheme or C, i.e. what people use Lua for?:
I guess the point with it would be to be another "language backend", which is optimized for one single thing, which is to be giving as good performance as possible while being as simple as possible to implement.
Or does the GVM code already serve this purpose, and is waiting for someone to implement a simple "GVM interpreter sandbox" environment?
The code generated by the C backend and the code generated by the universal backend are incompatible when it comes to task migration. This is because the two backends do not generate the same GVM code (due to differences in the set of inlined primitives). Moreover, the low-level representation of stack frames is different (for example the C backend enforces alignment of stack frames), and the ordering of basic-blocks is different. Currently I don’t have any plan to make the backends compatible for migrating continuations. It might be possible to make closures compatible though and I will think about it.
On the other hand, object->u8vector and u8vector->object are compatible for types other than procedures and continuations. It is possible to transfer data (even with circularities) between them, so an ad-hoc remote procedure call implementation should not be too difficult to build.
Marc
On Oct 20, 2015, at 11:45 PM, Bradley Lucier lucier@math.purdue.edu wrote:
Can you migrate it from a browser to a gambit-c interpreter running on some server (not php on Apache)?
On Oct 21, 2015, at 7:40 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
On the other hand, object->u8vector and u8vector->object are compatible for types other than procedures and continuations. It is possible to transfer data (even with circularities) between them, so an ad-hoc remote procedure call implementation should not be too difficult to build.
Speaking of this, is there documentation of the format used by object->u8vector and u8vector->object, other than the source code? If I want to use Gambit’s serialization, but also want to implement a strategy for exchanging serialized data with a tool written in something other than Gambit, what’s the best way to understand the format?
The source code is the only doc at this point, but it is a fairly straightforward encoding. Basically it is a prefix encoding of a tree using bytes, with a special code when there are cycles or sharing. Here’s a quick overview:
Single byte encoding for specific common objects:
#x50 0 #x51 1 #x52 2 #x53 3 #x54 4 #x55 5 #x56 6 #x57 7 #x58 8 #x59 9 #x5a 10 #x70 #f #x71 #t #x72 () #x73 #!eof #x75 #!void ...
Multi byte encoding for exact integers:
#x5e BYTE1 8 bit integer BYTE1 (top bit is sign) #x5d BYTE1 BYTE2 16 bit integer BYTE1 BYTE2 #x5c BYTE1 BYTE2 BYTE3 24 bit integer BYTE1 BYTE2 BYTE3 #x5b BYTE1 BYTE2 BYTE3 BYTE4 32 bit integer BYTE1 BYTE2 BYTE3 BYTE4 #x5f n BYTE1 ... BYTEn 8*n bit integer BYTE1 ... BYTEn
Multi byte encoding for pairs:
#x64 <car> <cdr> (<car> . <cdr>)
Multi byte encoding for vectors:
#x20 #() #x21 <ELEM1> #(ELEM1) #x22 <ELEM1> <ELEM2> #(ELEM1 ELEM2) #x23 <ELEM1> <ELEM2> <ELEM3> #(ELEM1 ELEM2 ELEM3) ... #x2e <ELEM1> ... <ELEM14> #(ELEM1 ... ELEM14) #x2f n <ELEM1> ... <ELEMn> #(ELEM1 ... ELEMn)
So for example, (object->u8vector '#(#f 20 (1 2 3))) is:
#u8(#x23 #x70 #x5e #x14 #x64 #x51 #x64 #x52 #x64 #x53 #x72) ---- ---- --------- ---- ---- ---- ---- ---- ---- ---- vect #f 20 pair 1 pair 2 pair 3 ()
Marc
On Oct 21, 2015, at 9:30 AM, mikel evins mevins@me.com wrote:
On Oct 21, 2015, at 7:40 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
On the other hand, object->u8vector and u8vector->object are compatible for types other than procedures and continuations. It is possible to transfer data (even with circularities) between them, so an ad-hoc remote procedure call implementation should not be too difficult to build.
Speaking of this, is there documentation of the format used by object->u8vector and u8vector->object, other than the source code? If I want to use Gambit’s serialization, but also want to implement a strategy for exchanging serialized data with a tool written in something other than Gambit, what’s the best way to understand the format?
On Oct 21, 2015, at 10:51 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
The source code is the only doc at this point, but it is a fairly straightforward encoding. Basically it is a prefix encoding of a tree using bytes, with a special code when there are cycles or sharing. Here’s a quick overview:
Thanks a bunch for this; it’s very helpful.
Marc,
This was not my question i.e. if I can migrate between JS/PHP/Java on the one hand and C on the other hand -
My question was, if I can implement in C, a "VM" that executes a compiled version of the code, within some kind of interpreter, so I easily can do completely safe Scheme code execution within that VM -
I.e. I can followup memory allocation and which globals/what environment I allow the "guest" code to run.
Perhaps this could be as simple as getting the JS/PHP/Java-format GVM code and implementing some kind of interpreter/VM for it?
Thanks
2015-10-21 20:40 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca:
The code generated by the C backend and the code generated by the universal backend are incompatible when it comes to task migration. This is because the two backends do not generate the same GVM code (due to differences in the set of inlined primitives). Moreover, the low-level representation of stack frames is different (for example the C backend enforces alignment of stack frames), and the ordering of basic-blocks is different. Currently I don’t have any plan to make the backends compatible for migrating continuations. It might be possible to make closures compatible though and I will think about it.
On the other hand, object->u8vector and u8vector->object are compatible for types other than procedures and continuations. It is possible to transfer data (even with circularities) between them, so an ad-hoc remote procedure call implementation should not be too difficult to build.
Marc
On Oct 20, 2015, at 11:45 PM, Bradley Lucier lucier@math.purdue.edu
wrote:
Can you migrate it from a browser to a gambit-c interpreter running on
some server (not php on Apache)?
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
-
Adam -
Bradley Lucier -
Marc Feeley -
mikel evins