opengrads-devel — OpenGrADS development issues, with focus on interfaces and extensions

[Opengrads-devel] Uploaded supplibs-2.0.1 to sf.net

[Arlindo da S. <da...@al...>]

All,

I have upload sources and binaries for i686, x86_64 and darwin/intel to
sf.net:


https://sourceforge.net/project/showfiles.php?group_id=161773&package_id=241681

These includes the new hdf 4.1r3 and the grib2c patches we have been talking
about.

Jennifer: if you would like to build from sources I'd suggest you check out
the sources so that you can apply patches and check them in. Exchanging
patches by e-mail just wastes time...

% gacvs co -P supplibs

For testing this I build grads-2.0.a0.oga.1 against. For reference, I posted
this at the developer's corner at:

    http://opengrads.org/pre-rel

This is meant as reference to check what you build against mine - it is not
meant for the end-user.

    Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: first crack

[Arlindo da S. <da...@al...>]

On Feb 3, 2008 11:14 AM, Brian Doty <do...@co...> wrote:

> sorry about our email ssytem tagging this stuff as junk.  it is very
> weird.
>
> I don't think grib2c would work on systems where sizeof(int) is 2.
>
Are there any such systems left?  I am remembering that the size is 8
> on our 64 bit linux, in which case it works ok with this small
> patch.  But my memory is vague on this; Jennifer may remember
> better... Brian
>

I think that compilers on x86_64 still use 32-bits for int (I just checked
gcc on my x86_64 linux box), so we don't have much to worry about right now.
Adding a test to configure would alert us if we are trying to build on
anything that does not have sizeof(int)=4 so that we can have it addressed
on the spot, rather than building grads and finding out that grads does not
work.

   Arlindo


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: first crack

[Patrice D. <per...@fr...>]

On Sun, Feb 03, 2008 at 11:14:39AM -0500, Brian Doty wrote:
> sorry about our email ssytem tagging this stuff as junk.  it is very  
> weird.
> 
> I don't think grib2c would work on systems where sizeof(int) is 2.   
> Are there any such systems left?  I am remembering that the size is 8  
> on our 64 bit linux, in which case it works ok with this small  
> patch.  But my memory is vague on this; Jennifer may remember  
> better... Brian

My recall is that the size of int is 4 on 64 bit linux, it is long that
has a different length. But in any case one should not rely on a
specific sizeof(int) since (unless I am wrong) it is not in the
standard.

--
Pat

Re: [Opengrads-devel] [Junk released by Allow List] Re: [Junk released by Allow List] Building GrADS v2 with new supplibs: first crack

[Patrice D. <per...@fr...>]

On Sun, Feb 03, 2008 at 10:36:51AM -0500, Arlindo da Silva wrote:
> On Feb 3, 2008 9:57 AM, Brian Doty <do...@co...> wrote:
> 
> > lengths in a GRIB msg are defined by the GRIB specification and are
> > independent of systems definitions like g2int.  It is appropriate to
> > hardcode the length.  Or to use a typedef that is dependent on the
> > GRIB definitions (ie, hardcoded).  It probably doesn't matter how
> > long hdr is (as long as it is at least 4 bytes ) but you want to read
> > exactly 4 bytes no more no less.. Brian
> >
> 
> 
> You and Jennifer are right. Do you think grib2c is robust enough to work on
> machines where sizeof(int)!=4? If not, it may pay to add something to
> configure.ac to detect such cases and stop with an error.
> 
> Pat: do you know how to do this?

There are indeed autoconf macros to test for a type length,
AC_CHECK_SIZEOF, for example
AC_CHECK_SIZEOF([uint8_t])
if test $ac_cv_sizeof_uint8_t -eq 1; then
 ...
fi



There are types of given length in 

#include <inttypes.h>

like
int32_t uint32_t int16_t and so on and so forth (it is in POSIX 99).

In libdap, if inttypes.h is found and the size of the types are right,
an include file based on inttypes.h is used. Otherwise types with the
correct size are searched for and corresponding symbols are set in
config.h.

The main configure macro is in conf/acinclude.m4 in DODS_CHECK_SIZES.

--
Pat

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: first crack

[Brian D. <do...@co...>]

sorry about our email ssytem tagging this stuff as junk.  it is very  
weird.

I don't think grib2c would work on systems where sizeof(int) is 2.   
Are there any such systems left?  I am remembering that the size is 8  
on our 64 bit linux, in which case it works ok with this small  
patch.  But my memory is vague on this; Jennifer may remember  
better... Brian

On Feb 3, 2008, at 10:36 AM, Arlindo da Silva wrote:

> Do you think grib2c is robust enough to work on machines where  
> sizeof(int)!=4?

Re: [Opengrads-devel] [Junk released by Allow List] Re: [Junk released by Allow List] Building GrADS v2 with new supplibs: first crack

[Arlindo da S. <da...@al...>]

On Feb 3, 2008 9:57 AM, Brian Doty <do...@co...> wrote:

> lengths in a GRIB msg are defined by the GRIB specification and are
> independent of systems definitions like g2int.  It is appropriate to
> hardcode the length.  Or to use a typedef that is dependent on the
> GRIB definitions (ie, hardcoded).  It probably doesn't matter how
> long hdr is (as long as it is at least 4 bytes ) but you want to read
> exactly 4 bytes no more no less.. Brian
>


You and Jennifer are right. Do you think grib2c is robust enough to work on
machines where sizeof(int)!=4? If not, it may pay to add something to
configure.ac to detect such cases and stop with an error.

Pat: do you know how to do this?

         Arlindo


