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