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 <mfl...@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<mfl...@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. > >>> > >>> _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
