modules-interest — Discussion forum for modules usage.

Re: [Modules] Compiling on Solaris 2.8?

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

What version of ld are you using? try 'ld --version' or 'which ld'

This mailing list is the support/user group/FAQ etc! :)


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

On Thu, 15 Aug 2002, Remme, Steve K wrote:

> Has anyone gotten this to successfully compile on Solaris 2.8? I'm getting
> core dumps on 'ld'. Are there any other support/user groups? FAQs? Any tips,
> hints, ideas would be appreciated.
> 
> Thanks!!
> 
> 
> Steve Remme
> Dev Engr, Sr
> 303.673.6966 voice  
> StorageTek
> INFORMATION made POWERFUL
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

[Modules] Compiling on Solaris 2.8?

[Remme, S. K <Re...@LO...>]

Has anyone gotten this to successfully compile on Solaris 2.8? I'm getting
core dumps on 'ld'. Are there any other support/user groups? FAQs? Any tips,
hints, ideas would be appreciated.

Thanks!!


Steve Remme
Dev Engr, Sr
303.673.6966 voice  
StorageTek
INFORMATION made POWERFUL

[Modules] Modules vs UPS

[Stefan S. <st...@ra...>]

Modules and Unix Product Support (UPS) are both products in the same
field, although UPS is a somewhat larger system.

Has someone compared Modules to UPS, and is this comparision documented 
somewhere?

Information on UPS can be found at http://www.fnal.gov/docs/products/ups/.

Stefan

Re: [Modules] Modules setup in cross-platform environments

[Stefan S. <st...@ra...>]

> As far as OS dependencies...in the modulefile
> add code like this...
> 
> set osname [ uname sysname ]
> 
> if {[ string compare $osname "SunOS" ] == 0} {
>     set ncdir   /<path>/toolX
>     set nctools tools.sun4v
> } elseif {[ string compare $osname "Linux" ] == 0} {
>     set ncdir /<path>/toolX-linux
>     set nctools tools.lnx86
> } else {
>     # some kind of error!
>     puts stderr "Error: This OS, $osname, is not 
> supported with\
>         [module-info specified]!"
> }

Thank you. It was mostly this I was looking for. Will be a little work for 
every modulefile, since platform support are not built into Modules.

Stefan

Re: [Modules] little used features

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

On Mon, 29 Jul 2002, R. K. Owen Ph D. wrote:
> On Mon, 29 Jul 2002, David C. Mores wrote:
>> 'Modules avail' is a crucially important function.  How would one otherwise
>> determine what modulefiles and versions of modulefiles are available?  You
>> cannot expect all user to be smart enough to go 'ls' the modulefile areas.
>> After all, isn't one of the principles here to isolate users from having to
>> know inner workings like this?
>> 
> 
> "module avail" would not go away; however, without caching, it would just
> descend through the entire modulefile tree each time a "module avail"
> is requested.  It would be comparable to doing a "find" on a modulefile
> directory tree, (and reading and interpreting every .version/.modulerc
> file it finds).
> 

Apropos such features --

Sometimes a command doesn't have the same name as its module.  It seems to me
that something like

     module whereis exename

could be extremely helpful for the average user, but the only way I can
imagine this could work would be if the administrator ran some command
periodically to create a "whereis" cache for each module.

Ted
-- 
 Ted Stern                           Engineering Applications
 Cray Inc.                                http://www.cray.com
 411 First Avenue South, Suite 600               206-701-2182
 Seattle, WA 98104-2860                     FAX: 206-701-2500
 Debuggers' motto:  Frango ut patefacium -- I break in order to reveal

Re: [Modules] little used features

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

"R.K. Owen Ph.D." <rk...@Ow...> writes:

> Hello, I have a couple of questions, because of all the respondents
> you may be the most affected by the semantic changes.
>
> So for the example below you have the bar module load foo with:
> 	module load foo/bar
>
> and that the .modulerc file exists at the modulefile "root"?

