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

[Opengrads-devel] Experimental survey

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

Guys,

  I am experimenting with the GoogleDocs form feature for preparing a GrADS
platform survey. Could you do me a favor and go to this address and complete
the survey?


http://spreadsheets.google.com/viewform?hl=en&formkey=dGctYWhkdTQyenZGSW40SjVOTGZWOUE6MA

  What do you think, is this something that I should send to gradsusr? Any
other platform related question that you would like included? Some of this
information can be derived from download statistics, but I never know how
much to trust these statistics.

  Cheers!

     Arlindo


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

Re: [Opengrads-devel] NetCDF-4 opendap support and gadap

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

On Oct 28, 2009, at 6:01 PM, Arlindo da Silva wrote:

> On Wed, Oct 28, 2009 at 7:33 AM, Jennifer Adams <jm...@co...>  
> wrote:
>
> On Oct 27, 2009, at 8:57 PM, Arlindo da Silva wrote:
>
> > Hi Jennifer,
> >
> >     What are your plans for dealing with gadap when adopting the new
> > NetCDF-4 with built-in OPeNDAP support? So far, I have been using
> > NetCDF-4 with an external (full) OPeNDAP library (libdap), which
> > also has what gadap needs.  Would we still be able to use the full
> > libdap alongside NetCDF-4 with built-in OPeNDAP?
> Sure. Why not? The netcdf-4 library with DAP replaces libnc-dap; gadap
> library needs libdap.
>
> The question is whether the OPeNDAP layer underneath NetCDF-4 causes  
> any namespace conflict. I got the impression from Dennis that it  
> would. I take that you've already checked this and showed it to  
> work. Correct?
No, I haven't tried it. OPeNDAP's recent namespace mods really messed  
things up -- I'll be bummed if it doesn't work, but maybe if I stick  
with older versions of libdap, I'll be okay. Anyway, I haven't thought  
about sequences, I'm still just looking at the dap interface for grids  
-- the coordinate axes are not showing up properly. Xdfopen will work  
if I tell it everything it needs to know for all grid dimensions....

>
> BTW, I don't know if you noticed, but I contributed a nc-config  
> script to netcdf. This makes it much easier to discover all the  
> dependencies in the configure macros.
I was very happy to find nc-config and used that script a few times,  
but I didn't know you had contributed it. Nice work!
--Jennifer

>
>      Arlindo
>
>
>
>
> > Or else, are you rewriting gadap? From some early exchange I had
> > with Dennis, I was under the impression that we would not have any
> > other option but to rewrite gadap.
> I don't want to modify gadap -- it's working fine. Maybe one day there
> will be a good netcdf interface for station data. I haven't yet looked
> at how the netcdf-4 dap interface handles sequences (as opposed to
> grids).
> --Jennifer
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>
>
> -- 
> Arlindo da Silva
> da...@al...
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference_______________________________________________
> 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] NetCDF-4 opendap support and gadap

[Arlindo da S. <arl...@gm...>]

On Wed, Oct 28, 2009 at 7:33 AM, Jennifer Adams <jm...@co...> wrote:

>
> On Oct 27, 2009, at 8:57 PM, Arlindo da Silva wrote:
>
> > Hi Jennifer,
> >
> >     What are your plans for dealing with gadap when adopting the new
> > NetCDF-4 with built-in OPeNDAP support? So far, I have been using
> > NetCDF-4 with an external (full) OPeNDAP library (libdap), which
> > also has what gadap needs.  Would we still be able to use the full
> > libdap alongside NetCDF-4 with built-in OPeNDAP?
> Sure. Why not? The netcdf-4 library with DAP replaces libnc-dap; gadap
> library needs libdap.
>

The question is whether the OPeNDAP layer underneath NetCDF-4 causes any
namespace conflict. I got the impression from Dennis that it would. I take
that you've already checked this and showed it to work. Correct?

BTW, I don't know if you noticed, but I contributed a nc-config script to
netcdf. This makes it much easier to discover all the dependencies in the
configure macros.

     Arlindo





> > Or else, are you rewriting gadap? From some early exchange I had
> > with Dennis, I was under the impression that we would not have any
> > other option but to rewrite gadap.
> I don't want to modify gadap -- it's working fine. Maybe one day there
> will be a good netcdf interface for station data. I haven't yet looked
> at how the netcdf-4 dap interface handles sequences (as opposed to
> grids).
> --Jennifer
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>



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

Re: [Opengrads-devel] NetCDF-4 opendap support and gadap

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

On Oct 27, 2009, at 8:57 PM, Arlindo da Silva wrote:

> Hi Jennifer,
>
>     What are your plans for dealing with gadap when adopting the new  
> NetCDF-4 with built-in OPeNDAP support? So far, I have been using  
> NetCDF-4 with an external (full) OPeNDAP library (libdap), which  
> also has what gadap needs.  Would we still be able to use the full  
> libdap alongside NetCDF-4 with built-in OPeNDAP?
Sure. Why not? The netcdf-4 library with DAP replaces libnc-dap; gadap  
library needs libdap.
> Or else, are you rewriting gadap? From some early exchange I had  
> with Dennis, I was under the impression that we would not have any  
> other option but to rewrite gadap.
I don't want to modify gadap -- it's working fine. Maybe one day there  
will be a good netcdf interface for station data. I haven't yet looked  
at how the netcdf-4 dap interface handles sequences (as opposed to  
grids).
--Jennifer

[Opengrads-devel] NetCDF-4 opendap support and gadap

[Arlindo da S. <arl...@na...>]

Hi Jennifer,

    What are your plans for dealing with gadap when adopting the new
NetCDF-4 with built-in OPeNDAP support? So far, I have been using NetCDF-4
with an external (full) OPeNDAP library (libdap), which also has what gadap
needs.  Would we still be able to use the full libdap alongside NetCDF-4
with built-in OPeNDAP? Or else, are you rewriting gadap? From some early
exchange I had with Dennis, I was under the impression that we would not
have any other option but to rewrite gadap.

   Thanks,

       Arlindo

Re: [Opengrads-devel] Buffer overflow vulnerability in GrADS

[Arlindo da S. <arl...@gm...>]

On Mon, Oct 26, 2009 at 4:43 PM, Jennifer Adams <jm...@co...> wrote:

> Hi, Arlindo --
> This is definitely worth fixing, but I think it will be simpler and faster
> to replace sprintf() with snprintf()
>

This is a 2 line fix: one call to snprintf(), followed  by ensuring NULL
termination, say pout[511]='\0'. An alternative would be to write a
slprintf() which does this combination (there are already strlcat(),
strlcpy() functions but no slprintf). However, folding this into gaprnt()
would allows us to simplify the code.


> rather than re-implement the message handling in GrADS.
>

You do not need to reimplement gaprnt(); it stays as it is. You just write a
gaprntf() cover function which does the pout thing with snprintf() and then
call the regular gaprnt(). Throughout the grads codebase you would be able
to replace the sprintf()+gaprnt() combination with a single call to
gaprntf(), therefore reducing loc.


> I'll put this on my list for the next release. I don't think it represents
> a security threat with the GDS.
>

I can think of a scenario or two where it could be exploited, but this is
not something I would broadcast on a publicly readable list. Probability is
low, though.

The main risk is that the whole gds+grads binary will not pass one of these
automated security audits, and the IT security cops would force us to take
the system down. Very often, you cannot argue with these guys.

   Thank you,

       Arlindo


--Jennifer
>
>
> On Oct 26, 2009, at 11:33 AM, Arlindo da Silva wrote:
>
> Brian, Jennifer et al,
>
>   As we all know, GrADS makes extensive use of the sprintf() function which
> is known to have the so-called buffer overflow vulnerability as explained in
> this document:
>
> http://developer.apple.com/mac/library/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html#//apple_ref/doc/uid/TP40002577
>
>   A good precaution would be to replace all occurrences of sprintf() with
> snprintf(), making sure the resulting string is NULL terminated.  Since many
> occurrences of sprintf() are associated with gaprnt(), it might be
> convenient to use the stdarg.h feature in the C standard library
>
>    http://en.wikipedia.org/wiki/Stdarg.h
>
>  and have a new function
>
>     gaprntf(int level,  const char *format, ...)
>
> which has the combined effect of sprintf() + gaprnt().
>
>   What do you think? I need to address this vulnerability before being able
> to deploy grads server side. I am willing to help implement this change in
> the main grads codebase.
>
>   Thanks,
>
>        Arlindo
>
>
> --
> Arlindo da Silva
> da...@al...
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>
> http://p.sf.net/sfu/devconference_______________________________________________
> 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...
>
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>


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

Re: [Opengrads-devel] Buffer overflow vulnerability in GrADS

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

Hi, Arlindo --
This is definitely worth fixing, but I think it will be simpler and  
faster to replace sprintf() with snprintf() rather than re-implement  
the message handling in GrADS. I'll put this on my list for the next  
release. I don't think it represents a security threat with the GDS.
--Jennifer


On Oct 26, 2009, at 11:33 AM, Arlindo da Silva wrote:

> Brian, Jennifer et al,
>
>   As we all know, GrADS makes extensive use of the sprintf()  
> function which is known to have the so-called buffer overflow  
> vulnerability as explained in this document:
>    http://developer.apple.com/mac/library/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html#/ 
> /apple_ref/doc/uid/TP40002577
>
>   A good precaution would be to replace all occurrences of sprintf()  
> with snprintf(), making sure the resulting string is NULL  
> terminated.  Since many occurrences of sprintf() are associated with  
> gaprnt(), it might be convenient to use the stdarg.h feature in the  
> C standard library
>
>    http://en.wikipedia.org/wiki/Stdarg.h
>
>  and have a new function
>
>     gaprntf(int level,  const char *format, ...)
>
> which has the combined effect of sprintf() + gaprnt().
>
>   What do you think? I need to address this vulnerability before  
> being able to deploy grads server side. I am willing to help  
> implement this change in the main grads codebase.
>
>   Thanks,
>
>        Arlindo
>
>
> -- 
> Arlindo da Silva
> da...@al...
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference_______________________________________________
> 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...

