iraf.net

Here are a bunch of small fixes, mostly dealing with help database issues:The UTILITIES package has a handful of issues:1) "help detab option=source" is looking for "detab.x" when it should be "t_detab.x"2) "help entab option=source" is looking for "entab.x" when it should be "t_entab.x"3) "help translit option=source" is looking for "tranlist.x" when it should be "t_translit.x"4) "help bases" needs a help fileIn the SYSTEMS package:1) "help spy option=source" is pointing to a file that doesn't exist. The actual source for spy seems to be in hlib for some reason.2) The "bench" command is generally undocumented.In the COLOR package:1) "help rgbto8 option=source" is looking for "rgbto8.cl" when it should be "t_rgbto8.x"2) There are some residual files from an apparently extinct "rgb8bit" task that can be removed.In the PROTO.VOL package:1) "help pvol option=source" has something wrong with it. I couldn't figure this bug out as the "vol.hd" seems correct. Probably indicates a problem in another ".hd" file somewhere. There appears to be duplicate ".hd" files in the doc directory. It's probably worth doing a general check on this package and its help databases to make sure all is kosher.In GUIAPPS.XAPPHOT package:1) "help xguiphot option=source" points to "src/t_xguiphot.x" but there's no "src" directory and the source file is actually called "x_xapphot.x".2) "help xgphot option=source" points to a non-existence "src" directoryIn IMMATCH doc directory:1) There's a file "imcentroid.hlp.old" that can/should probably be removed.=========================================In general, it's unclear to me what the convention is for using "t_" as a prefix for the SPP sources. Cheers,
Jason

[quote:a89d3e7556]Here are a bunch of small fixes, mostly dealing with help database issues: ........[/quote:a89d3e7556]Thanks for these, they've all been fixed for the next release.
[quote:a89d3e7556]In general, it's unclear to me what the convention is for using "t_" as a prefix for the SPP sources.[/quote:a89d3e7556]The convention is that the 't_' is used for the task entrypoint file, however it isn't strictly enforced. In some cases a file may contain multiple entry points (e.g. similar tasks) and so a 't_' isn't used, in other cases it was either forgotten or left out because it's a trivial application (e.g. LCASE).

Here are a couple more:In IMAGES.IMCOORDS1) "help mkcwcs option=source"2) "help mkcwwcs option=source"In IMAGES.TV.IIS1) "iis.hd" incorrectly states "# Help directory for the TV package".2) "help cv option=source" gives bad output.. not sure how to fix this one.JasonPS How close are things to the next release?

[quote:c973bc87f3]Here are a couple more: .....[/quote:c973bc87f3]Thanks, all fixed now. The last one will still look 'wrong' since CV is a task but matches the CURFIT library routines because it doesn't find a CV source option but does in curfit. The task is obsolete anyway.[quote:c973bc87f3]PS How close are things to the next release?[/quote:c973bc87f3]Expected in November w/ a frequent update schedule thereafter. It'll be v2.16

[quote="fitz"][quote:8a6bb21c91]
Expected in November w/ a frequent update schedule thereafter. It'll be v2.16[/quote:8a6bb21c91]Speaking of version numbers, are major version numbers in IRAF reserved for redesigns that break backwards compatibility? I started using IRAF with the 2.x series, I think. The 64-bit upgrade was a pretty huge thing. I had wondered if a 3.0 released was considered for it.Jason

[quote:a72be38be7]Speaking of version numbers, are major version numbers in IRAF reserved for redesigns that break backwards compatibility?[/quote:a72be38be7]By 'major version' you mean v3 versus v2 here, right? The change from IRAF v1.x was before my time so I've never been part of the decision, but the thinking is that an IRAF v3 would involve major architectural changes (e.g. tasks running under some framework other than the CL (or a CL alternative like pyraf)) a replacement to SPP, etc). The 64-bit port [b:a72be38be7]was[/b:a72be38be7] a big change and hence not an update to the v2.14 release, but it was actually just more than the usual amount of work required to support a platform. There are some incompatabilities, but breaking backward compatibility is done only as a last resort.The upcoming v2.16 earns a bump in version because of new VO capabilities in the system (e.g. URL support by all tasks, messaging to/from other applications via VO protocols, VO data access, etc). This is expected to be updated frequently because bugs found in the core capabilities will affect all binaries, but there will be something like a "make update" to make this as painless as possible. However, packages that don't support at least v2.15 will be missing out on these features as well.

