modules-interest — Discussion forum for modules usage.

Re: Perl Env::Modulecmd

[Ron I. <Ron...@mo...>]

Hi Mark --

(cc'ing to modules-interest with explanations)

Mark Lakata wrote:
> 
> Is this different from the standard perl interface?
> 
>  require "$ENV{MODULESHOME}/init/perl";
>  module("load","fred/1.0");
>  module("unload","sheila/4.5b");

It's similar in theory, but it does quite a bit more error checking, and
gives you a nicer syntax. Also, (depending on usage) it loads modules at
compile-time so the environment is always prepared before runtime
begins. This can be important if you have Perl code that depends on the
environment for its initialization.

> Actually, I had trouble installing the package:
[...]
> I think this is because "modulecmd" is not on my path... now we've got a
> chicken/egg problem: how do you add 'modulecmd' to the path if the
> Env::Modulecmd isn't loaded yet ? :)

Heh... indeed. This depends on modulecmd being in the path, and
$MODULEPATH being set. You can set $PERL_MODULECMD to get around the
first one... but it seems the init code that comes with 3.0.0 does some
other fancy things for you. We still use 2.2.1.1, and we don't use the
init functions or the .modulespath file, so I never came across this.
Perhaps another release that addresses these is in order. Stay tuned!

Thanks for the feedback.

--
Ron Isaacson
Morgan Stanley
ron...@mo... / (718) 754-2345

Perl Env::Modulecmd

[Ron I. <Ron...@mo...>]

Hello all --

Here at Morgan Stanley, we make extensive use of modulefiles. We have at
least one Perl package that requires that a particular modulefile be
loaded, or it will not function. I decided to develop a Perl module to
automate this process. (Actually, the most difficult part was not
confusing everybody with the dual meaning of the term "module"! Heh...)

There is now a module on CPAN called Env::Modulecmd. You can download it
from your favorite CPAN mirror, or directly from the main CPAN site at
http://www.cpan.org/authors/id/I/IS/ISAACSON/Env-Modulecmd-1.0.tar.gz .
Documentation is included, and the module is very easy to install and
use.

If you try out this module and have any feedback (positive or negative),
please pass it along. Suggestions and bug reports are welcome.

--
Ron Isaacson
Morgan Stanley
ron...@mo... / (718) 754-2345

Re: module bug in 3.0.8

[Sven U. <ut...@ko...>]

> > If I was using module 3.*, I would be posting a lot of bug reports. I
> > tried 3.1, and found an embarrasing bug, like trying to unload a module
> > twice would cause it to segv (I think Robert Minsk fixed this bug in the
> > latest patch). This lead me to believe that it wasn't stable. So I tried
> > 3.0, and I get segv's with the xrdb stuff. And maybe it is just my
> > imagination, but it 3.* appears to run slower than 2.2beta.

> About 4 months ago, I sent an e-mail to this mailing list reporting
> a segmentation fault I encountered in modules-3.1.0b.  You responded
> that you encountered the similar problem.  Within a week, Robert
> Minsk released modules-3.1.1.
> 
> I downloaded modules-3.1.1 and installed it using Tcl 8.3.2.  4
> months have passed, and it has been working great since then.  It is
> being used by more than 30 users to manage more than 80 utilities
> installed, 

Similar here.  I'm still running modules-3.0.6-rko (why?  I installed
modules-3.1.1, but it looks like I never bothered to upgrade.
Strange).  It is used by (at least) 50 Users to manage up to 150
different (versions of) tools, and my only complaint now that I
increased the maximum length of environment variables to 4KB(*) is the
one that the module xxx/yyy/zzz will be displayed as yyy/zzz in the
list of modules (maybe this is fixed in 3.1.1?).

So, please, keep up the good work

Sven

(*) before that it used to react fairly unstable once the path got to
    long, crashing, forgetting which modules where loaded, refusing to
    unload and more...
-- 
 _  __                     The Cognitive Systems Group
| |/ /___  __ _ ___                                       University of Hamburg
| ' </ _ \/ _` (_-<  phone:    +49 (0)40 42883-2576      Vogt-Koelln-Strasse 30
|_|\_\___/\__, /__/  fax  :    +49 (0)40 42883-2572             D-22527 Hamburg
          |___/ http://kogs-www.informatik.uni-hamburg.de/~utcke/home.html