>
> On Feb 3, 2008, at 12:09 AM, Arlindo da Silva wrote:
>
>  > On Feb 2, 2008 7:21 PM, Jennifer Adams <jm...@co...> wrote:
> >
> >
> > Arlindo --
> > There is a bug in seekgb.c of the g2clib that causes it to fail to
> > detect the end of a grib2 record if sizeof(g2int) != 4 (i.e. on 64-
> > bit systems). I guess we should put the patch in the subblib src
> > files we are redistributing (on your site and COLA's). This bug
> > causes gribmap to fail to find any records -- pretty bad.
> >
> >  # diff ./seekgb.c ~/Desktop/seekgb.c
> > 39a40
> > >       int hdr;
> > 68,69c69,70
> > <             k4=fread(&end,sizeof(g2int),1,lugb);
> > <             if (k4 == 1 && end == 926365495) {      //GRIB
> > message found
> > ---
> > >             k4=fread(&hdr,4,1,lugb);
> > >             if (k4 == 1 && hdr == 926365495) {      //GRIB
> > message found
> >
> >
> > If it is OK with you I'll replace int with g2int for consistency
> > with rest of grib2c. They do assume that g2int = int are 32 bits,
> > but keeping everything in terms of g2int will make it easier to
> > update the code if we ran into ints that are > 32 bits.
> >
> >             g2int hdr;
> > ...
> >             k4=fread(&hdr,sizeof(hdr),1,lugb);
> >             if (k4 == 1 && hdr == 926365495) {      //GRIB message
> > found
> >
> >
> >
> > --
> > Arlindo da Silva
> > da...@al...
>
>


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] [Junk released by Allow List] Re: [Junk released by Allow List] Building GrADS v2 with new supplibs: first crack

[Brian D. <do...@co...>]

lengths in a GRIB msg are defined by the GRIB specification and are  
independent of systems definitions like g2int.  It is appropriate to  
hardcode the length.  Or to use a typedef that is dependent on the  
GRIB definitions (ie, hardcoded).  It probably doesn't matter how  
long hdr is (as long as it is at least 4 bytes ) but you want to read  
exactly 4 bytes no more no less.. Brian

On Feb 3, 2008, at 12:09 AM, Arlindo da Silva wrote:

> On Feb 2, 2008 7:21 PM, Jennifer Adams <jm...@co...> wrote:
>
>
> Arlindo --
> There is a bug in seekgb.c of the g2clib that causes it to fail to  
> detect the end of a grib2 record if sizeof(g2int) != 4 (i.e. on 64- 
> bit systems). I guess we should put the patch in the subblib src  
> files we are redistributing (on your site and COLA's). This bug  
> causes gribmap to fail to find any records -- pretty bad.
>
>  # diff ./seekgb.c ~/Desktop/seekgb.c
> 39a40
> >       int hdr;
> 68,69c69,70
> <             k4=fread(&end,sizeof(g2int),1,lugb);
> <             if (k4 == 1 && end == 926365495) {      //GRIB  
> message found
> ---
> >             k4=fread(&hdr,4,1,lugb);
> >             if (k4 == 1 && hdr == 926365495) {      //GRIB  
> message found
>
>
> If it is OK with you I'll replace int with g2int for consistency  
> with rest of grib2c. They do assume that g2int = int are 32 bits,  
> but keeping everything in terms of g2int will make it easier to  
> update the code if we ran into ints that are > 32 bits.
>
>             g2int hdr;
> ...
>             k4=fread(&hdr,sizeof(hdr),1,lugb);
>             if (k4 == 1 && hdr == 926365495) {      //GRIB message  
> found
>
>
>
> -- 
> Arlindo da Silva
> da...@al...

Re: [Opengrads-devel] [Junk released by Allow List] Re: [Junk released by Allow List] Building GrADS v2 with new supplibs: first crack

[Arlindo da S. <da...@al...>]

On Feb 2, 2008 7:21 PM, Jennifer Adams <jm...@co...> wrote:

>
>
> Arlindo --
> There is a bug in seekgb.c of the g2clib that causes it to fail to detect
> the end of a grib2 record if sizeof(g2int) != 4 (i.e. on 64-bit systems).
> I guess we should put the patch in the subblib src files we are
> redistributing (on your site and COLA's). This bug causes gribmap to fail to
> find any records -- pretty bad.
>
>  # diff ./seekgb.c ~/Desktop/seekgb.c
> 39a40
> >       int hdr;
> 68,69c69,70
> <             k4=fread(&end,sizeof(g2int),1,lugb);
> <             if (k4 == 1 && end == 926365495) {      //GRIB message found
> ---
> >             k4=fread(&hdr,4,1,lugb);
> >             if (k4 == 1 && hdr == 926365495) {      //GRIB message found
>
>
If it is OK with you I'll replace int with g2int for consistency with rest
of grib2c. They do assume that g2int = int are 32 bits, but keeping
everything in terms of g2int will make it easier to update the code if we
ran into ints that are > 32 bits.

            g2int hdr;
...
            k4=fread(&hdr,sizeof(hdr),1,lugb);            if (k4 == 1 && hdr
== 926365495) {      //GRIB message found



-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] [Junk released by Allow List] Re: [Junk released by Allow List] Building GrADS v2 with new supplibs: first crack

[Arlindo da S. <da...@al...>]

On Feb 2, 2008 7:21 PM, Jennifer Adams <jm...@co...> wrote:

>
>
> Arlindo --
> There is a bug in seekgb.c of the g2clib that causes it to fail to detect
> the end of a grib2 record if sizeof(g2int) != 4 (i.e. on 64-bit systems).
> I guess we should put the patch in the subblib src files we are
> redistributing (on your site and COLA's). This bug causes gribmap to fail to
> find any records -- pretty bad.
>

OK, I'll patch it and check it in. Fell free to to checkout the supplib
sources and commit  but fixes like this one.

BTW, we autoconfiscated grib2c for easier integration in the supplibs; other
users of the library may appreciate this as well. We should contribute this,
along with your bug fix, to the 'upstream' maintainers. Are you in contact
with them?

Another important point. I need a small grib-2 file to add to the test
suite. Right now I have model.grb, model.nc and model.hdf - all the same
file, just in different formats.
(I test binary files by writing them out with 'fwrite' and then reading them
back.)
This allows me to apply the same test code to all of them. Ideally, one
should have a similar model.grb2 file.  Wes attempted to convert the
existing model.grb to grb 2 but wasn't able to because model.grb does not
conform to NCEP's tables, or some other obscure grib reason.


> The code path for hdf in sdfopen is new. I will look at it and see what's
> going wrong.
>

It would be good to have model_nc.ctl and model_hdf.ctl so I can test the
ctl interface for netcdf/hdf as well. If you contribute those 2 ctls I can
add the additional tests.


>
Where is model.hdf?
>

 When you checkout the sources look under pytests/data, all test data is
there.


> b) When using "set gxout fvwrite" to write binary files the missing value
> is not being written correctly, in either little-endian or big-endian mode.
> Is this a bug or a feature (I haven't verified whether v1.9 does the
> same)?
>
> Can you be more specific about what 'not being written correctly' means?
> Can you give me a script segment that shows what it is doing wrong? Undef
> handling in v2 is entirely different than 1.9 -- it won't help to look
> back.
>

The undef value is 1E+20 for the opened file (model.nc). I then use fwrite
to write all vars, levels, times, to disk. When I read it back a different
value is used for UNDEF:
2.2616e+06. Here is how to reproduce the error outside the testing
framework.  From the Unix command line:

- check out grads sources and go to the testing directory:

% cd grads/pytests

- Convince yourself that undef of input file is 1e+20

% ncdump data/model.nc

- Now convert model.nc to binary using 'fwrite'

% mkdir output
% ./lats4d -i model/model.nc -o output/stream -format stream -be -v

(or write a simple script to do just that; choose a variable with undefs,
like "ua").

- use stream.ctl to read file output/stream.bin that you just created. You
can either open this file in GrADS or use lats4d again for a quick summary:

% ./lats4d -i stream.ctl -format stats

...
     Name    Lev         Min         Max        MEAN        STDV         RMS
  --------- ---- ----------- ----------- ----------- ----------- -----------
  ua        1000    -12.9719  2.2616e+06  1.1868e+06  1.1296e+06  1.6383e+06
  ua         850    -22.5107  2.2616e+06  3.0661e+05  7.7434e+05  8.3272e+05
  ua         700    -19.0453  2.2616e+06  1.4750e+05  5.5850e+05  5.7757e+05
  ua         500    -26.0697  2.2616e+06   2055.4200  6.8046e+04  6.8067e+04
  ua         300    -30.2449     73.7551     12.3418     16.0524     20.2466
  ua         200    -18.9862     81.0138     14.3248     16.6574     21.9678
  ua         100    -19.2900     53.7100     11.3787     12.8745     17.1807
  --------- ---- ----------- ----------- ----------- ----------- -----------
+ ua           7    -30.2449  2.2616e+06  2.3472e+05  3.6177e+05  7.2858e+05

The maximum value is what was mistakenly written for UNDEF. Incidentally,
this problem does not happens with model.grb:

% ./lats4d -i model/model.ctl -o output/stream -format stream -be -v
% ./lats4d -i stream.ctl -format stats

...
    Name    Lev         Min         Max        MEAN        STDV         RMS
  --------- ---- ----------- ----------- ----------- ----------- -----------
  ua        1000    -12.9719     20.0281     -0.5000      6.5431      6.5601
  ua         850    -22.5107     29.7393      1.6346      8.3796      8.5361
  ua         700    -19.0453     33.9547      3.8051      9.2721     10.0211
  ua         500    -26.0697     50.9303      6.8472     11.9436     13.7655
  ua         300    -30.2449     73.7551     12.3418     16.0524     20.2466
  ua         200    -18.9862     81.0138     14.3248     16.6574     21.9678
  ua         100    -19.2900     53.7100     11.3787     12.8745     17.1807
  --------- ---- ----------- ----------- ----------- ----------- -----------
+ ua           7    -30.2449     81.0138      7.1189     11.9898     15.0878

   The test that is failing writes each input file to disk, and reads it
back checking each variable/level/time.

   Let me know if you have any questions.

       Arlindo

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] [Junk released by Allow List] Re: [Junk released by Allow List] Building GrADS v2 with new supplibs: first crack

[Jennifer A. <jm...@co...>]

On Feb 2, 2008, at 3:21 PM, Arlindo da Silva wrote:

> Jennifer/Brian et al,
>
> 1)  I have patched the supplibs sources to build with HDF v4.2r3  
> (just released). I'll be rebuilding and posting sources/binaries to  
> sf.net under version supplibs-2.0.1. For documentation on checking  
> out/building the supplibs check the wiki:
>
> http://opengrads.org/wiki/index.php?title=Supplemental_Libraries_% 
> 28Supplibs%29

> 2) I have obtained your original grads-2.0.a0 tar ball and updated  
> the build mechanism to work with the new supplibs. Please consult  
> the ChangeLog for a descriptions of the  mods I made. (see below).  
> Please check it out directly from our CVS repository:


Arlindo --
There is a bug in seekgb.c of the g2clib that causes it to fail to  
detect the end of a grib2 record if sizeof(g2int) != 4 (i.e. on 64- 
bit systems). I guess we should put the patch in the subblib src  
files we are redistributing (on your site and COLA's). This bug  
causes gribmap to fail to find any records -- pretty bad.

  # diff ./seekgb.c ~/Desktop/seekgb.c
39a40
 >       int hdr;
68,69c69,70
<             k4=fread(&end,sizeof(g2int),1,lugb);
<             if (k4 == 1 && end == 926365495) {      //GRIB message  
found
---
 >             k4=fread(&hdr,4,1,lugb);
 >             if (k4 == 1 && hdr == 926365495) {      //GRIB message  
found


>
>
> gacvs co -P -r GRADS2_DEV_BRANCH grads
>
> cd grads
> ./configure
> make
>
> Notice that gacvs is an alias for
>
> cvs -z3 -d:ext:da...@op...:/cvsroot/ 
> opengrads
>
> (replace "dasilva" with your own user id at sf.net). You also  
> checkoput anonymously from sf.net:
>
>    http://sourceforge.net/cvs/?group_id=161773
>
> 3) I also updated the test suite for working with v2; just type
>
> make check
>
> I also updated lats4d to work with grads v2. Of course, you can  
> only specify -format stream, sequential, stats or gs scripts to be  
> executed. Formats grib and coards cannot be specified because grads  
> v2 does not have LATS.
>
> I have some documentation about the test suite here:
>
> http://opengrads.org/wiki/index.php?title=PyTests:_GrADS_Test_Suite
>
>
> 4) Of the 70 tests, gradsv2 is failing 16. They are related to 2  
> issues:
>
> a) The "sdfopen model.hdf" is not quite working: it reports the  
> file as having 1 timestep instead of 5. I verified that the RH  
> binary Jennifer posted has exactly the same problem, so it does not  
> appear to be my build.
The code path for hdf in sdfopen is new. I will look at it and see  
what's going wrong. Where is model.hdf?

> b) When using "set gxout fvwrite" to write binary files the missing  
> value is not being written correctly, in either little-endian or  
> big-endian mode. Is this a bug or a feature (I haven't verified  
> whether v1.9 does the same)?
Can you be more specific about what 'not being written correctly'  
means? Can you give me a script segment that shows what it is doing  
wrong? Undef handling in v2 is entirely different than 1.9 -- it  
won't help to look back.

> Brian/Jennifer: I am submitting this to you as patches to v2 for  
> your review and adoption in v2 as you see fit.
I will put a priority on importing the build stuff.

--Jennifer

> If you do adopt these or your own mods for building with the new  
> supplibs and put out a new source tarball, I can help with "out of  
> the box" builds for distribution by COLA. I am not planning to  
> distributed this tag at the opengrads sf.net download area as it  
> does not yet have the hooks for developing/running opengrads  
> extensions.

> If you are interested, I can stop at COLA one of these mornings on  
> my way to work and do a quick walkthru of the test suite. Although  
> it is written in Python using PyUnit (a rip off of JUnit which you  
> may be familiar with from Java), you can write  all of your tests  
> as gs scripts. (However, I chose to write my tests in python). It  
> has been extremely useful for testing the binaries on the different  
> platforms. It only requires python v2.3 or later which is available  
> everywhere except for old servers.
>
> Pat: Let me know if this works with Fedora.
>
>   Cheers!
>
>        Arlindo
>
>
>
> ---------------------------------------------------------------------- 
> -----------------------
> GrADS ChangeLog
>
> 2008-01-31 <da...@op...>, Version GrADS 2.0.a0
>     * Imported Version 2.0.a0 sources from COLA into COLA vendor  
> branch.
>
> 2008-01-31 <da...@op...>, Version GrADS 2.0.a0-1
>     * This version temporarily placed under GRADS2_DEV_BRANCH
>     * Adapted build mechanism from v1.9.0-rc1 for v2.0.a0
>     * grads.h: no longer includes gasdf.h, and gasdf prototypes have
>     been moved into gasdf.h. This is important to avoid including
>     "netcdf.h" from NetCDF when building with NC-DAP (OPeNDAP
>     implementation of NetCDF).
>     * gagui.c, gsgui.c: replaced with v1.9.0-rc1 to cope with new
>     supplibs, also revised license terms to GPL 2
>     * gatypes.h: renamed Pixel->gaPixel to avoid conflict with new  
> supplibs.
>     * grads.c: changed main() to Main() for Win32; added main.c,  
> main_win32.c
>     * GNUmakefile: added for Win32
>     * w32_dist.csh: added for Win32
>     * pcx11e.[ch]: updated license to GPL
>     * gacfg.c: removed (c) 1997 Arlindo da Silva + old, unclear,  
> license terms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -- 
> Arlindo da Silva
> da...@al...
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ 
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
> --===============1092192969==--

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...

[Opengrads-devel] Building GrADS v2 with new supplibs: first crack

[Arlindo da S. <da...@al...>]

Jennifer/Brian et al,

1)  I have patched the supplibs sources to build with HDF v4.2r3 (just
released). I'll be rebuilding and posting sources/binaries to sf.net under
version supplibs-2.0.1. For documentation on checking out/building the
supplibs check the wiki:

http://opengrads.org/wiki/index.php?title=Supplemental_Libraries_%28Supplibs%29

2) I have obtained your original grads-2.0.a0 tar ball and updated the build
mechanism to work with the new supplibs. Please consult the ChangeLog for a
descriptions of the  mods I made. (see below). Please check it out directly
from our CVS repository:

gacvs co -P -r GRADS2_DEV_BRANCH grads

cd grads
./configure
make

Notice that gacvs is an alias for

cvs -z3 -d:ext:da...@op...:/cvsroot/opengrads

(replace "dasilva" with your own user id at sf.net). You also checkoput
anonymously from sf.net:

   http://sourceforge.net/cvs/?group_id=161773

3) I also updated the test suite for working with v2; just type

make check

I also updated lats4d to work with grads v2. Of course, you can only specify
-format stream, sequential, stats or gs scripts to be executed. Formats grib
and coards cannot be specified because grads v2 does not have LATS.

I have some documentation about the test suite here:

http://opengrads.org/wiki/index.php?title=PyTests:_GrADS_Test_Suite


4) Of the 70 tests, gradsv2 is failing 16. They are related to 2 issues:

a) The "sdfopen model.hdf" is not quite working: it reports the file as
having 1 timestep instead of 5. I verified that the RH binary Jennifer
posted has exactly the same problem, so it does not appear to be my build.

b) When using "set gxout fvwrite" to write binary files the missing value is
not being written correctly, in either little-endian or big-endian mode. Is
this a bug or a feature (I haven't verified whether v1.9 does the same)?

Brian/Jennifer: I am submitting this to you as patches to v2 for your review
and adoption in v2 as you see fit.  If you do adopt these or your own mods
for building with the new supplibs and put out a new source tarball, I can
help with "out of the box" builds for distribution by COLA. I am not
planning to distributed this tag at the opengrads sf.net download area as it
does not yet have the hooks for developing/running opengrads extensions.

If you are interested, I can stop at COLA one of these mornings on my way to
work and do a quick walkthru of the test suite. Although it is written in
Python using PyUnit (a rip off of JUnit which you may be familiar with from
Java), you can write  all of your tests as gs scripts. (However, I chose to
write my tests in python). It has been extremely useful for testing the
binaries on the different platforms. It only requires python v2.3 or later
which is available everywhere except for old servers.

Pat: Let me know if this works with Fedora.

  Cheers!

       Arlindo



---------------------------------------------------------------------------------------------
GrADS ChangeLog

2008-01-31 <da...@op...>, Version GrADS 2.0.a0
    * Imported Version 2.0.a0 sources from COLA into COLA vendor branch.

2008-01-31 <da...@op...>, Version GrADS 2.0.a0-1
    * This version temporarily placed under GRADS2_DEV_BRANCH
    * Adapted build mechanism from v1.9.0-rc1 for v2.0.a0
    * grads.h: no longer includes gasdf.h, and gasdf prototypes have
    been moved into gasdf.h. This is important to avoid including
    "netcdf.h" from NetCDF when building with NC-DAP (OPeNDAP
    implementation of NetCDF).
    * gagui.c, gsgui.c: replaced with v1.9.0-rc1 to cope with new
    supplibs, also revised license terms to GPL 2
    * gatypes.h: renamed Pixel->gaPixel to avoid conflict with new supplibs.

    * grads.c: changed main() to Main() for Win32; added main.c,
main_win32.c
    * GNUmakefile: added for Win32
    * w32_dist.csh: added for Win32
    * pcx11e.[ch]: updated license to GPL
    * gacfg.c: removed (c) 1997 Arlindo da Silva + old, unclear, license
terms


























-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: almost there

[Arlindo da S. <da...@al...>]

On Feb 2, 2008 5:05 AM, Patrice Dumas <per...@fr...> wrote:

> On Fri, Feb 01, 2008 at 11:12:25PM -0500, Arlindo da Silva wrote:
> > All,
> > 2)  As I said before, my current work on the 2.0.a0 sources is meant to
> > enable it to compile with the new supplibs, and reconcile the bug
> > fixes/robustness improvements we (mostly Pat) made to the v1.9 build.
>
> I am ready to contribute to that, but only if there is an access (read
> only is fine) to a version control system, such that local changes are
> kept in sync.
>

