View on GitHub

IRAF Community Distribution

IRAF maintained by the community

Home | Installation | Packages | X11IRAF | PyRAF | Forum

GRASP/TABLES/IRAF 2.11/HP-UX

Stephen Walton wrote on Apr 18, 1998



This post crosses several boundaries, so I'm hoping a post here will
reach the relevant folks.

I just installed the latest version of GRASP (an IRAF layered package
for processing helioseismology data) on IRAF V2.11 with TABLES 2.0.1.
I used the command "mkpkg -p tables -p grasp" in grasp$.  A couple of
the tasks complained about a missing ttools library.  (I didn't build
TABLES from the source; I used the precompiled HP-UX binaries.) After
a bit of checking, I found "tables$pkg/ttools/ttools.a" in the
archived HP700 objects, which I restored by "mkpkg hp700" in tables$
and copied this ttools.a to tables$bin.hp700/libttools.a.  With this
fix, GRASP built to completion with no errors. 

So:  Should ttools.a be put in tables$bin as libttools.a?  Why is the
file called something nonstandard anyway?  Or did the folks who wrote
the MKPKG files for GRASP do something wrong/unsupported?

--
Stephen Walton, Professor of Physics and Astronomy,
California State University, Northridge
stephen.walton@csun.edu

Doug Tody wrote on Apr 18, 1998


Hi Steve,

> This post crosses several boundaries, so I'm hoping a post here will
> reach the relevant folks.
> 
> I just installed the latest version of GRASP (an IRAF layered package
> for processing helioseismology data) on IRAF V2.11 with TABLES 2.0.1.
> I used the command "mkpkg -p tables -p grasp" in grasp$.  A couple of
> the tasks complained about a missing ttools library.  (I didn't build
> TABLES from the source; I used the precompiled HP-UX binaries.) After
> a bit of checking, I found "tables$pkg/ttools/ttools.a" in the
> archived HP700 objects, which I restored by "mkpkg hp700" in tables$
> and copied this ttools.a to tables$bin.hp700/libttools.a.  With this
> fix, GRASP built to completion with no errors. 
> 
> So:  Should ttools.a be put in tables$bin as libttools.a?  Why is the
> file called something nonstandard anyway?  Or did the folks who wrote
> the MKPKG files for GRASP do something wrong/unsupported?

If libttools.a is intended to be a public library it needs to be in
the tables LIB and BIN, and "checked out" by mkpkg when TTOOLS is updated.
I just checked the TTOOLS mkpkg and it builds this as a private library.
However, by convention private package libraries are called "libpkg.a"
to indicate that they are indeed private package libraries rather than
named external libraries, so it is not clear what is intended.  Either
TTOOLS needs to publically export this library to lib and pkg, or it is
a private library and packages like GRASP should not be referencing it.
The TABLES and GRASP folks will need to decide which is the situation.

	- Doug

Doug Tody       National Optical Astronomy Observatories    IRAF project
tody@noao.edu            950 N. Cherry Avenue            http://iraf.noao.edu
(520) 318-8217  P.O. Box 26732, Tucson, Arizona, 85726   FAX: +1 520 760-1709

Phil Hodge wrote on Apr 22, 1998


Doug Tody wrote:

>> So:  Should ttools.a be put in tables$bin as libttools.a?  Why is the
>> file called something nonstandard anyway?  Or did the folks who wrote
>> the MKPKG files for GRASP do something wrong/unsupported?
>
> If libttools.a is intended to be a public library it needs to be in
> the tables LIB and BIN, and "checked out" by mkpkg when TTOOLS is updated.
> I just checked the TTOOLS mkpkg and it builds this as a private library.
> However, by convention private package libraries are called "libpkg.a"

Is this documented somewhere?  The convention used in STSDAS and TABLES
is that a package library has the name of the package and is located in
the package directory.

> to indicate that they are indeed private package libraries rather than
> named external libraries, so it is not clear what is intended.  Either
> TTOOLS needs to publically export this library to lib and pkg, or it is
> a private library and packages like GRASP should not be referencing it.
> The TABLES and GRASP folks will need to decide which is the situation.

ttools.a is not a public library.  What does GRASP call from ttools.a,
do you know?

						Phil

Doug Tody wrote on Apr 22, 1998


Hi Phil,

