geiser-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Geiser-users] Racket-git breaks requiring racket/slideshow


From: Jose A. Ortega Ruiz
Subject: Re: [Geiser-users] Racket-git breaks requiring racket/slideshow
Date: Fri, 31 Aug 2012 02:52:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Hi Michael,

On Wed, Aug 29 2012, Michael Wilber wrote:

> Hey, geiser users!
>
> So in racket from git and latest geiser from git, when I require
> slideshow/pict from geiser (or indirectly by enter!-ing a file that
> requires slideshow/pict), it fails:
>
> Welcome to Racket v5.3.0.14.
> racket@> (require slideshow/pict)
> define-values: assignment disallowed;
>  cannot re-define a constant
>   constant: invoke-unit/core
>   in module: "/home/michael/racket/collects/racket/unit.rkt"
>   errortrace...:
>    
> /home/michael/.emacs.d/vendor/geiser/scheme/racket/geiser/enter.rkt:146:10: 
> (eval code)
> racket@>
>
> This also happens to geiser 0.1.4 which makes me think it's unrelated to
> the recent REPL image changes.

Yes, i'm pretty sure it's totally unrelated.

> It looks like Racket commit 403aaac is what broke things (checking this
> out and installing racket fails, checking out HEAD^ and trying again
> lets me import slideshow/pict without issues). This doesn't happen with
> v5.3.
>
> Also, commenting out all the parameterizations for
> current-load/use-compiled from scheme/racket/geiser/enter.rkt also makes
> (require slideshow/pict) work correctly.

Do you mean the calls to parameterize on lines 91 and 111? (specially,
that one needs removign the first is a bit surprising), or am i
misunderstanding?

> A general question: Why does geiser use its own
> current-load/use-compiled handler instead of using Racket's enter!
> functionality? There must be some reason to have that, but it's hard
> to tell since the two copies of enter.rkt have diverged so much.

I wanted to avoid loading modules unless explicitly requested by the
user.

With the default current-load/use-compiled, if you ask for the namespace
of a module that is not loaded, that will cause the module (and all its
dependencies) to be loaded...

That would mean that when one opens a new racket file with autodoc
enabled (or try a completion, or whatever), the module would get
automatically loaded without the user's consent.

I didn't find a way of asking Racket for a module's namespace without
causing it to be loaded automatically.  Providing my own
current-load/use-compiled in conjunction with the inhibit-eval parameter
you see there solved that problem.

Perhaps we could just call racket's current-load/use-compiled in my own
version, after using inhibit-eval... i also wanted access to the cache
of loaded modules that enter! maintains without duplicating it (that had
to do somehow with find-module!, which provides another functionality i
wanted: locating a module without having to load it), but probably
maintaining an independent geiser cache is perfectly okay.

Another thing i accomplished with all this was hiding Racket's enter!
from the user, so that Geiser can know at all times what's the current
namespace without having to poll Racket. But, againt, hat could probably
be also implemented by making Geiser's enter! call Racket's, shadowing
it as needed.

I'll try to take a closer look, unless you beat me at it! ;-)

Cheers,
jao
-- 
Love: a temporary insanity, curable by marriage.
 -Ambrose Bierce, author and editor (1842-1914)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]