PLaneT and automatic compilation bad interaction (was Re: [plt-dev] Re: problem with optimistic compilation)

Done in SVN (v4.2.1.7). I've adjusted `planet/resolver' to accept an
original-parameterization argument that the default module name
resolver provides. But `planet-resolve' still needs to use it somehow.

At Wed, 19 Aug 2009 09:28:09 -0500, Robby Findler wrote:
> Oh yes. That makes a lot of sense to me (I was worried about the  
> security ramifications of this direction but that suggestion helps  
> with that (by not adding any new problems....).)
> 
> Robby
> 
> On Aug 19, 2009, at 8:43 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> 
> > At Wed, 19 Aug 2009 08:28:58 -0500, Robby Findler wrote:
> >> Is there some lower-level module of mzscheme's that could be shared
> >> (say, #%kernel or something) and then have scheme/base be
> >> re-instantiated in the new namespace that planet creates?
> >
> > No, none that would help for this problem.
> >
> > The standard module name resolver saves the original namespace for
> > loading the Planet resolver. Maybe the solution is to save more of the
> > initial configuration (i.e., parameter settings) when loading the
> > resolver and to send that configuration to the Planet resolver. Then,
> > Planet can use that configuration for starting an installation.
> >
> >
> >> On Wed, Aug 19, 2009 at 8:12 AM, Matthew Flatt<mflatt at cs.utah.edu>  
> >> wrote:
> >>> At Tue, 18 Aug 2009 23:31:17 -0500, Robby Findler wrote:
> >>>> At this point, it seemed to me that it would be hopeless to try  
> >>>> to get
> >>>> the original values of the scheme/base parameters (specifically
> >>>> current-compile),
> >>>
> >>> I think we should work on making this possible. A program might  
> >>> set all
> >>> sorts of parameters before (dynamically) requiring a Planet path.  
> >>> Those
> >>> settings should apply while loading the package's modules after it's
> >>> installed, but they shouldn't affect installation of the package.
> >>> Installation should always act the same --- as if a completely new
> >>> OS-level process was started to install the package.
> >>>
> >>> I don't immediately know how to make that work (without actually
> >>> starting a process), but that seems like the right path.
> >>>
> >>>