MetaLab action notice from the `keeper' program

[Serena F. <fe...@me...>]

At about 2001-06-11 13:33:58 UCT, `keeper' moved the following files from
Incoming to utils/shell (things you need for doing serious shell programming):

modules-3.1.1-3.1.2.diff.gz provides for the dynamic modification of a user's environment via modulefiles. 
modules-3.1.2.tar.gz     provides for the dynamic modification of a user's environment via modulefiles.
modules.lsm              

Thank you for your contribution of time, effort, and creativity.

This message was a form letter generated by keeper 1.54, but replying to
it will reach the human who told keeper what to do.  You got this note
because you're listed as a maintainer or author in the archive part involved.
If your package was actually uploaded by someone else, and you know who that
person is, please try to get that person to list him or herself in the LSM.  
--
			fents (MetaLab co-maintainer)

RE: module bug in 3.0.8

[Hon-Chi N. <hon...@my...>]

Hi Mark

>Date: Fri, 8 Jun 2001 09:24:03 -0700 (PDT)
>From: Mark Lakata <la...@mi...>
>To: Leo Butler <le...@le...>
>Cc: mod...@En...
>Subject: RE: module bug in 3.0.8
>
  ...
>
>If I was using module 3.*, I would be posting a lot of bug reports. I
>tried 3.1, and found an embarrasing bug, like trying to unload a module
>twice would cause it to segv (I think Robert Minsk fixed this bug in the
>latest patch). This lead me to believe that it wasn't stable. So I tried
>3.0, and I get segv's with the xrdb stuff. And maybe it is just my
>imagination, but it 3.* appears to run slower than 2.2beta.
>
>I built using tcl8.0. That's what was on the system at the time, and the
>./configure script didn't complain.

About 4 months ago, I sent an e-mail to this mailing list reporting a segmentation fault I encountered in modules-3.1.0b.  You responded that you encountered the similar problem.  Within a week, Robert Minsk released modules-3.1.1.

I downloaded modules-3.1.1 and installed it using Tcl 8.3.2.  4 months have passed, and it has been working great since then.  It is being used by more than 30 users to manage more than 80 utilities installed, including about 20 EDA tools where each tool has several versions installed.  These users have been actively using modules-3.1.1 daily and none of the users have so far report any problem.

My testimonial won't be the only one among many other users of modules.  I'm sure there are many users out there can confirm my finding.

>
>I hate to sound anal (I know I am), but something as low level as
>'module' needs to be extremely robust. We have enough problems with the
>other tools that 'module' loads... :)

Yes, given "module" is used to manage other tools, especially tools as complex as EDA tools, it needs to be robust, just like Unix shells.  
But, how?   Just an user, since I'm not knowledgeable enough to modify and enhance it, I make my "minute" contribution by trying it, using it and reporting any bugs to the developers, e.g. Robert Minsk & R K Owen, so that they can continue improving modules-3.*.  They already demonstrate their greatness by voluntarily giving their time and effort to improve it, at least as an user, I can help them testing it, and let them know if something is broken.

In order for it to become robust and stable, as you want it to be, it needs positive criticism, not negative.  As you mentioned that you know how to hack modules, why not spend your effort and demonstrate your skill by improving modules-3.1.1?  I'm sure all modules-3.1.1 users can benefit from it.

Let's move on (modules-3.1.1) and leave the past (modules-2.2b) behind.  :^)

>
>-Mark

Just my 2c.

Regards
Hon-Chi


------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/

RE: module bug in 3.0.8

[Mark L. <la...@mi...>]

> Hello, Mark.
> 
> Disclaimer: just a user, not clueful enough to develop.
> 
> I wrestled with whether or not to stick with modules-2.2b (already
> deployed in parts of the company, working mostly fine) or move to
> modules-3.1.1 (built, tested, working fine for me).  I opted to make
> the move to the newer version for the following reasons:
> 
>   1. modules-2.2b is a dead-end; doesn't build well with newer
>      versions of Tcl, and should we find some new feature that
>      we wish to use that exhibits a bug, there's no recourse.

I hacked modules-2.2b to build with the late(st) versions of tcl, and even
offered to post the patches, but the offer was politely declined.
 
>   2. active development on modules-3.x by (primarily) R.K. Owen
>      and Robert Minsk, perhaps other anonymous contributors.
> 
>   3. some cool features added recently like "is-loaded". (Thanks,
>      Robert.)
 