[Opengrads-devel] Buffer overflow vulnerability in GrADS

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

Brian, Jennifer et al,

  As we all know, GrADS makes extensive use of the sprintf() function which
is known to have the so-called buffer overflow vulnerability as explained in
this document:

http://developer.apple.com/mac/library/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html#//apple_ref/doc/uid/TP40002577

  A good precaution would be to replace all occurrences of sprintf() with
snprintf(), making sure the resulting string is NULL terminated.  Since many
occurrences of sprintf() are associated with gaprnt(), it might be
convenient to use the stdarg.h feature in the C standard library

   http://en.wikipedia.org/wiki/Stdarg.h

 and have a new function

    gaprntf(int level,  const char *format, ...)

which has the combined effect of sprintf() + gaprnt().

  What do you think? I need to address this vulnerability before being able
to deploy grads server side. I am willing to help implement this change in
the main grads codebase.

  Thanks,

       Arlindo


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

[Opengrads-devel] Dear friend!

[Luiz R. T. <lui...@gm...>]

<DIV>Dear friend,<BR>I am willing to give you a big surprise. I found
a website:&nbsp; www.ollsu.com last week. They mainly sell phones ,
laptops, tvs ,digital cameras and motorbikes. I ordered a tv . now I
have got the product after 5 days. Its quality is very good.<BR>By the
way, they only sell new and original products and their products have
international warranty. Now , they are promoting their products, so
the prices are very competitives. If you need these products, you can
have a look. Don not miss the good chance !<BR>Best wishes! </DIV>

[Opengrads-devel] LATS interface documentation

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

All,
Here is the first crack at documenting the new LATS extension for GrADS v2:

    http://opengrads.org/doc/udxt/lats/

This html documentation is generated with "make html" from the
extensions/lats directory. All the documentation is ripped from the file
"liblats.c". Look at the opengrads wiki for information on creating such
documentation.

Mike: could you take a look at it, in particular where it says: "Mike,
please help!"?

  Cheers!

     Arlindo

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

[Opengrads-devel] New Orbital mask extension

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

All,

  I just introduced a new extension to mask gridded fields according to
satellite orbits, see:

      http://opengrads.org/doc/udxt/orb/

The plan is to have this on 2.0.a7.oga.3, along with the new lats extension.
Please update your extension directories

cd extensions
cvs upd -A -d

(Do not forget the -d or new directories will not show up.)

    Arlindo


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

Re: [Opengrads-devel] LATS ported to GrADS v2 as an extension

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

Hi, Arlindo --
I am not planning on a new release in the near future. After the  
initial hiccup, version 2.0.a7.1 has not been particularly buggy. Our  
next release will have some new features that are still under  
development. At the moment, we're working on the shapefile interface.
--Jennifer

On Oct 15, 2009, at 10:48 AM, Arlindo da Silva wrote:

> All,
>
>
>  With Mike's help I've been able to port the LATS interface as an  
> extension to GrADS v2.0.a7.oga.2. I used the opportunity do make a  
> few enhancements such as support for NetCDF-3, NetCDF-4/HDF-5 and  
> HDF-4 all from the same single executable, and support for NetCDF-4  
> compression. The UI has simplified a bit, you no longer need to go  
> through the "display" command. The following UDCs are provided:
>
>      User
>   Defined
>   COMMAND           Short Description                Function@Library
>  ---------- -----------------------------------   
> --------------------------
>  set_lats   Set LATS parameters                   
> c_lats_set@^liblats.gex
>  query_lats Query LATS parameters                 
> c_lats_query@^liblats.gex
>  lats_grid  Define LATS grid                      
> c_lats_grid@^liblats.gex
>  lats_data  Write data to LATS file               
> c_lats_data@^liblats.gex
>  ---------- -----------------------------------   
> --------------------------
>
> The lats4d.gs usage remains the same; it detects the version and use  
> the appropriate LATS command. Some additional information:
>
> 1) I fixed a bug which has been driving me crazy for almost 10  
> years: now you can call it twice in a row without exiting grads.
>
> 2) I created an alias for the "convention" parameter called  
> "format". These are equivalent
>
>     ga-> set_lats convention grib
>     ga-> set_lats format grib
>
> 3) From the same single executable added several format options
>
>     ga-> set_lats format netcdf    (same as coards which is now  
> deprecated)
>     ga-> set_lats format netcdf4  (this is actually hdf-5)
>     ga-> set_lats format hdf4
>
> 4) Added a compression option with NetCDF
>
>     ga-> set gzip 2       (the higher the number, the better the  
> compression)
>     ga-> set shave 12  (number of bits to shave from float mantissa)
>
>     These usually go hand and hand. If you set shave it will  
> automatically set gzip=2 if it has not been set already. I should be  
> able to add this feature to HDF-4 output as well, but this require a  
> patch I got from the HDF Group and I'd better leave the supplibs  
> alone for now.
>
> 5) Made lats4d.gs aware of these new features. Try these:
>
> % lats4d.sh -i model -o junk -format netcdf -v
> % lats4d.sh -i model -o junk -format netcdf4 -v
> % lats4d.sh -i model -o junk -format hdf4 -v
> % lats4d.sh -i model -o junk2 -format netcdf -shave -v
>
> Compare the file sizes. Notice that the file extensions are now  
> consistent with the file format. Mike is looking into adding GRIB-2  
> support so that we can close the circle: conversion from/to any  
> GrADS supported format.
>
> I still have some work to do on documentation and create a  
> comprehensive test suite (I might be able to borrow from my GrADS  
> v1.x test suite.) If anybody out there would like to help test this,  
> just check out from CVS:
>
> % gacvs co -P Grads
> % cd Grads
> % make binstall
>
> The lats4d.sh script is now included under opengrads/Contents and  
> all should work out of the box. I am not sure if I'll release this  
> as v2.0.a7.oga.3 or wait for 2.0.a8.
>
> Jennifer: Is 2.0.a8 coming out any time soon?
>
>   Cheers!
>
>       Arlindo
>
>
>
>
>
>
>
>
> -- 
> Arlindo da Silva
> da...@al...
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference_______________________________________________
> 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...

[Opengrads-devel] LATS ported to GrADS v2 as an extension

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

All,

 With Mike's help I've been able to port the LATS interface as an extension
to GrADS v2.0.a7.oga.2. I used the opportunity do make a few enhancements
such as support for NetCDF-3, NetCDF-4/HDF-5 and HDF-4 all from the same
single executable, and support for NetCDF-4 compression. The UI has
simplified a bit, you no longer need to go through the "display" command.
The following UDCs are provided:

     *User*
  Defined
  COMMAND           Short Description                Function@Library
 ---------- -----------------------------------  --------------------------*
* set_lats   Set LATS parameters                  c_lats_set@^liblats.gex
 query_lats Query LATS parameters                c_lats_query@^liblats.gex
 lats_grid  Define LATS grid                     c_lats_grid@^liblats.gex
 lats_data  Write data to LATS file              c_lats_data@^liblats.gex*
* ---------- -----------------------------------  --------------------------


The lats4d.gs usage remains the same; it detects the version and use the
appropriate LATS command. Some additional information:

1) I fixed a bug which has been driving me crazy for almost 10 years: now
you can call it twice in a row without exiting grads.

2) I created an alias for the "convention" parameter called "format". These
are equivalent

    ga-> set_lats convention grib
    ga-> set_lats format grib

3) From the same single executable added several format options

    ga-> set_lats format netcdf    (same as coards which is now deprecated)
    ga-> set_lats format netcdf4  (this is actually hdf-5)
    ga-> set_lats format hdf4

4) Added a compression option with NetCDF

    ga-> set gzip 2       (the higher the number, the better the
compression)
    ga-> set shave 12  (number of bits to shave from float mantissa)

    These usually go hand and hand. If you set shave it will automatically
set gzip=2 if it has not been set already. I should be able to add this
feature to HDF-4 output as well, but this require a patch I got from the HDF
Group and I'd better leave the supplibs alone for now.

5) Made lats4d.gs aware of these new features. Try these:

% lats4d.sh -i model -o junk -format netcdf -v
% lats4d.sh -i model -o junk -format netcdf4 -v
% lats4d.sh -i model -o junk -format hdf4 -v
% lats4d.sh -i model -o junk2 -format netcdf -shave -v

Compare the file sizes. Notice that the file extensions are now consistent
with the file format. Mike is looking into adding GRIB-2 support so that we
can close the circle: conversion from/to any GrADS supported format.

I still have some work to do on documentation and create a comprehensive
test suite (I might be able to borrow from my GrADS v1.x test suite.) If
anybody out there would like to help test this, just check out from CVS:

% gacvs co -P Grads
% cd Grads
% make binstall

The lats4d.sh script is now included under opengrads/Contents and all should
work out of the box. I am not sure if I'll release this as v2.0.a7.oga.3 or
wait for 2.0.a8.

Jennifer: Is 2.0.a8 coming out any time soon?

  Cheers!

      Arlindo








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

Re: [Opengrads-devel] Fwd: OpenGrADS Bundle v2.0.a7.oga.1 Released!

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

On Wed, Oct 7, 2009 at 10:55 AM, Jose F Nieves <ni...@lt...>wrote:

> Arlindo
>
> I cannot upload the bundle. I keep getting a Permission denied
>
> sftp>  cd /home/frs/project/o/op/opengrads/grads2/2.0.a7.oga.2
> sftp> put grads-2.0.a7.oga.2-bundle-amd64-unknown-freebsd7.2.tar.gz
> Uploading grads-2.0.a7.oga.2-bundle-amd64-unknown-freebsd7.2.tar.gz to
> /home/pfs/project/o/op/opengrads/grads2/2.0.a7.oga.2/grads-2.0.a7.oga.2-bundle-amd64-unknown-freebsd7.2.tar.gz
> Couldn't get handle: Permission denied
>
>
Hmm... This new FRS may not be handling the permissions correctly. Another
possibility is to do this through the web interface:

1) Logon to sf.net with your user name

2) Go to the File Manager page:

https://sourceforge.net/project/admin/explorer.php?group_id=161773

3) click on grads2

4) RIGHT click on 2.0.a7.oga.2, select "Uploads here" from the popup menu

5) On the top of the diretory list (above the "Name" header), click on
"Upload File", and upload the bundle. If this fails, put the tarball up
somewhere and I'll upload it for you.

(I'm cc'ing opengrads-devel because this is the general upload procedure on
sf.net.)

   Let me know if this works,

       Arlindo












> Jose
>



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

Re: [Opengrads-devel] Bundle v2.0.a7.oga.2

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

On Mon, Oct 5, 2009 at 7:35 PM, Jose F Nieves <ni...@lt...>wrote:

> > All,
> >    I just found a bug that I had introduced in a6 that caused printim to
>                                                 ^^^^
> Arlindo
>
> Do you mean a7?
>
>
Actually, I first introduced the bug in a6 and it remained in a7.
Unfortunately, the gxyat issue in freebsd is still there.

   Arlindo




> Jose
>
> > crash, one of those bugs that it is hard to track because the sideffect
> is
> > remote. In any event, the only file changed is *gxhpng.c*. I have bumped
> the
> > version to 2.0.a7.oga.*2* and I will be posting new builds shortly.  I'll
> > remove the oga.1 builds from sf.net.
> >
> >    Arlindo
> >
> > --
> > Arlindo da Silva
> > da...@al...
> >
> > --001517741a14d305b0047536bb54
> > Content-Type: text/html; charset=ISO-8859-1
> > Content-Transfer-Encoding: quoted-printable
> >
> > All,<div><br></div><div>=A0=A0 I just found a bug that I had introduced
> in =
> > a6 that caused printim to crash, one of those bugs that it is hard to
> track=
> >  because the sideffect is remote. In any event, the only file changed is
> <b=
> > >gxhpng.c</b>. I have bumped the version to 2.0.a7.oga.<b><span
> class=3D"Ap=
> > ple-style-span" style=3D"text-decoration: underline;">2</span></b> and I
> wi=
> > ll be posting new builds shortly. =A0I&#39;ll remove the oga.1 builds
> from =
> > <a href=3D"http://sf.net">sf.net</a>.</div>
> > <div><br></div><div>=A0=A0 Arlindo<br clear=3D"all"><br>-- <br>Arlindo da
> S=
> > ilva<br><a href=3D"mailto:da...@al...">da...@al...
> </a><br=
> > >
> > </div>
> >
> > --001517741a14d305b0047536bb54--
> >
> >
> > --===============8847676669459612718==
> > Content-Type: text/plain; charset="us-ascii"
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> >
> >
> -----------------------------------------------------------------------------
> > -
> > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
> now&#33;
> > http://p.sf.net/sfu/devconf
> > --===============8847676669459612718==
> > Content-Type: text/plain; charset="us-ascii"
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> >
> > _______________________________________________
> > Opengrads-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opengrads-devel
> >
> > --===============8847676669459612718==--
>



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

Re: [Opengrads-devel] Bundle v2.0.a7.oga.2

[Jose F N. <ni...@lt...>]

> All,
>    I just found a bug that I had introduced in a6 that caused printim to
                                                ^^^^
Arlindo

Do you mean a7?

Jose

> crash, one of those bugs that it is hard to track because the sideffect is
> remote. In any event, the only file changed is *gxhpng.c*. I have bumped the
> version to 2.0.a7.oga.*2* and I will be posting new builds shortly.  I'll
> remove the oga.1 builds from sf.net.
> 
>    Arlindo
> 
> -- 
> Arlindo da Silva
> da...@al...
> 
> --001517741a14d305b0047536bb54
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> All,<div><br></div><div>=A0=A0 I just found a bug that I had introduced in =
> a6 that caused printim to crash, one of those bugs that it is hard to track=
>  because the sideffect is remote. In any event, the only file changed is <b=
> >gxhpng.c</b>. I have bumped the version to 2.0.a7.oga.<b><span class=3D"Ap=
> ple-style-span" style=3D"text-decoration: underline;">2</span></b> and I wi=
> ll be posting new builds shortly. =A0I&#39;ll remove the oga.1 builds from =
> <a href=3D"http://sf.net">sf.net</a>.</div>
> <div><br></div><div>=A0=A0 Arlindo<br clear=3D"all"><br>-- <br>Arlindo da S=
> ilva<br><a href=3D"mailto:da...@al...">da...@al...</a><br=
> >
> </div>
> 
> --001517741a14d305b0047536bb54--
> 
> 
> --===============8847676669459612718==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> -----------------------------------------------------------------------------
> -
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> --===============8847676669459612718==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
> 
> --===============8847676669459612718==--