Whatever is kept on the opengrads.org CVS repository (soon "git") is open to
everyone for checkout (sf.net requirement), and of course  you have check in
privileges as well. I'll be mirroring COLAs releases on the COLA vendor
branch and merging it in to the trunk as soon as I reasonable.

BTW, I am bout to check in the revised pytests for v2; hold on checking in
to pytests for a sec. I'll send e-mail shortly.

     Arlindo


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: almost there

[Patrice D. <per...@fr...>]

On Fri, Feb 01, 2008 at 11:12:25PM -0500, Arlindo da Silva wrote:
> All,
> 2)  As I said before, my current work on the 2.0.a0 sources is meant to
> enable it to compile with the new supplibs, and reconcile the bug
> fixes/robustness improvements we (mostly Pat) made to the v1.9 build.

I am ready to contribute to that, but only if there is an access (read
only is fine) to a version control system, such that local changes are
kept in sync.

--
Pat

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: almost there

[Arlindo da S. <da...@al...>]

All,
1)   Regarding versioning. COLA is considered in this case the real
'upstream' maintainer of GrADS. If COLA releases version M.m.r (M=major,
m=minor, r=revision), any opengrads revisions of this tag will be denoted

        M.m.r.oga.i

where i = 1, 2, ... is an "increment". My real hope is that this versioning
becomes internal between the 2 groups and that as much as possible we try to
have public releases off COLA's M.m.r versions.