> The modules-interest list has been kinda quiet lately, but that's
> probably due in large part to the stability of modules-3.1.1.  I
> would suggest you try that version, and use a fairly modern version
> of Tcl.  If the problem persists, please post more info (OS version,
> build options, Tcl version, etc.).

or the stability of 2.2beta...

If I was using module 3.*, I would be posting a lot of bug reports. I
tried 3.1, and found an embarrasing bug, like trying to unload a module
twice would cause it to segv (I think Robert Minsk fixed this bug in the
latest patch). This lead me to believe that it wasn't stable. So I tried
3.0, and I get segv's with the xrdb stuff. And maybe it is just my
imagination, but it 3.* appears to run slower than 2.2beta.

I built using tcl8.0. That's what was on the system at the time, and the
./configure script didn't complain.

I hate to sound anal (I know I am), but something as low level as
'module' needs to be extremely robust. We have enough problems with the
other tools that 'module' loads... :)

-Mark

RE: module bug in 3.0.8

[Leo B. <le...@le...>]

Mark Lakata (la...@mi...) wrote:

> I am hesitant to upgrade for modules 3.* because of the many bugs (segvs)
> I have seen. Modules 2.2-beta seems to be much more stable (I have never
> seen a segv).
>
> Here's an example: I can load 'ie' and 'xdiff' independently, but if I try
> loading both, it bombs out. It must be the 'xrdb -merge' command that is
> the trouble maker, since I can load other modules without problem. If I
> had more time, I would try to debug it, but modules 2.2beta is working
> fine for us. Is there a compelling reason to switch to 3.*?
>
> [snippage]
>
> spark,~> module load ie
> spark,~> module load xdiff
> spark,~> module load ie xdiff
> Segmentation fault
> [more snippage]

Hello, Mark.

Disclaimer: just a user, not clueful enough to develop.

I wrestled with whether or not to stick with modules-2.2b (already
deployed in parts of the company, working mostly fine) or move to
modules-3.1.1 (built, tested, working fine for me).  I opted to make
the move to the newer version for the following reasons:

  1. modules-2.2b is a dead-end; doesn't build well with newer
     versions of Tcl, and should we find some new feature that
     we wish to use that exhibits a bug, there's no recourse.

  2. active development on modules-3.x by (primarily) R.K. Owen
     and Robert Minsk, perhaps other anonymous contributors.

  3. some cool features added recently like "is-loaded". (Thanks,
     Robert.)

The modules-interest list has been kinda quiet lately, but that's
probably due in large part to the stability of modules-3.1.1.  I
would suggest you try that version, and use a fairly modern version
of Tcl.  If the problem persists, please post more info (OS version,
build options, Tcl version, etc.).

Cheers,

- Leo

module bug in 3.0.8

[Mark L. <la...@mi...>]

I am hesitant to upgrade for modules 3.* because of the many bugs (segvs) 
I have seen. Modules 2.2-beta seems to be much more stable (I have never
seen a segv).

Here's an example: I can load 'ie' and 'xdiff' independently, but if I try
loading both, it bombs out. It must be the 'xrdb -merge' command that is
the trouble maker, since I can load other modules without problem. If I
had more time, I would try to debug it, but modules 2.2beta is working
fine for us. Is there a compelling reason to switch to 3.*?

sincerely,
Mark


spark,~> module load ie
spark,~> module load xdiff
spark,~> module load ie xdiff
Segmentation fault
spark,~> module display ie xdiff
-------------------------------------------------------------------
/mips/tools/freeware/modulefiles/ie/5:

Microsoft Internet Explorer 5 for Unix/Solaris

The executable is called 'iexplorer'

module-whatis    Microsoft Internet Explorer, web browser 
prepend-path     PATH /mips/tools/freeware/ie5/bin 
xrdb -merge      Iexplorer*background: #c0c0c0 
-------------------------------------------------------------------
-------------------------------------------------------------------
/mips/tools/freeware/modulefiles/xdiff/3.4:

module-whatis    xdiff, graphical diff browser 
prepend-path     PATH /mips/tools/freeware/xdiff-3.4 
xrdb -merge      /mips/tools/freeware/xdiff-3.4/xdiff.xrdb 
-------------------------------------------------------------------



Mark Lakata        1225 Charleston Road       voice 650-567-5170
MIPS Technologies  Mountain View CA 94043     fax   650-567-5002

Re: Building modulecmd on Linux

