Re: Bug#753620: wishlist: idl/gdl-written software
Hi All,
Thanks for all the comments!
On 04/07/14 14:45, Оlе Ѕtrеісhеr wrote:
- where to place the IDL/GDL-written software in the system
Since they are not machine specific, maybe a good place would be
/usr/share/gdl-packages/ ?
For the record, we have already /usr/share/gnudatalanguage/
There, under a "lib" subdirectory, reside the GDL-written .pro files
that constitute part of the GDL routine library.
We could then place other stuff in:
/usr/share/gnudatalanguage/idlastro
/usr/share/gnudatalanguage/cmsvlib
/usr/share/gnudatalanguage/tex2idl
/usr/share/gnudatalanguage/mpfit
/usr/share/gnudatalanguage/coyote
...
But on the other hand, these packages are in fact not related with GDL.
Yet, doing it this way would make it easy to expose everything to GDL in
one recursive path specification.
- how to name these packages?
use gdl- as prefix? However, this sounds ugly for the whole package:
gdl-idlastro.
There is one "historic" identifier as a candidate for prefix, i.e.
idl-pvwave that is part of the comp.lang.idl-pvwave newsgroup name that
dates back to 1995.
- should idlastro be splitted into multiple subpackages?
I would split it, if the different parts are somehow usable
independently. Also, not all packages may be usable under GDL (yet), right?
I doubt anyone knows a comprehensive answer to this question (but I'm
not an astronomer, and I have never used idlastro/astronlib/astron/...).
Can you give an overview what of idlastro works with GDL and what not?
How complete is GDL compared to IDL?
ditto. That really depends on what you use in IDL.
For some people GDL has more features than IDL (let's say they only do
file-format conversion with GDL, and they get a bonus with gettext path
completion at the GDL prompt);
for others GDL lacks some functionality but is the only viable option
e.g. if they need 1000 instances of IDL-code running at the same time,
what is simply out-of-question with IDL per-process licensing fees.
for others it is simply fairly functional;
for others it is still basically useless (e.g. if they only use IDL for
widget-based map plotting);
for others it will never be of any use (e.g. if they rely on .sav-format
binaries with pre-compiled IDL code).
I know of real-world examples for all of the cases listed above.
- what other IDL/GDL-written software is of interest?
Let me answer myself: CMSVLIB
(http://www.physics.wisc.edu/~craigm/idl/cmsave.html)
This one enables GDL to read IDL's .sav files (only data, not program code).
On 04/07/14 16:57, Gilles DUVERT wrote:
>>> - how to make these packages usable for IDL / PV-WAVE users?
>> Since IDL is non-free, I would consider this not as a primary goal. I
>> would concentrate on GDL.
> I wonder what Sywester means by "making useable"...
I posed this question quite abstractly, but in fact I don't have a very
good example. Some thoughts: not mixing the library files with GDL .pro
files, keeping any workarounds separately... - nothing really specific.
> My suggestion: we make a small installer-like script that will start
> at the first use of GDL, that ask for downloading
> idlastro+coyotelib+mpfit directly from their respective sites (see
> http://idlastro.gsfc.nasa.gov/). May be do the same for gsshsg data,
> as well. No need of handling that at debian level.
What about updates? Why not to benefit from the packaging-system
dependency database? Mirrors, package reviews, bug trackers - it all
works and was designed right for this purpose.
You mentioned gshhs - apparently, just yesterday, their FTP directory
structure has changed. This would make such script not functional. There
would be no automated mechanism to inform us that such thing does not
work. A gshhs package would not be affected.
Again, thanks for all the comments.
Best,
Sylwester
--
http://www.igf.fuw.edu.pl/~slayoo/
Reply to: