I'm concerned about this:
+ [sandbox-namespace-specs
+ (cons (λ () (namespace-anchor->namespace anchor))
It seems like this would cause all evaluators to share a single
namespace, if I'm reading the docs right. (That would be a good test to
add.) Why not just
[sandbox-namespace-specs
(append (sandbox-namespace-specs)
(if ___))]
instead?
Ryan
On 10/03/2013 02:09 PM, Stephen Chang wrote:
Here's another attempt at a patch. Would someone mind code reviewing it?
Ryan pointed me towards sandbox-namespace-specs and it seems to do the
trick. I also added some tests and the docs seem to compile ok.
On Wed, Oct 2, 2013 at 7:21 PM, Robby Findler
<ro...@eecs.northwestern.edu> wrote:
namespace-attach-module sets up shared state between two modules so that, in
this case, the racket/pretty in one namespace is the same as the
racket/pretty in the other.
Try putting a printf in the top-level of racket/pretty (and in various other
places in that code as it does what it does) and then doing the
dynamic-require with and without the attach.
Robby
On Wed, Oct 2, 2013 at 4:58 PM, Stephen Chang <stch...@ccs.neu.edu> wrote:
Ok here's another dumb question. Why is that namespace-attach-module
even needed? It seems the dynamic require on the next line does the
desired thing?
On Wed, Oct 2, 2013 at 4:16 PM, Stephen Chang <stch...@ccs.neu.edu> wrote:
Ok thanks for the explanations. I'll try doing one of the last two
suggestions.
On Wed, Oct 2, 2013 at 4:09 PM, Ryan Culpepper <ry...@ccs.neu.edu>
wrote:
No, the 'racket/pretty' module might be declared even if the symbol
isn't
defined (or "mapped") in the namespace:
> (define ns (make-base-namespace))
> (define repl-ns (current-namespace))
> (parameterize ((current-namespace ns))
(eval '(require (only-in racket/pretty))))
> (parameterize ((current-namespace ns))
(namespace-attach-module repl-ns 'racket/pretty))
namespace-attach-module: a different module with the same name is
already in the destination namespace
module name: "/opt/racket-5.3.6/collects/racket/pretty.rkt"
context...:
/opt/racket-5.3.6/collects/racket/private/misc.rkt:87:7
And the symbol can be defined in the namespace even if the module is
not
declared:
> (define ns (make-base-namespace))
> (define repl-ns (current-namespace))
> (parameterize ((current-namespace ns))
(eval '(define pretty-print-handler #t)))
> (parameterize ((current-namespace ns))
(namespace-variable-value 'pretty-print-handler))
#t
;; but racket/pretty is not declared,
;; and #t is not a good print handler
Ryan
On 10/02/2013 03:58 PM, Stephen Chang wrote:
A namespace is a mapping from top-level identifiers to whatever they
are,
as
well as a separate mapping from module names to modules (roughly).
What
you
care about here is the second mapping, but you're checking the first
with
the patch.
Thanks for the explanation. That helps a lot. So the danger with my
check is when someone has another definition of pretty-print handler
but racket/pretty has not been attached?
But given the context, ie the dynamic require on the next line, it
seems like there's already an assumption about what the identifier I'm
checking is, so in this specific situation, isnt my check sufficient?
Robby
On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang <stch...@ccs.neu.edu>
wrote:
Whether that identifier exists in the namespace has nothing to do
with
whether racket/pretty can be attached.
Can you explain this a little more because it's a little unintuitive
to
me?
One option would be for install-pretty-printer! to just catch and
discard
the error. Evaluators for some languages would mysteriously not
have
pretty-printing turned on by default.
Another option would be to attach racket/pretty before requiring
the
initial
language for the namespace.
Another option is use #:pretty-print? #f when attaching
racket/pretty
would
fail.
Ryan
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