[Dave B. <ba...@ho...>]

Phil:

I agree, but the current owner of modules.org hasn't been doing anything
with it.  Dr. Owen can give more details about it, as warranted.

At one point, I had asked the owner about his willingness to give up the
domain, but IIRC, Dr. Owen and the domain owner have been in contact,
and that was the end of the discussion between the DO, and I.

HTH.

Dave

-- 
Dave Barnett	System Software Engineer	x2784


Stupidity got us into this mess -- why can't it get us out?

Re: Building modulecmd on Linux

[<Phi...@mo...>]

>>>>> "Dave" == Dave Barnett <ba...@ho...> writes:

Dave> ftp.modules.org is no longer updated, but might be revived, evenutally.

Dave> The "official" home for modules is now sourceforge.net.

Dave> Dr. RK Owen (he recently posted about the building of Modules on
Dave> Linux...) has taken over direction of the development for modules.

Dave> You should be able to find the code at
Dave> ftp://modules.sourceforge.net/pub/modules as he suggested.

Hmm.  Well, if this is the case, then someone should really update the
www.modules.org page to reflect this.  That has 2 year old, stale
information on it, and that will just mislead people (as it did me).

Re: Building modulecmd on Linux

[Dave B. <ba...@ho...>]

Phil:

ftp.modules.org is no longer updated, but might be revived, evenutally.

The "official" home for modules is now sourceforge.net.

Dr. RK Owen (he recently posted about the building of Modules on
Linux...) has taken over direction of the development for modules.

You should be able to find the code at
ftp://modules.sourceforge.net/pub/modules as he suggested.


HTH.

Dave

-- 
Dave Barnett	System Software Engineer	x2784


If the #2 pencil is the most popular, why is it still #2?

Building modulecmd on Linux

[<Phi...@mo...>]

>>>>> "Phil" == Phil Moore <Phi...@mo...> writes:

Phil> We use the modules infrastructure to manage our shell environments
Phil> here at Morgan Stanley.  I brought the code along with me when I left
Phil> my previous employer back in 1992, and it has been very, very stable
Phil> for the past 9 years.

Phil> Now, I'm trying to build modulecmd on Linux, and getting stuck on:

Phil> gcc -c  -I.. -I. -I/ms/dist/tcl/VERS/8.0/include  -O2  utility.c
Phil> utility.c:488: initializer element is not constant

Many thanks to all the responses.  I was able to get our existing
2.2beta release hacked to compile, so we're over that hump.

Next, I need to look at getting us uptodate with a 3.X release.

But....

ftp.modules.org hasn't been responding for sometime.  I got a couple
of private pointers to copies of 3.1.1, but being a suspicious
untrusting paranoiac I'd like to be able to get the source from
modules.org.

Who maintains the www.modules.org website and the ftp.modules.org
archives?

Re: Building modulecmd on Linux

[R.K. O. Ph.D. <rk...@ow...>]

>
> I just re-joined this list after about 5 years off of it.  I noticed
> that on www.modules.org that things appear to have been revived, but
> that document is 2 years old, so I'm not so sure.
>
> We use the modules infrastructure to manage our shell environments
> here at Morgan Stanley.  I brought the code along with me when I left
> my previous employer back in 1992, and it has been very, very stable
> for the past 9 years.
>
> Now, I'm trying to build modulecmd on Linux, and getting stuck on:
>
> gcc -c  -I.. -I. -I/ms/dist/tcl/VERS/8.0/include  -O2  utility.c
> utility.c:488: initializer element is not constant
>
> Line 488 seems pretty innocuous:
>
> static FILE* aliasfile = stdout;
>
> But stdout is no longer a constant on Linux, so....  compile error.
>
> This problem is for the 2.2 release, and I see the same problem with
> 3.0 as well.  The platform is:
>
> (system:anyuser/wpm/wpm) uname -a
> Linux mglnxcs01 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown
>
> I would be shocked if I'm the first person to build this on Linux.
>
What you probably grabbed was the 3.0pre version.  There has been some
work on the 3.0 version which can be grabbed from
ftp://modules.sourceforge.net/pub/modules

As mentioned elsewhere, it's pretty stable, with a couple of caveats.
It compiles with almost any version of Tcl (no need to have access
to the Tcl internal headers).  It uses the GNU configure script,
and has much more capability.  And has a GPL.

