Menu
▾
▴
env-switcher-devel — General development of the env-switcher project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(24) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
(10) |
Feb
(5) |
Mar
(2) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: John L. <cf...@cl...> - 2004-04-13 01:57:19
|
=A6b =A4=BB, 2004-04-10 11:01, env...@li...urcefor= ge.net =BCg=B9D=A1G > Message: 1 > Date: Fri, 9 Apr 2004 17:27:10 -0400 (EDT) > From: Jeff Squyres <jsq...@la...> > To: John Lau <cf...@cl...> > Cc: env...@li... > Subject: Re: [env-switcher-devel] Can switcher solve the ordering probl= em of > modules with "prereq"? >=20 > On Thu, 8 Apr 2004, John Lau wrote: >=20 > > I would like to ask, can switcher solve the ordering problem of modul= es > > with "prereq"? > > > > For example, I have 2 mpi implementations so I have 2 modules (lam an= d > > mpich). And I have two BLACS librarys that using with 2 different mpi > > (blacs-lam and blacs-mpich). So in the blacs-lam module, it prereq la= m > > module. It works fine for module load. > > > > But it is not work in using with switcher because switcher always loa= d > > blacs module first. I try to change the listing order in switcher.ini > > but it still dont work. I guess it is following the alphabetical orde= r > > to load the modules. > > > > Do anyone have a solution to this problem? And can we change the > > switcher module loading order? >=20 > Ah -- this is a good point; I hadn't thought about this case. :-\ >=20 > IIRC, the switcher code is currently issuing individual "module load" > commands to load up your default set. If that's true, I think that > consolidating them into a single "module load a b c d ..." line might > allow "module" to do the Right Thing. >=20 > Can you confirm if this is true? >=20 > Can you try "module load lam blacs-lam" and "module load blacs-lam lam" > and see if "module" re-orders them properly? Oh, the module cannot reorder the load of modules... -_- "module add blacs/blacs-lam-1.1 mpi/lam-gcc32-7.0.3" cannot work while "module add mpi/lam-gcc32-7.0.3 blacs/blacs-lam-1.1" is ok! John Lau |
|
From: Jeff S. <jsq...@la...> - 2004-04-09 21:27:15
|
On Thu, 8 Apr 2004, John Lau wrote:
> I would like to ask, can switcher solve the ordering problem of modules
> with "prereq"?
>
> For example, I have 2 mpi implementations so I have 2 modules (lam and
> mpich). And I have two BLACS librarys that using with 2 different mpi
> (blacs-lam and blacs-mpich). So in the blacs-lam module, it prereq lam
> module. It works fine for module load.
>
> But it is not work in using with switcher because switcher always load
> blacs module first. I try to change the listing order in switcher.ini
> but it still dont work. I guess it is following the alphabetical order
> to load the modules.
>
> Do anyone have a solution to this problem? And can we change the
> switcher module loading order?
Ah -- this is a good point; I hadn't thought about this case. :-\
IIRC, the switcher code is currently issuing individual "module load"
commands to load up your default set. If that's true, I think that
consolidating them into a single "module load a b c d ..." line might
allow "module" to do the Right Thing.
Can you confirm if this is true?
Can you try "module load lam blacs-lam" and "module load blacs-lam lam"
and see if "module" re-orders them properly?
--
{+} Jeff Squyres
{+} jsq...@la...
{+} http://www.lam-mpi.org/
|
|
From: John L. <cf...@cl...> - 2004-04-08 03:30:15
|
Hi all, I would like to ask, can switcher solve the ordering problem of modules with "prereq"? For example, I have 2 mpi implementations so I have 2 modules (lam and mpich). And I have two BLACS librarys that using with 2 different mpi (blacs-lam and blacs-mpich). So in the blacs-lam module, it prereq lam module. It works fine for module load. But it is not work in using with switcher because switcher always load blacs module first. I try to change the listing order in switcher.ini but it still dont work. I guess it is following the alphabetical order to load the modules. Do anyone have a solution to this problem? And can we change the switcher module loading order? John Lau |
|
From: SourceForge.net <no...@so...> - 2004-03-08 18:10:52
|
Feature Requests item #905191, was opened at 2004-02-26 11:37 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=905191&group_id=51915 Category: Interface Improvements (example) Group: None >Status: Closed Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Jeff Squyres (jsquyres) Summary: Need switcher command to Initial Comment: So I understand the rationale for not forcing the current environment to match whatever the static switcher setting are set to for future shells... BUT- Let me contrast softenv once: Softenv has a "resoft" command which basically re- reads the .soft file and resets the environment to that of what would be expected in future shells. Switcher doesn't appear to have any functionality like that. This would be INSANELY useful. * Changes would be N changes + 1 refresh instead of N changes + N live shell update module commands (not counting the unloading of conflicts) * We've seen from problem reports that the current method is error prone in the event that a sysadmin doesn't start a new shell in some instances. This could be a non-issue if there was a switcher command to refresh from static settings. * It would be much more intuitive. switcher -- reload/refresh, whatever. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2004-03-08 12:54 Message: Logged In: YES user_id=11722 Fixed in CVS. Will be in 1.0.12. It's actually a neat little hack, and it exploits some amazing foresight that I had when I originally wrote switcher. /me pats himself on the back. ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-02-26 11:41 Message: Logged In: YES user_id=11722 This is actually a good idea. First thoughts are that it can do some module-based hokey-pokey behind the scenes. Won't happen in the next two weeks (at a minimum) but I'll see what I can do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=905191&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-03-07 22:31:05
|
Feature Requests item #877263, was opened at 2004-01-14 19:14 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 Category: Interface Improvements (example) Group: None >Status: Closed Priority: 5 Submitted By: Jeremy Enos (jenos) >Assigned to: Jeff Squyres (jsquyres) Summary: options require fixed order? Initial Comment: If I want to use the --system or --user options... they're required to be at the *end* of the command line. I don't see why this is necessary in the first place, but it's also not made clear on the syntax page. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2004-03-07 17:15 Message: Logged In: YES user_id=11722 Done; will be in 1.0.12. ---------------------------------------------------------------------- Comment By: Jeremy Enos (jenos) Date: 2004-02-26 19:05 Message: Logged In: YES user_id=270124 No inflammatory result intended of course. Also, estimations of what is intuitive is arguably ALWAYS subjective, yet we still pay attention to it. It's just feedback. :) As far as referring someone to the man page... bahhh. The first thing a user sees is the big fat usage screen indicating their command was in error, with absolutely no mention of ordering... as you mention below, this is fixed in the usage info now. (of course, having no updated OSCAR package in OPD, the endusers have little chance of seeing it) Not a big deal though... might as well save the effort until cmd line options are parsed flexibly. ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-02-26 11:40 Message: Logged In: YES user_id=11722 a) you made your [weak] point the first time. I believe that the switcher RPMs that ship with OSCAR now include [more] explicit instructions about how --system and --user must be at the end (although the original instructions were also quite clear, per normal unix man page conventions). b) I know that NCSA personnel don't like to read instructions; all the help instructions for switcher clearly state that the tag must be the second argument. I don't have any solution for this problem, unless you want me to force the addition of a "--tag" argument to identify the tag (then it can go anywhere in the line). c) if your intent was just to remind me that this ticket is still open, you could have chosen a far less inflamitory way to do so (what is a "natural" tendency for you is *highly* subjective and relative). ---------------------------------------------------------------------- Comment By: Jeremy Enos (jenos) Date: 2004-02-26 11:28 Message: Logged In: YES user_id=270124 I'm sure when you fix this it will probably be for all options and not just the options I made example of... but let me just give another example of counter-intuitive use. --list and -- show are both confusing here. [oscartst@posic mpich-vmi]$ switcher --list global mpi Note, that after typing this command, the next natural tendency is to "up-arrow" in the shell, type switcher --list mpi on the command line, and list out the rest. Hopefully the user is patient with the error in their face and will realize that they need to go to the middle of the command line, as follows: [oscartst@posic mpich-vmi]$ switcher mpi --list lam-7.0 lam-with-gm-7.0 mpich-ch_p4-gcc-1.2.5.10 mpich-ch_vmi-gcc-2.0.b3p1 [oscartst@posic mpich-vmi]$ ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-16 10:42 Message: Logged In: YES user_id=11722 After looking at the code again, I'm unfortunately reminded of the ugliness that requires this. It's not even worth describing. This is, of course, fixable, but it would probably mean ditching using the perl AppConfig module that I'm using for command line parsing (due to limitations of AppConfig), and then overhauling how I do command line parsing in switcher. This isn't hard, but it would probably take 1-3 hours to re-write and make it "just so". I just don't have time for that at the moment. :-( So, instead, I updated the help messages and man page (new section: BUGS) that describes this limitation, and I'll leave the bug open for the future when/if I have time to actually go fix this. :-) ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 19:30 Message: Logged In: YES user_id=11722 I'll see what I can do here. IIRC, there were some weird issues that forced me to put in the strict ordering. But that could have all been while I was writing the first version and just getting it to work. I'll see if it's easy to do this now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-02-27 00:18:04
|
Feature Requests item #877263, was opened at 2004-01-14 18:14 Message generated for change (Comment added) made by jenos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: options require fixed order? Initial Comment: If I want to use the --system or --user options... they're required to be at the *end* of the command line. I don't see why this is necessary in the first place, but it's also not made clear on the syntax page. ---------------------------------------------------------------------- >Comment By: Jeremy Enos (jenos) Date: 2004-02-26 18:05 Message: Logged In: YES user_id=270124 No inflammatory result intended of course. Also, estimations of what is intuitive is arguably ALWAYS subjective, yet we still pay attention to it. It's just feedback. :) As far as referring someone to the man page... bahhh. The first thing a user sees is the big fat usage screen indicating their command was in error, with absolutely no mention of ordering... as you mention below, this is fixed in the usage info now. (of course, having no updated OSCAR package in OPD, the endusers have little chance of seeing it) Not a big deal though... might as well save the effort until cmd line options are parsed flexibly. ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-02-26 10:40 Message: Logged In: YES user_id=11722 a) you made your [weak] point the first time. I believe that the switcher RPMs that ship with OSCAR now include [more] explicit instructions about how --system and --user must be at the end (although the original instructions were also quite clear, per normal unix man page conventions). b) I know that NCSA personnel don't like to read instructions; all the help instructions for switcher clearly state that the tag must be the second argument. I don't have any solution for this problem, unless you want me to force the addition of a "--tag" argument to identify the tag (then it can go anywhere in the line). c) if your intent was just to remind me that this ticket is still open, you could have chosen a far less inflamitory way to do so (what is a "natural" tendency for you is *highly* subjective and relative). ---------------------------------------------------------------------- Comment By: Jeremy Enos (jenos) Date: 2004-02-26 10:28 Message: Logged In: YES user_id=270124 I'm sure when you fix this it will probably be for all options and not just the options I made example of... but let me just give another example of counter-intuitive use. --list and -- show are both confusing here. [oscartst@posic mpich-vmi]$ switcher --list global mpi Note, that after typing this command, the next natural tendency is to "up-arrow" in the shell, type switcher --list mpi on the command line, and list out the rest. Hopefully the user is patient with the error in their face and will realize that they need to go to the middle of the command line, as follows: [oscartst@posic mpich-vmi]$ switcher mpi --list lam-7.0 lam-with-gm-7.0 mpich-ch_p4-gcc-1.2.5.10 mpich-ch_vmi-gcc-2.0.b3p1 [oscartst@posic mpich-vmi]$ ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-16 09:42 Message: Logged In: YES user_id=11722 After looking at the code again, I'm unfortunately reminded of the ugliness that requires this. It's not even worth describing. This is, of course, fixable, but it would probably mean ditching using the perl AppConfig module that I'm using for command line parsing (due to limitations of AppConfig), and then overhauling how I do command line parsing in switcher. This isn't hard, but it would probably take 1-3 hours to re-write and make it "just so". I just don't have time for that at the moment. :-( So, instead, I updated the help messages and man page (new section: BUGS) that describes this limitation, and I'll leave the bug open for the future when/if I have time to actually go fix this. :-) ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 18:30 Message: Logged In: YES user_id=11722 I'll see what I can do here. IIRC, there were some weird issues that forced me to put in the strict ordering. But that could have all been while I was writing the first version and just getting it to work. I'll see if it's easy to do this now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-02-26 16:53:16
|
Feature Requests item #905191, was opened at 2004-02-26 11:37 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=905191&group_id=51915 Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) >Assigned to: Jeff Squyres (jsquyres) >Summary: Need switcher command to Initial Comment: So I understand the rationale for not forcing the current environment to match whatever the static switcher setting are set to for future shells... BUT- Let me contrast softenv once: Softenv has a "resoft" command which basically re- reads the .soft file and resets the environment to that of what would be expected in future shells. Switcher doesn't appear to have any functionality like that. This would be INSANELY useful. * Changes would be N changes + 1 refresh instead of N changes + N live shell update module commands (not counting the unloading of conflicts) * We've seen from problem reports that the current method is error prone in the event that a sysadmin doesn't start a new shell in some instances. This could be a non-issue if there was a switcher command to refresh from static settings. * It would be much more intuitive. switcher -- reload/refresh, whatever. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2004-02-26 11:41 Message: Logged In: YES user_id=11722 This is actually a good idea. First thoughts are that it can do some module-based hokey-pokey behind the scenes. Won't happen in the next two weeks (at a minimum) but I'll see what I can do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=905191&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-02-26 16:52:07
|
Feature Requests item #877263, was opened at 2004-01-14 19:14 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: options require fixed order? Initial Comment: If I want to use the --system or --user options... they're required to be at the *end* of the command line. I don't see why this is necessary in the first place, but it's also not made clear on the syntax page. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2004-02-26 11:40 Message: Logged In: YES user_id=11722 a) you made your [weak] point the first time. I believe that the switcher RPMs that ship with OSCAR now include [more] explicit instructions about how --system and --user must be at the end (although the original instructions were also quite clear, per normal unix man page conventions). b) I know that NCSA personnel don't like to read instructions; all the help instructions for switcher clearly state that the tag must be the second argument. I don't have any solution for this problem, unless you want me to force the addition of a "--tag" argument to identify the tag (then it can go anywhere in the line). c) if your intent was just to remind me that this ticket is still open, you could have chosen a far less inflamitory way to do so (what is a "natural" tendency for you is *highly* subjective and relative). ---------------------------------------------------------------------- Comment By: Jeremy Enos (jenos) Date: 2004-02-26 11:28 Message: Logged In: YES user_id=270124 I'm sure when you fix this it will probably be for all options and not just the options I made example of... but let me just give another example of counter-intuitive use. --list and -- show are both confusing here. [oscartst@posic mpich-vmi]$ switcher --list global mpi Note, that after typing this command, the next natural tendency is to "up-arrow" in the shell, type switcher --list mpi on the command line, and list out the rest. Hopefully the user is patient with the error in their face and will realize that they need to go to the middle of the command line, as follows: [oscartst@posic mpich-vmi]$ switcher mpi --list lam-7.0 lam-with-gm-7.0 mpich-ch_p4-gcc-1.2.5.10 mpich-ch_vmi-gcc-2.0.b3p1 [oscartst@posic mpich-vmi]$ ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-16 10:42 Message: Logged In: YES user_id=11722 After looking at the code again, I'm unfortunately reminded of the ugliness that requires this. It's not even worth describing. This is, of course, fixable, but it would probably mean ditching using the perl AppConfig module that I'm using for command line parsing (due to limitations of AppConfig), and then overhauling how I do command line parsing in switcher. This isn't hard, but it would probably take 1-3 hours to re-write and make it "just so". I just don't have time for that at the moment. :-( So, instead, I updated the help messages and man page (new section: BUGS) that describes this limitation, and I'll leave the bug open for the future when/if I have time to actually go fix this. :-) ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 19:30 Message: Logged In: YES user_id=11722 I'll see what I can do here. IIRC, there were some weird issues that forced me to put in the strict ordering. But that could have all been while I was writing the first version and just getting it to work. I'll see if it's easy to do this now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-02-26 16:49:33
|
Feature Requests item #905191, was opened at 2004-02-26 10:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=905191&group_id=51915 Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: Need switcher command to "refresh" Initial Comment: So I understand the rationale for not forcing the current environment to match whatever the static switcher setting are set to for future shells... BUT- Let me contrast softenv once: Softenv has a "resoft" command which basically re- reads the .soft file and resets the environment to that of what would be expected in future shells. Switcher doesn't appear to have any functionality like that. This would be INSANELY useful. * Changes would be N changes + 1 refresh instead of N changes + N live shell update module commands (not counting the unloading of conflicts) * We've seen from problem reports that the current method is error prone in the event that a sysadmin doesn't start a new shell in some instances. This could be a non-issue if there was a switcher command to refresh from static settings. * It would be much more intuitive. switcher -- reload/refresh, whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=905191&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-02-26 16:40:39
|
Feature Requests item #877263, was opened at 2004-01-14 18:14 Message generated for change (Comment added) made by jenos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: options require fixed order? Initial Comment: If I want to use the --system or --user options... they're required to be at the *end* of the command line. I don't see why this is necessary in the first place, but it's also not made clear on the syntax page. ---------------------------------------------------------------------- >Comment By: Jeremy Enos (jenos) Date: 2004-02-26 10:28 Message: Logged In: YES user_id=270124 I'm sure when you fix this it will probably be for all options and not just the options I made example of... but let me just give another example of counter-intuitive use. --list and -- show are both confusing here. [oscartst@posic mpich-vmi]$ switcher --list global mpi Note, that after typing this command, the next natural tendency is to "up-arrow" in the shell, type switcher --list mpi on the command line, and list out the rest. Hopefully the user is patient with the error in their face and will realize that they need to go to the middle of the command line, as follows: [oscartst@posic mpich-vmi]$ switcher mpi --list lam-7.0 lam-with-gm-7.0 mpich-ch_p4-gcc-1.2.5.10 mpich-ch_vmi-gcc-2.0.b3p1 [oscartst@posic mpich-vmi]$ ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-16 09:42 Message: Logged In: YES user_id=11722 After looking at the code again, I'm unfortunately reminded of the ugliness that requires this. It's not even worth describing. This is, of course, fixable, but it would probably mean ditching using the perl AppConfig module that I'm using for command line parsing (due to limitations of AppConfig), and then overhauling how I do command line parsing in switcher. This isn't hard, but it would probably take 1-3 hours to re-write and make it "just so". I just don't have time for that at the moment. :-( So, instead, I updated the help messages and man page (new section: BUGS) that describes this limitation, and I'll leave the bug open for the future when/if I have time to actually go fix this. :-) ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 18:30 Message: Logged In: YES user_id=11722 I'll see what I can do here. IIRC, there were some weird issues that forced me to put in the strict ordering. But that could have all been while I was writing the first version and just getting it to work. I'll see if it's easy to do this now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-01-16 15:42:24
|
Feature Requests item #877263, was opened at 2004-01-14 19:14 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: options require fixed order? Initial Comment: If I want to use the --system or --user options... they're required to be at the *end* of the command line. I don't see why this is necessary in the first place, but it's also not made clear on the syntax page. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2004-01-16 10:42 Message: Logged In: YES user_id=11722 After looking at the code again, I'm unfortunately reminded of the ugliness that requires this. It's not even worth describing. This is, of course, fixable, but it would probably mean ditching using the perl AppConfig module that I'm using for command line parsing (due to limitations of AppConfig), and then overhauling how I do command line parsing in switcher. This isn't hard, but it would probably take 1-3 hours to re-write and make it "just so". I just don't have time for that at the moment. :-( So, instead, I updated the help messages and man page (new section: BUGS) that describes this limitation, and I'll leave the bug open for the future when/if I have time to actually go fix this. :-) ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 19:30 Message: Logged In: YES user_id=11722 I'll see what I can do here. IIRC, there were some weird issues that forced me to put in the strict ordering. But that could have all been while I was writing the first version and just getting it to work. I'll see if it's easy to do this now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-01-16 15:06:33
|
Bugs item #877264, was opened at 2004-01-14 19:17 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=877264&group_id=51915 Category: env-switcher functionality Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Enos (jenos) >Assigned to: Jeff Squyres (jsquyres) Summary: switcher errors cause lots of utilities to fail Initial Comment: There are two types of errors I've seen cause problems: * missing module file * directory doesn't exist but is in path Both of these have caused failures with common utilities like: sftp scp rsync Rather than ask all the utilities to change, I think env- switcher should. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2004-01-16 10:06 Message: Logged In: YES user_id=11722 I still maintain that switcher should tell you of errors on your system rather than you having to try to figure them out yourself (or even worse, users unexpectedly getting the wrong version of something, or not getting it at all, and not getting informed of it). That's just good sysadmin. All the errors that you cite (sftp, scp, rsync) are easily fixable -- fix your environment setup, and the problem goes away. Any sysadmin worth their salt can write a 5 line shell script to fix the problem, even in the presence of the warning messages from switcher (e.g., ssh over a list of hosts and run the desired switcher command). I added a big section to the README describing this in a bit more detail. Despite my feelings about this, it seems that there are resolutely lazy sysadmins out there (lazy in the bad sense of the word, not in the hacker/good sense of the word). I have not wanted to propagate bad sysadmin practices, but since at least one user has cared enough to be very, very persistent :-) in this matter, I have done two things: - added a "--enable-suppress-errors" option to configure, which will change switcher's default behavior when it encounters behavior. It is exactly equivalent to setting the "announce" attribute in the global section to "none" (i.e., running "switcher announce = none --system"). This is done at configure time, and therefore affects the entire switcher installation, and also does not require running a secondary command. - made new OSCAR RPMs with this "feature" enabled. v1.0.11 will be released shortly. New OSCAR RPMs will be committed shortly. ---------------------------------------------------------------------- Comment By: Jeremy Enos (jenos) Date: 2004-01-14 19:37 Message: Logged In: YES user_id=270124 My mistake... this feature already exists, it's just not the default, which I would still consider a problem. So I guess this request is for a default setting to be quiet. :) ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 19:20 Message: Logged In: YES user_id=11722 I'm not sure I know what you mean here -- as I already told you in e-mail, switcher already has the capability to turn such messages off. It's just not enabled by default in OSCAR. Are you asking about something else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=877264&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-01-16 14:59:49
|
Feature Requests item #877262, was opened at 2004-01-14 19:12 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877262&group_id=51915 Category: Interface Improvements (example) Group: None >Status: Closed Priority: 5 Submitted By: Jeremy Enos (jenos) >Assigned to: Jeff Squyres (jsquyres) Summary: syntax output lacking Initial Comment: What is likely the most common usage of the switcher command? My guess is: switcher <tag> = <name> There is a full page of syntax that a "--help" will invoke which doesn't mention the above usage! (I know the man page does, but the syntax is likely the first thing users will see) Also, "switcher --help" isn't even a valid option. That's an oversight I'm sure. Last problem with the syntax page is that it seems to be tailored more to admins than users. If anyone should be forced to read the man page, it should be admins. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2004-01-16 09:59 Message: Logged In: YES user_id=11722 The default help message has been streamlined and mostly discusses the "switcher <tag> = <name>" syntax. The original message is available through the "--more-help" option (listed at the bottom of the [new] default help message). --help and --more-help were added as valid options; you're right, that was clearly an oversight. :-) Fixed in CVS; new release shortly. ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 19:31 Message: Logged In: YES user_id=11722 Sounds reasonable. I'll tweak. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877262&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-01-15 00:37:04
|
Bugs item #877264, was opened at 2004-01-14 18:17 Message generated for change (Comment added) made by jenos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=877264&group_id=51915 Category: env-switcher functionality Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: switcher errors cause lots of utilities to fail Initial Comment: There are two types of errors I've seen cause problems: * missing module file * directory doesn't exist but is in path Both of these have caused failures with common utilities like: sftp scp rsync Rather than ask all the utilities to change, I think env- switcher should. ---------------------------------------------------------------------- >Comment By: Jeremy Enos (jenos) Date: 2004-01-14 18:37 Message: Logged In: YES user_id=270124 My mistake... this feature already exists, it's just not the default, which I would still consider a problem. So I guess this request is for a default setting to be quiet. :) ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 18:20 Message: Logged In: YES user_id=11722 I'm not sure I know what you mean here -- as I already told you in e-mail, switcher already has the capability to turn such messages off. It's just not enabled by default in OSCAR. Are you asking about something else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=877264&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-01-15 00:31:21
|
Feature Requests item #877262, was opened at 2004-01-14 19:12 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877262&group_id=51915 Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: syntax output lacking Initial Comment: What is likely the most common usage of the switcher command? My guess is: switcher <tag> = <name> There is a full page of syntax that a "--help" will invoke which doesn't mention the above usage! (I know the man page does, but the syntax is likely the first thing users will see) Also, "switcher --help" isn't even a valid option. That's an oversight I'm sure. Last problem with the syntax page is that it seems to be tailored more to admins than users. If anyone should be forced to read the man page, it should be admins. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 19:31 Message: Logged In: YES user_id=11722 Sounds reasonable. I'll tweak. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877262&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-01-15 00:30:08
|
Feature Requests item #877263, was opened at 2004-01-14 19:14 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: options require fixed order? Initial Comment: If I want to use the --system or --user options... they're required to be at the *end* of the command line. I don't see why this is necessary in the first place, but it's also not made clear on the syntax page. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 19:30 Message: Logged In: YES user_id=11722 I'll see what I can do here. IIRC, there were some weird issues that forced me to put in the strict ordering. But that could have all been while I was writing the first version and just getting it to work. I'll see if it's easy to do this now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-01-15 00:20:19
|
Bugs item #877264, was opened at 2004-01-14 19:17 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=877264&group_id=51915 Category: env-switcher functionality Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: switcher errors cause lots of utilities to fail Initial Comment: There are two types of errors I've seen cause problems: * missing module file * directory doesn't exist but is in path Both of these have caused failures with common utilities like: sftp scp rsync Rather than ask all the utilities to change, I think env- switcher should. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2004-01-14 19:20 Message: Logged In: YES user_id=11722 I'm not sure I know what you mean here -- as I already told you in e-mail, switcher already has the capability to turn such messages off. It's just not enabled by default in OSCAR. Are you asking about something else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=877264&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-01-15 00:17:20
|
Bugs item #877264, was opened at 2004-01-14 18:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=877264&group_id=51915 Category: env-switcher functionality Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: switcher errors cause lots of utilities to fail Initial Comment: There are two types of errors I've seen cause problems: * missing module file * directory doesn't exist but is in path Both of these have caused failures with common utilities like: sftp scp rsync Rather than ask all the utilities to change, I think env- switcher should. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=877264&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-01-15 00:14:57
|
Feature Requests item #877263, was opened at 2004-01-14 18:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: options require fixed order? Initial Comment: If I want to use the --system or --user options... they're required to be at the *end* of the command line. I don't see why this is necessary in the first place, but it's also not made clear on the syntax page. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877263&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2004-01-15 00:12:59
|
Feature Requests item #877262, was opened at 2004-01-14 18:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877262&group_id=51915 Category: Interface Improvements (example) Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: syntax output lacking Initial Comment: What is likely the most common usage of the switcher command? My guess is: switcher <tag> = <name> There is a full page of syntax that a "--help" will invoke which doesn't mention the above usage! (I know the man page does, but the syntax is likely the first thing users will see) Also, "switcher --help" isn't even a valid option. That's an oversight I'm sure. Last problem with the syntax page is that it seems to be tailored more to admins than users. If anyone should be forced to read the man page, it should be admins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465047&aid=877262&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2003-07-19 18:14:48
|
Bugs item #774192, was opened at 2003-07-19 09:58 Message generated for change (Comment added) made by jsquyres You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=774192&group_id=51915 Category: env-switcher functionality Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Squyres (jsquyres) Assigned to: Jeff Squyres (jsquyres) Summary: Failures when more than one default Initial Comment: Hi, I've been messing around with switcher scripts for some of the locally installed software on our cluster to allow our users to choose between different versions of our applications. I've written a modulefile for them and installed them via: switcher prog --add-name version /path/to/program The modulefile is copied to /opt/env-switcher/share and shows up correctly when I do: switcher and switcher prog Additionally, I can use the 'module' command to load and unload the modules, and the environment is updated appropriately. The problem comes when I use switcher prog = prog-version --system Then every new shell invocation gives: mpi(70):ERROR:105: Unable to locate a modulefile for 'mpi/lam-6.5.9 **** prog/prog-version' If I remove the default entry from mpi with: switcher mpi = none --system then I don't get the errors. In summary: -I've created a new modulefile -I can load/unload it fine using the module command -Switcher if it's the _only_ module with a default attr -If there is more than one tag with a default attribute it fails. I believe the failure occurs in /opt/modules/oscar-modules/switcher/1.0.9, near the end in the section: set modules_to_load [exec switcher --show-exec] if { $modules_to_load != "" } { module load $modules_to_load #module load "[exec switcher --show-exec]" } Unfortunately I don't really know tcl. Any ideas? ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2003-07-19 14:14 Message: Logged In: YES user_id=11722 This requred parsing the output that comes back from "switcher --show-exec", since multiple lines of output may come back. Each line may be either an "echo" command or a module name. If it's an "echo" command, just let it pass through. If it's a module name, then load or unload it (depending on the context). This fix is now in CVS. Thanks to Justin MacCallum for pointing this out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=774192&group_id=51915 |
|
From: SourceForge.net <no...@so...> - 2003-07-19 13:58:22
|
Bugs item #774192, was opened at 2003-07-19 09:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=774192&group_id=51915 Category: env-switcher functionality Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Squyres (jsquyres) Assigned to: Jeff Squyres (jsquyres) Summary: Failures when more than one default Initial Comment: Hi, I've been messing around with switcher scripts for some of the locally installed software on our cluster to allow our users to choose between different versions of our applications. I've written a modulefile for them and installed them via: switcher prog --add-name version /path/to/program The modulefile is copied to /opt/env-switcher/share and shows up correctly when I do: switcher and switcher prog Additionally, I can use the 'module' command to load and unload the modules, and the environment is updated appropriately. The problem comes when I use switcher prog = prog-version --system Then every new shell invocation gives: mpi(70):ERROR:105: Unable to locate a modulefile for 'mpi/lam-6.5.9 **** prog/prog-version' If I remove the default entry from mpi with: switcher mpi = none --system then I don't get the errors. In summary: -I've created a new modulefile -I can load/unload it fine using the module command -Switcher if it's the _only_ module with a default attr -If there is more than one tag with a default attribute it fails. I believe the failure occurs in /opt/modules/oscar-modules/switcher/1.0.9, near the end in the section: set modules_to_load [exec switcher --show-exec] if { $modules_to_load != "" } { module load $modules_to_load #module load "[exec switcher --show-exec]" } Unfortunately I don't really know tcl. Any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=774192&group_id=51915 |
|
From: <no...@so...> - 2002-10-11 17:37:10
|
Bugs item #612672, was opened at 2002-09-21 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=612672&group_id=51915 Category: env-switcher functionality Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jeff Squyres (jsquyres) Assigned to: Jeff Squyres (jsquyres) >Summary: Sentinel "none" val. not totally honored Initial Comment: The following usage scenario shows where the sentinel value "none" doesn't seem to work properly. Setting a value to "none" (at least for the "default" attribute) should actually delete the attribute. $ switcher foo --list default=system_bar exists=true $ switcher foo = user_bar $ switcher foo --list default=user_bar exists=true $ switcher foo = none $ switcher foo --list default=none exists=true Hence, the system value "system_bar" is effectively hidden. One can do a "--rm-attr" on default and get the expected behavior, but since "none" is documented to be a special sentinel value, it should just go ahead and remove the attribute, not just mark it as "none". ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2002-10-11 10:37 Message: Logged In: YES user_id=11722 This is incorrect, and a classic case of the author forgetting the original intention of a feature. :-) The sentinel "none" is meant to indicate that nothing should occur for that tag. Hence "switcher foo = none" means that the user does not want anything loaded for the foo tag, regardless of what the system-level default is. RTFM (man page) provides ample detail describing that this is the intent of the "none" value. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=612672&group_id=51915 |
|
From: <no...@so...> - 2002-09-26 14:05:59
|
Bugs item #612682, was opened at 2002-09-21 17:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=612682&group_id=51915 Category: env-switcher functionality Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Squyres (jsquyres) Assigned to: Jeff Squyres (jsquyres) >Summary: --show should indicate level of attribute Initial Comment: The --show command show somehow indicate what level the value is being resolved at (user or system). For example: $ switcher foo = user_bar $ switcher foo --show default=(user,user_bar) exists=(user,true) $ switcher foo --rm-attr default $ switcher foo --show default=(system,system_bar) exists=(system,true) ...or something along those lines. This makes it totally obvious as to what level a specific attribute is being resolved at. ---------------------------------------------------------------------- >Comment By: Jeff Squyres (jsquyres) Date: 2002-09-26 07:05 Message: Logged In: YES user_id=11722 Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=612682&group_id=51915 |
|
From: <no...@so...> - 2002-09-22 14:56:24
|
Bugs item #612836, was opened at 2002-09-22 07:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=612836&group_id=51915 Category: env-switcher functionality Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Squyres (jsquyres) Assigned to: Jeff Squyres (jsquyres) Summary: Infinite loop Initial Comment: The following command puts the command line parser into an infinite loop: $ switcher mpi default foo This is not legal syntax, but it should not go into an infinite loop -- it should print some kind of meaningful error message instead. ---------------------------------------------------------------------- Comment By: Jeff Squyres (jsquyres) Date: 2002-09-22 07:55 Message: Logged In: YES user_id=11722 Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=465044&aid=612836&group_id=51915 |
