[plt-dev] Re: planet compilation not happening for recursive requires

Thanks, Jacob. I can't see any flaw in the reasoning there and it does
seem like the most sensible way to break the dependency is right where
you've done it, namely that step 3. should not be in the cycle, but
off in its own world.

Assuming I've got that right, then the problem seems to be that there
is some part of CM that is being shared in that new namespace from the
old (which is what leads to the message "skipping: C:\...\info.ss
orig-registry #<module-registry> current-registry #<module-registry>"
-- that message, translated to English, says "the namespace that was
active at the time CM was instantiated is not the same namespace as is
currently active, there fore, I'm not going to compile this file".

Robby

On Thu, Feb 12, 2009 at 11:07 AM, Jacob Matthews <jacobm at cs.uchicago.edu> wrote:
> On Thu, Feb 12, 2009 at 5:05 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>
>> I believe that the first problem is traceable to resolver.ss, where a
>> new namespace is created before setup plt is called, with this funny
>> comment:
>>
>>           ;; oh man is this a bad hack!
>>           (parameterize ([current-namespace (make-namespace)])
>>             (let ([ipp (dynamic-require 'setup/plt-single-installer
>>                                         'install-planet-package)])
>>               (ipp path the-dir (list owner (pkg-spec-name pkg)
>>                                       extra-path maj min))))))
>>
>
> Yeah, this has been in planet since the beginning, and it's always
> bothered me. Unfortunately I never figured out how to get rid of it.
> In fact, IIRC, you're actually the person who suggested I do this when
> I discovered the problem for which it's the solution :) Last time it
> cropped up was in a thread from October 2007 called "can't install
> typed-scheme 2.0 due to namespace-attach-module error". I wrote:
>
> ;; ---
>
> I vaguely remember writing the code in question, which is:
>
>  ;; oh man is this a bad hack!
>  (parameterize ((current-namespace (make-namespace)))
>   (let ([ipp (dynamic-require '(lib "plt-single-installer.ss"
> "setup") 'install-planet-package)])
>     (ipp path the-dir (list owner (pkg-spec-name pkg) extra-path maj min))))
>
> This is used to compile the package, and (IIRC) has existed like this
> since the first version of planet. I believe the point of doing this
> strange and terrible thing was to allow what would otherwise be a
> cyclic module loading dependency, and sure enough if I change this to
> a normal old require I get an error message when I attempt to run
> setup-plt:
>
> dhcp-164-32:~/tmp/web-root/servlets/speeddating jacobm$ setup-plt
> setup-plt: bootstrapping from source...
> standard-module-name-resolver: cycle in loading at
> #<path:/Users/jacobm/svn/plt/collects/mzlib/cm.ss>:
> (#<path:/Users/jacobm/svn/plt/collects/mzlib/cm.ss>
> #<path:/Users/jacobm/svn/plt/collects/syntax/modresolve.ss>
> #<path:/Users/jacobm/svn/plt/collects/planet/resolver.ss>
> #<path:/Users/jacobm/svn/plt/collects/setup/plt-single-installer.ss>
> #<path:/Users/...
>
>  === context ===
> /Users/jacobm/svn/plt/collects/setup/setup.ss:59:20: loop
>
>
> Digging a bit, it appears that the cycle is real as opposed to one
> caused by unnecessary grouping of procedures. It goes like this:
> 1. The compilation manager needs to turn require-lines into paths.
> 2. The function that turns require-lines into paths (that's the
> modresolve thing) needs to resolve planet package require specs to
> filenames.
> 3. The planet resolver needs to be able to set up a package in the
> course of its resolution process, because that's the entire point of
> planet existing.
> 4. The setup procedure needs to use the compilation manager to compile packages.
>
> I believe the above hack was intended to allow me to create this cycle.
>
> ;; ---
>
> -jacob
>