Possible critical regression in 2.15.1 patch
Jason Quinn wrote on Feb 21, 2011
I hate to give an incomplete bug report where I haven't identified the culprit but I thought this might be worth a heads up.
I have noticed that images produced with lacos_spec (Peter van Dokkum's cosmic ray cleaning task) under 2.15.1 differ significantly from the same images produced under 2.15 and 2.14.1. The latter two agree and look like what I'd expect but the 2.15.1 results are unusual. (64-bit system)
Lacos_spec is a cl script that only uses the following IRAF tasks:
imcopy, imreplace, fit1d, imarith, median, blkrep, convolve, blkavg, imcalc
As these are "fundamental" tasks and affect science results, I deem this a serious bug. Have any of these NOT changed since 2.15? That would help me locate the culprit. I can also upload a tarball with some images and steps that produce the problem. I think I have eliminated all things that would make it a local issue.
Jason
PS This weekend I was learning to use git. I'm curious what version control system in used for IRAF and what kind of unit testing framework there is.
I have noticed that images produced with lacos_spec (Peter van Dokkum's cosmic ray cleaning task) under 2.15.1 differ significantly from the same images produced under 2.15 and 2.14.1. The latter two agree and look like what I'd expect but the 2.15.1 results are unusual. (64-bit system)
Lacos_spec is a cl script that only uses the following IRAF tasks:
imcopy, imreplace, fit1d, imarith, median, blkrep, convolve, blkavg, imcalc
As these are "fundamental" tasks and affect science results, I deem this a serious bug. Have any of these NOT changed since 2.15? That would help me locate the culprit. I can also upload a tarball with some images and steps that produce the problem. I think I have eliminated all things that would make it a local issue.
Jason
PS This weekend I was learning to use git. I'm curious what version control system in used for IRAF and what kind of unit testing framework there is.
Mike Fitzpatrick wrote on Feb 21, 2011
Hi Jason,
One explanation might be a bug discovered last week that is related to an earlier fix in the v2.15.1 patch: The effect is that for single-precision images zero pixel values are interpreted as 128, since this is in the low-level code it affects all tasks and might explain the different results. A new binary release is in preparation, otherwise if you want to upload the images and steps I can verify whether this fixes the problem here before releasing the binaries.
Our version control is historically of a "manual" nature however I'll be setting up an SVN system as part of planned iraf.noao.edu updates. I looked at GIT which has an all-repositories-are-equal philosophy but decided the there-exists-a-master-version zen of SVN fit better. We have some automated scripts to test general image tasks developed for testing ports, but there isn't really a comprehensive set of test scripts for the science apps (thus the long test period for v2.15).
One explanation might be a bug discovered last week that is related to an earlier fix in the v2.15.1 patch: The effect is that for single-precision images zero pixel values are interpreted as 128, since this is in the low-level code it affects all tasks and might explain the different results. A new binary release is in preparation, otherwise if you want to upload the images and steps I can verify whether this fixes the problem here before releasing the binaries.
PS This weekend I was learning to use git. I'm curious what version control system in used for IRAF and what kind of unit testing framework there is.
Our version control is historically of a "manual" nature however I'll be setting up an SVN system as part of planned iraf.noao.edu updates. I looked at GIT which has an all-repositories-are-equal philosophy but decided the there-exists-a-master-version zen of SVN fit better. We have some automated scripts to test general image tasks developed for testing ports, but there isn't really a comprehensive set of test scripts for the science apps (thus the long test period for v2.15).
Robert Janusz wrote on Feb 21, 2011
Does it mean that the IRAF 2.15.2 is in preparation? Or there will be a patch to a patch?
Mike Fitzpatrick wrote on Feb 21, 2011
More of a patch to a patch, but I'm just calling it v2.15.1a because it is such a small change (and is available now). A v2.15.2 patch is planned for later this summer.
Jason Quinn wrote on Feb 21, 2011
I am happy to report that this is fixed by the 2.15.1a patch.
Thanks for all the hard work as usual, devs!
Thanks for all the hard work as usual, devs!
Robert Janusz wrote on Feb 21, 2011
I installed IRAF 2.15.1a from scratch and extern packages "mscred" and "stsdas". In "fitsutil" folder, in the subfolder "lib" there are two unresolved links "libcfitsio.a" and "libmef.a", because the "bin" points to "bin.generic" and not to "bin.linux" (where the targets are). In "mscred" folder the "bin" point to "bin.generic" as well, not to "bin.linux" (the same for "stsdas" and "tables").
For "/iraf/iraf/unix" there is also void link "bin" to "bin.generic" which does not exist. The same to void link "as". The effect of this is that in "hlib" we have unresolved links "libboot.a, libboot_p.a, libos.a, libos_p.a" ("libboot.a" is in both "bin.linux, ...64" and the same "libos.a" but there are no "*_p.a" there).
Back to the "extern" packages. There is no "bin.linux" link to "bin.redhat" in "stsdas" and "tables". Because the "bin" link in both cases point to "bin.generic" we have many unresolved "lib*" links; there is also unresolved link "tables_v313".
Now in "/iraf/iraf/" I do "make check" and I can see the installed packages "is current" message. "make update" gives for all packages: "is not installed" and there is no data in the folders "fitsutil, mscred, stsdas, tables" - all contents removed.
For "/iraf/iraf/unix" there is also void link "bin" to "bin.generic" which does not exist. The same to void link "as". The effect of this is that in "hlib" we have unresolved links "libboot.a, libboot_p.a, libos.a, libos_p.a" ("libboot.a" is in both "bin.linux, ...64" and the same "libos.a" but there are no "*_p.a" there).
Back to the "extern" packages. There is no "bin.linux" link to "bin.redhat" in "stsdas" and "tables". Because the "bin" link in both cases point to "bin.generic" we have many unresolved "lib*" links; there is also unresolved link "tables_v313".
Now in "/iraf/iraf/" I do "make check" and I can see the installed packages "is current" message. "make update" gives for all packages: "is not installed" and there is no data in the folders "fitsutil, mscred, stsdas, tables" - all contents removed.
Robert Janusz wrote on Feb 21, 2011
Similar situation with 2.15.1a and the same "externs" exists on the iMac.
Jason Quinn wrote on Feb 21, 2011
rj
Similar situation with 2.15.1a and the same "externs" exists on the iMac.
Hi, rj. I moved your topic to a new thread "Broken symbolic links (moved topic)" so that it can be more easily found in the future.
Jason
Last post on Feb 21, 2011