Some folks are really married to the 2.2 version though and can't
tolerate any gotcha's that the 2.2 version handled well (like
deep modulefile directories).

Any code patches will be gratefully accepted.

Your mileage may vary,
	R.K.

+-----------------------+----------------------------------+
| R.K.Owen,PhD          | rk...@ow...   (408)377-5373 |
| KooZ Software         |                                  |
| NERSC/LBNL            | rk...@ne...   (510)486-7556 |
+-----------------------+----------------------------------+

Re: Building modulecmd on Linux

[Jonathan T. <jtu...@lu...>]

Phil,

I have built Modules Release 3.0.7-rko on RedHat v6.2 without issue.  This
seems to be a very stable version -- at least for us.  We have been using
it for 2 years, and have had no problems.  I also have it running with
Solaris 2.7.  Again, no problems.

Jon Turenne

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jonathan P. Turenne      Main Phone : (978) 692-2600
Lucent Technologies      Direct Line: (978) 952-7736
EDA Tools Group          Fax:         (978) 392-9250

Email:  jtu...@lu... 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Thu, 5 Apr 2001 Phi...@mo... wrote:

> 
> I just re-joined this list after about 5 years off of it.  I noticed
> that on www.modules.org that things appear to have been revived, but
> that document is 2 years old, so I'm not so sure.
> 
> We use the modules infrastructure to manage our shell environments
> here at Morgan Stanley.  I brought the code along with me when I left
> my previous employer back in 1992, and it has been very, very stable
> for the past 9 years.
> 
> Now, I'm trying to build modulecmd on Linux, and getting stuck on:
> 
> gcc -c  -I.. -I. -I/ms/dist/tcl/VERS/8.0/include  -O2  utility.c
> utility.c:488: initializer element is not constant
> 
> Line 488 seems pretty innocuous:
> 
> static FILE* aliasfile = stdout;
> 
> But stdout is no longer a constant on Linux, so....  compile error.
> 
> This problem is for the 2.2 release, and I see the same problem with
> 3.0 as well.  The platform is:
> 
> (system:anyuser/wpm/wpm) uname -a
> Linux mglnxcs01 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown
> 
> I would be shocked if I'm the first person to build this on Linux.
> 

Re: Building modulecmd on Linux

[Mark L. <la...@mi...>]

I had to hack the 2.2beta source to get it to compile under Linux. This is
what I did to get around the error you mention. I also had to hack the
Module*.c code to work with a newer version of tcl.

I offered to post these fixes (for HP-UX also), but I was told that
2.2beta is not supported, so no one wanted them.

-Mark


spark,Modules-v2.2BETA-mine> diff main.c*
66d65
< extern FILE* aliasfile;
73,74d71
<   aliasfile = stdout;
< 
Exit 1

spark,Modules-v2.2BETA-mine> diff utility.c*
44,51d43
< #if __linux__
< #include <string.h>
< #include <sys/types.h>
< #include <sys/stat.h>
< #include <fcntl.h>
< #include <stdlib.h>
< #endif
< 
496c488
< FILE* aliasfile;
---
> static FILE* aliasfile = stdout;
Exit 1


Mark Lakata
MIPS Technologies      
1225 Charleston Road   
Mountain View, CA 94043
phone 650-567-5170
fax   650-567-5002
email la...@mi...

On Thu, 5 Apr 2001 Phi...@mo... wrote:

> 
> I just re-joined this list after about 5 years off of it.  I noticed
> that on www.modules.org that things appear to have been revived, but
> that document is 2 years old, so I'm not so sure.
> 
> We use the modules infrastructure to manage our shell environments
> here at Morgan Stanley.  I brought the code along with me when I left
> my previous employer back in 1992, and it has been very, very stable
> for the past 9 years.
> 
> Now, I'm trying to build modulecmd on Linux, and getting stuck on:
> 
> gcc -c  -I.. -I. -I/ms/dist/tcl/VERS/8.0/include  -O2  utility.c
> utility.c:488: initializer element is not constant
> 
> Line 488 seems pretty innocuous:
> 
> static FILE* aliasfile = stdout;
> 
> But stdout is no longer a constant on Linux, so....  compile error.
> 
> This problem is for the 2.2 release, and I see the same problem with
> 3.0 as well.  The platform is:
> 
> (system:anyuser/wpm/wpm) uname -a
> Linux mglnxcs01 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown
> 
> I would be shocked if I'm the first person to build this on Linux.
> 
> 