> >> So:  Should ttools.a be put in tables$bin as libttools.a?  Why is the
> >> file called something nonstandard anyway?  Or did the folks who wrote
> >> the MKPKG files for GRASP do something wrong/unsupported?
> >
> > If libttools.a is intended to be a public library it needs to be in
> > the tables LIB and BIN, and "checked out" by mkpkg when TTOOLS is updated.
> > I just checked the TTOOLS mkpkg and it builds this as a private library.
> > However, by convention private package libraries are called "libpkg.a"
> 
> Is this documented somewhere?  The convention used in STSDAS and TABLES
> is that a package library has the name of the package and is located in
> the package directory.

It is an undocumented convention.  The idea is that if you call the internal
package library "libpkg.a" it should suggest to someone browsing the
directory that they should not try to use it.  One soon learns that libpkg.a
means internal package library as the name suggests.  A named library on
the other hand looks like something one might want to use, e.g. "-lttools".
It will work either way, but this is the convention we have used in our
packages.

For any library to be exported it must be installed in LIB and BIN, as
otherwise there is no multiple architecture support and it will disappear
when one does a "mkpkg generic", and the user discovered when they tried
to build GRASP.  Even if the architecture were unpacked to restore the
library to the package source directory, the architecture one is trying
to build for might be different than what the package source tree is
configured for.

If one wants to use code from a package which is not exported, the only
correct thing to do is copy the source and incorporate it in your package
(or try to generate an exported public library, which gets into issues
involving generality and frozen interfaces).
 
> > to indicate that they are indeed private package libraries rather than
> > named external libraries, so it is not clear what is intended.  Either
> > TTOOLS needs to publically export this library to lib and pkg, or it is
> > a private library and packages like GRASP should not be referencing it.
> > The TABLES and GRASP folks will need to decide which is the situation.
> 
> ttools.a is not a public library.  What does GRASP call from ttools.a,
> do you know?

Beats me.  The GRASP guys will need to answer that one.

	- Doug

Ed Anderson NSO/GONG x300 wrote on Apr 23, 1998


>> ttools.a is not a public library.  What does GRASP call from >> >> >> >> ttools.a, do you know?
> 
> Beats me.  The GRASP guys will need to answer that one.
> 
>         - Doug


Hi, 

Off the top of my head, GRASP calls "allrows" and  "tctexp" .

The export versions of GRASP usually have ttools.a copied into 
graspbin$libttools.a.

I've started playing with having MKPKG unpack this library from
the archive but I'm not yet satisfied with how it works.


-- Ed  

-- 
Ed Anderson, Senior Scientific Programmer,
Global Oscillation Network Group,
National Solar Observatory, Tucson AZ.
Phone: (520) 318-8300
Internet: anderson@noao.edu

Ed Anderson NSO/GONG x300 wrote on Apr 23, 1998


I'll grant you that using a "private" library is dangerous, but at
the same time I don't see the merit in having redundant source code
lying around either.  I can be persuaded either way, but there are 
other examples in the IRAF system where cross-package dependencies
occur so I didn't think it was such a big deal.

The subroutines in tables$pkg/ttools/lib are of sufficient general use
(at least to me) that I would encourage that they be put in tbtables 
or uttables to prevent further occurances of this type.

In the meantime, I have come up with the following method for getting
the ttools.a library from the Tables package on the fly if it does not
exist already in graspbin.


In the file grasplib$mkpkg.inc, I have added:

    $iffile (graspbin$libttools.a) then
        $echo "grasplib$libttools.a exists"
    $else
        $echo "Extracting ttools.a from TABLES package"
        $set CMD = "!$(grasp)lib/ttools.csh $(arch)"
        $(CMD)
    $endif
 

The csh script "ttools.csh" is:

    #! /bin/csh

    set old = $cwd                          # Save current Directory

    cd $iraf/../extern/grasp/bin$1          # Go to GRASPBIN

    mkdir TTOOLS                   # Make a directory for the extraction
    cd TTOOLS

    cat $iraf/../extern/tables/bin$1/OBJS.arc.Z \           #
Extract            | uncompress | tar -vxpf - pkg/ttools/ttools.a

    mv pkg/ttools/ttools.a ../libttools.a   # Move library to GRASPBIN

    cd ../                                  # Remove temporary directory
    rm -rf TTOOLS

    ranlib libttools.a                      # Run ranlib

    cd $old                                 # Return 


