[plt-dev] Re: Generated files and co-existing copies of DrScheme

On Nov 20, Carl Eastlund wrote:
> 
> I would be happy to try to simplify this to a single environment
> variable, but I think that means adding PLTADDONDIR and letting it
> replace PLTCOLLECTS and PLTPLANETDIR (not to mention the purely
> hypothetical PLTSCRIBBLEDIR).  I'm not sure whether breaking
> compatibility for anyone who uses PLTCOLLECTS or PLTPLANETDIR is
> worth it for the amount of simplification.

I don't think that it's possible to make a single variable as powerful
as all three.  In any case, and as is usually the case with
environment variables, changing things is very painful, since these
things are stuck in all kinds of places.


> >   So, I think that a command-line argument would be better.  It
> >   might even make sense to use `+U'.
> 
> Then I have to type it every time I run the command, though.

Why?  If you know how to use them, then you should be able to use a
script.


> I want something I can, for the most part, set and forget.  And I
> need the command that runs 'mzscheme' to be 'mzscheme', for instance
> (not 'mzscheme-4.2.2') so that scripts that call 'mzscheme' always
> get the one that I have chosen as recently built and fully
> functional.

I don't get this.  Translating an environment variable into a
command-line argument is trivial.  In this case, if there is a `+U'
and no environment variable, I can still get it with:

  #!/bin/sh
  if [ "x$PLTADDONDIR" = "" ]; then exec /path/to/plt/bin/mzscheme "$@"
  else exec /path/to/plt/bin/mzscheme +S "$PLTADDONDIR" "$@"
  fi

Or, since you want the addons to be in the PLT tree, then here's a
version that uses a PLTHOME variable:

  #!/bin/sh
  exec "$PLTHOME/plt/bin/mzscheme" +S "$PLTHOME/addons" "$@"

Now you just need to set PLTHOME and get everything -- and you don't
even need to specify the path to the right mzscheme to run.  You can
even call it `mz', making it even easier to start.

[FWIW, this is exactly how I run mzscheme -- I have a script that
chooses a binary based on PLTHOME, and I have a convenient shell alias
to toggle between the released version and the nightly build, and in
the case of the released version in my home directory I have this
script choose the right binary because I'm using a single directory
with binaries for all platforms.]

Look, the story with environment variables vs command-line flags is
esentially the same one as with keyword arguments vs parameters.
Parameters are more convenient in ways that make them lead to
potentially more mess, like forgetting that the code goes through some
dynamic context that changes it.  In your patch for example, you fetch
the environment variable dynamically, which means that things can get
interesting with code that uses `putenv'.  Fixing that wouldn't be
hard, and it would get a bit closer to just a command-line flag.

Another problem with environment variables is that they get passed on
in strange ways.  I've seen people hopelessly confused on Windows,
since changing the environment is done in an awkward way.  I've also
seen cases where people had scripts that would set the variable
somewhere on the way, in a place that they didn't see, leading to very
confusing bugs where things are just not right no matter what you do.
It's like the usual problem with parameters being dynamic, with the
added fun bit of doing so cross-language (from shells to the process),
and/or weird places where you get to set your environment variables.

This is why I'm saying that personally I like them -- I work in a way
that makes them very obvious (a traditional shell, basically).  But
that's not true for probably somewhere around 95% of the users.  (You
can see that in one of the many emails about PLTCOLLECTS -- it uses
the colon convention which just makes a lot of sense, and is used in
several places -- so I thought it would be much more known than it
turns out to be (=> roughly zero people knew about it).)


> I run into this problem every single day when I update my PLT trunk
> checkout.  I either have to spend the duration of a complete build
> (including all documentation, installed planet packages, and recovery
> from any build errors)

That goes back to the nightly build -- why not use it?  It *is*
happenning every day, and the results are packaged in about 200
different ways.  (Yes, you still need planet, in case the version or
some interface changed, but most of the work is done if you use the
nightly build.)

> unable to run any PLT Scheme code of any variety -- essentially
> unable to work -- [...]

Or the least you can do if you really don't want to use the nightly
build is run it during the night in a cron job.


On Nov 20, Carl Eastlund wrote:
> On Fri, Nov 20, 2009 at 9:05 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
> >
> > Not to be contrarian, but pre-relase docs are probably close enough
> > usually, right?
> 
> Unfortunately, the new docs invariably lack planet packages (both
> downloaded and development linked).  I spend a lot of time
> programming with planet code, and looking up documentation for it,
> and without up-to-date local documentation I wind up having to go to
> planet.plt-scheme.org and lookup documentation by browsing specific
> versions of each package, without the benefit of Help Desk's search
> page.

But that should be a much faster process to compile just these if you
use the nightly build.  Or in almost all cases you should be fine with
the same build when the PLT version didn't change.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!