Jennifer: Is this acceptable to you?

2)  As I said before, my current work on the 2.0.a0 sources is meant to
enable it to compile with the new supplibs, and reconcile the bug
fixes/robustness improvements we (mostly Pat) made to the v1.9 build.
It will also include the test suite "pytests". Once I am done with it, I'll
submit the mods to COLA in the hope that, after review and patches of their
own they will put out a new M.m.r release, say 2.0.a1.  I'll then re-import
 the new M.m.r release into our repository and this version will serve as a
new baseline for any future development out of the
opengrads.orgrepository. At this point, if Brian/Jennifer requests, I
can help making
"out of the box" builds with this version for eventual posting at COLA's
official download site.

Jennifer: is this acceptable to you?

3) As I mentioned in the opengrads.org web page, opengrads public releases
may occur when we need patches to enable our latest extensions. If there is
no such need, there shall be no opengrads release.  Of course, we may not
always agree, and at some point a patch we require may not be acceptable to
COLA. If we ever get to that point we will be tracking COLA releases with
the necessary patches and the scheme above will be used to identify our
versions. I hope we never get to that point.

4) BTW, we have had over 300 downloads of v1.9.0-rc1. Except for a glitch in
the Win32 build which I have since then fixed, I haven't heard any complaint
about the other binaries. I got few "thank you" saying that they finally got
a working gradsdods, so updating to the new libdap may have done the trick.
Let's keep our fingers crossed.  People are also happy with the new Win32
build. Now that companies are locking down PC's good (to the point that
people cannot even change environment variables such as PATH), having
something that runs off a memory stick with no installation seems to help.

  Have a nice weekend everyone!

      Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: almost there