Building modulecmd on Linux

[<Phi...@mo...>]

I just re-joined this list after about 5 years off of it.  I noticed
that on www.modules.org that things appear to have been revived, but
that document is 2 years old, so I'm not so sure.

We use the modules infrastructure to manage our shell environments
here at Morgan Stanley.  I brought the code along with me when I left
my previous employer back in 1992, and it has been very, very stable
for the past 9 years.

Now, I'm trying to build modulecmd on Linux, and getting stuck on:

gcc -c  -I.. -I. -I/ms/dist/tcl/VERS/8.0/include  -O2  utility.c
utility.c:488: initializer element is not constant

Line 488 seems pretty innocuous:

static FILE* aliasfile = stdout;

But stdout is no longer a constant on Linux, so....  compile error.

This problem is for the 2.2 release, and I see the same problem with
3.0 as well.  The platform is:

(system:anyuser/wpm/wpm) uname -a
Linux mglnxcs01 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown

I would be shocked if I'm the first person to build this on Linux.

Examples?

[Leo B. <lb...@br...>]

Hello, all.

I'm interested in helping to put together a document for
distribution with modules that includes examples of some
standard and advanced modulefiles.  My motivation comes
from two sources; one, to give something useful back to
the project and two, to learn something new.  I was taught
a few techniques in the last year that have served me and
my group well; it just seems natural to formalize some of
these into a document to share with others.

Examples I know of:
  o Using a modulefile to handle default software
    versioning on a project (modulefile loading
    and unloading other modulefiles)
  o Sharing a license file between multiple
    modulefiles
  o Automatically unloading a modulefile upon a
    "module load" of a different version

There are some other experiments that I've run in the
past that I sadly did not document well; another reason
to get some of this into a shared document.

Do others have any interest in doing this as well?

Cheers,

- Leo
 
----------------------------------------------------------------------
Leo Butler                                         Staff ASIC Engineer
Brocade Communications                           Phone: (408) 487-8096
1745 Technology Drive                            Fax:   (408) 392-6675
San Jose, CA 95110                          mailto:lb...@br...

configure created from autoconf differs from CVS configure

[Ted S. <st...@cr...>]

I find that the CVS configure differs from the configure created by autoconf
from the configure.in file.  In particular, the python target is not created
correctly using the CVS configure.  However, if I remove configure and run
autoconf to regenerate it, it creates the python target correctly.

Is this just a typo in the configure file?  Was it updated when configure.in
was modified?

Ted
-- 
 Ted Stern                                          Engineering Applications
 Cray Inc.                                               http://www.cray.com
 411 First Avenue South, Suite 600    Direct 206-701-2182, Main 206-701-2000
 Seattle, WA 98104-2860                                    FAX  206-701-2500

ps file for doc?

[Erich W. <ewh...@ax...>]

Hello,

I'm referring to the 3.1.1 distribution of Modules:

The file doc/Modules-Paper.doc appears to be in Framemaker format not in
Postscript as noted in the README file. Is there a postcript or PDF version
of this paper somewhere on the net I can take a look at? I am writing a
paper for a technical conference about using Modules in a engineering
development environment and I'd like to make proper references to the source
material.

Thanks,

Erich Whitney
Axiowave Networks, Inc.
Phone: (508) 460-6969 ext 765
Fax: (508) 460-8111
E-mail: ewh...@ax...
Web: http://www.axiowave.com

Re: installation requirements

[Istvan M. <mi...@im...>]

Hi Ted,

I am not involved with the Modules development but I will try to
answer your questions:

Ted Stern <st...@cr...> writes:

> It appears that the modules package depends on X libraries.  What specific
> part of the package requires this?  X is a pretty big thing to depend on,
> especially for supercomputers that would not primarily be used for X
> applications.

Only the x-resource command needs to X11 libraries and you can compile
without X11 by passing --without-x to configure.

> Tcl dependency:  Is there a minimal prerequisite subset of Tcl for modules?
> It seems like it would be more efficient to require only the locations of
> the static libtcl.a library or equivalent, and the location of the init.tcl
> file.  

At compile time you will also need the TCL header files.

> And since the init.tcl file is not only a prerequisite but a
> run-time requirement, perhaps an example modulefile that sets
> modules-specific environment variables pointing to the init.tcl file
> should be provided.

