Closed timj closed 9 years ago
I probably agree...
@dsberry -- only probably?
If @sfgraves wants to work on the JSA legacy paper and @dsberry wants to work on the AST paper I can do the removal :smile:
The only question is whether @MalcolmCurrie would prefer to do it immediately after the 2015A release.
I'm always happy to remove things :-)
I've pushed two commits, one removing kaprh and one removing echwind (including their updates to applications/configure.ac, the Makefile.dependencies and their entires in componentset.xml file, and their lines in Makefile.in)
Doing a git grep 'kaprh' I noticed that a couple of lines in polpack may need some work, in files
applications/polpack/Polka_procs.tcl applications/polpack/Polka.tcl.in
Thanks. @sfgraves the lengths you'll go to to avoid writing the paper... I'm not sure why you reassigned the ticket to me. I'm going to reassign it to @dsberry because I have no idea why POLPACK depends on kaprh:
2610 # Only report ADAM errors on the last attempt.
2611 if { $ntry < 2 } {
2612 set ok [Obey kaprh trantrace "transform=$map logfile=$logfile" noreport]
2613 } {
2614 set ok [Obey kaprh trantrace "transform=$map logfile=$logfile"]
2615 }
There's a whole chunk of code using TRANTRACE. Either we are meant to be supporting TRANSFORM
HDS structures (so TRANTRACE should be in KAPPA) or else we need to do this another way. I'm out of ideas.
I knew there was some good reason why I only probably agreed...
HDS TRANSFORM structures are only used by polka if the user choose to use a full 6 coefficient linear transformation to align the images. But... this facility has been thoroughly broken since 15-NOV-1999 when Mark modified ccdpack:register to remove the option of writing the results as a TRANSFORM structure. So I presume that no one has used the full 6 coefficient fit in polka since at last that date (and probably never :-( ). So I propose simply removing that option from polka since it is clearly not needed.
I'm happy to make the attempt.
Actually, I have no idea how to test that polka still runs so it's probably a bad idea.
Done. See 1cfe219ee96
There doesn't seem to be any reason to keep
echwind
andkaprh
in the main tree. I asked on the Starlink list aboutechwind
and no-one responded. No-one can seriously recommend using anything fromkaprh
at this point (the only issue being some old documents referring to old commands).