[plt-dev] Re: Generated files and co-existing copies of DrScheme
On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund wrote: > That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR > to control placement of Planet and Scribble generated files, (2) pick > a conventional place in the PLT tree for users to store it who can and > wish to do so, and (3) longer term, think about a way to fit > development link code into this story. So -- what do the rest of you > developer folks think? I did #1 and #2 on a branch (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir). I updated the C implementation of (find-system-path 'addon-dir) to first check the PLTADDONDIR environment variable; Planet and Scribble both use the addon-dir, so it seems to be the right point of control. I also updated the Scribble documentation for find-system-path, and added an svn:ignore property for $PLTHOME/add-on as a canonical place for in-tree add-on directories. I have built the PLT tree with PLTADDONDIR set (which put scribble files in the custom add-on directory), run `planet show' (which constructed and queried a planet cache in the custom add-on directory), and run $PLTHOME/collects/tests/run-automated-tests.ss (which succeeded). All of this was on Mac OS X. Does anyone object if I move this to the trunk? Is there anything I need to do first (e.g. testing on other platforms)? I have attached the relevant patch for the trunk if anyone wants to try this change without grabbing the whole branch. --Carl plt+addon-dir.diff Description: Binary data _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
[plt-dev] Re: Generated files and co-existing copies of DrScheme
On Nov 17, Carl Eastlund wrote: > On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund wrote: > > That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR > > to control placement of Planet and Scribble generated files, (2) pick > > a conventional place in the PLT tree for users to store it who can and > > wish to do so, and (3) longer term, think about a way to fit > > development link code into this story. So -- what do the rest of you > > developer folks think? > > I did #1 and #2 on a branch > (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir). I > updated the C implementation of (find-system-path 'addon-dir) to > first check the PLTADDONDIR environment variable; Planet and > Scribble both use the addon-dir, so it seems to be the right point > of control. I also updated the Scribble documentation for > find-system-path, and added an svn:ignore property for > $PLTHOME/add-on as a canonical place for in-tree add-on directories. I see several issues with this: 1. As much as I personally like environment variables, it seems that they're generally confusing. Doing this change as another variable means that now the exact collection search is determined by: - $PLTCOLLECTS - Uses of `-S', `-X', and `-U' - $PLTADDONDIR - Any dynamic changes to the search path The first is a good source of complaints and confusion, and adding another environment variable seems like it will make things worse. (It doesn't help that Windows and even OSX users find it difficult to control them.) So, I think that a command-line argument would be better. It might even make sense to use `+U'. 2. There is a potential problem with code that uses `find-system-path' with 'addon-dir where 'pref-dir should have been used. But at least on my system I don't see anything that would break. 3. IIUC, the only problem that this solves is using several different installations with the same version number, is this true? Is that problem *so* common? If so, then maybe have instead a way to use your own additional suffix to the version part that gets used in ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? Or maybe go the other way -- make the default addon-dir include the version (so on linux it becomes ~/.plt-scheme/), and have no version directory for the local collects (so they end up in exactly the same place), planet can drop the version directory too (and the redundantly outdated "300" part). Then it makes more sense to have a command line flag or environment variable move everything, without getting a second level of version-dependant directories. (The only problem that I see here is that the planet "cache" is less of a cache than it is now.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
[plt-dev] Re: Generated files and co-existing copies of DrScheme
On Tue, Nov 17, 2009 at 4:55 PM, Carl Eastlund wrote: > On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund wrote: >> That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR >> to control placement of Planet and Scribble generated files, (2) pick >> a conventional place in the PLT tree for users to store it who can and >> wish to do so, and (3) longer term, think about a way to fit >> development link code into this story. So -- what do the rest of you >> developer folks think? > > I did #1 and #2 on a branch > (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir). I updated > the C implementation of (find-system-path 'addon-dir) to first check > the PLTADDONDIR environment variable; Planet and Scribble both use the > addon-dir, so it seems to be the right point of control. I also > updated the Scribble documentation for find-system-path, and added an > svn:ignore property for $PLTHOME/add-on as a canonical place for > in-tree add-on directories. > > I have built the PLT tree with PLTADDONDIR set (which put scribble > files in the custom add-on directory), run `planet show' (which > constructed and queried a planet cache in the custom add-on > directory), and run $PLTHOME/collects/tests/run-automated-tests.ss > (which succeeded). All of this was on Mac OS X. > > Does anyone object if I move this to the trunk? Is there anything I > need to do first (e.g. testing on other platforms)? I have attached > the relevant patch for the trunk if anyone wants to try this change > without grabbing the whole branch. An update -- Matthew has agreed to take over this code and to (eventually) add a corresponding command line option to control the "addon-dir". I have repeated the test steps above with the latest changes from the trunk, and merged my changes onto the trunk. --Carl _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
[plt-dev] Re: Generated files and co-existing copies of DrScheme
On Nov 30, Carl Eastlund wrote: > On Tue, Nov 17, 2009 at 4:55 PM, Carl Eastlund wrote: > > On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund wrote: > >> That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR > >> to control placement of Planet and Scribble generated files, (2) pick > >> a conventional place in the PLT tree for users to store it who can and > >> wish to do so, and (3) longer term, think about a way to fit > >> development link code into this story. So -- what do the rest of you > >> developer folks think? > > > > I did #1 and #2 on a branch > > (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir). I updated > > the C implementation of (find-system-path 'addon-dir) to first check > > the PLTADDONDIR environment variable; Planet and Scribble both use the > > addon-dir, so it seems to be the right point of control. I also > > updated the Scribble documentation for find-system-path, and added an > > svn:ignore property for $PLTHOME/add-on as a canonical place for > > in-tree add-on directories. > > > > I have built the PLT tree with PLTADDONDIR set (which put scribble > > files in the custom add-on directory), run `planet show' (which > > constructed and queried a planet cache in the custom add-on > > directory), and run $PLTHOME/collects/tests/run-automated-tests.ss > > (which succeeded). All of this was on Mac OS X. > > > > Does anyone object if I move this to the trunk? Is there anything I > > need to do first (e.g. testing on other platforms)? I have attached > > the relevant patch for the trunk if anyone wants to try this change > > without grabbing the whole branch. > > An update -- Matthew has agreed to take over this code and to > (eventually) add a corresponding command line option to control the > "addon-dir". I have repeated the test steps above with the latest > changes from the trunk, and merged my changes onto the trunk. I missed this, and I already undid it. I will re-commit later tonight with a command line option, and with reading the environment variable once. (Which means that your C-side commit will be split into a separate piece that will read the variable.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
The "300" in the planet cache path contains stuff that is common to all 3xx and 4.x versions (cached copies of the uninstalled .plt files... maybe that's all?). Robby On Fri, Nov 20, 2009 at 1:36 AM, Eli Barzilay wrote: > On Nov 17, Carl Eastlund wrote: >> On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund wrote: >> > That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR >> > to control placement of Planet and Scribble generated files, (2) pick >> > a conventional place in the PLT tree for users to store it who can and >> > wish to do so, and (3) longer term, think about a way to fit >> > development link code into this story. So -- what do the rest of you >> > developer folks think? >> >> I did #1 and #2 on a branch >> (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir). I >> updated the C implementation of (find-system-path 'addon-dir) to >> first check the PLTADDONDIR environment variable; Planet and >> Scribble both use the addon-dir, so it seems to be the right point >> of control. I also updated the Scribble documentation for >> find-system-path, and added an svn:ignore property for >> $PLTHOME/add-on as a canonical place for in-tree add-on directories. > > I see several issues with this: > > 1. As much as I personally like environment variables, it seems that > they're generally confusing. Doing this change as another variable > means that now the exact collection search is determined by: > - $PLTCOLLECTS > - Uses of `-S', `-X', and `-U' > - $PLTADDONDIR > - Any dynamic changes to the search path > The first is a good source of complaints and confusion, and adding > another environment variable seems like it will make things worse. > (It doesn't help that Windows and even OSX users find it difficult > to control them.) > > So, I think that a command-line argument would be better. It might > even make sense to use `+U'. > > 2. There is a potential problem with code that uses `find-system-path' > with 'addon-dir where 'pref-dir should have been used. But at > least on my system I don't see anything that would break. > > 3. IIUC, the only problem that this solves is using several different > installations with the same version number, is this true? Is that > problem *so* common? If so, then maybe have instead a way to use > your own additional suffix to the version part that gets used in > ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? > > Or maybe go the other way -- make the default addon-dir include the > version (so on linux it becomes ~/.plt-scheme/), and have > no version directory for the local collects (so they end up in > exactly the same place), planet can drop the version directory too > (and the redundantly outdated "300" part). Then it makes more > sense to have a command line flag or environment variable move > everything, without getting a second level of version-dependant > directories. (The only problem that I see here is that the planet > "cache" is less of a cache than it is now.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > _ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Fri, Nov 20, 2009 at 2:36 AM, Eli Barzilay wrote: > On Nov 17, Carl Eastlund wrote: >> On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund wrote: >> > That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR >> > to control placement of Planet and Scribble generated files, (2) pick >> > a conventional place in the PLT tree for users to store it who can and >> > wish to do so, and (3) longer term, think about a way to fit >> > development link code into this story. So -- what do the rest of you >> > developer folks think? >> >> I did #1 and #2 on a branch >> (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir). I >> updated the C implementation of (find-system-path 'addon-dir) to >> first check the PLTADDONDIR environment variable; Planet and >> Scribble both use the addon-dir, so it seems to be the right point >> of control. I also updated the Scribble documentation for >> find-system-path, and added an svn:ignore property for >> $PLTHOME/add-on as a canonical place for in-tree add-on directories. > > I see several issues with this: > > 1. As much as I personally like environment variables, it seems that > they're generally confusing. Doing this change as another variable > means that now the exact collection search is determined by: > - $PLTCOLLECTS > - Uses of `-S', `-X', and `-U' > - $PLTADDONDIR > - Any dynamic changes to the search path > The first is a good source of complaints and confusion, and adding > another environment variable seems like it will make things worse. > (It doesn't help that Windows and even OSX users find it difficult > to control them.) You forgot $PLTPLANETDIR. 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. > 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. 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. > 2. There is a potential problem with code that uses `find-system-path' > with 'addon-dir where 'pref-dir should have been used. But at > least on my system I don't see anything that would break. That sounds like a complaint about find-system-path, regardless of this environment variable. > 3. IIUC, the only problem that this solves is using several different > installations with the same version number, is this true? Is that > problem *so* common? If so, then maybe have instead a way to use > your own additional suffix to the version part that gets used in > ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? 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) unable to run any PLT Scheme code of any variety -- essentially unable to work -- or I need some way to have two PLT Scheme installations of the same version that don't "share" compiled planet code. > Or maybe go the other way -- make the default addon-dir include the > version (so on linux it becomes ~/.plt-scheme/), and have > no version directory for the local collects (so they end up in > exactly the same place), planet can drop the version directory too > (and the redundantly outdated "300" part). Then it makes more > sense to have a command line flag or environment variable move > everything, without getting a second level of version-dependant > directories. (The only problem that I see here is that the planet > "cache" is less of a cache than it is now.) Maybe we need two settings -- PLTADDONIR and PLTVERSION. The PLTADDONDIR would then be static (I'd have no need to set it more than once -- and if I don't mind the default, not at all), and have a subdirectory for each version, plus one for a shared planet cache. Then I could set PLTVERSION for separate installations, which would override the version string *only* for the purposes of choosing a subdirectory of PLTADDONDIR. The directory tree would look like this: $PLTADDONDIR/ planet-cache/ 4.2.2/ collects/ planet/ scribblings/ 4.2.2.1/ collects/ planet/ scribblings/ ...and so forth... This would be a significant change to the way things are layed out, though. My current patch doesn't break any existing setup or change any existing directory structure. Furthermore it is already written. --Carl ___
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
Pardon my pre-morning-coffee thinking. There were a few mistakes here: On Fri, Nov 20, 2009 at 8:35 AM, Carl Eastlund wrote: >> 3. IIUC, the only problem that this solves is using several different >> installations with the same version number, is this true? Is that >> problem *so* common? If so, then maybe have instead a way to use >> your own additional suffix to the version part that gets used in >> ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? > > 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) unable to run any PLT Scheme code of any > variety -- essentially unable to work -- or I need some way to have > two PLT Scheme installations of the same version that don't "share" > compiled planet code. The above describes the problem I run into in general, much of which is alleviated by PLTPLANETDIR. I still have the problem of clashing docs, so I can't run Help Desk in the interim and I'm stuck with the newest version afterword. However I am able to run mzscheme, drscheme, planet, setup-plt, etc. >> Or maybe go the other way -- make the default addon-dir include the >> version (so on linux it becomes ~/.plt-scheme/), and have >> no version directory for the local collects (so they end up in >> exactly the same place), planet can drop the version directory too >> (and the redundantly outdated "300" part). Then it makes more >> sense to have a command line flag or environment variable move >> everything, without getting a second level of version-dependant >> directories. (The only problem that I see here is that the planet >> "cache" is less of a cache than it is now.) > > Maybe we need two settings -- PLTADDONIR and PLTVERSION. The > PLTADDONDIR would then be static (I'd have no need to set it more than > once -- and if I don't mind the default, not at all), and have a > subdirectory for each version, plus one for a shared planet cache. > Then I could set PLTVERSION for separate installations, which would > override the version string *only* for the purposes of choosing a > subdirectory of PLTADDONDIR. The directory tree would look like this: > > $PLTADDONDIR/ > planet-cache/ > 4.2.2/ > collects/ > planet/ > scribblings/ > 4.2.2.1/ > collects/ > planet/ > scribblings/ > ...and so forth... Moving PLTCOLLECTS here is odd because that's usually a user directory, much like planet development links. So I'm not sure if the collects/ subdirectory should be there. And perhaps the preferences file should be there (at the same level as planet-cache). Since this part is all hypothetical, the structure is up for debate anyway. --Carl _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Fri, Nov 20, 2009 at 7:50 AM, Carl Eastlund wrote: > Pardon my pre-morning-coffee thinking. There were a few mistakes here: > > On Fri, Nov 20, 2009 at 8:35 AM, Carl Eastlund wrote: >>> 3. IIUC, the only problem that this solves is using several different >>> installations with the same version number, is this true? Is that >>> problem *so* common? If so, then maybe have instead a way to use >>> your own additional suffix to the version part that gets used in >>> ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? >> >> 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) unable to run any PLT Scheme code of any >> variety -- essentially unable to work -- or I need some way to have >> two PLT Scheme installations of the same version that don't "share" >> compiled planet code. > > The above describes the problem I run into in general, much of which > is alleviated by PLTPLANETDIR. I still have the problem of clashing > docs, so I can't run Help Desk in the interim and I'm stuck with the > newest version afterword. However I am able to run mzscheme, > drscheme, planet, setup-plt, etc. Not to be contrarian, but pre-relase docs are probably close enough usually, right? Robby _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Fri, Nov 20, 2009 at 9:05 AM, Robby Findler wrote: > On Fri, Nov 20, 2009 at 7:50 AM, Carl Eastlund wrote: >> Pardon my pre-morning-coffee thinking. There were a few mistakes here: >> >> On Fri, Nov 20, 2009 at 8:35 AM, Carl Eastlund wrote: 3. IIUC, the only problem that this solves is using several different installations with the same version number, is this true? Is that problem *so* common? If so, then maybe have instead a way to use your own additional suffix to the version part that gets used in ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? >>> >>> 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) unable to run any PLT Scheme code of any >>> variety -- essentially unable to work -- or I need some way to have >>> two PLT Scheme installations of the same version that don't "share" >>> compiled planet code. >> >> The above describes the problem I run into in general, much of which >> is alleviated by PLTPLANETDIR. I still have the problem of clashing >> docs, so I can't run Help Desk in the interim and I'm stuck with the >> newest version afterword. However I am able to run mzscheme, >> drscheme, planet, setup-plt, etc. > > 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. --Carl _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [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 > 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 u
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Fri, Nov 20, 2009 at 3:51 PM, Eli Barzilay wrote: > 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 >> wrote: >> > >> > Not to be contrarian, but pre-relase docs are probabl
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Nov 20, Carl Eastlund wrote: > > Re: command line argument vs environment variable: > > You are right, it works either way. Since we already have > environment variables to control this kind of thing, I went with > another environment variable. I don't think having two things > controlled via enviroment and one via command line is going to be > somehow less confusing than having three environment variables. If, > some day, we overhaul this configuration system, I have no problem > with going to all command line arguments (or just one switch, as a > command line argument). The general good direction, IMO, is to avoid environment variables as much as possible. So if you want to add a new knob, doing that with a command line argument has better chances of being useful and of staying around. Do you have any *concrete* point for preferring an environment variable over a command-line argument? > First, do we want to redesign our local configuration system, > addressing issues of how directory trees are laid out, what options > users have, and how users express choices. This will take careful > design, time to implement, and a decision of how to deal with the > fact that it will almost certainly break existing configurations. This was mostly done, with the new command line arguments and with changes that happened in the past. PLTCOLLECTS might be more difficult to pull out, but I won't cry when this is done. > Re: nightly build: > > This doesn't solve my problem, because nightly builds do not include > planet packages, Of course, but I talked about building the PLT tree itself, which is a conserable chunk of work that you don't need to do. > and a new nightly build will still clobber the local planet and > scribble files of an older one with the same version. How? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Fri, Nov 20, 2009 at 4:32 PM, Eli Barzilay wrote: > On Nov 20, Carl Eastlund wrote: >> >> Re: command line argument vs environment variable: >> >> You are right, it works either way. Since we already have >> environment variables to control this kind of thing, I went with >> another environment variable. I don't think having two things >> controlled via enviroment and one via command line is going to be >> somehow less confusing than having three environment variables. If, >> some day, we overhaul this configuration system, I have no problem >> with going to all command line arguments (or just one switch, as a >> command line argument). > > The general good direction, IMO, is to avoid environment variables as > much as possible. So if you want to add a new knob, doing that with a > command line argument has better chances of being useful and of > staying around. Do you have any *concrete* point for preferring an > environment variable over a command-line argument? I am preferring consistency over inconsistency. Betamax was better than VHS, but once 90% of the world was VHS there was no sense in making Betamax any more. People are using our VHS options already, so why not give them more VHS, even if Betamax is better? That *was* my argument. I think my point that "users only have to use the old way or the new way, not both" undermines it. If users use *either* the PLTPLANETDIR environment variable *or* a command line option for add-on directories, it becomes easier to justify the inconsistency. However, since I am using the same kind of script as you for calling PLT executables -- the command line approach is only easy to use if we make sure every PLT executable can accept the same argument. Do we have a single point of control for that? Or will we have to edit several programs to make sure they accept this new option? >> First, do we want to redesign our local configuration system, >> addressing issues of how directory trees are laid out, what options >> users have, and how users express choices. This will take careful >> design, time to implement, and a decision of how to deal with the >> fact that it will almost certainly break existing configurations. > > This was mostly done, with the new command line arguments and with > changes that happened in the past. PLTCOLLECTS might be more > difficult to pull out, but I won't cry when this is done. What new command line arguments do we have for this? The only ones I see are for collections; I don't see any for planet, scribble, or preferences -- any of the Mz/DrScheme generated files. >> Re: nightly build: >> >> This doesn't solve my problem, because nightly builds do not include >> planet packages, > > Of course, but I talked about building the PLT tree itself, which is a > conserable chunk of work that you don't need to do. But that's the part that also doesn't clobber anything, and thus isn't a problem for me. >> and a new nightly build will still clobber the local planet and >> scribble files of an older one with the same version. > > How? How else would it work? Where will it put these things, other than right where the previous build did? --Carl _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Nov 20, Carl Eastlund wrote: > On Fri, Nov 20, 2009 at 4:32 PM, Eli Barzilay wrote: > > > > The general good direction, IMO, is to avoid environment variables > > as much as possible. So if you want to add a new knob, doing that > > with a command line argument has better chances of being useful > > and of staying around. Do you have any *concrete* point for > > preferring an environment variable over a command-line argument? > > I am preferring consistency over inconsistency. Right, and my point is that moving *consistently* to command-line flags is good. Otherwise, why would -X and -S get added in v4? > However, since I am using the same kind of script as you for calling > PLT executables -- the command line approach is only easy to use if > we make sure every PLT executable can accept the same argument. Do > we have a single point of control for that? If I had a use for such a flag, then I'd add it in my scripts. > > This was mostly done, with the new command line arguments and with > > changes that happened in the past. PLTCOLLECTS might be more > > difficult to pull out, but I won't cry when this is done. > > What new command line arguments do we have for this? `-S' and `-X'. And `-U', which is going to interact in a funny way with a PLTADDON option. > The only ones I see are for collections; I don't see any for planet, > scribble, or preferences -- any of the Mz/DrScheme generated files. I'm talking about adding these through a command line argument instead of an environment variable. If we had arguments for these, then there wouldn't be an issue to talk about? > >> and a new nightly build will still clobber the local planet and > >> scribble files of an older one with the same version. > > > > How? > > How else would it work? Where will it put these things, other than > right where the previous build did? It has only things from the PLT tree, it cannot clobber anything in your local directories. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Fri, Nov 20, 2009 at 4:55 PM, Eli Barzilay wrote: > > Right, and my point is that moving *consistently* to command-line > flags is good. Otherwise, why would -X and -S get added in v4? Sorry, I gotcha now. Yes, if PLTCOLLECTS has been supplanted by command line arguments, then PLTPLANETDIR and PLTADDONDIR should be too. >> >> and a new nightly build will still clobber the local planet and >> >> scribble files of an older one with the same version. >> > >> > How? >> >> How else would it work? Where will it put these things, other than >> right where the previous build did? > > It has only things from the PLT tree, it cannot clobber anything in > your local directories. The act of unpacking the nightly build will not do so, but the inevitable subsequent act of installing planet packages will. Thus I'm not sure what the nightly build will save me, in terms of allowing separate copies of PLT Scheme to coexist. --Carl _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Nov 20, Carl Eastlund wrote: > >> >> and a new nightly build will still clobber the local planet and > >> >> scribble files of an older one with the same version. > >> > > >> > How? > >> > >> How else would it work? Where will it put these things, other > >> than right where the previous build did? > > > > It has only things from the PLT tree, it cannot clobber anything > > in your local directories. > > The act of unpacking the nightly build will not do so, but the > inevitable subsequent act of installing planet packages will. Thus > I'm not sure what the nightly build will save me, in terms of > allowing separate copies of PLT Scheme to coexist. Yes, you have to do the planet part yourself either way. (But I don't see how controlling the addons directory will help there.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Fri, Nov 20, 2009 at 5:14 PM, Eli Barzilay wrote: >> >> The act of unpacking the nightly build will not do so, but the >> inevitable subsequent act of installing planet packages will. Thus >> I'm not sure what the nightly build will save me, in terms of >> allowing separate copies of PLT Scheme to coexist. > > Yes, you have to do the planet part yourself either way. (But I don't > see how controlling the addons directory will help there.) The same way it will help anywhere else. By directing one nightly build to install stuff in a different place than the other. Am I missing something obvious here about your point? Because you seem to be contradicting my original premise, without coming out and saying so. Re: command line versus environment, a quick test showed me that, for instance, mzscheme accepts -X but plt-help does not. So a "run PLT executables via script based on $PLTHOME" solution suddenly has to special case different options for each command. The nice thing about environment variables is that the same set works for every command; extra ones are ignored. --Carl _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Nov 20, Carl Eastlund wrote: > On Fri, Nov 20, 2009 at 5:14 PM, Eli Barzilay wrote: > >> > >> The act of unpacking the nightly build will not do so, but the > >> inevitable subsequent act of installing planet packages > >> will. Thus I'm not sure what the nightly build will save me, in > >> terms of allowing separate copies of PLT Scheme to coexist. > > > > Yes, you have to do the planet part yourself either way. (But I > > don't see how controlling the addons directory will help there.) > > The same way it will help anywhere else. My question is how -- what's this "same way"? > By directing one nightly build to install stuff in a different place > than the other. Am I missing something obvious here about your > point? Because you seem to be contradicting my original premise, > without coming out and saying so. I'm not making any point -- I might be missing something about either the problem or the suggested solution, and I just didn't ask about it so far. If you're still planning to run a build every day, then what is exactly the problem? My best guess is that you're trying to avoid the wait while a build is happening -- it's only a guess, but if this is the case then how about using the ultimate parameter: mkdir ~/plt-build HOME=~/plt-build ...build everything... move directories from ~/plt-build to where they usually live > Re: command line versus environment, a quick test showed me that, > for instance, mzscheme accepts -X but plt-help does not. So a "run > PLT executables via script based on $PLTHOME" solution suddenly has > to special case different options for each command. The nice thing > about environment variables is that the same set works for every > command; extra ones are ignored. You're right, that's a general problem that already exists with `-X' and the rest. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
At Fri, 20 Nov 2009 15:51:19 -0500, Eli Barzilay wrote: > Look, the story with environment variables vs command-line flags is > esentially the same one as with keyword arguments vs parameters. I completely agree. But how does this lead you to the conclusion that environment variables are bad? At the Scheme level, we always prefer to use function arguments instead of parameters. But threading some configuration information everywhere (such as the current output port) is a huge pain. So we have parameters, and various functions accept an optional argument whose default value is drawn from a parameter. Similarly, the -X and -S arguments were not added to `mzscheme' because environment variables are an inherently bad idea. They were added because it's better to supply those configurations directly when practical. But the environment variables stayed, because it's not always practical to thread a command-line argument through a chain of scripts. > 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. The same with parameters, but we'd have a hard time getting by without them. It looks to me like a PLTADDONDIR environment variable is appropriate, and `mzscheme' should also accept a command-line flag to override it. _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Nov 21, Matthew Flatt wrote: > At Fri, 20 Nov 2009 15:51:19 -0500, Eli Barzilay wrote: > > Look, the story with environment variables vs command-line flags > > is esentially the same one as with keyword arguments vs > > parameters. > > I completely agree. But how does this lead you to the conclusion > that environment variables are bad? There's no conclusion that they're automatically bad -- just that they should be avoided if possible. The problem with `plt-help' is an indication that an environment variable would be more convenient than to find a way to thread command-line flags through applications. Given this, having both a command-line flag and an environment variable is a good solution, and the fact that if both are specified then the flag should override the variable is a good indication that the variable lookup should happen once on startup rather than every time. BTW, the problem that I said already exists is not with `-X' and `-S', it's `-U' which is a problem in that plt-help doesn't accept it. But there's another potential problem: the addon-dir is used for code, which means that the two settings are dependent, so it would have been nice if there was a way to do them both in PLTCOLLECTS. Also, speaking about using environment variables -- how about another for the preference, and respecting HOME when set on Windows possible with some `expand-user-path*' that will work on Windows too? The latter two are especially annoying for writing cross-platform scripts, where I often need to edit code to use (getenv "HOME") for it to work on my (windows) laptop. > > 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. > > The same with parameters, but we'd have a hard time getting by > without them. They're not the same -- parameters are in the scheme world, so they're uniform like all other code. But environment variables are set in very different ways and in different places. For example, at some point the debian distribution arranged for PLTCOLLECTS to be set in the default user environment (at least IIRC), on windows you have several ways to change them, and finally trying to control environment variables in deployed applications is very easy on unix/osx, and very difficult on Windows (which is what lead to the need for `path-up'). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Mon, Nov 30, 2009 at 9:17 PM, Eli Barzilay wrote: >> An update -- Matthew has agreed to take over this code and to >> (eventually) add a corresponding command line option to control the >> "addon-dir". I have repeated the test steps above with the latest >> changes from the trunk, and merged my changes onto the trunk. > > I missed this, and I already undid it. I will re-commit later tonight > with a command line option, and with reading the environment variable > once. (Which means that your C-side commit will be split into a > separate piece that will read the variable.) I really don't think that this is a good way to manage our project - dueling commits and reverts. Once something is discussed and decided upon, one person shouldn't just unilaterally undo it. If something needs changing, it should be discussed. Everyone overwriting everyone else's changes just leads to chaos. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Nov 30, 2009, at 7:34 PM, Sam TH wrote: On Mon, Nov 30, 2009 at 9:17 PM, Eli Barzilay wrote: An update -- Matthew has agreed to take over this code and to (eventually) add a corresponding command line option to control the "addon-dir". I have repeated the test steps above with the latest changes from the trunk, and merged my changes onto the trunk. I missed this, and I already undid it. I will re-commit later tonight with a command line option, and with reading the environment variable once. (Which means that your C-side commit will be split into a separate piece that will read the variable.) I really don't think that this is a good way to manage our project - dueling commits and reverts. Once something is discussed and decided upon, one person shouldn't just unilaterally undo it. If something needs changing, it should be discussed. Everyone overwriting everyone else's changes just leads to chaos. If there's an exception to this, it's Eli. That is, I think the "buildmaster" is the one person you have to trust to make any change, anywhere in the tree. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
+1 On Mon, Nov 30, 2009 at 8:42 PM, John Clements wrote: > > On Nov 30, 2009, at 7:34 PM, Sam TH wrote: > >> On Mon, Nov 30, 2009 at 9:17 PM, Eli Barzilay wrote: An update -- Matthew has agreed to take over this code and to (eventually) add a corresponding command line option to control the "addon-dir". I have repeated the test steps above with the latest changes from the trunk, and merged my changes onto the trunk. >>> >>> I missed this, and I already undid it. I will re-commit later tonight >>> with a command line option, and with reading the environment variable >>> once. (Which means that your C-side commit will be split into a >>> separate piece that will read the variable.) >> >> I really don't think that this is a good way to manage our project - >> dueling commits and reverts. Once something is discussed and decided >> upon, one person shouldn't just unilaterally undo it. If something >> needs changing, it should be discussed. Everyone overwriting everyone >> else's changes just leads to chaos. > > If there's an exception to this, it's Eli. That is, I think the > "buildmaster" is the one person you have to trust to make any change, > anywhere in the tree. > > John > > > _ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
+1. (altho in this particular case, if Eli had emailed again, that would probably have been better.) Robby On Mon, Nov 30, 2009 at 9:52 PM, Jay McCarthy wrote: > +1 > > On Mon, Nov 30, 2009 at 8:42 PM, John Clements > wrote: >> >> On Nov 30, 2009, at 7:34 PM, Sam TH wrote: >> >>> On Mon, Nov 30, 2009 at 9:17 PM, Eli Barzilay wrote: > > An update -- Matthew has agreed to take over this code and to > (eventually) add a corresponding command line option to control the > "addon-dir". I have repeated the test steps above with the latest > changes from the trunk, and merged my changes onto the trunk. I missed this, and I already undid it. I will re-commit later tonight with a command line option, and with reading the environment variable once. (Which means that your C-side commit will be split into a separate piece that will read the variable.) >>> >>> I really don't think that this is a good way to manage our project - >>> dueling commits and reverts. Once something is discussed and decided >>> upon, one person shouldn't just unilaterally undo it. If something >>> needs changing, it should be discussed. Everyone overwriting everyone >>> else's changes just leads to chaos. >> >> If there's an exception to this, it's Eli. That is, I think the >> "buildmaster" is the one person you have to trust to make any change, >> anywhere in the tree. >> >> John >> >> >> _ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > _ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
Eli, people don't commit random stuff to the trunk. What's going in -- especially into the base of 'remote' people -- is done in a responsible manner. I am sure that if you were around and accessible Carl and Ryan and Sam and Stevie and everyone would ask you on how to proceed. As it is, Carl asked me and I said 'propose X to Matthew' and Matthew agreed to some variant. So when you see such an unusual commit, PLEASE ask the committer on what's going on and don't just undo things. If/when the nature of the developer community changes, we will entrust you with more enforcement (especially rejection) power. Until then, let's navigate this in a friendlier manner -- Matthias _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Nov 30, Sam TH wrote: > On Mon, Nov 30, 2009 at 9:17 PM, Eli Barzilay wrote: > > > > I missed this, and I already undid it. [...] > > [...] Once something is discussed and decided upon, one person > shouldn't just unilaterally undo it. [...] Yes, this was discussed, one decision was (a) it should be added with a flag, and another "decision" (for lack of any objections) was to not make it re-use the environment variable on each use of `find-system-path'. Due to these decisions, I assumed that Carl would do the necessary work before committing on the trunk -- and when I saw a commit that didn't include that, it was easier for me to revert and re-do. If the commit message had indicated that this is known to be broken wrt to these decisions and that Matthew intends to fix it, I wouldn't have reversed it and probably wouldn't have done the work myself. Same goes for the explanation email that came after the commit, which I only saw after I started my work. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
(And to clarify this point: this was not rejection, it was "volunteering" to finish the work.) On Dec 1, Matthias Felleisen wrote: > > Eli, people don't commit random stuff to the trunk. What's going in > -- especially into the base of 'remote' people -- is done in a > responsible manner. I am sure that if you were around and accessible > Carl and Ryan and Sam and Stevie and everyone would ask you on how > to proceed. As it is, Carl asked me and I said 'propose X to > Matthew' and Matthew agreed to some variant. So when you see such an > unusual commit, PLEASE ask the committer on what's going on and > don't just undo things. If/when the nature of the developer > community changes, we will entrust you with more enforcement > (especially rejection) power. Until then, let's navigate this in a > friendlier manner -- Matthias -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
Thanks, Eli. Its nice to see you pitching in on stuff like that. Robby On Tue, Dec 1, 2009 at 9:23 AM, Eli Barzilay wrote: > (And to clarify this point: this was not rejection, it was > "volunteering" to finish the work.) > > > On Dec 1, Matthias Felleisen wrote: >> >> Eli, people don't commit random stuff to the trunk. What's going in >> -- especially into the base of 'remote' people -- is done in a >> responsible manner. I am sure that if you were around and accessible >> Carl and Ryan and Sam and Stevie and everyone would ask you on how >> to proceed. As it is, Carl asked me and I said 'propose X to >> Matthew' and Matthew agreed to some variant. So when you see such an >> unusual commit, PLEASE ask the committer on what's going on and >> don't just undo things. If/when the nature of the developer >> community changes, we will entrust you with more enforcement >> (especially rejection) power. Until then, let's navigate this in a >> friendlier manner -- Matthias > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > _ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Re: Generated files and co-existing copies of DrScheme
On Tue, Dec 1, 2009 at 10:19 AM, Eli Barzilay wrote: > On Nov 30, Sam TH wrote: >> On Mon, Nov 30, 2009 at 9:17 PM, Eli Barzilay wrote: >> > >> > I missed this, and I already undid it. [...] >> >> [...] Once something is discussed and decided upon, one person >> shouldn't just unilaterally undo it. [...] > > Yes, this was discussed, one decision was (a) it should be added with > a flag, and another "decision" (for lack of any objections) was to not > make it re-use the environment variable on each use of > `find-system-path'. Due to these decisions, I assumed that Carl would > do the necessary work before committing on the trunk -- and when I saw > a commit that didn't include that, it was easier for me to revert and > re-do. The problem here is that we have no policy about who makes decisions about the trunk. I find this process very frustrating -- I put lots of effort into making sure what I committed was acceptable and addressed all necessary issues, so that my commit would not be wasted. Despite all my effort (a long thread on plt-dev, consulting Matthias, consulting Matthew, multiple rounds of merging changes from the trunk, rebuilding, and testing), it wasn't good enough. The code needed to be taken out immediately for a rewrite some time later. I'm sure Eli finds it frustrating, too -- he contributed a lot to that thread on plt-dev, only to see a commit that didn't live up to what he thought had been decided about the feature. I doubt he wanted to spend his Monday night rewriting my code, and I appreciate his efforts to do so. What is our policy on committing code to the trunk? How do I know when something is good enough? Who decides? I have no idea, and it makes me very reluctant to put my time into anything else that goes into the trunk if I have no way of predicting that it might be kept or not. (I recognize that, in this case, the feature was kept. However, if the details had been only slightly different, it might not have been. Furthermore, since Eli had to take out my code and rewrite it, none of my code itself was kept, and the effort I made to write and test it did not pay off.) --Carl _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
