[Ecls-list] Kamen Lisp update, questions

[Dustin Long]

Hi all,

I've been working on improving Kamen Lisp, and wanted to give an update 
on my status, as well as shoot off a few questions.

1) Linux stability is greatly improved. There were some string problems, 
as I thought, mostly involving null termination. Also, it seems Firefox 
*really* doesn't like how ECL uses signaling. I had to make a custom 
build of ECL which can optionally disable signal handling during boot up.

2) I threw in a basic security model. It works by wrapping each 
interpretation of a webpage's lisp code in a new symbol 
"ext:call-secure", which is a function taking a zero-arg lambda 
expression. When it runs that lambda, no call to a "sensitive" operation 
is allowed. The custom ECL build was also modified for this: sensitive 
operations call the function "ext:security-check", which signals an 
error if it is within "ext:call-secure". The following functions are 
treated as sensitive: open, load, quit, truename, rename-file, 
delete-file, probe-file, file-write-date, file-author, directory, 
si:chdir, si:mkdir, si:rmdir, si:system, si:getpid, si:open-pipe, 
si:run-program.

3) Lisp errors propagate back to Firefox as Javascript errors.

4) Mismatched parenthesis will no longer crash Firefox.

5) License changed to the MPL/GPL/LGPL tri-license, as was suggested by 
Pierre.

You can see this for yourself with version 0.91, same place as before [ 
http://www.cs.stevens.edu/~dlong/software/kamen/index.php ]. The patch 
I'm using for my custom ECL is available as well.

Now I have some questions, if I may:

1) For the security model, are there any other dangerous symbols I 
missed? I know there's at least a few I noticed at the last minute but 
forgot to include. But I'd like to make sure I get them for in the next 
release.

2) How can I get multiple environments at once? I tried crawling through 
the source but couldn't find an answer. I'd like to be able to do 
something like this:

cl_object a = new_env();
cl_object b = new_env();
si_safe_eval(3, <some form>, a, Cnil);
si_safe_eval(3, <some form>, b, Cnil);

such that the two forms can't see each others' global bindings. This 
seems to happen with threads, but I can't figure out how.

3) I ran into a problem where the Linux machine I use for building ECL 
had a newer version of glibc than another Linux machine I tested it on. 
Consequently, loading libecl.so dynamically failed. Is there a configure 
option I can use that forces compilation with something like a lowest 
common denominator?

That's all for now. Any help would be appreciated.

Thanks!
Dustin