[racket-dev] sporadic failure when building PLaneT docs

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Fri Aug 19 23:10:58 EDT 2011

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


Posted on the dev mailing list.