[racket] Fresh sandboxes in Scribble documentation (was: Typed macros in untyped code)

From: Eli Barzilay (eli at barzilay.org)
Date: Fri Nov 19 15:25:51 EST 2010

10 minutes ago, Neil Toronto wrote:
> 
> The problem: because we create one evaluator and use it for everything, 
> our documentation examples aren't independent.

This is only to make it run faster.  Creating a sandbox can be
expensive, and I'd expect a TR sandbox to be much more expensive.

BTW, redefinitions should be fine, since after the sandbox is created
it works in a "repl mode", maybe TR is forbidding redefinitions?


> All of my examples set a parameter. If I used `parameterize'
> instead, they'd all look like this:
> 
>      @(examples #:eval bigfloat-eval
>                 (parameterize ([bf-bits  ...])
>                   <some-computation>)
>                 (parameterize ([bf-bits  ...])
>                   <some-computation>)
>                 ...)
> 
> I can't combine them all under one `parameterize' because I'd lose
> the REPL-like interaction.

[This is an unrelated problem -- and you can probably get it to look
better by setting the parameter as a side effect, or maybe return
multiple values assuming there's a small number so it's easy to
correlate the code with the results, or even "help" that with
something like:

  (parameterize ([foo bar])
    (list 'some=    <some-computation>
          'another= <another-computation>
          ...))

]


> But as it is, I can't reorder my examples or `defproc's without
> thinking seriously about the effect they'll have on each other.

Then don't use a single sandbox.  Or avoid definitions that need to be
redone later (eg, different names or just use `let' more).  (Perhaps
this is how you got to the `parameterize' problem?)


> So I tried to solve the independent-examples problem by creating a
> fresh evaluator for each example. When I tried to run it, it took
> forever. And then it ran out of memory and DrRacket asked for more.
> 
> Currently, I only create a new evaluator for *specific* examples
> that have certain effects, but this won't scale. Question for the
> group: is there a better way to isolate examples? I've got a voodoo
> half-idea that I can branch the original evaluator using
> continuations, but I don't know how.

No, that shouldn't help because the environment is changed as a
side-effected.

There's several things that you can do to speed things up:

* Explicitely kill the sandboxes.

* Re-use the language modules (with `sandbox-namespace-specs' or
  whatever you get from scribble), which means that you don't need to
  pay to reload and reinitialize the language for every sandbox.

* Possibly `call-with-trusted-sandbox-configuration' can make things
  run even faster (but maybe the default does that already).

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!


Posted on the users mailing list.