[Opengrads-devel] Bundle v2.0.a7.oga.2

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

All,
   I just found a bug that I had introduced in a6 that caused printim to
crash, one of those bugs that it is hard to track because the sideffect is
remote. In any event, the only file changed is *gxhpng.c*. I have bumped the
version to 2.0.a7.oga.*2* and I will be posting new builds shortly.  I'll
remove the oga.1 builds from sf.net.

   Arlindo

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

Re: [Opengrads-devel] Fwd: OpenGrADS Bundle v2.0.a7.oga.1 Released!

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

On Wed, Sep 30, 2009 at 12:26 PM, Jose F Nieves <ni...@lt...>wrote:

> Arlindo
>
> make gex-check is giving me this
>
>
Has gxyat been built? Look for gxyat.gex in extensions/gxyat:

1) If gxyat.gex does not exist:

% cd extensions/gxyat
% make

  and send me output

2) If gxyat exists, start grads

%   opengrads/Contents/grads -bl
...
ga-> q udc
ga-> gxyat

and send me the output of that.

  My guess is that gxyat could not be built for some reason, perhaps cairo
related.

     Arlindo










>
> Jose
>
> test_gxyat_pdf (gxyat.ut.ut) ... ERROR
> test_gxyat_png (gxyat.ut.ut) ... ERROR
> test_gxyat_ps (gxyat.ut.ut) ... ERROR
> test_gxyat_svg (gxyat.ut.ut) ... ERROR
> test_set_rgba (gxyat.ut.ut) ... ERROR
>
>
>
> ======================================================================
> ERROR: test_gxyat_pdf (gxyat.ut.ut)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/home/work/grads/build/grads-2.0.a7.oga.1/extensions/gxyat/ut.py",
> line 53, in test_gxyat_pdf
>    self.ga("gxyat -v /tmp/ps.pdf")
>  File "lib/grads/gacore.py", line 220, in cmd
> GrADSError: 'GrADS returned rc=99 for <gxyat -v /tmp/ps.pdf>'
>
> ======================================================================
> ERROR: test_gxyat_png (gxyat.ut.ut)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/home/work/grads/build/grads-2.0.a7.oga.1/extensions/gxyat/ut.py",
> line 28, in test_gxyat_png
>    self.ga("gxyat -v /tmp/ps.png")
>  File "lib/grads/gacore.py", line 220, in cmd
> GrADSError: 'GrADS returned rc=99 for <gxyat -v /tmp/ps.png>'
>
> ======================================================================
> ERROR: test_gxyat_ps (gxyat.ut.ut)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/home/work/grads/build/grads-2.0.a7.oga.1/extensions/gxyat/ut.py",
> line 40, in test_gxyat_ps
>    self.ga("gxyat -v /tmp/ps.ps")
>  File "lib/grads/gacore.py", line 220, in cmd
> GrADSError: 'GrADS returned rc=99 for <gxyat -v /tmp/ps.ps>'
>
> ======================================================================
> ERROR: test_gxyat_svg (gxyat.ut.ut)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/home/work/grads/build/grads-2.0.a7.oga.1/extensions/gxyat/ut.py",
> line 66, in test_gxyat_svg
>    self.ga("gxyat -v /tmp/ps.svg")
>  File "lib/grads/gacore.py", line 220, in cmd
> GrADSError: 'GrADS returned rc=99 for <gxyat -v /tmp/ps.svg>'
>
> ======================================================================
> ERROR: test_set_rgba (gxyat.ut.ut)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/home/work/grads/build/grads-2.0.a7.oga.1/extensions/gxyat/ut.py",
> line 77, in test_set_rgba
>    self.ga("set_rgba 60 125 125 125 0 1")
>  File "lib/grads/gacore.py", line 220, in cmd
> GrADSError: 'GrADS returned rc=1 for <set_rgba 60 125 125 125 0 1>'
>
>
>


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

Re: [Opengrads-devel] At last, OpenGrADS Bundle v2.0.a7.oga.1 build

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

On Sep 29, 2009, at 10:22 AM, Arlindo da Silva wrote:

> All,
>
>   Jennifer: I usually ship a full set of HTML documentation with the  
> bundle for those cases when you are offline and need to look  
> something up. Lately the doc/ directory in your tarballs have not  
> been updated. Do you think you could update this for "a8"?
Yes, updating the doc pages in the src release is on my list of things  
to do for the next release.

--Jennifer

[Opengrads-devel] At last, OpenGrADS Bundle v2.0.a7.oga.1 build

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

All,
  After a very busy summer/early fall, I have been able to make a 2.0.a7
build with the opengrads extensions. Although there no new extensions being
released (I have a couple in the works but not ready for prime time yet),
there have been some improvements under hood. Most importantly, I have added
a detailed unit test suite for the extensions. Here is the build sequence
after your untar:

% ./configure
% make
% make check   (to test the core grads engine)
% make gex-check (to test the extensions)
% make bundle-dist (to create tarballs for sf.net)

There a total of 75 new tests for the extensions. Some of these will say
"skipped", which means that these a place holders (a real test is yet to be
written). These tests are very important to make sure changes in the main
engine by COLA do not break the extensions.

Mike: all the tests in libmf are place holders; just enter the test code
under mf/ut.py (use the other */ut.py as examples). We also need
documentation...

Jennifer: I usually ship a full set of HTML documentation with the bundle
for those cases when you are offline and need to look something up. Lately
the doc/ directory in your tarballs have not been updated. Do you think you
could update this for "a8"?

BTW, I never released a 2.0.a6. Mike reported that it had broken his wxmap
system and we suspected the extensions were hosed. This prompt me to write
these tests, and it took me longer than anticipated.

  Let me know if you experience any problem with the build.

   Cheers!

      Arlindo

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

Re: [Opengrads-devel] Clab mask offset

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

Hi, Gary --
Thanks for forwarding the bug report. I will need the script and the  
data set used to generate the image in order to reproduce the error so  
I can track it down.
--Jennifer


On Aug 27, 2009, at 11:55 AM, Love, Mr. Gary, Contractor, Code 7542  
wrote:

> Hi,
>
> The attached plot shows an offset between the contour label and the
> label mask underneath.
>
> Gary G. Love (SAIC)
> Senior Scientist
> Marine Meteorology Division
> Naval Research Laboratory
> Monterey, CA 93943
> 831-656-4767
>
>
> -----Original Message-----
> From: Jin, Dr. Hao
> Sent: Thursday, August 27, 2009 8:41 AM
> To: Love, Mr. Gary, Contractor, Code 7542
> Subject: RE: GrADS questions
>
> Hi Gary,
>
> Please look at the attached image, it seems that there is a bug with
> "clab mask" in GrADS version 2.0.a7.1.  The masked label area doesn't
> match the label position.  Could you forward this email GrADS
> developers?
>
> Thanks,
> Hao
>
> -----Original Message-----
> From: Jin, Dr. Hao
> Sent: Tuesday, August 25, 2009 2:33 PM
> To: Love, Mr. Gary, Contractor, Code 7542
> Subject: RE: GrADS questions
>
> Hi Gary,
>
> I found that new GaRDS version 2.0.a7.1 has a clab mask feature to
> address the problem 2 in my yesterday email.  I installed the new
> version and it works well.
>
> Cheers,
> Hao
>
>
> -----Original Message-----
> From: Jin, Dr. Hao
> Sent: Monday, August 24, 2009 3:53 PM
> To: Love, Mr. Gary, Contractor, Code 7542
> Subject: GrADS questions
>
> Hi Gary,
>
> I have a few questions regarding to GrADS:
> 1) I knew that we can use "set strmden" to control the density of the
> streamlines.  I want to less streamlines even if I have "set strmden  
> 1".
> How can we do that?
> 2) I plot the contour on the top of shaded fields.  How can we have
> transparent background for the contour labels?
> 3) Could I create transparent color shading?
>
> Thanks a lot,
> Hao
> <2009082700_000_sst- 
> sfc_g1 
> .gif 
> > 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july_______________________________________________
> 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...

[Opengrads-devel] Unit tests for extensions

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

Mike et al.,
   I am in the processes of writing unit tests for the extensions based on
PyUnit, much like pytests. Here is the idea. Under each extensions/dir there
is a file called "ut.py" which implements the tests. I implemented a
prototype under ams:

% cd extensions/ams
% (cvs upd ut.py)
% ./ut.py

