| GDL 0.8.9 released [message #43565] |
Fri, 22 April 2005 03:45  |
![marc schellens[1] is currently offline](theme/default/images/xoffline.png.pagespeed.ic.XRkd1fkXye.png "marc schellens[1] is currently offline")
marc schellens[1]
Messages: 183
Registered: January 2000
|
Senior Member |
|
|
GDL - GNU Data Language, the free IDL clone
Now with z-buffer device, new subroutines, many improvements,
important bug fixes...
GDL now understands main programs and the .RUN command :-)
New routines (overall more than 250 subroutines implemented):
SPAWN, WAIT, FINITE, ROUTINE_INFO, TEMPORARY, DIST, TVSCL
For a sorted list of all implemented subroutines enter HELP,/LIB at
the command prompt.
FEATURES:
*FULL* syntax compatibility with IDL 6.0
*ALL* IDL language elements are supported, including:
_EXRA, _REF_EXTRA and _STRICT_EXTRA keywords,
Objects, Pointers, Structs,
Common blocks, Assoc variables,
Arrays, System variables,
All operators, All data types...
Compiles on Linux and Mac OS X (10.2, 10.3, with g++ 3.3)
GDL is part of the Fink project (http://fink.sourceforge.net)
The file input output system is fully implemented
(Exception: For formatted I/O the C() sub-codes are not supported yet)
Most image file formats (jpeg, tiff, ...) are supported.
netCDF files are fully supported.
HDF file support.
Basic HDF5 file support.
READFITS and WRITEFITS from the IDL-Astrolib are working.
Graphical output is partially implemented. The PLOT, OPLOT, PLOTS,
XYOUTS, SURFACE and TV commands (along with WINDOW, WDELETE, SET_PLOT,
WSET, TVLCT) work (important keywords, some !P system variable tags and
multi-plots are supported) for X windows, z-buffer and postscript
output.
A GUI (widgets) is not implemeted yet.
HOMEPAGE:
http://gnudatalanguage.sourceforge.net
DOWNLOAD:
http://sourceforge.net/projects/gnudatalanguage/
Gaurav Khanna provides binaries for Mac OS X on his HPC page:
http://hpc.sourceforge.net
Check it out!
marc
|
|
|
|
|
|
| GDL - a little uppdate... [message #43729 is a reply to message #43565] |
Fri, 22 April 2005 18:55  |
Y.T.
Messages: 25
Registered: December 2004
|
Junior Member |
|
|
m_schellens@hotmail.com wrote:
> GDL - GNU Data Language, the free IDL clone
>
>
> Now with z-buffer device, new subroutines, many improvements,
> important bug fixes...
>
> GDL now understands main programs and the .RUN command :-)
>
[ etc etc ]
So I had a look at that, and I am a lot less impressed than I was when
I first heard that there is such a thing as a free IDL clone.
As far as I can figure out, GDL uses the 'readline' library to receive
input from the user, the 'gsl' library to perform the math and 'plplot'
to output the result -- in other words, it is really just a parser that
connects some other pieces.
Now by itself that isn't a problem, but I do have to wonder about the
choice -- why gsl? why plplot?
Isn't gnuplot much, much, much more popular? I'm not aware of any
current linux distro that doesn't have it -- while the latest plplot
rpm for redhat that I can find is for 7.3, and there don't seem to be
any newer .debs or slack-tgzs either.
And why gsl? That ain't exactly mainstream either (better than plplot,
though).
The more I think about it, the more obvious it appears to me to write
an IDL clone in python, which is popular and widespread, has it's own
array-math routines (which compete with IDL's in speed and versatility)
and through things like python/Tk or python/gtk even has a native link
into the OSes windowing environment.
Maybe I'm naive about something here. Maybe I'm missing something.
But after three days of failed attempts to get GSL and plplot to
compile properly ("[error 1]", why thank you for that valuable
information) on two otherwise perfectly vanilla machines (one RH9 and
one Slack10) I'm just a little puzzled and maybe just a tad frustrated.
Well, OK, maybe quite a bit frustrated. ;)
Why would someone make a current, live, under-development-right-now
project dependent on things that haven't been included in a distro in
three years? That require five year old software tools to be built?
Well, I haven't given up yet and I'm still trying -- but this obviously
requires a pretty hefty pot of coffee before it'll run anywhere...
I'll let y'all know if/when I ever manage to get this working.
cordially
Y.T.
--
Remove YourClothes before you email me.
|
|
|
|
| Re: GDL - a little uppdate... [message #43768 is a reply to message #43729] |
Tue, 26 April 2005 10:04 |
George White
Messages: 10
Registered: November 1998
|
Junior Member |
|
|
On 22 Apr 2005, Y.T. wrote:
>
> m_schellens@hotmail.com wrote:
>> GDL - GNU Data Language, the free IDL clone
>>
>>
>> Now with z-buffer device, new subroutines, many improvements,
>> important bug fixes...
>>
>> GDL now understands main programs and the .RUN command :-)
>>
> [ etc etc ]
>
>
> So I had a look at that, and I am a lot less impressed than I was when
> I first heard that there is such a thing as a free IDL clone.
>
> As far as I can figure out, GDL uses the 'readline' library to receive
> input from the user, the 'gsl' library to perform the math and 'plplot'
> to output the result -- in other words, it is really just a parser that
> connects some other pieces.
>
> Now by itself that isn't a problem, but I do have to wonder about the
> choice -- why gsl? why plplot?
It is a problem if GDL can't readily substitute other libraries. Plotting
is a tricky area, but certainly for the numerical codes there are often
newer libraries that are significantly better for certain problems than
the "state of the art" a few years ago..
IDL uses Numerical Recipes, which tends to err on the side of simplicity
while GSL aims to stay closer to the "state of the art", but that doesn't
say you won't run into limitations on a particular problem.
> Isn't gnuplot much, much, much more popular? I'm not aware of any
> current linux distro that doesn't have it -- while the latest plplot
> rpm for redhat that I can find is for 7.3, and there don't seem to be
> any newer .debs or slack-tgzs either.
Popularity is the last metric an IDL fan should be using -- if you want
popular you'll have to stick with Excel. Gnuplot's underlying graphics
model is very limited. It does have its own language, but that is wasted
if you are writing your own interpreter. Based on my own experience,
plplot would have been high on the list of candidates for a reliable
plotting library with capabilities well matched to IDL's own plotting.
> And why gsl? That ain't exactly mainstream either (better than plplot,
> though).
>
> The more I think about it, the more obvious it appears to me to write
> an IDL clone in python, which is popular and widespread, has it's own
> array-math routines (which compete with IDL's in speed and versatility)
> and through things like python/Tk or python/gtk even has a native link
> into the OSes windowing environment.
>
> Maybe I'm naive about something here. Maybe I'm missing something.
>
> But after three days of failed attempts to get GSL and plplot to
> compile properly ("[error 1]", why thank you for that valuable
> information) on two otherwise perfectly vanilla machines (one RH9 and
> one Slack10) I'm just a little puzzled and maybe just a tad frustrated.
I've bult GDL on Irix 6.5, RH Fedora 2&3, and Mandrake 9&10. Irix was a
bit of a struggle, but the others either have RPMS or the libraries build
and install from sources without much trouble.
> Well, OK, maybe quite a bit frustrated. ;)
>
> Why would someone make a current, live, under-development-right-now
> project dependent on things that haven't been included in a distro in
> three years? That require five year old software tools to be built?
If you get things right the first time, you don't have to keep changing
them. I pretty sure it will be easier for you to get plplot and gsl
working than to rewrite GDL to use some other library, but if you prefer
the latter approach nobody will stop you, and if you end up with something
better, you might even become a hero.
If you need netcdf and the hdf's your troubles are just beginning -- I
found fedora src RPM's which I used to make and install the libraries.
GDL linked fine, but my last attempt to use them on Fedora core 3 resulted
in a fragile GDL. That may have been due to trying to run an XFS
filesystem on the vanilla Fedora kernel (4k stack), but when I try the
lastest hdf libraries GDL won't compile (it appears that some names have
been changed).
> Well, I haven't given up yet and I'm still trying -- but this obviously
> requires a pretty hefty pot of coffee before it'll run anywhere...
And a pretty hefty linux machine. I'm used to an SGI Octane with 512k
RAM. Linux seems to need 1G RAM perform reliably on the same size data
sets that worked with 512k on Irix.
> I'll let y'all know if/when I ever manage to get this working.
I find GDL very useful for simple tasks when real IDL tells me there
aren't any licenses available and on machines where we haven't installed
IDL.
There are also big advantages to having source -- some of our
IDL jobs have recently started giving errors writing large HDF files
and I would like to see if using O_SYNC with open() helps.
--
George White <aa056@chebucto.ns.ca> <gnw3@acm.org>
189 Parklea Dr., Head of St. Margarets Bay, Nova Scotia B3Z 2G6
|
|
|
|
| Re: GDL - a little uppdate... [message #43785 is a reply to message #43729] |
Mon, 25 April 2005 08:05 |
Brian Gough
Messages: 1
Registered: April 2005
|
Junior Member |
|
|
"Y.T." <ytyourclothes@p.zapto.org> writes:
> But after three days of failed attempts to get GSL and plplot to
> compile properly ("[error 1]", why thank you for that valuable
> information) on two otherwise perfectly vanilla machines (one RH9 and
> one Slack10) I'm just a little puzzled and maybe just a tad frustrated.
Please could you report any compilation problems to bug-gsl@gnu.org if
they are not covered in the README/INSTALL file. Thanks.
--
Brian Gough
(GSL Maintainer)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
