whalesong/whalesong/repl-prototype
2013-04-16 17:45:57 -06:00
..
htdocs evaluation still broken. 2013-04-16 17:45:57 -06:00
modularize-input-port.rkt trying to get the module output working. 2013-04-08 19:00:18 -06:00
README adding limit-memory flag to the sandboxed server, preliminary README. 2013-04-12 13:49:03 -06:00
repl-compile.rkt got the namespacing stuff to work. can redefine in the repl things that have been defined in the namespace. 2013-03-04 14:21:18 -07:00
sandboxed-server.rkt adding limit-memory flag to the sandboxed server, preliminary README. 2013-04-12 13:49:03 -06:00
server.rkt forgot call to sync 2013-04-16 13:10:27 -06:00
write-runtime.rkt fixing the printing of values 2013-04-04 17:29:39 -06:00

This is an experiment in the dynamic evaluation of whalesong-generated
code.

----------------------------------------------------------------------

1.  Run 'write-runtime.rkt'.  This generates the runtime.js and
library.js files in htdocs/collects.  At the moment, the only files
written out are those that support whalesong/wescheme, though to make
this work, we'll want to parameterize write-runtime.rkt so it can take
in the name of the languages that the REPL should know about.

2.  Start the sandboxed server.  Run sandboxed-server.rkt.

Warning: you may need to first "raco make" both "sandboxed-server.rkt"
and "server.rkt", because the Racket compilation may otherwise hit the
memory ceiling imposed by the sandbox itself!

----------------------------------------------------------------------

TODO:

1.  Parameterize write-runtime so it can take in a list of the
language modules we need to compile.  Similarly, parameterize
sandbox-server.rkt so it knows which languages to allow.

2.  Allow non-sexp-based language support.  Currently, there's a nasty
location bug in Racket 5.3.3's module-reader that makes us lose
location information.  I'm considering just forking a copy of the
module reader just so we're not blocked on waiting for Racket 5.3.4,
either that or losing location information altogether.