No, the modulerc is at $MODULEPATH/foo/.modulerc, a separate one for
each package:

$MODULEPATH/
  foo/
    .modulerc
    4.1.1
    5.2
    5.2.1
    6.2
  otherpackage/
    .modulerc
    1.0
    2.0
  yapackage/
    .modulerc
    1.5
    1.6

> If so, then the proposed new semantics would be that the .modulerc
> file exists in the ./foo directory and would likely be:
>
> #%Module1.0
>
> module-version 4.1.1   obsolete_deleted_May2000
> module-version 5.2     bar  # this is the version to be used with package bar
> module-version /5.2.1   OBSOLETE-1020718c
> module-version /6.2     default
>
> where only "versions" are given with an optional prepended '/'
> and you continue to use "module load foo/bar" to load foo/5.2 .
>
> This .modulerc set-up would backwardly compatible too.

OK, so since we already have .modulerc inside foo all we'd need to do
is change the version numbers from foo/4.1.1 to 4.1.1 right? I will do
some tests with the current CVS version to see how it behaves on our
current setup and with this change.

-- 
	Istvan

Re: [Modules] little used features

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

On Mon, 29 Jul 2002, David C. Mores wrote:

> "R.K. Owen Ph.D." wrote:
> 
> >
> > 1) Does anyone use the .modulerc files?  To do things like
> >         module-version
> 
> Yes - although we use the older .version file to set a default version.  If you wish to remove this,
> then there needs to be an alternate way to set a default verison that can be different for different platforms.
> 

The .version file would not go away.  The current implementation does
a "module-version xxx default" under the covers, and this is how the
module-version mechanism sets default versions.

> >
> > 2) Caching for "module avail".  I rarely enable it for my own
> > systems, but I have maybe 50+ modulefiles on each.
> 
> 'Modules avail' is a crucially important function.  How would one otherwise determine what modulefiles and versions of modulefiles are available?  You cannot expect all user to be smart enough to go 'ls' the modulefile areas.  After all, isn't one of the principles here to isolate users from having to know inner workings like this?
> 

"module avail" would not go away; however, without caching, it would just
descend through the entire modulefile tree each time a "module avail"
is requested.  It would be comparable to doing a "find" on a modulefile
directory tree, (and reading and interpreting every .version/.modulerc
file it finds).

	R.K.

+------------------+---------------------+
| R.K.Owen,PhD     | rk...@ow...    |
| KooZ Software    | Environment Modules |
| NERSC/LBNL       | rk...@ne...    |
+------------------+---------------------+

Re: [Modules] little used features

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

Hello, I have a couple of questions, because of all the respondents
you may be the most affected by the semantic changes.

So for the example below you have the bar module load foo with:
	module load foo/bar

and that the .modulerc file exists at the modulefile "root"?

If so, then the proposed new semantics would be that the .modulerc
file exists in the ./foo directory and would likely be:

#%Module1.0

module-version 4.1.1   obsolete_deleted_May2000
module-version 5.2     bar  # this is the version to be used with package bar
module-version /5.2.1   OBSOLETE-1020718c
module-version /6.2     default

where only "versions" are given with an optional prepended '/'
and you continue to use "module load foo/bar" to load foo/5.2 .

This .modulerc set-up would backwardly compatible too.

	R.K.

On Sun, 28 Jul 2002 mi...@im... wrote:

> "R.K. Owen Ph.D." <rk...@Ow...> writes:
> 
> > 1) Does anyone use the .modulerc files?  To do things like
> >	module-version
> >	module-alias
> 
> We use .modulerc files extensively. We use Modules for about 60
> packages and have about 200 module files for various versions of
> these. We have a .modulerc for most of these packages with one or
> more module-version lines. Example:
> 
> #%Module1.0
> 
> module-version foo/4.1.1   obsolete_deleted_May2000
> module-version foo/5.2     bar  # this is the version to be used with package bar
> module-version foo/5.2.1   OBSOLETE-1020718c
> module-version foo/6.2     default
> 
> We don't use module-alias.
> 
> > 2) Caching for "module avail".  I rarely enable it for my own
> > systems, but I have maybe 50+ modulefiles on each.
> 
> We have this enabled but could live without it.
> 
> We are still using a locally hacked version of the old 3.0beta release
> but we are hoping to upgrade to a recent rko version at some point.
> 

