I'd like to note that there is a massive need for documentation here. Maybe something like a "GDL documentation project" or some such? A wiki-based(?) way for folks to note what works and how.
help,/lib is woefully inadequate.
It doesn't help to see something like
DEVICE,CLOSE_FILE,FILENAME,LANDSCAPE,PORTRAIT,DECOMPOSED,GET_DECOMPOSED,Z_BUFFERING,SET_RESOLUTION
when there's no documentation which devices will actually accept which of the keywords. 'oh, look, I can do device,/portrait to get idl-like plots' -- except that I can't. Hum.
This would also be an important place to note things that work, but different from the way things work in IDL. For example in IDL close,/all will not only close all open LUNs, but also free them. While in GDL one still has to issue a free_lun.
And a long-time IDL user like myself has no chance of figuring out what this is supposed to be:
MAGICK_WRITEINDEXES,[2 Args]
I can't even figure out what this might be, much less what arguments it might take.
Or what on earth is this:
LINKIMAGE,[4 Args]
Is this information actually useful to anybody? I mean anybody who does NOT already know what this is supposed to be?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GDL should always behave like IDL.
So CLOSE,/ALL should be changed in GDL
I will do this as soon as I have access to my development computer.
Note that incompatibilities should be posted
in the "bugs" tracker (not missing functions/features, they should go into the "feature request" tracker)
HELP,/LIB gives a list of all internal subroutines GDL knows.
As some stuff is implemented a bit differently (using ImageMagick for the IO of images for example) some routines show up, which are not in IDL and in GDL are only used for some external functions, not supposed to be used directly.
I have to think about if hide or mark such functions is a good idea.
LINKIMAGE is documented in HACKING. There is an example in src/dll as well.
Nevertheless documentation is needed indeed.
Marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe that's a stupid question, but when you say "incompatibilities should be posted in the "bugs" tracker (not missing functions/features, they should go into the "feature request" tracker)" then it isn't clear to me where the line between the two really is.
Example:
f = findgen(200,200)
tvscl,f,channel=1
tvscl,transpose(f),channel=2
this should give me a nice and colorful result. But apparently the "channel" keyword to the "tvscl" function doesn't work. Is that a bug? It doesn't throw an error, so it's a bug, no?
If I do this:
f = f/max(f)*255
tv,f,channel=1
then I get an actual error message ("% Keyword parameter CHANNEL not allowed in call to: TV")
so in this case it's a feature request? But surely the tvscl routine is simply a "bytscl" followed by a "tv"? Or am I misunderstanding something entirely? So the line between bug and missing feature seems blurry...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) It is insanely cool that I can mention some missing functionality and next it pops up in the CVS. You folks rock!
2) This doesn't really answer the question, though: when there is a non-functioning keyword in an otherwise functioning routine - is that a bug or a feature request?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just a question, but is there any documentation for GDL or perhaps a list of all the IDL functions that have been implemented and those that haven't.
James Johnson
James,
Probably the easiest way to get a list of implemented functions in GDL is to type:
help,/lib
at the GDL prompt.
Joel
Is there a way to list the output on a page to page basis?
I have put here such a list
http://aramis.obspm.fr/~coulais/IDL/list_GDL_0.8.11.txt
I'd like to note that there is a massive need for documentation here. Maybe something like a "GDL documentation project" or some such? A wiki-based(?) way for folks to note what works and how.
help,/lib is woefully inadequate.
It doesn't help to see something like
DEVICE,CLOSE_FILE,FILENAME,LANDSCAPE,PORTRAIT,DECOMPOSED,GET_DECOMPOSED,Z_BUFFERING,SET_RESOLUTION
when there's no documentation which devices will actually accept which of the keywords. 'oh, look, I can do device,/portrait to get idl-like plots' -- except that I can't. Hum.
This would also be an important place to note things that work, but different from the way things work in IDL. For example in IDL close,/all will not only close all open LUNs, but also free them. While in GDL one still has to issue a free_lun.
And a long-time IDL user like myself has no chance of figuring out what this is supposed to be:
MAGICK_WRITEINDEXES,[2 Args]
I can't even figure out what this might be, much less what arguments it might take.
Or what on earth is this:
LINKIMAGE,[4 Args]
Is this information actually useful to anybody? I mean anybody who does NOT already know what this is supposed to be?
GDL should always behave like IDL.
So CLOSE,/ALL should be changed in GDL
I will do this as soon as I have access to my development computer.
Note that incompatibilities should be posted
in the "bugs" tracker (not missing functions/features, they should go into the "feature request" tracker)
HELP,/LIB gives a list of all internal subroutines GDL knows.
As some stuff is implemented a bit differently (using ImageMagick for the IO of images for example) some routines show up, which are not in IDL and in GDL are only used for some external functions, not supposed to be used directly.
I have to think about if hide or mark such functions is a good idea.
LINKIMAGE is documented in HACKING. There is an example in src/dll as well.
Nevertheless documentation is needed indeed.
Marc
Maybe that's a stupid question, but when you say "incompatibilities should be posted in the "bugs" tracker (not missing functions/features, they should go into the "feature request" tracker)" then it isn't clear to me where the line between the two really is.
Example:
f = findgen(200,200)
tvscl,f,channel=1
tvscl,transpose(f),channel=2
this should give me a nice and colorful result. But apparently the "channel" keyword to the "tvscl" function doesn't work. Is that a bug? It doesn't throw an error, so it's a bug, no?
If I do this:
f = f/max(f)*255
tv,f,channel=1
then I get an actual error message ("% Keyword parameter CHANNEL not allowed in call to: TV")
so in this case it's a feature request? But surely the tvscl routine is simply a "bytscl" followed by a "tv"? Or am I misunderstanding something entirely? So the line between bug and missing feature seems blurry...
Support for the CHANNEL keyword has been added to TV and TVSCL. The updated code is in the CVS repository for GDL.
Joel
Two things:
1) It is insanely cool that I can mention some missing functionality and next it pops up in the CVS. You folks rock!
2) This doesn't really answer the question, though: when there is a non-functioning keyword in an otherwise functioning routine - is that a bug or a feature request?
I have added a page at wikibooks to allow people to edit a user manual and other documentation.<br>
http://en.wikibooks.org/wiki/User:Pwillis/GNU/GNU_Data_Language_Manual
Revise that link. I started a public book instead:<br>
http://en.wikibooks.org/wiki/GNU_Data_Language