[racket-dev] , en and enter! sometimes do nothing, and it's changing over releases?

From: Ray Racine (ray.racine at gmail.com)
Date: Sat Feb 9 22:40:55 EST 2013

So apropos to
http://blog.racket-lang.org/2009/03/drscheme-repl-isnt-lisp.html one "fix"
to the enter! bug is to keep it as simple as possible and as Robby hinted,
fresh load the module into a new namespace on every enter.

I've done some minimal testing and so far things appear to work.

 - No custom loader which attempts to minimize module reloading as
currently being done in enter.rkt.  Instead use the existing CM logic
within the Racket's default  behavior.
 - enter.rkt is stable over internal changes as no tricks are being played
to "smart" incremental load.
 - Reloading Typed Racket modules now works by a simple require/typed on
 - Emulates DrRacket behavior.

Disadvantage, when (re)entering a module, it is from scratch, hence,
slower.  But I've been re-entering slightly modified TR module in some of
my personal code that has a pretty healthy typed-racket module dependency
graph and with Racket's default CM behavior it's about a 3 sec load.

The only issue with this approach is on support for re-entering/entering a
different module.   Currently 'enter!' loads the module and then
extends/injects into the namespace racket/enter.  Obviously this it to
allow one to enter! another module from within the currently entered
module.  In plain ol' Racket no problem.

However if the module I'm entering is a typed/racket module then the
injected do-enter! method is untyped and fails when trying to (re)enter
another module.  By creating simple typed-enter.rkt which require/typed
do-enter! and then exports it everything works.

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.

How do I do that?



On Thu, Feb 7, 2013 at 9:15 AM, Greg Hendershott
<greghendershott at gmail.com>wrote:

> Once upon a time, ~5.3, the XREPL ,en command would always reload a
> file provided the timestamp changed.
> As a result, I could do something _roughly_ like DrRacket F5 in Emacs:
> Touch the file and ,en it.  The whole file would be evaluated, and I'd
> have a REPL where I could explore/tweak.
> But somewhere around ~5.3.1, ,en stopped doing this reliably.
> Sometimes it would just do nothing, even if the file timestamp had
> changed (and even if I made some change to the contents, just in case
> it was doing a checksum or whatever).
> I thought to try using enter!. And that worked consistently.
> But somewhere around ~5.3.2, enter! has stopped behaving consistently.
> Does anyone have any idea would could be going on??
> More info/comments:
> - I normally use XREPL. (require xrepl) is the _only_ thing in my racketrc.
> - The above issue happens with or without XREPL. (I tried again today
> to confirm.)
> - Although I love the idea of Geiser, I've had it also sometimes not
> reevaluate (similar issue). Anyway sometimes I just want to strip
> things down to be simpler; lately I'm in such a phase where I haven't
> been using it. I might or could use it again someday.
> - A (related?) issue is that sometimes the first invocation of enter!
> gives an error like this:
>   > (enter! "client.rkt")
>   module->namespace: module not instantiated in the current namespace
>     name:
> #<resolved-module-path:"/Users/greg/src/scheme/collects/lob/example/client.rkt">
>     context...:
>      /Users/greg/src/plt/racket/collects/racket/enter.rkt:33:0: do-enter!
>      /Users/greg/src/plt/racket/collects/racket/private/misc.rkt:87:7
> But then a second invocation works fine. i.e. Need to do it twice in a row.
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130209/4eaf9c1b/attachment.html>

Posted on the dev mailing list.