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
