I agree that it is different.
I disagree that this is a problem.
The documentation says that is executes the code with a time
restriction. This implies to me that (call-with-limits X #f t) should
not use more than X secs of resources, but it is trivial to produce
counter-examples. Without this
I think that, in this case, changing the documentation and adding the
functionality with a different name is the way to go.
Robby
On Tue, Nov 26, 2013 at 10:49 AM, Jay McCarthy j...@racket-lang.org wrote:
I agree that it is different.
I disagree that this is a problem.
The documentation
How can you change the documentation to say anything other than
Wherever you see an thunk having a time restriction, don't think that
that means the thunk is restricted to using only a certain amount of
time? We'd have to say something like Time in this content is a
-first-order- notion of time,
This isn't the semantics of the limits. It is about the way that calling
the evaluator interacts with threads. Changing this program (from Eli's
email)
- ,r racket/sandbox
- (define e (make-evaluator 'racket))
- (e '(define foo 1))
- (e '(thread (lambda () (sleep 5) (set! foo
+1 for Robby.
On Nov 26, 2013, at 12:05 PM, Robby Findler ro...@eecs.northwestern.edu wrote:
This isn't the semantics of the limits. It is about the way that calling the
evaluator interacts with threads. Changing this program (from Eli's email)
- ,r racket/sandbox
- (define e
IIUC, this makes the limit thing -- and therefore sandboxes -- behave
*very* differently. The original intention was that the time limit is
on something similar to what you get with `time'.
A very visible way to see the effect of this change:
- ,r racket/sandbox
- (define e
Thanks!
I think Jay and I became confused about the purpose of
`call-with-limits` and thought it was supposed to constrain the time
used by evaluation, no matter what it tries to do.
We should revert the change, clarify the docs at `call-with-limits`,
and maybe add something else to
7 matches
Mail list logo