and it will run the tests (the top driver looping over the extensions is not
written yet. I have placed ut.py template under mf/

cd extensions/mf
cvs upd ut.py
./ut.py

It will say something like

             Testing MF Extensions
             ---------------------

- Testing with GrADS binary ../../src/grads
- Testing with data file ../../pytests/data/model.ctl

test_esmrf (__main__.utMF) ... ok
test_grhist (__main__.utMF) ... ok
test_linreg (__main__.utMF) ... ok
test_mfhilo (__main__.utMF) ... ok
test_re2 (__main__.utMF) ... ok
test_smth2d (__main__.utMF) ... ok
test_tcprop (__main__.utMF) ... ok
test_uv2trw (__main__.utMF) ... ok


All you need to do is to write the functions test_esmrf, ..., test_uv2trw.
Look at ams/ut.py and TestModelFile.py under pytests/ for examples. Also,
take a look at the wiki:


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

This is really the only way to make sure our builds are working on all
platform. Testing these manually is simply to time consuming.

Mike:  Do you think you would be able to fill in the tests for libmf? It
would be good if tests could be written for model.ctl, but other *small*
input files would be OK. I have v2.0.a6.oga.1 on hold since you reported it
broke your wxmaps. The builds pass the regular pytests, with these new tests
we will be able to say whether the extensions are broken or not.

  Let me know if you have questions,

  Cheers!

    Arlindo



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

Re: [Opengrads-devel] Merging with a6

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

On Wed, Jun 10, 2009 at 7:41 PM, Arlindo da Silva <da...@al...>wrote:

> All,
>    I am in the process of merging the trunk (CVS module: Grads) with COLA's
> 2.0.a6. Please refrain from checking in/out to/from the TRUNK until I am
> done.
>

I am done with the merger. However, "make check" reports 2 problems:
======================================================================
ERROR: test_03_Display (TestModelFile.grads_url)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/dasilva/src/2/Grads/pytests/TestModelFile.py", line 249, in
test_03_Display
    self._CheckCint('ua',-12,18,3,z=1,t=1)
  File "/Users/dasilva/src/2/Grads/pytests/TestModelFile.py", line 268, in
_CheckCint
    self.assertEqual(cmin,int(self.ga.rword(1,2)))
ValueError: invalid literal for int() with base 10: '-9e+08'

======================================================================
FAIL: test_01_Stats (TestModelFile.grads_stn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/dasilva/src/2/Grads/pytests/TestModelFile.py", line 314, in
test_01_Stats
    self._stats(  'slp',
'2842','-999','1496','982.5','1046.5','985','1045','5')
  File "/Users/dasilva/src/2/Grads/pytests/TestModelFile.py", line 326, in
_stats
    self.assertEqual(v_undef,ga.rword(7,4))
AssertionError: '-999' != '-9.99e+08'

I can reproduce these errors with COLA builds, so I think is something in
COLA's codebase.

Jennifer: I posted something on gradsusr regarding "test_03_Display" (undef
handling with gradsdap). The second error may not be an error, simply the
fact that we have now a different value for UNDEFs. Correct?

   Arlindo


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

[Opengrads-devel] Merging with a6

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

All,
   I am in the process of merging the trunk (CVS module: Grads) with COLA's
2.0.a6. Please refrain from checking in/out to/from the TRUNK until I am
done.

     Arlindo

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

[Opengrads-devel] Automatic updates for OpenGrADS Bundles?

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

On Fri, May 29, 2009 at 11:43 AM, Mike Fiorino <mfi...@gm...> wrote:

> hi arlindo,
>
[snip]

>
> 2) will this -P Extensions be the standard way to get deal with the
> extensions?  vice Grads/extensions?
>

Not with API 0 because these extensions (like extensions in python, perl)
are tied to a particular version of grads. (If data structures in grads.h
get changed you can really mess things up if you mix and match versions).

The only point of a standalone Extensions module is for sharing latest
patches with advanced users such as Kevin. For the general grads user having
a consistent, zero-conf opengrads bundle is the simplest to explain, install
and maintain.

The main problem with this approach is that as GrADS v2.0 matures the
extensions may need to be updated on a more frequent basis. What I was
thinking is to start producing updates (perhaps even automatically) for a
base opengrads version. For example, grads-2.0.a5.oga would exist as a full
download, and it would come with a script to perfom updates, mostly
associated with revisions in the extensions.


> kevin, i could just copy the 1.10 Extensions into 2.0 and update that
> version of the package, but it seems the better way to go is to keep the
> grads-version independent code separate... so, i'll wait until arlindo
> defines how to deal with the extensions code before announcing to
> gradsusr...
>


Until we have an update infrastructure (which would require building the
updates on all supported platforms, something I do not have time for right
now) the best solution may be to have the standalone Extension *sources*
posted on sf.net, properly versioned:

gex-2.0.a5.oga.5.p1.tar.gz
gex-1.10.r2.oga.p1.tar.gz

which means "patch 1" of the extensions in the corresponding bundle.
Interested users who cannot wait for the next bundle release would then
build from sources. There is nothing preventing you or someone else from
posting binaries, but will need to come with very careful directions of
where to insert these into the bundle.
(I have a half-finished script under bundle/ for this: bundle_install.pl).
As I said, an update script would be very nice, but we need to find a
solution for the builds --- we need more building volunteers!

I'm cc'ing the opengrads development list to open this up for discussion.

   Cheers,

       Arlindo


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



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