Re: [racket-dev] , en and enter! sometimes do nothing, and it's changing over releases?
Well, there is a fundamental question about this strategy, namely *which* code do you reevaluate when a change is made? It isn't easy to determine that in general. Robby On Sun, Feb 10, 2013 at 8:33 AM, Ray Racine ray.rac...@gmail.com wrote: That aligns with the Geiser comment. I'd gotten to the point where I was questioning the utility of having a custom enter-load/use-compiled as opposed create a base namespace, dynamic-require, module-namespace, current-namespace switch. Simpler, leverages existing functionality, far more robust to load changes in the api down the road, and down the road compilation manager improvements. Even before the current breakage, when using Geiser at fairly frequent intervals I had to kill the REPL and restart as the incremental enter/load seemed to get confused. That particular issue could have been in Geiser however and not necessarily in racket/enter. On Sun, Feb 10, 2013 at 7:57 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Sorry that it has taken me so long to join in and that I overlooked the PR way back in September. I think the problem is that `enter-load/use-compiled' doesn't follow the protocol for a load handler, which changed slightly for submodules. Specifically, if the second argument to the load handler is a list that starts with #f, the load handler isn't supposed to try to load code from source. I've pushed a repair that works for the example in PR 13096 and for `(enter! slideshow/pict)'. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] , en and enter! sometimes do nothing, and it's changing over releases?
On 2013-02-10 05:57:52 -0700, Matthew Flatt wrote: Sorry that it has taken me so long to join in and that I overlooked the PR way back in September. Thanks for the fix! On a related note, should any of the following interactions work? $ racket Welcome to Racket v5.3.3.1. - (enter! (submod scheme/unit compat)) ; module-namespace: unknown module in the current namespace ; name: #resolved-module-path:(submod ; /home/asumu/plt/racket-git/collects/scheme/unit.rkt compat) ; [,bt for context] - (module foo racket (define x 3) (module bar racket (define x 5))) - (enter! 'foo) 'foo (enter! 'bar) ; module-namespace: unknown module in the current namespace ; name: #resolved-module-path:'bar ; [,bt for context] 'foo (enter! (submod . bar)) ; standard-module-name-resolver: no base path for relative submodule path: ; (submod . bar) [,bt for context] Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] , en and enter! sometimes do nothing, and it's changing over releases?
Yes, the Geiser server is meta to the target namespace and evals the sent form in target namespace. racket/enter.rkt does inject ;; Injecting racket/enter into the namespace to allow entering another module (unless (memq '#:dont-re-require-enter flags) (namespace-require 'racket/enter))) And I agree tooling such as Geiser, xrepl should be meta to entered namespace(s). On Sun, Feb 10, 2013 at 1:28 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Ray Racine wrote: So the goal is to have entering a module inject the proper typed or untyped version of do-enter! by doing a namespace-require on either enter.rkt or typed-enter.rkt. To do that I need to query the current-namespace as to whether the namespace language is racket or typed/racket, a namespace-language procedure. That won't be a general-enough hack: what happens with other languages? But more generally there is no way to do that that works everywhere, since some languages would want to stay very restricted and not allow any new bindings. I think that the xrepl approach for this (and likely geiser's) works well: you use `enter!' at the meta level, which means that there is no need for any injections. So it looks to me better if things stay as they are, with direct uses of `enter!' being somewhat limited as they are now, and using a proper meta tool when needed. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] , en and enter! sometimes do nothing, and it's changing over releases?
An hour and a half ago, Asumu Takikawa wrote: On 2013-02-10 05:57:52 -0700, Matthew Flatt wrote: Sorry that it has taken me so long to join in and that I overlooked the PR way back in September. Thanks for the fix! On a related note, should any of the following interactions work? $ racket Welcome to Racket v5.3.3.1. - (enter! (submod scheme/unit compat)) ; module-namespace: unknown module in the current namespace There is no such submodule, but (enter! (submod racket/unit compat)) does work, and incidentally, exposes the fact that xrepl doesn't show a submodule path in its prompt, yet. (I'm not sure how it would be shown, btw, using the submod form is very verbose for a prompt.) - (module foo racket (define x 3) (module bar racket (define x 5))) - (enter! 'foo) 'foo (enter! 'bar) ; module-namespace: unknown module in the current namespace ; name: #resolved-module-path:'bar ; [,bt for context] 'foo (enter! (submod . bar)) ; standard-module-name-resolver: no base path for relative submodule path: ; (submod . bar) [,bt for context] I'm not sure about these, but IIRC, there was a similar question about doing the same in drr. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] , en and enter! sometimes do nothing, and it's changing over releases?
An hour ago, Ray Racine wrote: Yes, the Geiser server is meta to the target namespace and evals the sent form in target namespace. racket/enter.rkt does inject ;; Injecting racket/enter into the namespace to allow entering another module (unless (memq '#:dont-re-require-enter flags) (namespace-require 'racket/enter))) And I agree tooling such as Geiser, xrepl should be meta to entered namespace (s). Right -- the flag is something that I added for xrepl to make it possible to avoid the injection. I think that geiser does that too. (And otherwise, it should.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