Looks like init.tcl is loaded before any modulefiles are looked
at. There maybe an environment variable to override the initial search
path that you could set from the init shell fragments but I couldn't
figure out what it is.
-- 
	Istvan

installation requirements

[Ted S. <st...@cr...>]

Hello Environment Modules people --

I'm one of the people keeping tabs on the CVS state of modules development.
As has long been Cray practice, we intend to continue using environment
modules to help organize the programming environment for users and developers.
Not only that, we would like to have pretty much the same kind of modules
interface on all of our platforms.  But this brings up a few questions about
installation prerequisites in recent versions of modules.

It appears that the modules package depends on X libraries.  What specific
part of the package requires this?  X is a pretty big thing to depend on,
especially for supercomputers that would not primarily be used for X
applications.

Tcl dependency:  Is there a minimal prerequisite subset of Tcl for modules?
It seems like it would be more efficient to require only the locations of
the static libtcl.a library or equivalent, and the location of the init.tcl
file.  And since the init.tcl file is not only a prerequisite but a run-time
requirement, perhaps an example modulefile that sets modules-specific
environment variables pointing to the init.tcl file should be provided.

Sorry if these questions appear naive, I come to this from the user, not
the OS, side of the house.

-- 
 Ted Stern                                          Engineering Applications
 Cray Inc.                                               http://www.cray.com
 411 First Avenue South, Suite 600    Direct 206-701-2182, Main 206-701-2000
 Seattle, WA 98104-2860                                    FAX  206-701-2500

modules 3.1.1 - .version files broken

[David C. M. <dav...@lm...>]

While evaluating modules 3.1.1 against our old standby 2.2b, I see that 3.1.1 has improved, but processing of the .version files is broken.  The .version file does not seem to be used beyond the second level of module file directory.  For example mtest/.version file is sourced and sets a ModulesVersion (2.0) at this directory level.  However, when in mtest/2.0, the mtest/2.0/.version file is not used or intrepreted to set the ModulesVersion at this directory level.  Consequently, the intended default
version is not set and the desired modulefile is not intrepreted.

Maintainers: Is this sufficient information for you to investigate?

Thanks,
Dave

Re: Segmentation fault on Modules-3.1.0b in tcsh

[Mark L. <la...@mi...>]

I had the same problem a few weeks ago. It has been fixed, but I don't
know if a new version has been released yet. In the meantime, I am using
the more reliable 2.2beta.

-Mark

Mark Lakata
MIPS Technologies      
1225 Charleston Road   
Mountain View, CA 94043
phone 650-567-5170
fax   650-567-5002
email la...@mi...

On Mon, 29 Jan 2001, Hon-Chi Ng wrote:

> Hi
> 
> Has anyone encountered "Segmentation fault" error when running "module"
> command of modules-3.1.0b on tcsh or csh?  Specifically, "module unload" and
> "module list"?
> 
> The "module" command runs fine most of the time.  What I have noticed is if
> I ran "module unload" for once or twice, it started to give "Segmentation
> fault" errors on subsequent "module unload" & "module list" commands.
> 
> However, it rarely gives error on "module avail", "module whatis", "module
> help", "module display" & "module load" commands.
> 
> In addition, it doesn't always fail on the same module command, as depending
> on the previous module commands executed.
> 
>   % module unload gcc
>   Segmentation fault
> 
>   % module list
>   Currently Loaded Modulefiles:
>   Segmentation fault
> 
> I also tried to use --verbose option for module, but it didn't get any
> additional message before "Segmentation fault" error message.
> 
> I only encountered the "Segmentation fault" error on tcsh and csh, but I
> can't duplicate it under bash.
> 
> I ran it on tcsh 6.10.  BTW, I believe my tcsh 6.10 is stable as I've been
> using it for the last 2 months without problem, except the above.  And I
> also duplicate the problem on tcsh 6.09, which has been running without
> problem for more than 1 year.  I can also duplicate the problem on Solaris
> /bin/csh.
> 
> I configured my modules-3.1.0b with default options except
>     --prefix=
>     --with-module-path=
>     --with-version-path=
>     --with-tcl-libraries=
>     --with-tcl-include=
> 
> I built it using gcc 2.95.2 and linked it to Tcl 8.3.2 on Solaris 2.7.
> 
> Is it a bug in modules-3.1.0, or is it caused by user error?  If it's user
> error, what are the possible mistakes I made that might lead to it?
> 
> Thanks.  Your help is highly appreciated.
> 
> 
> Regards
> Hon-Chi
> 
> 
> ------------------------------------------------------------
> --== Sent via Deja.com ==--
> http://www.deja.com/
> 
> 
> 

