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!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