Re: [Modules] little used features

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

"R.K. Owen Ph.D." wrote:

>
> 1) Does anyone use the .modulerc files?  To do things like
>         module-version

Yes - although we use the older .version file to set a default version.  If you wish to remove this,
then there needs to be an alternate way to set a default verison that can be different for different platforms.

>
>         module-alias

No - never was able to figure out the how or why for usings this.

>
> both of these commands rely on a shallow directory structure
> in their implementation.  I have never used them for my own
> use, though, and can only see a number of limited ways where
> they may be useful.

The .version file is in the old 2.2b version of modules, and has always been able to work with deep directory structures.

>
>
> I could just assume that both are broken and re-code both into
> a workable form, but with slightly different semantics.
>
> 2) Caching for "module avail".  I rarely enable it for my own
> systems, but I have maybe 50+ modulefiles on each.

'Modules avail' is a crucially important function.  How would one otherwise determine what modulefiles and versions of modulefiles are available?  You cannot expect all user to be smart enough to go 'ls' the modulefile areas.  After all, isn't one of the principles here to isolate users from having to know inner workings like this?

>
>
> At one of the sites I had frequented, they had hundreds of modulefiles
> where each package had modulefiles for various versions, and
> they never removed anything no matter how old and crufty.
>
> I tended to not do "module avail" there because they just had too
> much garbage to wade through.  (BTW - they used a serious old version,
> I used my own instead, but needed --disable-version-magic to read their
> .version files.)
>

You can always cut down on the garbage by doing a 'module avail xxx' (wild cards would be nice here) once you have identified the major application name of interest.

Dave

Re: [Modules] little used features

[Alexander B. <abo@e.kth.se>]

"R.K. Owen Ph.D." <rk...@Ow...> writes:

> 1) Does anyone use the .modulerc files?

Not us, I think.

> 2) Caching for "module avail".  I rarely enable it for my own
> systems, but I have maybe 50+ modulefiles on each.

We have lots of modules, but I'm thinking about writing a GUI app for
browsing/selecting among them. It would probably have its own cache anyway.

/abo

Re: [Modules] little used features

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

"R.K. Owen Ph.D." <rk...@Ow...> writes:

> 1) Does anyone use the .modulerc files?  To do things like
>	module-version
>	module-alias

We use .modulerc files extensively. We use Modules for about 60
packages and have about 200 module files for various versions of
these. We have a .modulerc for most of these packages with one or
more module-version lines. Example:

#%Module1.0

module-version foo/4.1.1   obsolete_deleted_May2000
module-version foo/5.2     bar  # this is the version to be used with package bar
module-version foo/5.2.1   OBSOLETE-1020718c
module-version foo/6.2     default

We don't use module-alias.

> 2) Caching for "module avail".  I rarely enable it for my own
> systems, but I have maybe 50+ modulefiles on each.

We have this enabled but could live without it.

We are still using a locally hacked version of the old 3.0beta release
but we are hoping to upgrade to a recent rko version at some point.

-- 
	Istvan

Re: [Modules] little used features

[Peter W. O. <pw...@In...>]

>>>>> On Sun, Jul 28, 2002 at 08:59:57AM -0700, "rk" == R.K. Owen Ph.D. <rk...@ow...> wrote:
rk> 1) Does anyone use the .modulerc files?  To do things like

not us (yet, though I do not remember why we wanted this in the first
place, there was something very smart we wanted to do, but it has
slipped my mind)