-- 
Ed Anderson, Senior Scientific Programmer,
Global Oscillation Network Group,
National Solar Observatory, Tucson AZ.
Phone: (520) 318-8300
Internet: anderson@noao.edu

Doug Tody wrote on Apr 23, 1998


Hi Ed,

> I'll grant you that using a "private" library is dangerous, but at
> the same time I don't see the merit in having redundant source code
> lying around either.  I can be persuaded either way, but there are 
> other examples in the IRAF system where cross-package dependencies
> occur so I didn't think it was such a big deal.

This is a typical "interface violation" situation.  Time for my interface
violation speech I'm afraid.

The problem is that you are setting a trap; by using internal routines
that are not part of any defined, exported interface, you create a situation
where your code may break if the other guy changes the internals of his
program (which is likely unless it is frozen).  If enough people do this
it can lead to the old "one step forward and one step back" scenario,
where a code change breaks something somewhere else.  Eventually, after
a few years of this, the system locks up and people are afraid to change
any code.  The system has to be frozen to avoid introducing new bugs, and
eventually it dies (is replaced by something else and the cycle starts
over).

Interface violations are always very tempting, as it is so easy to do
these things if you look into someone's code.  The alternatives are usually
harder, and there might not be time to pursue them.  Interface violations
can be ok if the program is intended to have a short life and can be
carefully controlled the whole time.  But if this sort of thing gets out of
hand in a large system it can be a real problem.

The only safe ways to handle things like this are to 1) export the desired
interface routines and library if they are judged generally useful and
the interface (API) can be frozen, or 2) if there are only one or two
cases like this and it is judged not worthwhile to export the library,
at least not yet, then copy the code into your application.

> the same time I don't see the merit in having redundant source code
> lying around either.  I can be persuaded either way, but there are 

The merit is that your code is then immune from changes in the other
part of the system, and the other guy can change his code without worrying
about breaking yours.

> other examples in the IRAF system where cross-package dependencies

The only exception might be where the same person is responsible for both
pieces of code and things can be controlled "internally" at some level.
Even so it should be avoided if package boundaries have to be crossed.

Sorry about the speech, but I couldn't let this pass.  This is an issue of
major importance for large systems.  It seems so simple, but it isn't.

	- Doug

Phil Hodge wrote on Apr 24, 1998


Ed Anderson wrote:

> Off the top of my head, GRASP calls "allrows" and  "tctexp" .

I asked Bernie Simon about this.  Both these routines have been superceded
by new routines in the selector subdirectory of tbtables, and the selector
routines are in the public libtbtables.a library.  allrows and tctexp are
currently still in ttools/lib, however.  If you keep us informed about what
you need, we can move useful subroutines into libtbtables.a.

Doug Tody wrote:

> This is a typical "interface violation" situation.  Time for my interface
> violation speech I'm afraid.

Thanks for the explanation, Doug.  You're absolutely right.

This happened to us this past week.  A task in one of the tables packages
was calling tbcftg, which is not part of the public interface.  (The public
subroutines are listed in tables$lib/tbtables/doc/calls.doc, and most of
these are described in the latex file tables$doc/tbtables.tex.)  I made
some changes recently to allow longer column names and units in FITS tables,
and in the process I deleted tbcftg.x, which is now obsolete.  As a result,
the tables package failed to link.

						Phil

Ed Anderson NSO/GONG x300 wrote on Apr 24, 1998



Hi Doug,

Thanks for the speech ;) ... all points are well taken.

ed> the same time I don't see the merit in having redundant source code
ed> lying around either.  I can be persuaded either way, but there are 

doug> The merit is that your code is then immune from changes in the other
doug> part of the system, and the other guy can change his code without worrying
doug> about breaking yours.


My fear is/was that if I "copy out" the source code I need from the TTOOLS
package, and these things are modified in the future, then my code may produce
tables which would no longer be "readable" by the TTOOLS tasks.  Chances of 
that are probably slim but that was my thought when if first started using
this stuff several years ago.

I guess I would re-iterate that the subroutines in ttools$lib are very useful
generally for codes which create and manipulate tables.  I would then suggest
that ttools.a (or a least the ttools$lib subset of ttools.a) become an exported
library ... or to move these routines into tbtables.


-- Ed

Last post on Apr 24, 1998