<div dir="ltr">Do you need to do the same thing with file/convertible?<div> </div><div>Robby</div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Oct 3, 2013 at 1:09 PM, Stephen Chang <<a href="mailto:stchang@ccs.neu.edu" target="_blank">stchang@ccs.neu.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. <div class="HOEnZb"><div class="h5"> On Wed, Oct 2, 2013 at 7:21 PM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> 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 <<a href="mailto:stchang@ccs.neu.edu">stchang@ccs.neu.edu</a>> 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 <<a href="mailto:stchang@ccs.neu.edu">stchang@ccs.neu.edu</a>> 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 <<a href="mailto:ryanc@ccs.neu.edu">ryanc@ccs.neu.edu</a>> >> > 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 <<a href="mailto:stchang@ccs.neu.edu">stchang@ccs.neu.edu</a>> >> >>>> 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: >> >>>>> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> >> >>>> >> >>>> >> >>>> >> >> > > </div></div></blockquote></div> </div>