rk> 2) Caching for "module avail".

definitely yes (we have several hundred modulefiles ...)


Cheers
	--pwo

--
Peter W. Osel                   Sr. Network & Systems Manager
Infineon Technologies           Email: pw...@In...
North America Corp.             Phone: +1 (408) 501 6321
1730 North First Street         Fax:   +1 (408) 501 2410
San Jose, CA 95112, USA         WWW:   http://pwo.de/

pgp key fingerprint = 79 2D DD 49 C0 AA D8 CF  2C F9 A5 6A BA 37 0E 28

Re: [Modules] little used features

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

> 1) Does anyone use the .modulerc files?  To do things like

not us

> 2) Caching for "module avail".  I rarely enable it for my own
> systems, but I have maybe 50+ modulefiles on each.

not us


 
-Mark

[Modules] little used features

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

Hello All:

If you've been looking at the CVS repository for modules
( http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/modules/modules/ )
you may have noticed that there are lots of changes being
made for the upcoming 3.2 version.

The prime one for me is deep modulefile directories, and
I've had some success in making it happen.

However, there are some little used features (to me) that are causing great
difficulties, and I wanted to get a sense of what's being used out
there.

1) Does anyone use the .modulerc files?  To do things like
	module-version
	module-alias
both of these commands rely on a shallow directory structure
in their implementation.  I have never used them for my own
use, though, and can only see a number of limited ways where
they may be useful.

I could just assume that both are broken and re-code both into
a workable form, but with slightly different semantics.

2) Caching for "module avail".  I rarely enable it for my own
systems, but I have maybe 50+ modulefiles on each.

At one of the sites I had frequented, they had hundreds of modulefiles
where each package had modulefiles for various versions, and
they never removed anything no matter how old and crufty.

I tended to not do "module avail" there because they just had too
much garbage to wade through.  (BTW - they used a serious old version,
I used my own instead, but needed --disable-version-magic to read their
.version files.)

Your comments would be appreciated,
	R.K.

+------------------+---------------------+
| R.K.Owen,PhD     | rk...@ow...    |
| KooZ Software    | Environment Modules |
| NERSC/LBNL       | rk...@ne...    |
+------------------+---------------------+

RE: [Modules] Modules setup in cross-platform environments

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

David C. Mores (dav...@ba...) wrote:

> Your can use the .version or .modulerc to control which 
> version of an application is going to be the default on
> a particular platform with something like this:
> [snip]

Great example, David.

I just wanted to comment on your last paragraph:

> This is an arrangement we have been using successfully for 
> the past 10 years with Modules version 2.2b.  Version 3.x 
> still has problems with more than two directory levels.

Version 3.1.6 of modules is likely to be the last version
in the 3.1.x branch, and this issue won't be addressed there.
The code base has been undergoing a fairly significant rewrite
in the 3.2 branch, with the "greater than 2 levels" issue one
of the things being dealt with.

One group in our company is still on modules 2.2b as well,
although I moved my group over to 3.1.x some time ago.  I'm
looking forward to the >2 levels as well so we can all be on
the same version here.

I must say that I've been delighted with the fact that all of
the Tcl I've added to the modulefiles to implement various
features has been compatible between both versions of modules.

Just FYI.

Regards,

- Leo Butler

Re: [Modules] Modules setup in cross-platform environments

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

The other ideas proposed are fine ideas. When I used to work at Lawrence
Berkeley Labs, the directory stucture of the installed packages was NFS
mounted, so that different platforms would mount different physical disks a=
t
the same mount point. This made all of the modules platform independent.
However, that becomes somewhat of a headache of NFS administration.

We use [uname sysname] switches here.

-Mark

Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-517=
0
MIPS Technologies              Mountain View CA 94043     fax   650-567-500=
2

On Fri, 26 Jul 2002, Stefan Svensson wrote:

> I try to learn how to set up Modules, but I have not yet found any=20
> documentation on how to set up a cross-platform environment where you hav=
e=20
> different platforms (Solaris, HP-UX, SGI, Linux), os revisions (Solaris=
=20
> 5.6, 7, 8; HP-UX 9, 10.20, 11; etc) and, of course, different application=
=20
> versions.
>=20
> Are there any documents on this, does anyone have any experience - or do =
I=20
> have to find out the hard way? :-)
>=20
> Stefan
>=20
> --=20
> Stefan Svensson                     Phone: +46-90-135000
> Himlastigen 14                      WWW: http://raggmunk.nu/~stefan/
> 906 41 Ume=E5, Sweden                 ICQ: 1956984
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>=20

RE: [Modules] Modules setup in cross-platform environments

[Andy B. <AB...@in...>]

A quick note on versioning (mentioned below)...

When you do a "module load foo", assume you have a directory struct like
below:
Modules
	modulefiles
		foo
			1.0
			1.2
			1.10

Then the module actually loaded is the "latest". However, the default
version of the modulecmd binary wasn't sorting numerically; thus the above
command would actually load "foo/1.2" instead of "foo/1.10".

The above isn't a problem for most third-party software, because in your
Module scripts you normally load third-party software specifically (i.e.
"module load jdk/1.3" rather than "module load jdk"). However, for internal
software (such as loading the correct module script to set your local
environment for an internal product version), this can and does become a
problem--it certainly was for us.

Harlan Stenn patched the binary to account for this, but I don't know if it
made it into the distro.

Just to be safe, when I'm setting up versions for internal software scripts
I always use leading zeros to indicate versions.

Regards,
Andy


-----Original Message-----
From: David C. Mores [mailto:dav...@ba...]
Sent: Friday, July 26, 2002 11:00
To: modules interest group
Subject: Re: [Modules] Modules setup in cross-platform environments


Stefan Svensson wrote:

> I try to learn how to set up Modules, but I have not yet found any
> documentation on how to set up a cross-platform environment where you have
> different platforms (Solaris, HP-UX, SGI, Linux), os revisions (Solaris
> 5.6, 7, 8; HP-UX 9, 10.20, 11; etc) and, of course, different application
> versions.
>
> Are there any documents on this, does anyone have any experience - or do I
> have to find out the hard way? :-)

Your can use the .version or .modulerc to control which version of an
application
is going to be the default on a particular platform with something like
this:

#%Module
#
# $Id: .version,v 1.7 2002-07-26 10:28:25-04 dmores Exp $
#
##########################################################################
switch -regexp -- [uname sysname].[uname release] {
 { "HP-UX.*" }
        { set ModulesVersion "20.5" }
 { "SunOS.5.*" }
        { set ModulesVersion "25.3" }
}

The 20.5 and 25.3 refer to directories by that name where the .version file
lives - e.g. appname/20.5
and appname/25.3 - where the .version file is in directory appname.  The
modulefile for each version
lives in the 20.5 and 25.3 subdirectory.  You can also have a .version file
in each subdiretory if you need
more than one modulefile to choose from but want one to be the default.

In modulefiles you can  use a similar arrangement to set the environment
based on
the platform type with something like this TCL code fragment:

set  TOOL_HOME       /home/tool_25.3_a

#------ O/S specific settings
switch -regexp -- [uname sysname].[uname release] {

    SunOS.5.* {

        append-path  PATH   $TOOL_HOME/sol/bin

    }

    HP-UX.* {

        append-path  PATH   $TOOL_HOME/hpux/bin

    }


    default {

        error "The modulefile [module-info name]: is not supported under O/S
[uname sysname].[uname release]"

    }

}


This is an arrangement we have been using successfully for the past 10 years
with Modules version 2.2b.  Version 3.x still has problems with more than
two directory levels.

Hope this helps you.

Dave



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Modules-interest mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Modules setup in cross-platform environments

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

Stefan Svensson wrote:

> I try to learn how to set up Modules, but I have not yet found any
> documentation on how to set up a cross-platform environment where you have
> different platforms (Solaris, HP-UX, SGI, Linux), os revisions (Solaris
> 5.6, 7, 8; HP-UX 9, 10.20, 11; etc) and, of course, different application
> versions.
>
> Are there any documents on this, does anyone have any experience - or do I
> have to find out the hard way? :-)

Your can use the .version or .modulerc to control which version of an application
is going to be the default on a particular platform with something like this:

#%Module
#
# $Id: .version,v 1.7 2002-07-26 10:28:25-04 dmores Exp $
#
##########################################################################
switch -regexp -- [uname sysname].[uname release] {
 { "HP-UX.*" }
        { set ModulesVersion "20.5" }
 { "SunOS.5.*" }
        { set ModulesVersion "25.3" }
}

The 20.5 and 25.3 refer to directories by that name where the .version file lives - e.g. appname/20.5
and appname/25.3 - where the .version file is in directory appname.  The modulefile for each version
lives in the 20.5 and 25.3 subdirectory.  You can also have a .version file in each subdiretory if you need
more than one modulefile to choose from but want one to be the default.

In modulefiles you can  use a similar arrangement to set the environment based on
the platform type with something like this TCL code fragment:

set  TOOL_HOME       /home/tool_25.3_a

#------ O/S specific settings
switch -regexp -- [uname sysname].[uname release] {

    SunOS.5.* {

        append-path  PATH   $TOOL_HOME/sol/bin

    }

    HP-UX.* {

        append-path  PATH   $TOOL_HOME/hpux/bin

    }


    default {

        error "The modulefile [module-info name]: is not supported under O/S [uname sysname].[uname release]"

    }

}


This is an arrangement we have been using successfully for the past 10 years with Modules version 2.2b.  Version 3.x still has problems with more than two directory levels.

Hope this helps you.

Dave

Re: [Modules] Modules setup in cross-platform environments

[<ea...@at...>]

For each version of a different tool you have a separate
module file e.g.:

vendorA/v1.0
vendorA/v1.1
vendorA/v2.0
vendorB/r2002.01
vendorB/r2002.06

for vendorA and vendorB you can have a default version
pointed to by the file .version:

% ls -a <path>/modules/modulefiles/toolX
.            .version     v03.20.s004  v03.20.s007  
v3.30.s014
..           3.11.p001    v03.20.s005  v3.20.p1

% cat <path>/modules/modulefiles/toolX/.version
#%Module1.0##############################################
#######################
##
##
##
#
set ModulesVersion "3.11.p001"


% module load toolX
#### gives he default

% module load toolX/v03.20.s005
#### chooses version v03.20.s005


As far as OS dependencies...in the modulefile
add code like this...

set osname [ uname sysname ]

if {[ string compare $osname "SunOS" ] == 0} {
    set ncdir   /<path>/toolX
    set nctools tools.sun4v
} elseif {[ string compare $osname "Linux" ] == 0} {
    set ncdir /<path>/toolX-linux
    set nctools tools.lnx86
} else {
    # some kind of error!
    puts stderr "Error: This OS, $osname, is not 
supported with\
        [module-info specified]!"
}


I hope this helps...
Sorry if things wrap funny...

/Ed
> I try to learn how to set up Modules, but I have not yet found any 
> documentation on how to set up a cross-platform environment where you have 
> different platforms (Solaris, HP-UX, SGI, Linux), os revisions (Solaris 
> 5.6, 7, 8; HP-UX 9, 10.20, 11; etc) and, of course, different application 
> versions.
> 
> Are there any documents on this, does anyone have any experience - or do I 
> have to find out the hard way? :-)
> 
> Stefan
> 
> -- 
> Stefan Svensson                     Phone: +46-90-135000
> Himlastigen 14                      WWW: http://raggmunk.nu/~stefan/
> 906 41 Umeå, Sweden                 ICQ: 1956984
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] Modules setup in cross-platform environments

