Re: [racket-dev] patch for make-base-eval
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 make-base-eval.patch Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] patch for make-base-eval
Do you need to do the same thing with file/convertible? Robby On Thu, Oct 3, 2013 at 1:09 PM, Stephen Chang stch...@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 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
Re: [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 stch...@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 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
Re: [racket-dev] patch for make-base-eval
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
[racket-dev] patch for make-base-eval
Can I push the attached (1-line) patch? I don't have a good grasp of namespaces so I would like someone to review it first. Right now, make-base-eval tries to attach racket/pretty to the namespace regardless of whether it's already there, which sometimes results in an exception (for example if the #lang given to make-base-eval is racket). The patch simply first checks if the desired identifier is already there. fix-make-base-eval-pretty.patch Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] patch for make-base-eval
On 10/02/2013 03:19 PM, Stephen Chang wrote: Can I push the attached (1-line) patch? I don't have a good grasp of namespaces so I would like someone to review it first. Right now, make-base-eval tries to attach racket/pretty to the namespace regardless of whether it's already there, which sometimes results in an exception (for example if the #lang given to make-base-eval is racket). The patch simply first checks if the desired identifier is already there. Whether that identifier exists in the namespace has nothing to do with whether racket/pretty can be attached. 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
Re: [racket-dev] patch for make-base-eval
The last two sound better than the others to me, FWIW. Robby On Wed, Oct 2, 2013 at 2:37 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: On 10/02/2013 03:19 PM, Stephen Chang wrote: Can I push the attached (1-line) patch? I don't have a good grasp of namespaces so I would like someone to review it first. Right now, make-base-eval tries to attach racket/pretty to the namespace regardless of whether it's already there, which sometimes results in an exception (for example if the #lang given to make-base-eval is racket). The patch simply first checks if the desired identifier is already there. Whether that identifier exists in the namespace has nothing to do with whether racket/pretty can be attached. 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 http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] patch for make-base-eval
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
Re: [racket-dev] patch for make-base-eval
Yes. Also, it's not enough to check that 'racket/pretty' (or really, the name 'racket/pretty' resolves to) isn't declared in the target namespace; you must also check any module it (transitively) requires is either undeclared or was attached from the same namespace you want to attach racket/pretty from. Ryan On 10/02/2013 03:50 PM, Robby Findler 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. Robby On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang stch...@ccs.neu.edu mailto: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
Re: [racket-dev] patch for make-base-eval
Right, exactly. Which is why Ryan's earlier suggestions are better: You can avoid all this mess. Robby On Wed, Oct 2, 2013 at 2:59 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: Yes. Also, it's not enough to check that 'racket/pretty' (or really, the name 'racket/pretty' resolves to) isn't declared in the target namespace; you must also check any module it (transitively) requires is either undeclared or was attached from the same namespace you want to attach racket/pretty from. Ryan On 10/02/2013 03:50 PM, Robby Findler 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. Robby On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang stch...@ccs.neu.edu mailto: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 http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] patch for make-base-eval
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
Re: [racket-dev] patch for make-base-eval
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
Re: [racket-dev] patch for make-base-eval
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
Re: [racket-dev] patch for make-base-eval
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