[Patrice D. <per...@fr...>]

On Fri, Feb 01, 2008 at 02:05:53PM -0500, Arlindo da Silva wrote:
> On Feb 1, 2008 7:38 AM, Jennifer Adams <jm...@co...> wrote:
> 
> > Arlindo, Could you please make a change to your gacfg.c and/or your
> > configure scripts in your v2 branch so that users and developers will be
> > able to distinguish between a COLA build and and Opengrads build?
> >
> 
> So far I have changed the version string in configure.ac from "2.0.a0" to "
> 2.0.a0-1". Perhaps I should have something more explicit such as "
> 2.0.a0-1.oga"

It is not a good idea to have - in the version string. What is the most
classical is a mixed digit and . (in ascii ascending order, please :-).
But adding a special tag for the opengrads build would be right, given
that these are more or less parallel versions. So something like
2.0.0.oga.

> Pat: how are you labeling the versions in Fedora?

We use what 'upstream' provides. In any case I may package opengrads or
COLA grads depending on which one is the most on the bleeding edge, but
I won't package both at a given time.

Version strings that are in the ascending ascii order are much easier to
use for packaging.

There is an additional release number we use to track the changes in the
package but it is not relevant for you.

--
Pat

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: almost there

[Jennifer A. <jm...@co...>]

On Feb 1, 2008, at 2:03 PM, Arlindo da Silva wrote:

> On Feb 1, 2008 7:38 AM, Jennifer Adams <jm...@co...> wrote:
> Arlindo,
> Could you please make a change to your gacfg.c and/or your  
> configure scripts in your v2 branch so that users and developers  
> will be able to distinguish between a COLA build and and Opengrads  
> build?
>
> So far I have changed the version string in configure.ac from  
> "2.0.a0" to "2.0.a0-1".
That's a little too subtle.
> Perhaps I should have something more explicit such as "2.0.a0-1.oga"
How about something like og<officialCOLAversion#>.n
Where n increments as you do iterations ...
Jennifer

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: almost there

