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

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