[racket-dev] sporadic failure when building PLaneT docs

On Fri, Aug 19, 2011 at 12:50 PM, Eli Barzilay <eli at barzilay.org> wrote:
> Three hours ago, Robby Findler wrote:
>>
>> I'm not seeing anything when looking at your code that looks
>> suspicious, but I'm not sure of the ins and outs of the sandbox
>> protocols so I'm not sure who to blame here (well, probably the
>> sandbox needs to be blamed since the error is not illuminating, but
>> there may be other problems that that error is masking).
>>
>> One difference that I notice is that scribble's make-base-eval doesn't
>> create the evaluator in the same way your code does; it uses a
>> different argument to make-evaluator that puts the evaluator into a
>> different mode somehow. That could be relevant.
>>
>> Maybe Eli can say more?
>
> I have no idea what the problem is, or how to get it without involving
> planet.

I don't see why that should stop you.

To spur you along, I've noticed that the sandbox creates a module with
the name 'program from the use-lang function on line 518 which seems
to be making its way over to the argument to evaluate-program (line
564) and from there the module is required but without, apparently,
ever evaluating the module (or maybe evaluating it in a different
namespace).

This sure seems like something that someone who is familiar with how
the sandbox code works could shed some light on. I tried working
through the code a little bit this evening but find it difficult to
read.

For example, I think code like this:

  (when ns (set! ns (ns)))

is bad style; when you're using "ns" for a variable to stand for
"namespace" you should probably make sure it is bound to a namespace,
or use something else. Also, it seems unwise to add that kind of
imperative dependency to reasoning about what is going on with 'ns'
and when it is (may be) created. I would have used two variables.

I'll also note that this line seems like it can lead to a bug because
shortly thereafter I see this:

  (when ns (current-namespace ns))

which looks like it can fail in the case that the limit-thunk does
something to above the computation that does the set!.

I can't tell for sure if this can happen because I got lost in the
call-with-limits.

I did notice that call-with-limits has this

  (let ([r #f])
    ..stuff..
    (define r ...)
     ...use r ...)

in such a way that the outer binding of 'r' is never used which seems
a little suspicious. At a min, that unused binding probably be
removed, but maybe there is an actual bug there and those two 'r's are
supposed to not shadow each other?

Robby