[Arlindo da S. <da...@al...>]

On Feb 1, 2008 7:38 AM, Jennifer Adams <jm...@co...> wrote:

> Arlindo, Could you please make a change to your gacfg.c and/or your
> configure scripts in your v2 branch so that users and developers will be
> able to distinguish between a COLA build and and Opengrads build?
>

So far I have changed the version string in configure.ac from "2.0.a0" to "
2.0.a0-1". Perhaps I should have something more explicit such as "
2.0.a0-1.oga"

Pat: how are you labeling the versions in Fedora?


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: almost there

[Arlindo da S. <da...@al...>]

On Feb 1, 2008 4:22 AM, Patrice Dumas <per...@fr...> wrote:

> On Fri, Feb 01, 2008 at 02:24:05AM -0500, Arlindo da Silva wrote:
> >
> > Pat: can you check whether I captured all your dynamic supplib mods? In
> > particular, check m4/grib2.m4. The new HDF requirement may be
> particularly
> > challenging for you on Fedora as it requires a non-standard build of
> HDF-4
>
> No it won't be challenging since we already use --disable-netcdf... In
> fact it is sometime required to be able to link with hdf and netcdf
> together, first time it came in was for gdal (or grass), on Wed Feb  8
> 2006.
>

This is very encouraging.


> > (--disable-netcdf). Do you know who maintains HDF-4 on Fedora? If you
> cannot
>
> I comaintain HDF4 on fedora with Orion Poplawski.
>
> > have 2 versions of the HDF-4 library supported on fedora one solution
> may be
> > to drop NetCDF altogether as in the old days of v1.5 (or was it 1.6?
> Hoop
> > will remember) and let the standard HDF do the reading for both NetCDF
> and
> > HDF. Apparently HDF4.2r2 supports the NetCDF-3 API, if not I have a
> wrapper
> > library that could be useful.
>
> It supports the NetCDF-3 API but does it support the netcdf files?
>

HDF-4 have allways being able to read NetCDF files from Unidata, and of
course its own HDF-4 format. It only writes in HDF-4 format, though.  By
adding the NetCDF-3 API, I can't imagine they would drop support for reading
NetCDF files. BTW, NetCDF-2 and NetCDF-3 have different APIs but exactly the
same file format. NetCDF-4 adopts HDF-5 as its file format, but can still
read/write its previous NetCDF-2/3 format.


>
> Anyway there is support for both hdf4 builds with enable-dyn-supplibs
> (in hdf4.m4). If a build with sd_ appended (--disable-netcdf) is detected
> hdf2netcdf.h is included (to be seen in configure.ac).
>

This code fragment appears to be commented out in the configure.ac file. (I
was wondering what this was all about.) Am I correct to assume that if I
build HDF-4 with --disable-netcdf I should still be able to use the same
library to build v1.9? Have you ever tested it? If this is the case, I only
have to maintain one type of HDF-4 build in the supplibs.

  Thanks,

          Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: almost there

[Jennifer A. <jm...@co...>]

Arlindo,
Could you please make a change to your gacfg.c and/or your configure  
scripts in your v2 branch so that users and developers will be able  
to distinguish between a COLA build and and Opengrads build?
Thanks,
Jennifer


On Feb 1, 2008, at 2:24 AM, Arlindo da Silva wrote:

> All,
>
> I have checked in the grads v2 sources in our repo, and updated the  
> build to use the new supplibs. I'm keeping v2 temporarily on a  
> trunk until Brian comes up with the UDXT API and we can start  
> developing for v2. In the mean time I'll continue the pygrads work  
> with v1.9.
>
> To check out what I have:
>
> % gacvs co -P -r GRADS2_DEV_BRANCH grads
> % cd grads
> % ./configure --without-hdf
> % make
>
> and all should build with the current supplibs (well, almost: I  
> forgot to install grib2.h in include/grib2c; it is attached, do it  
> by hand for now in your copy of the supplibs)
>
> 1) I need to finish work on the supplibs before you can enable hdf.  
> Give me a day or two.
> 2) do not run the pytests as I am yet to adjust these for v2  
> (different binaries, no LATS, etc)
> 3) Read the ChangeLog to see how I modified COLA's original tarball
> 4) I have put in the hooks to build on windows, but have not tried  
> it; in fact, I only tried it on my Mac.
>
> Pat: can you check whether I captured all your dynamic supplib  
> mods? In particular, check m4/grib2.m4. The new HDF requirement may  
> be particularly challenging for you on Fedora as it requires a non- 
> standard build of HDF-4 (--disable-netcdf). Do you know who  
> maintains HDF-4 on Fedora? If you cannot have 2 versions of the  
> HDF-4 library supported on fedora one solution may be to drop  
> NetCDF altogether as in the old days of v1.5 (or was it 1.6? Hoop  
> will remember) and let the standard HDF do the reading for both  
> NetCDF and HDF. Apparently HDF4.2r2 supports the NetCDF-3 API, if  
> not I have a wrapper library that could be useful.
>
>   Let me know if it builds on your platform.
>
>     Arlindo
>
>
>
>
>
> -- 
> Arlindo da Silva
> da...@al...
> <grib2.h>------------------------------------------------------------- 
> ------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ 
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...

Re: [Opengrads-devel] Building GrADS v2 with new supplibs: almost there

[Patrice D. <per...@fr...>]

On Fri, Feb 01, 2008 at 02:24:05AM -0500, Arlindo da Silva wrote:
> 
> Pat: can you check whether I captured all your dynamic supplib mods? In
> particular, check m4/grib2.m4. The new HDF requirement may be particularly
> challenging for you on Fedora as it requires a non-standard build of HDF-4

No it won't be challenging since we already use --disable-netcdf... In
fact it is sometime required to be able to link with hdf and netcdf 
together, first time it came in was for gdal (or grass), on Wed Feb  8 2006.

> (--disable-netcdf). Do you know who maintains HDF-4 on Fedora? If you cannot

I comaintain HDF4 on fedora with Orion Poplawski.