[Stefan S. <st...@ra...>]

I try to learn how to set up Modules, but I have not yet found any=20
documentation on how to set up a cross-platform environment where you hav=
e=20
different platforms (Solaris, HP-UX, SGI, Linux), os revisions (Solaris=20
5.6, 7, 8; HP-UX 9, 10.20, 11; etc) and, of course, different application=
=20
versions.

Are there any documents on this, does anyone have any experience - or do =
I=20
have to find out the hard way? :-)

Stefan

--=20
Stefan Svensson                     Phone: +46-90-135000
Himlastigen 14                      WWW: http://raggmunk.nu/~stefan/
906 41 Ume=E5, Sweden                 ICQ: 1956984

[Modules] unsubscribe avemzi virvit@udm.ru

[VirVit <vi...@ud...>]

[Modules] Greetings!

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

Hello to the modules-interest community.

The mailing list is now hosted at SourceForge, so there
should be no further interruptions in service.  The
project homepage at http://modules.sf.net is not yet
updated with mailing list information, but that should
be taken care of by the end of the week.

You should have received a welcome message at the time
you were subscribed, and this has a randomly generated
password that you may wish to change.  Just follow the
link in the email to get to the mailman interface at
SourceForge to change it or modify your delivery preferences.

The older mail archives are not yet available; we do have
them, and are in the process of asking the SourceForge
folks how we can get them into the geocrawler archives.

Regards,

- Leo Butler

Email Marketing-Support Center

[E-News <Fre...@co...>]

<HTML>
<HEAD><TITLE>Online Marketing Strategies</TITLE><META http-equiv=3DContent=
-Type content=3D"text/html; 
charset=3Dwindows-1252"><META content=3D"MSHTML 5.50.4134.100" name=3DGENE=
RATOR><META content=3DFrontPage.Editor.Document name=3DProgId>
    </HEAD><BODY vLink=3D#c0c0c0 link=3D#c0c0c0 bgColor=3D#FFFFFF leftMarg=
in=3D0>
     <DIV align=3Dcenter><CENTER><TABLE height=3D0 cellSpacing=3D0 cellPad=
ding=3D0 width=3D500 border=3D0>
	<TBODY><TR><TD width=3D"100%" height=3D200><P align=3Dcenter>
	<FONT face=3D"Georgia, Times New Roman" size=3D7>
	<B><FONT color=3D#08296b>Need More Clients?</FONT></B></FONT></P><P align=
=3Dcenter>
	<FONT face=3D"Times New Roman" size=3D5><B><FONT color=3D#ff0000>
	Increase Your Sales 15%-40% Every Month!</FONT></B>
<HR>
<FONT color=3D#ff0000><B><FONT face=3D"Times, New Roman" color=3D#08296b s=
ize=3D3>
Targeted E-mail Marketing Is A Proven Method For Return Sales<br>
</FONT></B>
<FONT color=3D#000000 size=3D3>
  With a database of over 150 million "targeted" addresses, we can reach y=
our potential clients
  anywhere in the world.  Our staff creates interactive ad campaigns, spec=
ifically targeted to 
  your client base, and designed to produce staggering responses for your =
business.  A steady 
  lead source can make sure your sales team will consistently close deals.
</FONT>
<P>
   <FONT face=3D"Times, New Roman" size=3D3><B><FONT color=3D#08296b>The G=
reatest 
      Return On Your Marketing Dollar</FONT></B>
