Menu
▾
▴
opengrads-devel — OpenGrADS development issues, with focus on interfaces and extensions
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(19) |
Feb
(50) |
Mar
(10) |
Apr
(1) |
May
(12) |
Jun
(4) |
Jul
(17) |
Aug
(39) |
Sep
(9) |
Oct
|
Nov
|
Dec
(12) |
| 2009 |
Jan
(8) |
Feb
(11) |
Mar
(4) |
Apr
(3) |
May
(2) |
Jun
(2) |
Jul
(1) |
Aug
(2) |
Sep
(3) |
Oct
(17) |
Nov
(8) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(12) |
Aug
|
Sep
|
Oct
(12) |
Nov
|
Dec
|
| 2011 |
Jan
(10) |
Feb
|
Mar
|
Apr
(2) |
May
(6) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(25) |
Nov
(4) |
Dec
(2) |
| 2012 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(5) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Arlindo da S. <da...@al...> - 2010-10-05 14:03:39
|
On Tue, Oct 5, 2010 at 5:16 AM, Patrice Dumas <per...@fr...> wrote: > On Mon, Oct 04, 2010 at 04:40:17PM -0400, Jennifer Adams wrote: > > > > > >Regarding the supplibs, I have been working on the switch to cairo > > >for graphics rendering. At the moment, I am only working in the > > >mac environment, using the macports installation of cairo, so I > > >don't really know what the issues are regarding building from > > >source, or for the autoconfiguration. If any of you can provide > > >some guidance, especially for the autoconf stuff, it would be most > > >welcome. There must be some existing code out there that does > > >this, maybe already in opengrads, but I haven't looked for it yet. > > cairo uses pkgconfig. So something like > > cairo_pkgconfig=yes > PKG_CHECK_MODULES([CAIRO],[cairo >= $cairo_min_version],, > [cairo_pkgconfig=no]) > > should set CAIRO_LIBS and CAIRO_CFLAGS. This should be enough for > linking dynamically against the system library. > > > The libs it requires when statically linking should be listed in > Requires.private:. To link statically against the supplibs, I guess that > you have 2 options. Either simply supply the right link flags and > include dirs, either hardcoded or using GA_SET_FLAGS and similar. Or > put the .pc files obtained when compiling supplibs in a specific > directory in the supplibs, set PKG_CONFIG_PATH to this directory, and > use a pkg-config call, like > pkg-config --static cairo --libs > > I don't know if you'd want to put pkg-config in the supplibs too, then, > but, in case you wonder, on my debian squeeze box, pkg-config links against > glib, which in turns requires libpcre, and no other dependency (besides > a C library) seems to be involved. > > > (Cairo, however needs quite a bit of depednecies, but it is not clear to me > how you want to handle the backends of cairo? On my box, the xcb backend > is used: > > pkg-config --static cairo --libs > -lcairo -lpixman-1 -lfontconfig -lexpat -lfreetype -lpng12 -lz -lm > -lxcb-render-util -lXrender -lxcb-render -lX11 -lpthread -lxcb -lXau -lXdmcp > > But I guess that on MacOSX the Quartz backend should be used, on Windows > the win32 backend, on other UNIX the xlib backend?) > > Nice to hear form you! The opengrads supplibs includes pkg-config and builds (whenever possible) builds all packages with it. The main reason being this autoconf integration. As for my experience building cairo in the supplibs. This is the only library that I have *not* succeeded to build statically on all platforms. Not quite sure what the issues are. Since the opengrads wrappers automatically sets LD_LIBRARY_PATH, this have not been a problem. So far I have used cairo primarily for gxyat with only 4 backends: PNG, SVG, ps and pdf. I disable everything else to avoid any unnecessary dependency. Jennifer: which back ends do you intend to use? Arlindo -- Arlindo da Silva da...@al... |
|
From: Patrice D. <per...@fr...> - 2010-10-05 10:02:12
|
On Mon, Oct 04, 2010 at 04:40:17PM -0400, Jennifer Adams wrote:
> >
> >Regarding the supplibs, I have been working on the switch to cairo
> >for graphics rendering. At the moment, I am only working in the
> >mac environment, using the macports installation of cairo, so I
> >don't really know what the issues are regarding building from
> >source, or for the autoconfiguration. If any of you can provide
> >some guidance, especially for the autoconf stuff, it would be most
> >welcome. There must be some existing code out there that does
> >this, maybe already in opengrads, but I haven't looked for it yet.
cairo uses pkgconfig. So something like
cairo_pkgconfig=yes
PKG_CHECK_MODULES([CAIRO],[cairo >= $cairo_min_version],,
[cairo_pkgconfig=no])
should set CAIRO_LIBS and CAIRO_CFLAGS. This should be enough for
linking dynamically against the system library.
The libs it requires when statically linking should be listed in
Requires.private:. To link statically against the supplibs, I guess that
you have 2 options. Either simply supply the right link flags and
include dirs, either hardcoded or using GA_SET_FLAGS and similar. Or
put the .pc files obtained when compiling supplibs in a specific
directory in the supplibs, set PKG_CONFIG_PATH to this directory, and
use a pkg-config call, like
pkg-config --static cairo --libs
I don't know if you'd want to put pkg-config in the supplibs too, then,
but, in case you wonder, on my debian squeeze box, pkg-config links against
glib, which in turns requires libpcre, and no other dependency (besides
a C library) seems to be involved.
(Cairo, however needs quite a bit of depednecies, but it is not clear to me
how you want to handle the backends of cairo? On my box, the xcb backend
is used:
pkg-config --static cairo --libs
-lcairo -lpixman-1 -lfontconfig -lexpat -lfreetype -lpng12 -lz -lm -lxcb-render-util -lXrender -lxcb-render -lX11 -lpthread -lxcb -lXau -lXdmcp
But I guess that on MacOSX the Quartz backend should be used, on Windows
the win32 backend, on other UNIX the xlib backend?)
--
Pat
|
|
From: Jennifer A. <jm...@co...> - 2010-10-04 20:56:39
|
This reply went out to Arlindo only, and I wanted the entire list to see it. --Jennifer Begin forwarded message: > From: Jennifer Adams <jm...@co...> > Date: October 4, 2010 4:22:17 PM EDT > To: Arlindo da Silva <da...@al...> > Subject: Re: [Opengrads-devel] Opengrads bundle 2.0.a9 being uploaded > > Arlindo, et al., > I'm glad to hear that 2.0.a9 is behaving well with opengrads. I have > not heard any complaints about a9 so far. As for the OS X builds, I > have not upgraded to snow leopard yet, but Brian has, so I will > likely be putting out three OS X releases next time. I will keep > doing the powerpc builds until one of the supplib upgrades breaks > something. > > Regarding the supplibs, I have been working on the switch to cairo > for graphics rendering. At the moment, I am only working in the mac > environment, using the macports installation of cairo, so I don't > really know what the issues are regarding building from source, or > for the autoconfiguration. If any of you can provide some guidance, > especially for the autoconf stuff, it would be most welcome. There > must be some existing code out there that does this, maybe already > in opengrads, but I haven't looked for it yet. > --Jennifer > > > > > On Oct 4, 2010, at 3:18 PM, Arlindo da Silva wrote: > >> All, >> >> I have finished merging COLA's latest 2.0.a9 with our code base >> and started uploading binaries to sf.net. Now that the colorized >> text feature is in COLA's codebase merging is becoming easier. The >> only thing I have to do is to add the hooks for the extensions >> which is localized in a couple of places, and some mods in the main >> grads.c mainly for the windows and java builds. (I am not >> distributing the java builds yet.) >> >> Not many updates in the extensions this time. As per Jennifer >> request, I have dropped the shape extension altogether (last time >> it was hidden, this time I didn't even build it.) I also had to >> make a small (but subtle) change in the LATS extension because of >> some internal change in the main grads codebase. This was good, the >> revised LATS is more robust this now. >> >> Snow Leopard update. I have a 99% functional build on Mac OS X >> 10.6 (Snow Leopard, 64 bits). All seems to work fine with the core >> grads functionality from COLA. I only have an issue with the LATS >> extension, in particular when writing GRIB-1 files -- the netcdf/ >> hdf output works just fine. I suspect it has something to do with >> the size of integers. Until I fix this I'll not release the SNow >> Leopard build. The good news for Jennifer is that her builds >> should work out of the box on SL. >> >> Jose, >> >> When you have a chance, could you make the FreeBSD builds? Thanks. >> >> Cheers, >> >> Arlindo >> >> -- >> Arlindo da Silva >> da...@al... >> ------------------------------------------------------------------------------ >> Virtualization is moving to the mainstream and overtaking non- >> virtualized >> environment for deploying applications. Does it make network security >> easier or more difficult to achieve? Read this whitepaper to >> separate the >> two and get a better understanding. >> http://p.sf.net/sfu/hp-phase2-d2d_______________________________________________ >> 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... > > > -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jm...@co... |
|
From: Jose F N. <ni...@lt...> - 2010-10-04 20:34:17
|
> > Jose, > > When you have a chance, could you make the FreeBSD builds? Thanks. > > Cheers, > > Arlindo Arlindo Sure. Jose |
|
From: Arlindo da S. <da...@al...> - 2010-10-04 19:18:51
|
All, I have finished merging COLA's latest 2.0.a9 with our code base and started uploading binaries to sf.net. Now that the colorized text feature is in COLA's codebase merging is becoming easier. The only thing I have to do is to add the hooks for the extensions which is localized in a couple of places, and some mods in the main grads.c mainly for the windows and java builds. (I am not distributing the java builds yet.) Not many updates in the extensions this time. As per Jennifer request, I have dropped the shape extension altogether (last time it was hidden, this time I didn't even build it.) I also had to make a small (but subtle) change in the LATS extension because of some internal change in the main grads codebase. This was good, the revised LATS is more robust this now. Snow Leopard update. I have a 99% functional build on Mac OS X 10.6 (Snow Leopard, 64 bits). All seems to work fine with the core grads functionality from COLA. I only have an issue with the LATS extension, in particular when writing GRIB-1 files -- the netcdf/hdf output works just fine. I suspect it has something to do with the size of integers. Until I fix this I'll not release the SNow Leopard build. The good news for Jennifer is that her builds should work out of the box on SL. Jose, When you have a chance, could you make the FreeBSD builds? Thanks. Cheers, Arlindo -- Arlindo da Silva da...@al... |
|
From: Arlindo da S. <da...@al...> - 2010-07-24 03:35:54
|
All, I am writing to you becuase in the past you were kind enough to help us testing the Windows build. Getting GrADS v2.0.a8 to work on Windows was a little harder this time. For one, I had to rebuild the supplibs, and recently I have upgraded to a more recent version of the cygwin compilers which gave me some headache. So before I put these binaries out there some beta testing is in order. We got almost 5,000 downloads of the previous windows build, so a buggy win32 build has the potential of creating a lot of e-mail traffic on the list. If you are willing to give it a try, you can find the binaries here: Self installing package (setup.exe): http://opengrads.org/pre-rel/win32/grads-2.0.a8.oga.1-win32_superpack.exe ZIP: http://opengrads.org/pre-rel/win32/grads-2.0.a8.oga.1-win32_superpack.zip It should work as before, however pre-NT versions of windows (Windows 95, 98 & ME) are no longer supported. Please write directly to me (da...@op...) if you have any problems with this build. Any help greatly appreciated. Thank you, Arlindo -- Arlindo da Silva da...@al... |
|
From: Arlindo da S. <da...@al...> - 2010-07-15 13:54:40
|
All,
See below in yellow my comment to a user regarding glibc and binary
portability.
Arlindo
---------- Forwarded message ----------
From: Arlindo da Silva <da...@al...>
Date: Thu, Jul 15, 2010 at 9:38 AM
Subject: Re: [gradsusr] OpenGrADS Bundle 2.0.a8 Released!
To: GrADS Users Forum <gra...@gr...>
On Thu, Jul 15, 2010 at 8:06 AM, Earnshaw, Paul <
pau...@me...> wrote:
> Arlindo,
>
> frpe@eld188:> uname -a
> Linux eld188 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:34:33 EDT 2009 i686 i686
> i386 GNU/Linux
> frpe@eld188:> gcc --version
> gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> frpe@eld188:> ldd --version
> ldd (GNU libc) 2.3.4
>
> I have since run the executable on a different machine and I get a more
> obvious error message associated with the information you wanted:
>
> /net/home/h01/gmdd/grads2/Contents/Linux/Versions/2.0.a8.oga.1/i686/grads:
> error while loading shared libraries: requires glibc 2.5 or later dynamic
> linker
>
>
That is exactly it. You will get the same error if you try COLA's i686 build
which was also uses glibc 2.5. Up to now I had been building the i686
version of the OpenGrADS Bundle on a machine with glibc 2.3.4 as yours.
However, I hit a problem with 2.0.a8 version of gribmap using this version
of glibc. In the end I had to build it on a newer machine with glibc 2.5.
For the record: for binary portability, more important than the particular
version of gcc is the version of glibc. In this particular case, I rebuilt
grads with gcc 4.1.2 and glibc 2.3.4 and I could not get gribmap to work. On
Linux, you can find the glibc version with "ldd --version". In the future
perhaps we should have the glibc version as part of the binary tarball
filename (at least on Linux).
> I take it this means with the current version of glibc I will not be able
> to run 2.0.a8.oga.1?
>
>
Almost. I have a build of grads 2.0.a8 on i686 using glibc 2.3.4; it passes
all of my tests (including extensions but not the large grib feature) except
for gribmap. If can make it it available to you offline, but I'd rather not
post it on sf.net because it is not 100% functional. If you do not need the
new large file feature of gribmap you could mix & match and use the
2.0.a7.oga.3 version of gribmap and everything else from 2.0.a8. If
interested, write to me at da...@op... and I'll make this build
available to you.
Arlindo
--
Arlindo da Silva
da...@al...
--
Arlindo da Silva
da...@al...
|
|
From: Arlindo da S. <da...@al...> - 2010-07-13 01:54:47
|
All, I have posted binaries tarballs for supplibs 2.2.0 and grads 2.0.a8.oga.1 on sf.net: https://sourceforge.net/downloads/opengrads/grads2/2.0.a8.oga.1/ https://sourceforge.net/downloads/opengrads/supplibs/2.2.0/ If someone would like to give it a try before I make a general announcement I'd really appreciate it. I still need to finish the Snow Leopard and Windows builds. I'll post the final sources when I finish all the other builds. For now, use the checkout instructions below to build from sources. Cheers! Arlindo On Sun, Jul 11, 2010 at 10:58 AM, Arlindo da Silva <da...@al...>wrote: > All, > > I'm making progress towards the 2.0.a8 upgrade. > > 1) The supplibs have been upgraded to version 2.2.0. To get the fresh > sources and build, > > % gacvs co -d supplibs-2.2.0 -P supplibs > % cd supplibs-2.2.0/src > % make install > > So far I've tested this on Mac OS X 10.5.8, RHEL 5 (x86_64) and RHEL4 > (i686). > > 2) The Grads codebase has been merged with COLA's. Since COLA now has a > single executable, I've replaced our previous build with COLA's, making > small adjustments for supporting the extensions and the extra-platforms we > support. I am afraid we have lost the integration with pkg-config, something > I could restore later. However, the close we track COLA's codebase the less > the maintenance costs on our end. To check it out and build, > > % gacvs co -d Grads-2.0.a8 -P Grads > % ln -s /path/to/your/supplibs/arch supplibs > % cd Grads-2.0.a8 > % configure > % make > % make check > > It passes all tests on Mac OS X 10.5.8 (Leo), x86_64 and i686. I'll try Mac > OS X 10.6 (Snow Leo) and Windows once I have robust builds on these 3 > platforms. > > 3) For testing the extensions: > > % make binstall > (put opengrads/Contents in your path) > % cd extensions > % make check > > It passes all 93 tests on Darwin and x86_64. However, it fails a single > test on i686: the creation of grads_grib files with the LATS extension (all > other formats work). I love these tests... > > Mike, > > To reproduce the problem, simply try (using lats4d.sh under > opengrads/Contents): > > % lats4d.sh -i model.nc -o junk -format grads_grib > > This will complete successfully, but when you try to read the file all > variables will be UNDEF. I tried downgrading the LATS extension to the > 2.0.a7.oga.3 version (that is, before your recent mods) but the problem > persisted. The previous 2.0.a7.oga.3 binaries work with the current LATS > extension. So it may be related to some internal grads changes, probably > related to gribmap, but I am not sure. Could you take a look at it? > > Thanks, > > Arlindo > > > > > > > > > > -- > Arlindo da Silva > da...@al... > -- Arlindo da Silva da...@al... |
|
From: Jennifer A. <jm...@co...> - 2010-07-12 18:37:20
|
On Jul 12, 2010, at 12:19 PM, Arlindo da Silva wrote:
> Jennifer,
>
> Is the doc/ directory in your 2.0.a8 source tarball up to date?
> I'd like to update the documentation we ship with the bundle (for
> off-line use).
I had updated the a8 code with new doc files but forgot to commit new
versions of existing files. Here is a link to a tarball (it will
unpack as ./doc/* ) that has all the documentation web pages, current
as of today.
ftp://iges.org/pub/jma/dev20/grads-doc-20100712.tar.gz
--Jennifer
|
|
From: Arlindo da S. <da...@al...> - 2010-07-12 16:19:58
|
On Sun, Jul 11, 2010 at 1:14 PM, Arlindo da Silva <da...@al...>wrote: > All, > > I think I narrowed down the problem to a possible bug in the gribmap > utility in grads 2.0.a8. The LATS extension I mentioned earlier writes out a > .grb and .ctl file, using the "gribmap" utility to create the index file > (thru a system() call). When I manually recreated the gribmap file (.gmp) by > hand using the gribmap fom 2.0.a7 it all worked fine. Therefore I suspect > there may be an issue with the 2.0.a8 gribmap utility on the i686platform, at least with the version that I built. I tried running the i686 > binaries running by COLA but it does not work on my i686 platform: > > gribmap -0 -i junk.ctl > /home/dasilva/gribmap: error while loading shared libraries: requires glibc > 2.5 or later dynamic linker > > > I am running: > > gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11) > Linux voda.gsfc.nasa.gov 2.6.9-89.0.23.ELsmp #1 SMP Fri Mar 5 17:56:21 EST > 2010 i686 i686 i386 GNU/Linux > > > I am attaching the .grb and .ctl files in question. To reproduce the > problem, just run > > % gribmap -0 -i junk.ctl > > and see if you can open the resulting dataset in grads. When using gribmap > in a8 I get all undefs. > > Jennifer, Hoop: > > Can you confirm whether we have an issue with 2.0.a8 gribmap on i686? > As I said earlier, I have no problems on x86_64 and Mac OS X 10.5.8. This > appears to be 32-bit Linux specific. > > Many thanks to Hoop and Jennifer for verifying that their i686 build of *gribmap* worked OK on the sample grib file I originally attached to this message; only my build was broken. I am happy to report that I have now produced a successful build of 2.0.a8.oga.1 on i686. The problem I was experiencing could be traced to the fact that I was building with gcc 3.x and glibc<2.5, a combination that up to now had produced very portable builds. For some reason that I decided not to dig into, the new gribmap appears to require gcc 4.x and glibc>=2.5. I have also made a 64-bit build on Mac OS X 10.6 (Snow Leopard). It passes all basic grads tests, but there seem to be issues with a couple of extensions that I need to look into. I'll see what I can do, but it won't hold up release as the Leopard build works just fine on Snow Leopard. This required HDF-4 to be upgraded to 4.2.5, something that I am yet to check in to the baselibs. After I do this, I'll recheck the build on the other platforms and upload the supplibs to sf.net. I'll then attempt a Windows build. Jennifer, Is the doc/ directory in your 2.0.a8 source tarball up to date? I'd like to update the documentation we ship with the bundle (for off-line use). Cheers! Arlindo -- Arlindo da Silva da...@al... |
|
From: Arlindo da S. <da...@al...> - 2010-07-12 00:54:50
|
On Sun, Jul 11, 2010 at 6:38 PM, Jennifer Adams <jm...@co...> wrote: > Arlindo, > I would like to request that you remove your shapefile support in > opengrads. The shape.c source file was an excellent start, but the interface > that I put into a8 is a lot more complete and also sets the stage for the > creation of shapefiles that is coming in the next release. I think it will > be confusing for the users to try to keep the two interfaces straight. > This a good idea. However, I am afraid I would break people's production scripts without much notice. I am thinking I'll comment out the shp_* entries in the "udxt". This way it would not be available by default and it won't appear when you do a "q udc"; I'll also remove the documentation from our website. However, for those who would need time to revise their production scripts they could re-activate the shape extensions by removing the comments. At least until the next release. Reasonable? Arlindo > --Jennifer > > -- > Jennifer M. Adams > IGES/COLA > 4041 Powder Mill Road, Suite 302 > Calverton, MD 20705 > jm...@co... > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Opengrads-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengrads-devel > > -- Arlindo da Silva da...@al... |
|
From: Jennifer A. <jm...@co...> - 2010-07-11 22:46:37
|
OK. I checked those in. --Jennifer On Jul 10, 2010, at 6:52 PM, Arlindo da Silva wrote: > Jennifer, > > I just redid the opengrads supplibs to get in sync with COLA's; > I'll post specific versions shortly. One of my goals is to have pre- > compiled supplibs that could be used to build both opengrads and the > standard COLA grads distributions. We just need a small patch in > your configure.ac and src/Makefile.am files, see below. The patch in > configure.ac is so that the shapefile includes are found; the patch > in Makefile.am is so that the Athena GUI (gagui) builds. > > Thanks, > > Arlindo > > ----------------------------------------------------------------------------------------------------------- > Index: configure.ac > =================================================================== > RCS file: /cvsroot/opengrads/cola/grads2/configure.ac,v > retrieving revision 1.1.1.6 > diff -r1.1.1.6 configure.ac > 403c403 > < GA_SET_FLAGS([shapelib]) > --- > > GA_SET_FLAGS([shapelib shp]) > 407c407 > < GA_SET_INCLUDE_VAR([shp_inc], [shapelib]) > --- > > GA_SET_INCLUDE_VAR([shp_inc], [shapelib shp]) > Index: src/Makefile.am > =================================================================== > RCS file: /cvsroot/opengrads/cola/grads2/src/Makefile.am,v > retrieving revision 1.1.1.6 > diff -r1.1.1.6 Makefile.am > 33c33 > < INCLUDES = $(readline_inc) $(printim_inc) $(grib2_inc) $(nc_inc) \ > --- > > INCLUDES = $(readline_inc) $(printim_inc) $(grib2_inc) $(gui_inc) > $(nc_inc) \ > > > -- > Arlindo da Silva > da...@al... > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________ > 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... |
|
From: Jennifer A. <jm...@co...> - 2010-07-11 22:46:14
|
On Jul 11, 2010, at 1:14 PM, Arlindo da Silva wrote: > All, > > I think I narrowed down the problem to a possible bug in the > gribmap utility in grads 2.0.a8. The LATS extension I mentioned > earlier writes out a .grb and .ctl file, using the "gribmap" utility > to create the index file (thru a system() call). When I manually > recreated the gribmap file (.gmp) by hand using the gribmap fom > 2.0.a7 it all worked fine. Gribmap and the code in gaddes that reads the index file are substantially different to support large grib files. I wouldn't expect a comparison with 2.0.a7 to be helpful. > Therefore I suspect there may be an issue with the 2.0.a8 gribmap > utility on the i686 platform, at least with the version that I > built. I tried running the i686 binaries running by COLA but it does > not work on my i686 platform: > > gribmap -0 -i junk.ctl > /home/dasilva/gribmap: error while loading shared libraries: > requires glibc 2.5 or later dynamic linker That looks like an error message related to a problem with your local system, not with the source code. > > I am running: > > gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11) > Linux voda.gsfc.nasa.gov 2.6.9-89.0.23.ELsmp #1 SMP Fri Mar 5 > 17:56:21 EST 2010 i686 i686 i386 GNU/Linux That's an old version of gcc. I am using 4.2.1 (for the mac) and 4.1.2 on CentOS. > > I am attaching the .grb and .ctl files in question. To reproduce the > problem, just run > > % gribmap -0 -i junk.ctl > > and see if you can open the resulting dataset in grads. When using > gribmap in a8 I get all undefs. Works perfectly for me. > > Jennifer, Hoop: > > Can you confirm whether we have an issue with 2.0.a8 gribmap on > i686? The a8 builds have been in use since late March with not a single squeak from the users. --Jennifer > As I said earlier, I have no problems on x86_64 and Mac OS X 10.5.8. > This appears to be 32-bit Linux specific. > > Thanks, > > Arlindo > > > On Sun, Jul 11, 2010 at 10:58 AM, Arlindo da Silva <da...@al... > > wrote: > All, > > I'm making progress towards the 2.0.a8 upgrade. > > 1) The supplibs have been upgraded to version 2.2.0. To get the > fresh sources and build, > > % gacvs co -d supplibs-2.2.0 -P supplibs > % cd supplibs-2.2.0/src > % make install > > So far I've tested this on Mac OS X 10.5.8, RHEL 5 (x86_64) and > RHEL4 (i686). > > 2) The Grads codebase has been merged with COLA's. Since COLA now > has a single executable, I've replaced our previous build with > COLA's, making small adjustments for supporting the extensions and > the extra-platforms we support. I am afraid we have lost the > integration with pkg-config, something I could restore later. > However, the close we track COLA's codebase the less the maintenance > costs on our end. To check it out and build, > > % gacvs co -d Grads-2.0.a8 -P Grads > % ln -s /path/to/your/supplibs/arch supplibs > % cd Grads-2.0.a8 > % configure > % make > % make check > > It passes all tests on Mac OS X 10.5.8 (Leo), x86_64 and i686. I'll > try Mac OS X 10.6 (Snow Leo) and Windows once I have robust builds > on these 3 platforms. > > 3) For testing the extensions: > > % make binstall > (put opengrads/Contents in your path) > % cd extensions > % make check > > It passes all 93 tests on Darwin and x86_64. However, it fails a > single test on i686: the creation of grads_grib files with the LATS > extension (all other formats work). I love these tests... > > Mike, > > To reproduce the problem, simply try (using lats4d.sh under > opengrads/Contents): > > % lats4d.sh -i model.nc -o junk -format grads_grib > > This will complete successfully, but when you try to read the > file all variables will be UNDEF. I tried downgrading the LATS > extension to the 2.0.a7.oga.3 version (that is, before your recent > mods) but the problem persisted. The previous 2.0.a7.oga.3 binaries > work with the current LATS extension. So it may be related to some > internal grads changes, probably related to gribmap, but I am not > sure. Could you take a look at it? > > Thanks, > > Arlindo > > > > > > > > > > -- > Arlindo da Silva > da...@al... > > > > -- > Arlindo da Silva > da...@al... > < > junk > .ctl > > > < > junk > .grb > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________ > 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... |
|
From: Jennifer A. <jm...@co...> - 2010-07-11 22:46:13
|
Arlindo, I would like to request that you remove your shapefile support in opengrads. The shape.c source file was an excellent start, but the interface that I put into a8 is a lot more complete and also sets the stage for the creation of shapefiles that is coming in the next release. I think it will be confusing for the users to try to keep the two interfaces straight. --Jennifer -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jm...@co... |
|
From: Arlindo da S. <da...@al...> - 2010-07-11 14:59:31
|
All,
I'm making progress towards the 2.0.a8 upgrade.
1) The supplibs have been upgraded to version 2.2.0. To get the fresh
sources and build,
% gacvs co -d supplibs-2.2.0 -P supplibs
% cd supplibs-2.2.0/src
% make install
So far I've tested this on Mac OS X 10.5.8, RHEL 5 (x86_64) and RHEL4
(i686).
2) The Grads codebase has been merged with COLA's. Since COLA now has a
single executable, I've replaced our previous build with COLA's, making
small adjustments for supporting the extensions and the extra-platforms we
support. I am afraid we have lost the integration with pkg-config, something
I could restore later. However, the close we track COLA's codebase the less
the maintenance costs on our end. To check it out and build,
% gacvs co -d Grads-2.0.a8 -P Grads
% ln -s /path/to/your/supplibs/arch supplibs
% cd Grads-2.0.a8
% configure
% make
% make check
It passes all tests on Mac OS X 10.5.8 (Leo), x86_64 and i686. I'll try Mac
OS X 10.6 (Snow Leo) and Windows once I have robust builds on these 3
platforms.
3) For testing the extensions:
% make binstall
(put opengrads/Contents in your path)
% cd extensions
% make check
It passes all 93 tests on Darwin and x86_64. However, it fails a single test
on i686: the creation of grads_grib files with the LATS extension (all other
formats work). I love these tests...
Mike,
To reproduce the problem, simply try (using lats4d.sh under
opengrads/Contents):
% lats4d.sh -i model.nc -o junk -format grads_grib
This will complete successfully, but when you try to read the file all
variables will be UNDEF. I tried downgrading the LATS extension to the
2.0.a7.oga.3 version (that is, before your recent mods) but the problem
persisted. The previous 2.0.a7.oga.3 binaries work with the current LATS
extension. So it may be related to some internal grads changes, probably
related to gribmap, but I am not sure. Could you take a look at it?
Thanks,
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: Arlindo da S. <da...@al...> - 2010-07-10 22:52:37
|
Jennifer,
I just redid the opengrads supplibs to get in sync with COLA's; I'll post
specific versions shortly. One of my goals is to have pre-compiled supplibs
that could be used to build both opengrads and the standard COLA grads
distributions. We just need a small patch in your configure.ac and
src/Makefile.am files, see below. The patch in configure.ac is so that the
shapefile includes are found; the patch in Makefile.am is so that the Athena
GUI (gagui) builds.
Thanks,
Arlindo
-----------------------------------------------------------------------------------------------------------
Index: configure.ac
===================================================================
RCS file: /cvsroot/opengrads/cola/grads2/configure.ac,v
retrieving revision 1.1.1.6
diff -r1.1.1.6 configure.ac
403c403
< GA_SET_FLAGS([shapelib])
---
> GA_SET_FLAGS([shapelib shp])
407c407
< GA_SET_INCLUDE_VAR([shp_inc], [shapelib])
---
> GA_SET_INCLUDE_VAR([shp_inc], [shapelib shp])
Index: src/Makefile.am
===================================================================
RCS file: /cvsroot/opengrads/cola/grads2/src/Makefile.am,v
retrieving revision 1.1.1.6
diff -r1.1.1.6 Makefile.am
33c33
< INCLUDES = $(readline_inc) $(printim_inc) $(grib2_inc) $(nc_inc) \
---
> INCLUDES = $(readline_inc) $(printim_inc) $(grib2_inc) $(gui_inc)
$(nc_inc) \
--
Arlindo da Silva
da...@al...
|
|
From: Jennifer A. <jm...@co...> - 2010-04-05 13:56:44
|
Hi, Everyone -- I have been using hdf5-1.8.4-patch1 -- sorry for the misinformation at supplibs.html. I updated the version number on that page; the link to the source code points to the right tarball. I originally took ncurses from the opengrads supplibs but Hoop had some trouble building it, so I went to the gnu.org page and got their latest ncurses. I wasn't sure what the version of ncurses was in the opengrads supplibs -- they may be the same. I decided to release a8 without waiting for netcdf-4.1.1, it would probably be fine to use the newer rc3, but I have not tested it. Curl is newer also, this was required for the dap interface in netcdf-4, and so libdap and libgadap had to be rebuilt (but there were no problems). Some of the other supplibs have released newer versions (jasper and therefore g2clib) but I haven't bothered to upgrade those ... I don't think it's necessary at this point. --Jennifer On Apr 3, 2010, at 10:21 AM, Arlindo da Silva wrote: > All, > > Before we merge COLA's newly released 2.0.a8 codebase, I believe > it is time for us synchronize our supplibs with COLA's. We should > be able to do this even for Netcdf, now that COLA has adopted > NetCDF-4/HDF-5 as well. This way our builds will differ from COLA > only by the inclusion of the extensions. Unfortunately, our > config.ac is still different, perhaps we can unify this as well > (with slight patches to handle the extensions.) > > Jennifer: Ed Hartnett just released NetCDF-4.1.1-rc3 while your > recent builds use the rc2. I am leaning towards RC3, what do you > think? BTW, your table under > > http://iges.org/grads/gadoc/supplibs.html > > appears o have a typo: it refers to HDF-5 v 1.8.3, while the untar > instructions refer to 1.8.4-patch1 (the correct version recommended > by Unidata). > Arlindo > > -- > Arlindo da Silva > da...@al... > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > 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... |
|
From: Arlindo da S. <da...@al...> - 2010-04-03 14:21:52
|
All,
Before we merge COLA's newly released 2.0.a8 codebase, I believe it is
time for us synchronize our supplibs with COLA's. We should be able to do
this even for Netcdf, now that COLA has adopted NetCDF-4/HDF-5 as well. This
way our builds will differ from COLA only by the inclusion of the
extensions. Unfortunately, our config.ac is still different, perhaps we can
unify this as well (with slight patches to handle the extensions.)
Jennifer: Ed Hartnett just released NetCDF-4.1.1-rc3 while your recent
builds use the rc2. I am leaning towards RC3, what do you think? BTW, your
table under
http://iges.org/grads/gadoc/supplibs.html
appears o have a typo: it refers to HDF-5 v 1.8.3, while the untar
instructions refer to 1.8.4-patch1 (the correct version recommended by
Unidata).
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: Arlindo da S. <da...@al...> - 2009-11-16 16:07:45
|
On Mon, Nov 16, 2009 at 3:54 AM, pedro tsai <ped...@ya...> wrote: > hi Arlindo, > > FYI, I remember you mention about running GradVM on mobile device. Anyway, > I was working on Google android (for my company project). It turns out > Android is, well, it is really Linux with some Google modification to > kernel. The applications running on Android are Java applications, but > instead of Java bytecode running on JVM, the java applications are compiled > to Dalvik bytecode and running on DVM. You can do a search on 'Dalvik' on > Google, and there should a lots of information on this. > > So I think if GradVM is fully functional, it might be relatively easy to > get it running on Google android. As you mention, it might be very useful > to be able to do this. > > Yes, I am very interested in this, specially now that Verizon has a droid phone (I am still with Verizon.) It would be very cool. NestedVM goes from C to mips assembly and from there to java bytecode. We will need to figure out how to get Dalvik bytecode instead, or else let the GVMserver run remotely, and only have the client running on droid. Now, for the iPhone it may be better to build everything with Objective C. Apparently Sun has a Java implementation for the iPhone but Apple's licensing terms prevent them from releasing it. There is another Java implementation for the iPhone but it requires jailbreaking and it is probably not legal. So, it may make more sense to start with Android. Arlindo -- Arlindo da Silva da...@al... |
|
From: Arlindo da S. <da...@al...> - 2009-11-16 15:53:59
|
On Mon, Nov 16, 2009 at 3:39 AM, pedro tsai <ped...@ya...> wrote: > hi Arlindo, > > It is good hear from you. It is no problem, I really want to get this > thing running properly and get some feedbacks. > > (a). Yes, we can add the '-l' option. > > (b). Ideally, we want output of server command that is relevant to the > user to go back to the client window, and we also need to print out any > error message on the server console side for debugging purpose. I think > hijack gaprnt() will provide finer control on what information to send to > client and what to print out to terminal on the server side. Where as > re-direct stdout would lacks this finer control. I don't know which way is > easier, but I think gaprnt() solution might be more viable in the long run. > > I'll add the hooks for gaprnt(). The "C code" will call a gaprnt() function on the java side; I'll let you handle the message passing from that point on. OK? > (c) I need to investigate the Java client side capture of graphics display > to see how it is done. But we can also send printim output file to the > client via socket connection (this is not hard to do), and then user can use > what ever mechanism available on the device to print the image file. For > now, perhaps it is easier to send the printim file to client, and later we > can consider client side graphics capture. > > Sending the file to client is more than adequate. > (d) If client is running inside a browser, then we do need some kind of > Console class > that can embedded inside a browser. I think this would be a nice > feature. Would like to do some search on google to see if may be some one > has already implement such class with Jline support (or other similar > command completion). > > I will update with your modification, and we go from there. > > Thank you for the quick response. Arlindo talk to you later, > > Pedro > > --- On *Sun, 11/15/09, Arlindo da Silva <da...@al...>* wrote: > > > From: Arlindo da Silva <da...@al...> > Subject: Re: code for GradsVM > To: "pedro tsai" <ped...@ya...> > Cc: ope...@li... > Date: Sunday, November 15, 2009, 4:49 PM > > > Hi Pedro, > > Sorry for the very long time, but I finally am able to get back to > GrADSVM. I have now integrated the java code under the opengrads codebase, > and updated the grads.class (built through nestedvm) to the latest grads > 2.0.a7. > > I tried your your client/server code and it works as advertised. Very nice > work, indeed. I have made some small alterations: > > 1) I preserved the previous monolithic JGrads.class. Therefore, I renamed > the client class GVMclient. > > 2) I fixed a small bug in gxJ.java related to color definition. > > 3) I moved all non-nestedvm code to a separate Java/ directory. > > 4) Added targets to the Makefile to create grads.jar; renamed Makefile -> > GNUmakefile to make it clear that GNU make is required. > > Here are the remaining issues: > > a) Would it be possible to add an option to "conn" to pass to the server, > e.g., > > ga-> conn -l > > If omitted, the client could ask the user if portrait is desired. > > b) We need to capture the server's stdout and ship it back to the client. > As we talked before, we could hijack gaprnt() and buffer the output on the > java side and ship it back to the client upon finishing a command. Or else, > one might be able to intercept stdout. Which one do you think is easier to > do. (I can have gaprnt() calling a java function much like the gxJ > functions.) > > c) The command printim now creates an image file on the server side. We > need to find a way to ship this file back to the client. Can this be done > byte-by-byte through the sockets? Another possibility would be to implement > printim entirely in java as a screendump of the graphical canvas. (Are there > built in methods for this?) > > d) Right now GrADSVM is a console application. Last year I was > experimenting with a Console class, but it lacked jline support. Having a > built in console one might be able to deploy the client through WebStart. Do > you agree? > > BTW, you can find the revised jar (including sources) here: > > http://opengrads.org/devel/java/ > > or you can get the full sources from cvs: > > % gacvs co -P grads > > See the Java/ directory. To build the nestedvm code you need a Mac, or else > you need to build the nestedvm toolchain yourself for other platorms. The > nestedvm compiled supplibs should be portable. > > GVMclient/server can be run from the jar, e.g., > > % java -cp ./grads.jar GVMserver > % java -cp ./grads.jar GVMclient > > I think we are very close to have something for an early release to the > community. What do you think? > > Cheers! > > Arlindo > > > On Mon, Mar 2, 2009 at 2:47 AM, pedro tsai <ped...@ya...<http://mc/compose?to=ped...@ya...> > > wrote: > >> hi Arlindo, >> >> Attached is GradsVM client/server code. Un-tar the files into your >> working >> directory where the other NestVM generated code/data are located. So far, >> >> I have not yet touch NestVM generated files, I just add new code in the >> same top-level directory where original NestVM files are. >> >> 1. To compile the code, type 'make'. To list all the new files, type >> 'make info'. >> >> 2. To run, you need 2 windows (one for client process, one for >> GradsVM process) >> >> on the client window, type 'make run' >> >> on the server window, type 'make svc' >> >> once the system running, the first command to type on client's side >> readline input is >> >> 'conn' /* by default, it will use IP 127.0.0.1, and port 6789 >> and 6790. If these ports are used on your system, you can change >> them (in SockIPC.java) and then re-compile. I use 2 ports, one >> for >> 'gacmd' communication and one for 'graphics primitives' >> communication. >> >> If you want to run GradsVM on remote host, type >> >> 'conn ip-addr' >> >> Once the connection is establish, you should see output on the >> 'server side' window. You need to hit a 'Return' on the server >> side window, otherwish the gradsVM thread is blocking after the >> initial Grads information display ('Landscape mode ('n' ...) >> >> Now you can enter 'grads' command, then they should be executed >> by GradsVM. >> >> To exit the client, type 'quit', this will disconnect and kill >> the client process. You can start a new client process again >> to connect to GradVM server. I did not have 'disconnect' command >> implement, but it is not hard to do. >> >> 3. The naming convention for the files is: the server side code starts >> with >> 'GVM...'. The client side code starts with 'JG...'. Files that do not >> have either prefixs are utility code or are used by both (like >> SockIPC.java) >> >> 4. You can have more than 1 client connect to the server, each client >> will get its own GradsVM, but right now there is bug, so I think it will >> dead-lock the gradsVM. >> >> 5. There are other issues, for example, the command line argument on >> the client side is not pass to the GradsVM, this is easy to fix. And >> also, >> the information test from GradsVM is not sent back to client. (e.g, q >> file, q dim....). >> >> If you can not run the prototype, let me know. >> I think there is still a lots of work to refine this...... >> >> Pedro >> >> >> > > > > -- > Arlindo da Silva > da...@al... <http://mc/compose?to=da...@al...> > > > -- Arlindo da Silva da...@al... |
|
From: Arlindo da S. <da...@al...> - 2009-11-16 02:27:41
|
All, I have added some building instructions on the wiki: http://opengrads.org/wiki/index.php?title=Building_GrADS_under_NestedVM_from_Sources Arlindo -- Arlindo da Silva da...@al... |
|
From: Arlindo da S. <da...@al...> - 2009-11-16 00:49:43
|
Hi Pedro,
Sorry for the very long time, but I finally am able to get back to
GrADSVM. I have now integrated the java code under the opengrads codebase,
and updated the grads.class (built through nestedvm) to the latest grads
2.0.a7.
I tried your your client/server code and it works as advertised. Very nice
work, indeed. I have made some small alterations:
1) I preserved the previous monolithic JGrads.class. Therefore, I renamed
the client class GVMclient.
2) I fixed a small bug in gxJ.java related to color definition.
3) I moved all non-nestedvm code to a separate Java/ directory.
4) Added targets to the Makefile to create grads.jar; renamed Makefile ->
GNUmakefile to make it clear that GNU make is required.
Here are the remaining issues:
a) Would it be possible to add an option to "conn" to pass to the server,
e.g.,
ga-> conn -l
If omitted, the client could ask the user if portrait is desired.
b) We need to capture the server's stdout and ship it back to the client. As
we talked before, we could hijack gaprnt() and buffer the output on the java
side and ship it back to the client upon finishing a command. Or else, one
might be able to intercept stdout. Which one do you think is easier to do.
(I can have gaprnt() calling a java function much like the gxJ functions.)
c) The command printim now creates an image file on the server side. We need
to find a way to ship this file back to the client. Can this be done
byte-by-byte through the sockets? Another possibility would be to implement
printim entirely in java as a screendump of the graphical canvas. (Are there
built in methods for this?)
d) Right now GrADSVM is a console application. Last year I was experimenting
with a Console class, but it lacked jline support. Having a built in console
one might be able to deploy the client through WebStart. Do you agree?
BTW, you can find the revised jar (including sources) here:
http://opengrads.org/devel/java/
or you can get the full sources from cvs:
% gacvs co -P grads
See the Java/ directory. To build the nestedvm code you need a Mac, or else
you need to build the nestedvm toolchain yourself for other platorms. The
nestedvm compiled supplibs should be portable.
GVMclient/server can be run from the jar, e.g.,
% java -cp ./grads.jar GVMserver
% java -cp ./grads.jar GVMclient
I think we are very close to have something for an early release to the
community. What do you think?
Cheers!
Arlindo
On Mon, Mar 2, 2009 at 2:47 AM, pedro tsai <ped...@ya...> wrote:
> hi Arlindo,
>
> Attached is GradsVM client/server code. Un-tar the files into your working
> directory where the other NestVM generated code/data are located. So far,
> I have not yet touch NestVM generated files, I just add new code in the
> same top-level directory where original NestVM files are.
>
> 1. To compile the code, type 'make'. To list all the new files, type
> 'make info'.
>
> 2. To run, you need 2 windows (one for client process, one for
> GradsVM process)
>
> on the client window, type 'make run'
>
> on the server window, type 'make svc'
>
> once the system running, the first command to type on client's side
> readline input is
>
> 'conn' /* by default, it will use IP 127.0.0.1, and port 6789
> and 6790. If these ports are used on your system, you can change
> them (in SockIPC.java) and then re-compile. I use 2 ports, one for
>
> 'gacmd' communication and one for 'graphics primitives'
> communication.
>
> If you want to run GradsVM on remote host, type
>
> 'conn ip-addr'
>
> Once the connection is establish, you should see output on the
> 'server side' window. You need to hit a 'Return' on the server
> side window, otherwish the gradsVM thread is blocking after the
> initial Grads information display ('Landscape mode ('n' ...)
>
> Now you can enter 'grads' command, then they should be executed
> by GradsVM.
>
> To exit the client, type 'quit', this will disconnect and kill
> the client process. You can start a new client process again
> to connect to GradVM server. I did not have 'disconnect' command
> implement, but it is not hard to do.
>
> 3. The naming convention for the files is: the server side code starts
> with
> 'GVM...'. The client side code starts with 'JG...'. Files that do not
> have either prefixs are utility code or are used by both (like
> SockIPC.java)
>
> 4. You can have more than 1 client connect to the server, each client
> will get its own GradsVM, but right now there is bug, so I think it will
> dead-lock the gradsVM.
>
> 5. There are other issues, for example, the command line argument on
> the client side is not pass to the GradsVM, this is easy to fix. And
> also,
> the information test from GradsVM is not sent back to client. (e.g, q file,
> q dim....).
>
> If you can not run the prototype, let me know.
> I think there is still a lots of work to refine this......
>
> Pedro
>
>
>
--
Arlindo da Silva
da...@al...
|
|
From: Arlindo da S. <da...@al...> - 2009-11-15 22:30:33
|
All,
I just updated the Java version of GrADS to the latest v2.0.a7. You can
get the jar here:
http://opengrads.org/devel/java/grads-2.0.a7.oga.3.1.jar
and to run it:
java -jar grads-2.0.a7.oga.3.1.jar
I have included support for geotiff and kml. However, it still lacks:
* NetCDF-4
* OPeNDAP
* Athena Widgets
* X11 widgets
* Extensions
Both NetCDF-4 and OPeNDAP are supplib issues that I may be able to sort out,
we will see. The gagui stuff is better off re-implemented in native Java.
The extensions may need to be linked in; fortran 90 extensions will be
tough.
Brian: In the gxJava.c (replacement for gxX.c) I have only code for the
basic graphics; the X11 widget portion is stubbed out for now. I'd need your
help figuring this out. A good reason reason for having the X11 Widgets
working is that one could include grads.jar in data DVDs such as those put
out by NCEP.
The jar also includes a GVMclient/GVMserver that Pedro contributed, but we
are still polishing the final details on these. This allows you to run the
server on one machine and the client in another. The client/server split is
different from the old grads client/server the Pedro contributed years back.
The client is now very thin, with all the shading/contouring being done at
the backend, only the painting of the screen happens client-side.
Right now I only have a NestedVM tool chain for Mac OS X. I'll be writing a
wiki page documenting the build details.
Brian/Jennifer: all the java code is in a separate Java/ directory; only
gxJava.c resides under src/. If you are interested I can develop a patch for
your configure.ac/Makefile.am that would allow you to build grads.jar
automatically. Since you work on Macs, you should be able to use my nestedvm
toolchain. But once you are setup is just a matter of entering
% source /usr/local/NestedVM/env.sh
% ./configure --host mips
% make java-dist
and grads.jar is created.
Cheers!
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: Arlindo da S. <da...@al...> - 2009-11-13 14:16:11
|
96 responses Summary See complete responses Which versions of GrADS do you regularly use? GrADS v1.700%GrADS v1.82021%GrADS v1.93536%GrADS v1.1011%GrADS v2.07780%Don't know.22% People may select more than one checkbox, so percentages may add up to more than 100%. Do you build your own version of GrADS or download pre-compiled binaries? I build my own GrADS (using pre-compiled supplibs)1010%I build my own GrADS from scratch1213%I download pre-compiled binaries7477%None of the above, someone else installed it for me77% People may select more than one checkbox, so percentages may add up to more than 100%. Where do you download GrADS from? COLA website5257%Sourceforge (OpenGrADS)4752%From my OS distribution22%Other 33%I don't know, someone else installed it for me78% People may select more than one checkbox, so percentages may add up to more than 100%. If using the OpenGrADS builds, which of the following do you regularly use? Extensions (re, fish, gxyat, shape, etc)3186%Python Interface (PyGrADS)1028%Perl Interface (Gerl)26%PHP Interface38%TCL Interface13% People may select more than one checkbox, so percentages may add up to more than 100%. Which kind of device do you run GrADS on? Desktop7679%Server1920%Notebook (screen larger than 10")3941%Netbook (10" screen or smaller )44%iPhone/iPOD touch00%Pocket PC22%Other1111% People may select more than one checkbox, so percentages may add up to more than 100%. Which operating system do you run GrADS on? Microsoft Windows3638%Mac OS X2021%Linux i686 (32 bits)4850%Linux x86_64 (64 bits)4648%FreeBSD i686 (32 bits)11%FreeBSD amd (64 bits)11%Solaris22%SGI IRIX11%IBM AIX33%Other88% People may select more than one checkbox, so percentages may add up to more than 100%. If running GrADS on Microsoft Windows, which version? Windows 95, 98, ME38%Windows NT00%Windows 200000%Windows XP2976%WIndows Vista1129%Windows 7513%MS-DOS13%Other13% People may select more than one checkbox, so percentages may add up to more than 100%. If running GrADS on Mac OS X, which version? Tiger (10.4) PowerPC15%Tiger (10.4) Intel15%Leopard (10.5) PowerPC419%Leopard (10.5) Intel1781%Snow Leopard (10.6)629%Other00% People may select more than one checkbox, so percentages may add up to more than 100%. If running GrADS on Linux, which distribution? Debian710%Ubuntu2231%Fedora2028%RedHat Enterprise2231%CentOS1419%Mandriva23% Suse2231%Gentoo23%Slackware11%Arch Linux11%Xandros00%Other46% People may select more than one checkbox, so percentages may add up to more than 100%. Which new platform would you like to see GrADS running on? Extraordinary Software.Personaly I don't need any new platforms to be supported by (Open)GrADS. Only ones I need to be supported for now are 32bit and 64bit Linuxes. That because I'm currently using OpenGrads only for batch prosessing of GFS-model outputs to custom forecast maps ( http://www.flcenter.net/gfs_ennusteet.html) and thats why I don't need any mobile or desktop support. Those maps are done with huge custom PHP -script which "extends" my variant of OG's PHP interface to create extremely huge GrADS-script which finally makes those maps... Servers are 64bit Debians and current dev-des... Number of daily responses -- Arlindo da Silva da...@al... |
|
From: Arlindo da S. <da...@al...> - 2009-11-12 15:29:48
|
On Thu, Nov 12, 2009 at 10:09 AM, <ale...@cm...> wrote: > Dear Arlindo, > > I have compiled your GrADS Platform Survey, I hope this is useful for all > GrADS community! ;-) > > Thank you! > P.S.: to use McGraG with different platform (windows, linux), do you think > it's possible (and easy to use) to run them simply using a virtual machine > with Mac OSx? The problem there is legal; Apple does not endorse the OSx86 effort, although for the most part it has been looking the other way. For example, no one working for the U.S. government (like myself) would be able to use it. Porting McGraG under Windows and Linux it's a prohibitive > effort I haven't looked into your implementation, but the idea would be to abstract out the graphical/windowing system aspects. This was my initial attempt with gagui, but so far only a version based on the now dated Athena widgets is available: I still use it, but I feel like I am driving a Ford Model T :-). I see McGraG as an implementation of a GrADS IDE (integrated development environment). How much of the functionality (not implementation) is Aqua specific? How much could be implemented as an Eclipse plugin? The advantage of an eclipse plugin is that it would run everywhere. Arlindo -- Arlindo da Silva da...@al... |
15 messages has been excluded from this view by a project administrator.