> have 2 versions of the HDF-4 library supported on fedora one solution may be
> to drop NetCDF altogether as in the old days of v1.5 (or was it 1.6? Hoop
> will remember) and let the standard HDF do the reading for both NetCDF and
> HDF. Apparently HDF4.2r2 supports the NetCDF-3 API, if not I have a wrapper
> library that could be useful.

It supports the NetCDF-3 API but does it support the netcdf files?

Anyway there is support for both hdf4 builds with enable-dyn-supplibs
(in hdf4.m4). If a build with sd_ appended (--disable-netcdf) is detected 
hdf2netcdf.h is included (to be seen in configure.ac).

--
Pat

Re: [Opengrads-devel] lats4d

[Brian D. <do...@co...>]

Arlindo, with version 2 we are taking a long term view of GrADS and  
not focusing on short term issues.  It is our judgement that over the  
next 5 years and beyond it will be less work overall for us to re- 
implement the data output capability of GrADS rather than to go  
forward with the prior implementation.  This decision is based on a  
number of factors, not all of them technical.  While it is desirable  
to maintain upward compatibility, we of course view an entirely new  
version of GrADS as an opportunity to put GrADS on the right track  
for the future.  We must work towards an extremely stable code base.   
We cannot keep patching and putting out fires and still have time to  
implement the new features that COLA and others need -- and COLA  
needs rapid improvements to GrADS on a number of fronts.  The  
ensemble dimension is just the first major item.  The many new data  
formats already released or in the pipeline have already been  
discussed and these are external forcings we have no control over.   
We have warned you a number of times over the last couple years of  
our intention to come out with a new version that will change many  
things including lats, and this code will continue to have a rapid  
rate of improvement for another year or two and perhaps longer.   
GrADS is first and foremost a tool for COLA and the research  
community to meet strategic research goals going forward.  If the  
situation were different and we had more staff and resources perhaps  
we would have been able to support more legacy code.  But we must  
face the reality of what we have and fit our project into those limits.

And as already stated, we have not yet had time to re-implement the  
data output feature, since we have released v2 somewhat earlier than  
we had intended due to NCEP's grib2 timeline.  We have ben working  
very hard ever since NCEP announced their changeover date to get v2  
to the best state possible for that deadline... Brian

On Jan 30, 2008, at 12:31 PM, Arlindo da Silva wrote:

> On Jan 30, 2008 9:37 AM, Jennifer Adams <jm...@co...> wrote:
> We know that the loss of the LATS interface severely impacts many  
> users. But our intention is to *replace* it with something better,  
> not to eliminate the functionality completely. Consider this:
>
> set x; set y; set z; set t; set e
> set gxout fwrite
> set fwrite -nc file.nc
> d var
> disable fwrite
>
>
> Let's keep this technical discussion out of gradsusr...
>
> My main concern about this design is that when I think of "fwrite"  
> I think of stream I/O in the POSIX sense, and self-describing files  
> such as netcdf and hdf (and their API) do not conform to the stream  
> I/O model. Unless you want to restrict the feature above to only  
> write one variable per file on a single shot, I suspect you will  
> have to rewrite all the infrastructure in the LATS library,  
> including metadata setup layer and the LATS table, specially if you  
> are concerned about enforcing standards such as CF or being able to  
> write GRIB files.
>
> You are aware that PCMDI has already set in motion the process of  
> legally making LATS opensource, and that folks at PCMDI are aware  
> that LATS is used in GrADS, have given permission for COLA to do so  
> in the past, and have never expressed any opposition to it.  
> (Correct me if I am wrong.) Also, the license does not say that you  
> cannot modify the code; it simply states
>
>  * Copyright:    1996, Regents of the University of California
>  *        This software may not be distributed to others without
>  *        permission of the author.
>
> And as I understand it, the authors have given this permission to  
> COLA. Honestly, I don't understand why the license issue has now  
> emerged as a major impediment to continue supporting LATS in  
> GrADS.  (Yes, I admit, this conflicts with GPL, and we are living  
> in sin while the paperwork takes its course.)
>
> Regarding the LATS code proper. I realize this is a matter of  
> opinion, but I consider the LATS code well written: lots of  
> comments, modular and extensible with even a user guide. The  
> NetCDF-2 API it uses is the only true interoperable API among  
> NetCDF-2,3,4 and HDF-4, so I personally have no issues with it.  
> However, if one would elect to convert it to the NetCDF-3 API this  
> could be done relatively easy given the semantic equivalence of the  
> two APIs.  In the past few years we have developed at GMAO a small  
> wrapper library (libmfhd3.a)  which adds a NetCDF-3 API to HDF-4,  
> so converting LATS to the NetCDF-3 API would not require us to  
> write an HDF-4 module with the SD interface (which in itself is a  
> wrapper around the NetCDF-2 API with additional features thrown in).
>
> What exactly are the *technical issues* with LATS that makes it not  
> a viable alternative?
> Clearly, it would need to be extended to handle a 5th dimension  
> (although one could start by keeping the output files 4D, not a bad  
> idea in my opinion) and add additional formats such as GRIB-2.
>
> Sorry if it sounds like I am second guessing your decision, but I  
> am really having a hard time understanding the rationale behind it.
>
>             Arlindo
>
> -- 
> Arlindo da Silva
> da...@al...

Re: [Opengrads-devel] lats4d

[Arlindo da S. <da...@al...>]

On Jan 30, 2008 9:37 AM, Jennifer Adams <jm...@co...> wrote:

> We know that the loss of the LATS interface severely impacts many users.
> But our intention is to *replace* it with something better, not to eliminate
> the functionality completely. Consider this:
> set x; set y; set z; set t; set e
> set gxout fwrite
> set fwrite -nc file.nc
> d var
> disable fwrite
>
>
Let's keep this technical discussion out of gradsusr...

My main concern about this design is that when I think of "fwrite" I think
of stream I/O in the POSIX sense, and self-describing files such as netcdf
and hdf (and their API) do not conform to the stream I/O model. Unless you
want to restrict the feature above to only write one variable per file on a
single shot, I suspect you will have to rewrite all the infrastructure in
the LATS library, including metadata setup layer and the LATS table,
specially if you are concerned about enforcing standards such as CF or being
able to write GRIB files.

