[racket-dev] patch for make-base-eval
> Do you need to do the same thing with file/convertible?
The current version only attaches file/convertible.
>
> Robby
>
>
> On Thu, Oct 3, 2013 at 1:09 PM, Stephen Chang <stchang at ccs.neu.edu> 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
>> <robby at 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 <stchang at 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 <stchang at 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 <ryanc at 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
>> >> >>>> <stchang at 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
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>
>> >
>> >
>
>