1) "help specshift" has "dopcor" spelled wrong in the "See also" section2) In the "see also" section of both "specshift" and "sapertures", "proto.wcsreset" appears to be in the imcoords package now instead of proto.3) help "declarations" in the "see also" section lists "begin" but there is no such help for "begin" (nor for "end"). Should probably just be removed from the listing.4) The "spy v" command throws an error because it looks for a MACH environment variable, which tends not to be set on modern Linux distributions. Not sure how to fix this in an architecture independent way. Maybe just eliminate this option. Or maybe test if variable is test and fallback on just "spy" if not.5) "help commands" has a couple minor mistakes:A) In the SYNTAX section:taskname (arg1, ... argN, par=val, ... par=val redir)is missing a comma before "redir" and I think should betaskname (arg1, ... argN, par=val, ... par=val, redir) In the ELEMENTS section:>>[GIP] append graphics output to a file, e.g, >G fileis missing a bracket in the example. Should be>>[GIP] append graphics output to a file, e.g, >>G fileActually, the "[GIP]" is kind of confusing. It looks like a choice of letters. The only valid way to use this is ">G" and ">>G", right? On the other hand, if GIP is an acronym, it is never defined.C) In the DESCRIPTION section, right at the end, there's a mention that a command block can be sent to the background with "& queuename". This is the only reference I'm aware of that IRAF has a named queuing system. Computers are so fast today I'm having trouble creating a command that takes a while to finish to test this. Does IRAF support named queues? What's an example of its use?D) There is surprisingly no mention in the IRAF help files anywhere (that I recall) about using escaped system commands (eg.. "!ls"). so at the moment, it's technically an undocumented feature. I've noticed often in the IRAF sources a double-bang (eg "!!ls") is used instead of a single-bang. Is this some VAX vs UNIX difference?

Hi Jason,Thanks for the careful reading. The documentation changes have been made for the next release. Similarly, the SPY command no longer relies on the MACH variable.[quote:142628180d]Actually, the "[GIP]" is kind of confusing. It looks like a choice of letters. The only valid way to use this is ">G" and ">>G", right? On the other hand, if GIP is an acronym, it is never defined. [/quote:142628180d]The [GIP] refer to the Graphics, Image or Plot streams. As implemented currently these all refer to the graphics redirection, in the origin IRAF architecture however graphics and imaging were seen as separate I/O streams (not quite sure where/when/why the 'P' came in).[quote:142628180d]C) In the DESCRIPTION section, right at the end, there's a mention that a command block can be sent to the background with "& queuename". [/quote:142628180d]Named queues were another part of the original design never implemented, I've just removed the reference from the help page.[quote:142628180d] There is surprisingly no mention in the IRAF help files anywhere (that I recall) about using escaped system commands (eg.. "!ls"). so at the moment, it's technically an undocumented feature.[/quote:142628180d]I think it might be in the original CL User's Guide or somesuch, but '!' is a shell escape to the user's default $SHELL, and '!!' forces the use of a Bourne shell for the command.[/quote]

Some more quick fixes for "help strings" this time:1) In USAGE changing "substr (str, start, end)" to "substr (str, first, last)" would make the arguments match the names used in the description section.2) In the DESCRIPTION section for substr, this sentence: "[i:d23c0b1f03]The last value may be larger than first, in which case the returned string is reversed.[/i:d23c0b1f03]" has it backwards.I would recommend changing the section to something like this:[quote:d23c0b1f03]Extracts a substring from string [b:d23c0b1f03]str[/b:d23c0b1f03] from index [b:d23c0b1f03]first[/b:d23c0b1f03] to index [b:d23c0b1f03]last[/b:d23c0b1f03]. The first character in the string is at index 1. The last value may be smaller than first, in which case the returned string is reversed.[/quote:d23c0b1f03]3) In the DESCRIPTION section for strstr and strlstr, the argument list is "str1, str1" when it should be "str1, str2".

Thanks, the changes have been made!

More or less, the documentation of IRAF is in decent shape and I'm looking forward to the new release. I will continue to collect minor issues as I notice them while using IRAF but they are fairly infrequent now and getting more minor.1) In "help imdelete", the second example is a little messed up. Instead of[code:1:56c0845257]cl> imdel fits* ver+
cl> Delete file 'fits1' ? (yes): yes
cl> Delete file 'fits2' ? (yes): yes
cl> Delete file 'fits3' ? (yes): yes
[/code:1:56c0845257]Should be:[code:1:56c0845257]cl> imdel fits* ver+
delete image `fits1' ? (yes): yes
delete image `fits2' ? (yes): yes
delete image `fits3' ? (yes): yes
[/code:1:56c0845257]Imdelete should have a "See also" for "delete".2) The file for "help access" sort of pulls double duty and also covers the imaccess task.. but a separate help file for imaccess already exists. Merging or separating the two completely would be better. At the least, the USAGE section of "help access" could use a newline between the two examples. If the the help files are to remain separate, each file should point to the other one in the "See also" section.3) The style of the "See also" section for "help expressions" needs cleanup and is different from all the other help files.4) General comment about help files: The help files are liberally sprinkled with empty sections like the ones for TIME REQUIREMENTS and BUGS for "help imdelete". As the documentation has been mature for a long time, I think removing empty sections would benefit the overall user-perception of the documentation state. Could probably be done very quickly with the aid of a script.4) General question about login screen. The top of my login screen looks like this:[code:1:56c0845257] NOAO/IRAF PC-IRAF Revision 2.15.1a EXPORT Mon Feb 21 18:54:16 MST 2011
This is the EXPORT version of IRAF V2.15.1a supporting PC systems.
[/code:1:56c0845257]All the information in the second line appears to be redundant to information in the first line. Is such a verbose, two-line version string necessary? I'm not sure the second "human friendly" version is worth the extra visual clutter. I've never understood what exactly the "EXPORT" adjective actually means.In the welcome message, a mention of the "help intro" document may be worthwhile. Having an easy-to-find introduction "in-house" at the door instead of relying on external PS or PDF documents would be very positive addition and seems to make sense. When I ran IRAF for a university on a large AFS network, where new undergrad students were being introduced to IRAF often, and it was cumbersome to explain where to find the introductory materials at the IRAF websites. In my opinion, the "help intro" document is too short to be a good introduction but it's a start.PS In "help intro", at the very beginning, there's a "Among it's responsibilities..." that should be "Among its responsibilities..." (i.e., no apostrophe)

Successfully installed IRAF 2.16. Congratulations on the release! I haven't gotten the chance to try out the new features but they sound exciting. No major problems.One of the help fixes I submitted previously still has an error.[code:1:9fa93cb0c6]vocl> help translit option=source
[/code:1:9fa93cb0c6]is still looking for the wrong source file. (It was changed but there was a spelling error introduced in the fix.)Another new quick fix: in[code:1:9fa93cb0c6]vocl> help "next"[/code:1:9fa93cb0c6]The code in the EXAMPLES section should use "i<=NCOLS" and "j<=NLINES"... off-by-one errors. You may also wish you add an initializer for "total"... compare with the help for "break".Cheers,
Jason

Hi Jason,Thanks as always for the careful read, these have been fixed (for real, this time) for the next update.Cheers,
-Mike