V2.13 Beta-2 Now Available
Mike Fitzpatrick wrote on Apr 20, 2006
As the feature story says, a new release of the V2.13 Beta is now available and features a port for Cygwin under Windows XP SP2.
Please use this thread to report any problems, comments, or suggestions. Feedback on the new ports especially would help.
Thanks,
-Mike
Please use this thread to report any problems, comments, or suggestions. Feedback on the new ports especially would help.
Thanks,
-Mike
Emilliano Gregori wrote on Apr 20, 2006
Hello,
I just installed the cygwin port on a fully patched win2k machine (with SP4, Rollup and recent updates). I also installed DS9 version 4.0b9.
The IRAF system seems to work well with win2k but I have a problem with image display. When I run the command:
display dev$pix 1
I get the following error message:
ERROR: Cannot open device (node!imtool,,512,512)
The IRAF network hosts file contains the following line:
emiliano-4ec1e7 : emiliano-4ec1e7!/iraf/iraf/bin.cygwin/irafks.e
where "emiliano-4ec1e7" is the correct name of the machine. I also tried to set the "node" variable in the login.cl with:
set node = "emiliano-4ec1e7!"
but it does not work (same error message)... I looked in the graphcap file, and all the imt devices contain "node!"... shall I change them to the name of the machine? To solve the problem, I defined the environment variable IMTDEV with:
export IMTDEV="inet:5137:127.0.0.1"
before running the IRAF cl, as stated in the Unix/IRAF Site Manager Guide.
In this way image display with DS9 works well.
Many thanks,
Emiliano.
I just installed the cygwin port on a fully patched win2k machine (with SP4, Rollup and recent updates). I also installed DS9 version 4.0b9.
The IRAF system seems to work well with win2k but I have a problem with image display. When I run the command:
display dev$pix 1
I get the following error message:
ERROR: Cannot open device (node!imtool,,512,512)
The IRAF network hosts file contains the following line:
emiliano-4ec1e7 : emiliano-4ec1e7!/iraf/iraf/bin.cygwin/irafks.e
where "emiliano-4ec1e7" is the correct name of the machine. I also tried to set the "node" variable in the login.cl with:
set node = "emiliano-4ec1e7!"
but it does not work (same error message)... I looked in the graphcap file, and all the imt devices contain "node!"... shall I change them to the name of the machine? To solve the problem, I defined the environment variable IMTDEV with:
export IMTDEV="inet:5137:127.0.0.1"
before running the IRAF cl, as stated in the Unix/IRAF Site Manager Guide.
In this way image display with DS9 works well.
Many thanks,
Emiliano.
Mike Fitzpatrick wrote on Apr 20, 2006
Thanks for the message. It appears that DS9 doesn't implement the unix sockets for Cygwin and the install script doesn't check for a /dev directory before trying to create fifo pipes. On the iraf client side the task first checks for a unix socket and then falls back to fifos, neither of which exist meaning that explicitly specifying inet sockets is required.
I can fix the install script for the next update, until then another workaround is to simply create the fifos manually, e.g.
Setting IMTDEV in your .cshrc/.bashrc will also work as you've shown.
-Mike
I can fix the install script for the next update, until then another workaround is to simply create the fifos manually, e.g.
% mkdir /dev # create a /dev under cygwin
% mkfifo /dev/imt1i /dev/imt1o # make the fifo pipes
Setting IMTDEV in your .cshrc/.bashrc will also work as you've shown.
-Mike
Emilliano Gregori wrote on Apr 20, 2006
Mike,
I created the fifos, but it does not work: the "disp" command freezes the cl, and then I have to manually kill the x_tv.e process.
I also lauched ds9 with "-fifo /dev/imt1" but it's the same story...
Emiliano
I created the fifos, but it does not work: the "disp" command freezes the cl, and then I have to manually kill the x_tv.e process.
I also lauched ds9 with "-fifo /dev/imt1" but it's the same story...
Emiliano
Mike Fitzpatrick wrote on Apr 20, 2006
I've just simply gotta quit testing with debug clients....You're right, I get the same thing from DS9 but not with VXimtool meaning there's something not enabled. The best bet now is to use the IMTDEV definition, I can make it so that these appear in the graphcap magically when the install script is run so no user-definiton is required.
Sorry about the hassles, please keep those reports coming though.
Cheers,
-Mike
Sorry about the hassles, please keep those reports coming though.
Cheers,
-Mike
Antonis Manousakis wrote on Apr 20, 2006
Dear all,
Relative to the New release of IRAF (2.13) I have a problem with the digiphot package,
The only task that works is the apphot.
Is anyone know how to fix it?
Thank for the time
Antonis :)
Relative to the New release of IRAF (2.13) I have a problem with the digiphot package,
ecl> digi
apphot. daophot. photcal. ptools.
digiphot> dao
ERROR: task `tables' has no param file
"if (defpar ("tables.motd")) {"
line 6: daophot$daophot.cl
called as: `daophot ()'
digiphot>
The only task that works is the apphot.
Is anyone know how to fix it?
Thank for the time
Antonis :)
Mike Fitzpatrick wrote on Apr 20, 2006
The TABLES package is required for DAOPHOT, you've apparently got TABLES defined as a package but either because that was in the distribution or to your own installation but with an incorrect path (e.g. did you forget the trailing '/' on the pathname?). I wouldn't be surprised if the distribution erroneously had my local hlib$extern.pkg file, in any even you'll need to be sure TABLES is installed before using DAOPHOT. Post back if you still have problems.
Cheers,
-Mike
Cheers,
-Mike
Antonis Manousakis wrote on Apr 20, 2006
Dear Fitz,
The distro have a large extern.pkg and I replaced it with the extern.pkg.IRAFNET and finally the daophot runs.
Antonis
The distro have a large extern.pkg and I replaced it with the extern.pkg.IRAFNET and finally the daophot runs.
Antonis
Doug Mink wrote on Apr 20, 2006
I got IRAF running fine on a user's Mac Intel laptop, but none of the system tools I need to compile and link a new package--gcc, ar, or makefile (for some external stuff-- are there. Do you know where I can get them?
-Doug (who got everything to work just find under Cygwin in just a few hours)
-Doug (who got everything to work just find under Cygwin in just a few hours)
Mike Fitzpatrick wrote on Apr 20, 2006
You need to install the XCode package from the OSX install DVD (scroll down the screen and you'll see the developers stuff).
-Mike
-Mike
Doug Mink wrote on Apr 20, 2006
> You need to install the XCode package from the OSX install DVD
> (scroll down the screen and you'll see the developers stuff).
That did it. Everything compiled and linked flawlessly. Now we find out whether it works... Thanks!
-Doug
> (scroll down the screen and you'll see the developers stuff).
That did it. Everything compiled and linked flawlessly. Now we find out whether it works... Thanks!
-Doug
pakuliak wrote on Apr 20, 2006
Dear Fitz,
I've got the same problem with TABLES as antonism did.
I have TABLES previously installed and the path has the trailing"/", and no any evidences that extern.pkg is your local, but the error message is the same.
Where can the problem be looked for?
Ludmila
I've got the same problem with TABLES as antonism did.
I have TABLES previously installed and the path has the trailing"/", and no any evidences that extern.pkg is your local, but the error message is the same.
ERROR: task `tables' has no param file
"if (defpar ("tables.motd")) {"
line 6: daophot$daophot.cl
called as: `daophot ()'
Where can the problem be looked for?
Ludmila
Mike Fitzpatrick wrote on Apr 20, 2006
You can use the command "cl> show tables" to see what the current definition of the path is and make sure it is correct. Normally this is defined in the hlib$extern.pkg file, but look also for a definition in your login.cl or loginuser.cl file. Lastly, be sure you installed the TABLES package source and not just the binaries, this is what contains the 'tables.cl" file that loads the package.
Cheers,
-Mike
Cheers,
-Mike
Roland Roberts wrote on Apr 20, 2006
I ran into a problem with hedit in my previous install and so updated to the beta release. The install went fine, but when I attempted to run cl or ecl, I ran into two problems.
First, one of the test in ecl has this:
That last little test ... else if ($os_mach == "cygwin") then ... cause tcsh to die because $os_mach is not defined. Adding a ( ?$os_mach ) first eliminates this problem. But it's not clear to me why os_mach is in there at all since it is only used twice in the script....
First, one of the test in ecl has this:
if (! $?MACH) then
if (-f /etc/redhat-release) then
if (`uname -m` == "ppc") then
setenv mach linuxppc
else
setenv mach redhat
endif
else if (-f /etc/SuSE-release) then
set mach = suse
else
set mach = `uname -s | tr '[A-Z]' '[a-z]'`
set os_mach = `uname -s | tr '[A-Z]' '[a-z]' | cut -c1-6`
endif
if ($mach == "darwin") then
if ("`uname -m`" == "i386") then
setenv mach macintel
else
setenv mach macosx
endif
else if ($os_mach == "cygwin") then
setenv mach cygwin
endif
That last little test ... else if ($os_mach == "cygwin") then ... cause tcsh to die because $os_mach is not defined. Adding a ( ?$os_mach ) first eliminates this problem. But it's not clear to me why os_mach is in there at all since it is only used twice in the script....
Mike Fitzpatrick wrote on Apr 20, 2006
It was meant as a bit of future-proofing since the version is part of the string returned by 'uname -s', however the $os_mach then apparently isn't always set. Moving that line outside of the if should fix it, but if you're on an FC5 system I'm confused about why you don't see a /etc/redhat-release file. Is it actually there?
-Mike
-Mike
Roland Roberts wrote on Apr 20, 2006
/etc/redhat-release is present; but if you look closely at the nesting, you'll note that the test for "if ($mach == 'darwin') ..." is not in an else after the test of /etc/redhat-release, but rather...
if (! $?MACH) then
if (-f /etc/redhat-release) then
...
else if (-f /etc/SuSE-release) then
...
else
....
endif
if ($mach == "darwin") then
...
else if ($os_mach == "cygwin") then
...
endif
...
endif
Roland Roberts wrote on Apr 20, 2006
Below is a unified diff for what I've done to cl.csh on FC5. I encountered two problems, the first of which I mentioned before with $os_mach causing the script to abort.
Elsewhere I've read that I should be able to do #!/usr/local/bin/ecl to get a script to run and that is supposed to be equivalent to ecl < SCRIPT. Neither works for me out-of-the-box. I'm not sure why the hash-bang doesn't work. But using ecl < SCRIPT doesn't work without two of the patches below.
First, if -old is specified, it should get shifted off argv. Second, when the final exec is done, it should pass any command-line arguments. Without this, an attempt to run
seems to not pass in the parameters.
Elsewhere I've read that I should be able to do #!/usr/local/bin/ecl to get a script to run and that is supposed to be equivalent to ecl < SCRIPT. Neither works for me out-of-the-box. I'm not sure why the hash-bang doesn't work. But using ecl < SCRIPT doesn't work without two of the patches below.
First, if -old is specified, it should get shifted off argv. Second, when the final exec is done, it should pass any command-line arguments. Without this, an attempt to run
ecl < SCRIPT PARAM1 PARAM2...
seems to not pass in the parameters.
469 roland> diff -uw cl.csh cl.csh.~1~
--- cl.csh 2006-09-29 23:22:08.000000000 -0400
+++ cl.csh.~1~ 2006-09-27 22:23:49.000000000 -0400
@@ -17,7 +17,6 @@
else if ($#argv > 0) then
if ("$argv[1]" == "-old" || "$argv[1]" == "-o") then
set cl_binary = "cl.e"
- shift
endif
endif
@@ -73,11 +72,10 @@
else
setenv mach macosx
endif
- else if ( $?os_mach ) then
- if ($os_mach == "cygwin") then
+ else if ($os_mach == "cygwin") then
setenv mach cygwin
endif
- endif
+
if (-e $iraf/bin.$mach/$cl_binary) then
set MACH = $mach
@@ -179,4 +177,4 @@
set file = ${IRAFBIN}$cl_binary
# Run the desired CL.
-exec $file $*
+exec $file
470 roland>
Mike Fitzpatrick wrote on Apr 20, 2006
You're right that the cygwin/darwin code should be in the else-clause.
The #!cl thing refers directly to the cl.e executable and not the 'cl' startup script,
e.g.
Note that since there is no login.cl read you'll need to have the script define more of the environment, load packages, etc See http://iraf.noao.edu/iraf/web/new_stuff/cl_host.html for details.
-Mike
The #!cl thing refers directly to the cl.e executable and not the 'cl' startup script,
e.g.
#!/iraf/iraf/bin.redhat/ecl.e -fNote that since there is no login.cl read you'll need to have the script define more of the environment, load packages, etc See http://iraf.noao.edu/iraf/web/new_stuff/cl_host.html for details.
-Mike
iwold wrote on Apr 20, 2006
Thank you Mike for all your help.
I can now display images, but I am getting the following error when I attempt to copy images:
Despite this error a new file is created, however it is not a valid copy of the original image. Any help would be greatly appreciated.
Isak
I can now display images, but I am getting the following error when I attempt to copy images:
imcopy dev$pix newpix
ERROR: cannot open pixel file (newpix)Despite this error a new file is created, however it is not a valid copy of the original image. Any help would be greatly appreciated.
Isak
Mike Fitzpatrick wrote on Apr 20, 2006
One of the environment variables you need to define (since there is no login.cl to set it for you) is the 'imdir' directory where the .pix half of an OIF image goes. The 'imtype' variable sets the default image type (normally .imh) and can also be reset to "fits" to automatically create FITS images, otherwise explicitly setting the extension will force the type (e.g. "imcopy dev$pix newpix.fits", but note that the '$' will be taken as a host shell variable and must be escaped, use of iraf logicals in #!cl scripts generally just cause problems).
-Mike
-Mike
Last post on Apr 20, 2006