You are aware that PCMDI has already set in motion the process of legally
making LATS opensource, and that folks at PCMDI are aware that LATS is used
in GrADS, have given permission for COLA to do so in the past, and have
never expressed any opposition to it. (Correct me if I am wrong.) Also, the
license does not say that you cannot modify the code; it simply states

 * Copyright:    1996, Regents of the University of California
 *        This software may not be distributed to others without
 *        permission of the author.

And as I understand it, the authors have given this permission to COLA.
Honestly, I don't understand why the license issue has now emerged as a
major impediment to continue supporting LATS in GrADS.  (Yes, I admit, this
conflicts with GPL, and we are living in sin while the paperwork takes its
course.)

Regarding the LATS code proper. I realize this is a matter of opinion, but I
consider the LATS code well written: lots of comments, modular and
extensible with even a user guide. The NetCDF-2 API it uses is the only true
interoperable API among NetCDF-2,3,4 and HDF-4, so I personally have no
issues with it. However, if one would elect to convert it to the NetCDF-3
API this could be done relatively easy given the semantic equivalence of the
two APIs.  In the past few years we have developed at GMAO a small wrapper
library (libmfhd3.a)  which adds a NetCDF-3 API to HDF-4, so converting LATS
to the NetCDF-3 API would not require us to write an HDF-4 module with the
SD interface (which in itself is a wrapper around the NetCDF-2 API with
additional features thrown in).

What exactly are the *technical issues* with LATS that makes it not a viable
alternative?
Clearly, it would need to be extended to handle a 5th dimension (although
one could start by keeping the output files 4D, not a bad idea in my
opinion) and add additional formats such as GRIB-2.

Sorry if it sounds like I am second guessing your decision, but I am really
having a hard time understanding the rationale behind it.

            Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] GrADS v2.0.a1: First impressions

[Arlindo da S. <da...@al...>]

On Jan 29, 2008 4:54 PM, Brian Doty <do...@co...> wrote:

> Arlindo, we will be working on drafting an interface specification.
> The idea is that if the specification is followed, the UDF developer
> can have confidence his/her code will work with future COLA GrADS
> releases.  We'll ask for comments once we have something... Brian
>

I look forward to it. One way we have done this in the ESMF is to have the
earlier discussion around "use case scenarios" rather than a detailed API
spec. Kind like test-driven design: write the examples first, then formalize
the API and eventually code.

Another suggestion I'd have is to think about UDFs and UDCs (user defined
commands) from the get go. These 2 go very well together as the UDCs can be
used to configure the UDFs, therefore keeping the argument list manageable
for complex UDFs. And in some cases all you need is an UDC, not an UDF.

Let me know of I can be of any help.

    Arlindo


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] GrADS v2.0.a1: First impressions

[Brian D. <do...@co...>]

Arlindo, we will be working on drafting an interface specification.   
The idea is that if the specification is followed, the UDF developer  
can have confidence his/her code will work with future COLA GrADS  
releases.  We'll ask for comments once we have something... Brian

On Jan 28, 2008, at 9:05 AM, Arlindo da Silva wrote:

>
> Brian/Jennifer: I could have a first crack at adding the dynamic  
> UDFs/UDFs hooks, and go over with you in a face-to-face meeting at  
> COLA. Or else, I can be available for questions if you would prefer  
> to have a first crack yourselves. Let me know.
>

[Opengrads-devel] GrADS v2.0.a1: First impressions

[Arlindo da S. <da...@al...>]

All,
  First of all, congratulations to Jennifer and Brian on the milestone! I am
very much looking forward to making v2 the focus for the opengrads
activities.

  I was able to download Jennifer's sources last night and relatively easily
build it with the new supplibs. For convenience I built --without-hdf as I
wanted to see v2 in action rather than tinker with baselibs. Was able to
start it from the command classic line as well as through the pygrads
interpreter. (PyGrADS has limit functionality as I need the IPC extension to
exchange variables with python, something *not* used in pytests.) Yes, the
"-u" switch works out of the box. This means that the pytests should work
pretty much out of the box except for small adjustments for new executable
names, etc. However, I had to go to bed before I could play it.

My approach was as follows. The autoconf scripts in the v1.9 code base
appear in better shape than in v2.0.a1 (they are supplibs v2 ready, include
Pat's dynamic supplibs, and have other cleanup and more robust discovery
macros). Therefore, I started with our configure.ac and Makefile.am,
replaced all the files in src/, doc/, lib/ and etc/ with the
v2.0.a1versions. Then I merged the src/Makefile.am with the what we
had from
v1.9 and voila it built grads and gradsdap. I still need to do a bit clean
as I cut a couple of corners to get it done quickly. But the message is: we
should be able to v2.0.a1 building with the supplibs, Pat's dyn supplibs
feature, and pytests in a relatively short amount of time. This will allow
builds on all the platforms supported by the new supplibs, including
windows. Here is my proposed roadmap:

1. Place all current opengrads development under a GRADS1_DEV_BRANCH

2. Import GrADS v2.0.a1 into our CVS repo, in the usual COLA vendor branch,
release tag v2_0_a1

3. Patch the hdf4 in the current supplibs (I expect this to be a single line
change in the GNUmakefile) and rebuild them. Since I still have my sandboxes
around I may only have to rebuild hdf4 and re-tar.

4. Clean up what I did last night, making sure I have a full build
--with-hdf, and make sure "make check" and the pytests work. I'll need to
iterate with Pat to make sure the dynamic supplibs also work. I'll then
check this into the trunk, merging it with the COLA vendor branch. From that
point on, checking out module "Grads" will produce the v2 codebase.

At this point we can submit it to COLA as a patch or simply give them a tag
as Jennifer has repository privileges. If COLA is interested, I can help out
with builds at the platforms we have supplibs for; hoop is also setup to
build on solaris. My next priority would be to add the hooks for dynamically
linked extensions as this is the bread-and-butter of opengrads.

Brian/Jennifer: I could have a first crack at adding the dynamic UDFs/UDFs
hooks, and go over with you in a face-to-face meeting at COLA. Or else, I
can be available for questions if you would prefer to have a first crack
yourselves. Let me know.

Porting the current extensions to v2 deserves its own roadmap. Let's
postpone this discussion.

As always, any comments on this proposal is greatly appreciated.

  Cheers,

     Arlindo









-- 
Arlindo da Silva
da...@al...