Reading Files, User Interaction, Python VM

53 views
Skip to first unread message

Sphaerica

unread,
Jan 1, 2012, 5:00:33 PM1/1/12
to Skulpt
Okay. You're going to get so sick of me, but I think you'll like what
I'm doing with Skulpt, and the exposure it gets.

The same problem that killed me for being able to interrupt a program
in a long running or infinite loop, and also that stymied efforts to
implement an interactive debugger, now has hit me in two other areas,
user interaction (i.e. event loops) and reading files from the server.

Because the entire program runs as one big eval() it never
relinquishes CPU time. This prevents the user from doing any mouse
clicks or data entry (except through a javascript confirm, prompt or
alert). It also prevents reading files of any sort from the server,
because that can only be done with an HttpXMLRequest call, which in
turn requires that the eval take a breather to let the response come
back (which then becomes another issue, either resuming the compile/
execution as a result of the callback, or else putting the data
somewhere and having execution resume and know how to test if its
ready and where to pick the data up).

In the end, I got around the file problem by preloading any needed
files into cookies before starting execution (which in turn puts a 4K
limit on file size), and creating a version of Sk.read() that looks
first in the cookies, and second in builtins for files. I have a few
strategies for deciding what to preload, none of which are perfect,
but for my purposes they'll do.

In the end, though... I'd like to consider at some date breaking the
code up in the compiler so that it can be run in chunks. This would
in theory mean putting everything in code blocks and creating an array
of such blocks to each be run by separate eval() calls. That would
get messy. It would also require some persistence in program memory,
and I'm unsure if you use local or global variables.

I wish I had the time (a few lifetimes) to start fresh. Looking at
the parse() and compile() functions defined in Python, I realized that
the best solution might be to write a Virtual Machine in javascript.
This would then eliminate the need for a special Python compiler, and
the VM could take care of threading itself (i.e yielding time
periodically, and resuming through a settimeout() call, which would
even allow for simultaneously running multiple programs). Performance
would suck, but the implementation could be unrestrained.

I'd love to do a project like that but I'd never finish. Is anyone
interested in putting together an open source group effort to try?
Reply all
Reply to author
Forward
0 new messages