<FONT color=3D#000000><BR><FONT size=3D3>Targeted e-mail marketing is the =
most effective way to reach
global and local markets with a small expense compared to that of conventi=
onal marketing.  
Quality work and a dedicated professional staff will ensure your ad campai=
gn to be successful.  
Put our educated team of marketers to work for you.<br><br></B></FONT></p>=
</tr></td></tbody>
<P>
<TABLE width=3D400 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D#08296b size=3D4>Fill out the form be=
low to speak
with one <br>of our marketing specialists.</FONT></TD></TR></TBODY></TABLE=
>
<P><FONT color=3D#08296b size=3D2>Required Input Field<FONT color=3D#ff000=
0
size=3D2>*</FONT></FONT> 
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D#333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D#ffffcc>
  <TBODY>
  <TR>
    <TD align=3Dmiddle>
      <FORM action=3Dmailto:mar...@ya...?subject=3DE-marketing_=
Inquiry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D"100%">
        <TBODY>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Times, New Roman" color=3D#08296b
          size=3D2>Name</FONT><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000
            size=3D2>*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Times, New Roman" color=3D#08296b size=3D2>Web 
            Address</FONT></TD>
          <TD><INPUT value=3Dhttp:// name=3DURL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Times, New Roman" color=3D#08296b size=3D2>Company 
            Name</FONT><FONT 
            face=3D"Times, New Roman" color=3D#ff0000
            size=3D2>*</FONT></TD>
          <TD><INPUT name=3DCOMPANY_NAME></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Times, New Roman" color=3D#08296b size=3D2>
            State</FONT><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
            size=3D2>*</FONT></TD>
          <TD><INPUT size=3D2 name=3DSTATE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Times, New Roman" color=3D#08296b size=3D2>Business 
            Phone</FONT><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
            size=3D2>*</FONT></TD>
          <TD><INPUT name=3DBUS_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Times, New Roman" color=3D#08296b size=3D2>Home 
            Phone</FONT></TD>
          <TD><INPUT name=3DHOME_PHONE></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Times, New Roman" color=3D#08296b size=3D2>Email 
            Address</FONT><FONT 
            face=3D"Arial, Helvetica, sans-serif" color=3D#ff0000 
            size=3D2>*</FONT></TD>
          <TD><INPUT name=3DEMAIL></TD></TR>
        <TR>
          <TD align=3Dright width=3D"50%"><FONT 
            face=3D"Times, New Roman" color=3D#08296b size=3D2>Type of 
            Business</FONT></TD>
          <TD><INPUT name=3DTYPE_OF_BUSINESS></TD></TR></TBODY></TABLE>
      <P><INPUT type=3Dsubmit value=3D"Submit Information" name=3Dsubmit> 
    </FORM></P></TD></TR></TBODY></TABLE>
<BR><BR>
<TABLE width=3D500>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT face=3D"Times, New Roman" color=3D#08296b
      size=3D1>To be removed, please  
      <A href=3D"mailto:d_l...@eu...?subject=3DRemove_E-market=
ing">Click 
      here.<FONT color=3D#666600></A></FONT>.</FONT></TD></TR></TBODY></TA=
BLE></P></CENTER></BODY></HTML>

Re: List active, MacOS X

[<me...@cs...>]

In reply to Patrick Gundlach (pg...@le...):

> Hi,
> 
> i have been looking at the mailing list archive. Is this list still
> active? 
> 
> Are there any reports on running modules on MacOS X?
> 
> It does not even configure, but before sending a bug-report or
> investigating it further there might be some of you with comments.
> 
> Patrick
> -- 
> I'll fade into the darkness

Yep the list is active.  I just tried it on a machine and I got to the
point where its looking for tcl, which is pretty far down the list,
what errors are you getting?
I can play with it here and see if I can't get it working, we don't
really use the machine for anything though so I haven't bothered.

Thanks,

Kent
-- 
Kent Mein
me...@cs...
http://www.cs.umn.edu/~mein

List active, MacOS X

[Patrick G. <pg...@le...>]

Hi,

i have been looking at the mailing list archive. Is this list still
active? 

Are there any reports on running modules on MacOS X?

It does not even configure, but before sending a bug-report or
investigating it further there might be some of you with comments.

Patrick
-- 
I'll fade into the darkness