On Tue, 9 Mar 2004, Lombard, David N wrote:
> > This is how switcher has *always* been -- the switcher command only > > changes your preferences, it does *not* change your current > environment. > > It is very strongly documented this way. From the text: > > I understand this is what it's always done -- I expected that. I've > never used switcher, given my LAM preference. :^D
:-)
> > In fact, it would be very difficult to make it change your current > > environment -- there's a bunch of very sitcky technical issues > involved. > > The Unicos modules command worked that way (changing the current > environment), similarly to my understanding of the underlying modules > project, by aliasing commands to source directly into the current shell.
switcher uses the unicos modules as the back-end. switcher-reload is simply an alias to "module unload switcher; module load switcher".
Ah... so unloading and loading the switcher module will remove the current mpi module and then add the statically defined one to my env? If so, this would explain why one command would be extra complicated to implement, and I'd understand that. I was thinking that the other modules existed independently of switcher itself and were merely managed by it.
<Per other thread>
I'm not going to fight about this. If you want to fix it, switcher is free and licensed such that you can modify the code to your heart's content. Feel free to do so.
Of course. But this same dialogue would be necessary anyway just so I understood the issue.
And honestly, how many times will people use switcher? Very few times. So why spend a *LOT* of effort in optimizing a relatively uncommon case? Wouldn't we rather have a) a better MPI, or b) OPD mods, or c) database integration, or ....one of a million other things that is pending?
This is just not worth it. There are a lot of other, much more important things to do.
Agreed. I was just trying to understand what the complicated part of this was.
> I merely pass on to you what I get back from the user experience. I > cannot (will not) pass this back to them unless I feel they're being > unreasonable. Besides that, IF we can make something easier for the > user that makes sense to them, we should be taking that route rather > than the RTFM approach. That approach is contradictory to all our > effort put into OSCAR in general.
Wow. Thanks for those words of praise.
They're not critical words... at least not destructively. I just want to have a clear understanding of the details of why OSCAR [or switcher] doesn't do something before I prescribe a big fat RTFM to a user. Information armament, if you will.
Jeremy
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
