Two days ago, Matthew Flatt wrote:
>
> If you don't need this functionality enabled by default, you could
> install a `load/use-compiled' handler that similarly recognized
> paths into a ".zip" file.
The problem with that is that it's a hook that gets used only for
loading code -- a lower level hook would allow loading any content
from whatever (an archive, a cache divert, or a url).
A possibly nice place for it would be hooking onto security guards --
in a similar way that parameter guards can change the actual value.
For example, a security guard for openning a file could be expected to
return a port, which a user-installed guard can now create from any of
these sources. It would also be nice for the sandboxing aspect of
security guards: instead of throwing an error, a FS guard could divert
the requests to a local "disk file" similarly to what VMs do, a
network guard could be used to provide a fake connection that can be
used to test network code.
As a concrete example, consider the problem of not being able to have
default-sandboxed code do anything with preferences. In its current
role, that's the *right* decision for the sandbox library, but right
now your only choices are either to go with the default and forbid it,
or allow access to your own preference. With such a security-guard-
as-IO-hooks facility, the sandbox library could instead divert the
preferences file into a private per-sandbox file (and with some more
work, an in-memeory file representation, or a cheap way of achieving
it with a shm filesystem from the OS).
Another concrete example: imagine a homework assignment to implement a
specific server, with sandbox tests that execute the code in an
environment that arranges to have testing code talk to the sandbox and
test it, with no danger of "leaking out" a student server.
> I must admit, though, I'm disappointed if we can't rely on an
> OS-supplied filesystem to provide a good filesystem abstraction.
> Maybe there's some OS-level extension you could use to mount a file
> in an existing filesystem as a new filesystem (like Mac OS X's
> mounting of ".dmg" files)?
I have the same opinion in general -- but in reality we have the same
problem in NEU also. The releases are all stored on NFS (in
"/proj/racket", which you might know as its former name), and to
ensure that they always have the recently released version, they made
the /usr/bin executables be symlinks to that directory[*]. I measured
running drracket on a random machine -- it took about 40 seconds to
start the first time, and subsequent runs took <5 seconds. I know
that it'll still take a bunch of work to go from a hook as I imagine
above to running it from a zip file, so that part is not really
related to this problem, and I think that the proper solution is to
simply have them use the PPA to install racket locally on all of the
machines. Danny: I think that the same solution should be suggested
in your case.
([*] But they didn't update the names, which means that students often
try to run "drracket" and when it doesn't work assume that it's not
installed...)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