Re: Segmentation fault on Modules-3.1.0b in tcsh

[Robert M. <eg...@ce...>]

Hon-Chi Ng wrote:
> 
> Hi
> 
> Has anyone encountered "Segmentation fault" error when running "module"
> command of modules-3.1.0b on tcsh or csh?  Specifically, "module unload" and
> "module list"?
> 
> The "module" command runs fine most of the time.  What I have noticed is if
> I ran "module unload" for once or twice, it started to give "Segmentation
> fault" errors on subsequent "module unload" & "module list" commands.
> 
> However, it rarely gives error on "module avail", "module whatis", "module
> help", "module display" & "module load" commands.
> 
> In addition, it doesn't always fail on the same module command, as depending
> on the previous module commands executed.
> 
>   % module unload gcc
>   Segmentation fault
> 
>   % module list
>   Currently Loaded Modulefiles:
>   Segmentation fault
> 
> I also tried to use --verbose option for module, but it didn't get any
> additional message before "Segmentation fault" error message.
> 
> I only encountered the "Segmentation fault" error on tcsh and csh, but I
> can't duplicate it under bash.
> 
> I ran it on tcsh 6.10.  BTW, I believe my tcsh 6.10 is stable as I've been
> using it for the last 2 months without problem, except the above.  And I
> also duplicate the problem on tcsh 6.09, which has been running without
> problem for more than 1 year.  I can also duplicate the problem on Solaris
> /bin/csh.
> 
> I configured my modules-3.1.0b with default options except
>     --prefix=
>     --with-module-path=
>     --with-version-path=
>     --with-tcl-libraries=
>     --with-tcl-include=
> 
> I built it using gcc 2.95.2 and linked it to Tcl 8.3.2 on Solaris 2.7.
> 
> Is it a bug in modules-3.1.0, or is it caused by user error?  If it's user
> error, what are the possible mistakes I made that might lead to it?
> 
> Thanks.  Your help is highly appreciated.
> 
> Regards
> Hon-Chi
> 
> ------------------------------------------------------------
> --== Sent via Deja.com ==--
> http://www.deja.com/

I have located the bug and I am trying to figure out how to generate a
release on sourceforge.  I will try to release a new version as soon as
possible.
--
Robert Minsk                            Centropolis Effects, LLC.
eg...@ce...                10950 Washington Blvd., Studio B
                                        Culver City, Ca. 90232-4025

Segmentation fault on Modules-3.1.0b in tcsh

[Hon-Chi N. <hon...@my...>]

Hi

Has anyone encountered "Segmentation fault" error when running "module"
command of modules-3.1.0b on tcsh or csh?  Specifically, "module unload" and
"module list"?

The "module" command runs fine most of the time.  What I have noticed is if
I ran "module unload" for once or twice, it started to give "Segmentation
fault" errors on subsequent "module unload" & "module list" commands.

However, it rarely gives error on "module avail", "module whatis", "module
help", "module display" & "module load" commands.

In addition, it doesn't always fail on the same module command, as depending
on the previous module commands executed.

  % module unload gcc
  Segmentation fault

  % module list
  Currently Loaded Modulefiles:
  Segmentation fault

I also tried to use --verbose option for module, but it didn't get any
additional message before "Segmentation fault" error message.

I only encountered the "Segmentation fault" error on tcsh and csh, but I
can't duplicate it under bash.

I ran it on tcsh 6.10.  BTW, I believe my tcsh 6.10 is stable as I've been
using it for the last 2 months without problem, except the above.  And I
also duplicate the problem on tcsh 6.09, which has been running without
problem for more than 1 year.  I can also duplicate the problem on Solaris
/bin/csh.

I configured my modules-3.1.0b with default options except
    --prefix=
    --with-module-path=
    --with-version-path=
    --with-tcl-libraries=
    --with-tcl-include=

I built it using gcc 2.95.2 and linked it to Tcl 8.3.2 on Solaris 2.7.

Is it a bug in modules-3.1.0, or is it caused by user error?  If it's user
error, what are the possible mistakes I made that might lead to it?

Thanks.  Your help is highly appreciated.


Regards
Hon-Chi


------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/