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

2013-02-11 Thread Robby Findler
IMO, DrRacket-like functionality would be nice to have in an Emacs setting
and probably using a sandbox is the way to get it. You'd want to not use
the default settings for the sandbox, tho, but give more permissions for
file access (and probably a few other things).

Robby


On Mon, Feb 11, 2013 at 1:07 AM, Eli Barzilay e...@barzilay.org wrote:

 9 hours ago, Greg Hendershott wrote:
  I'm inclined to add a new command to XREPL that takes that approach,
  to experiment. I was spelunking in DrRacket source but I'm slow to
  isolate that from what else is going on. It sounds like you
  understand it; is there a code sample you could share?

 I'm not sure what exactly you're after, but you can get most of that
 using a ,switch command to create a new namespace, then using it with
 a ! flag to reset it.

 --
   ((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

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2013-02-10 Thread Robby Findler
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?

2013-02-10 Thread Asumu Takikawa
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?

2013-02-10 Thread Ray Racine
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?

2013-02-10 Thread Eli Barzilay
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?

2013-02-10 Thread Eli Barzilay
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


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

2013-02-09 Thread Michael Wilber
Is this related to the enter bug?

$ racket
Welcome to Racket v5.3.2.3.
 (enter! slideshow/pict)
define-values: assignment disallowed;
 cannot re-define a constant
  constant: invoke-unit/core
  in module: /home/michael/local/racket/collects/racket/unit.rkt
  context...:
   /home/michael/local/racket/collects/racket/unit.rkt: [running body]
   standard-module-name-resolver
   /home/michael/local/racket/collects/mzlib/unit.rkt: [traversing imports]
   /home/michael/local/racket/collects/texpict/mrpict.rkt: [traversing imports]
   /home/michael/local/racket/collects/slideshow/pict.rkt: [traversing imports]
   /home/michael/local/racket/collects/racket/enter.rkt:51:0: enter-require
   /home/michael/local/racket/collects/racket/enter.rkt:33:0: do-enter!

It, and similar issues, bit geiser too. For a time, Geiser would give
similar problems even when simply evaluating (require slideshow/pict):
http://bugs.racket-lang.org/query/?cmd=view%20audit-traildatabase=defaultpr=13096

I'm not sure how, but Geiser recently implemented some workaround in one
of their recently released versions:

M-x run-racket

Welcome to Racket v5.3.2.3.
racket@ ,enter slideshow/pict
racket@slideshow/pict (circle 10)
(a circle appears in the REPL)


Ray Racine ray.rac...@gmail.com writes:
 I've been seeing the same behavior.  I think something got broke in
 racket/enter enter!.   I don't think it is a Geiser, XRepl issue other
 then both I believe leverage the racket/enter module.  Bit of a pain in the
 arse bug, nice if someone could look in to it.

 Thanks,

 Ray


 On Thu, Feb 7, 2013 at 9:15 AM, Greg Hendershott
 greghendersh...@gmail.comwrote:

 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

 _
   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?

2013-02-09 Thread Ray Racine
Ahh to enable log/trace in module.c there is a conditional define for
LOG_ATTACH at the top of the source file.


On Sat, Feb 9, 2013 at 3:15 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote:

 Typed Racket generates submodules, so that may cause this even if you
 don't write them explicitly.

 Sam

 On Sat, Feb 9, 2013 at 3:12 PM, Ray Racine ray.rac...@gmail.com wrote:
  Yes  PR 13096 is the same error message that I'm getting.  However, I'm
  seeing this in my TR code.  I don't have any submodules in my code
 however,
  as TR submodules don't work,  so I think the problem is more generic than
  submodules in enter!.
 
 
  On Sat, Feb 9, 2013 at 2:42 PM, Asumu Takikawa as...@ccs.neu.edu
 wrote:
 
  On 2013-02-09 12:30:29 -0700, Michael Wilber wrote:
   $ racket
   Welcome to Racket v5.3.2.3.
(enter! slideshow/pict)
   define-values: assignment disallowed;
cannot re-define a constant
 constant: invoke-unit/core
 in module: /home/michael/local/racket/collects/racket/unit.rkt
 context...:
  /home/michael/local/racket/collects/racket/unit.rkt: [running body]
  standard-module-name-resolver
  /home/michael/local/racket/collects/mzlib/unit.rkt: [traversing
   imports]
  /home/michael/local/racket/collects/texpict/mrpict.rkt: [traversing
   imports]
  /home/michael/local/racket/collects/slideshow/pict.rkt: [traversing
   imports]
  /home/michael/local/racket/collects/racket/enter.rkt:51:0:
   enter-require
  /home/michael/local/racket/collects/racket/enter.rkt:33:0:
 do-enter!
 
  I believe this one is actually related to PR 13096:
 
 
 http://bugs.racket-lang.org/query/?debug=database=defaultcmd=view+audit-trailcmd=viewpr=13096
 
  (that bug is due to an interaction between submodules and enter!)
 
  Cheers,
  Asumu
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 
 
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev