fitz |
04/20/2006 05:21AM (Read 31272 times)
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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
|
|
|
|
emiliano |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 12/05/2005
Posts: 38
|
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 1I 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.ewhere "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.
|
|
|
|
fitz |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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.[code:1:7b62e50cd6]
% mkdir /dev # create a /dev under cygwin
% mkfifo /dev/imt1i /dev/imt1o # make the fifo pipes
[/code:1:7b62e50cd6]Setting IMTDEV in your .cshrc/.bashrc will also work as you've shown.-Mike
|
|
|
|
emiliano |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 12/05/2005
Posts: 38
|
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
|
|
|
|
fitz |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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
|
|
|
|
antonism |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 12/12/2005
Posts: 4
|
Dear all, Relative to the New release of IRAF (2.13) I have a problem with the digiphot package,
[quote:643edf2dd4]
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>
[/quote:643edf2dd4]
The only task that works is the apphot. Is anyone know how to fix it? Thank for the time
Antonis
Antonis Manousakis
|
|
|
|
fitz |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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
|
|
|
|
antonism |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 12/12/2005
Posts: 4
|
Dear Fitz, The distro have a large extern.pkg and I replaced it with the extern.pkg.IRAFNET and finally the daophot runs. Antonis
Antonis Manousakis
|
|
|
|
dougmink |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 12/09/2005
Posts: 17
|
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)
|
|
|
|
fitz |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
You need to install the XCode package from the OSX install DVD (scroll down the screen and you'll see the developers stuff).-Mike
|
|
|
|
dougmink |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 12/09/2005
Posts: 17
|
> 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
|
|
|
|
pakuliak |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 06/01/2006
Posts: 14
|
Dear Fitz,
I've got the same problem with TABLES as [b:dd918eccce]antonism[/b:dd918eccce] 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.[code:1:dd918eccce]ERROR: task `tables' has no param file
"if (defpar ("tables.motd")) {"
line 6: daophot$daophot.cl
called as: `daophot ()'
[/code:1:dd918eccce]
Where can the problem be looked for?Ludmila
|
|
|
|
fitz |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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
|
|
|
|
rbroberts |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/26/2006
Posts: 18
|
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:[code:1:17c50d4d7a]
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
[/code:1:17c50d4d7a]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....
Roland B. Roberts, PhD
RL Enterprises
Brooklyn, NY
|
|
|
|
fitz |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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
|
|
|
|
rbroberts |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/26/2006
Posts: 18
|
/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...[code:1:890d4d0677]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
[/code:1:890d4d0677]
Roland B. Roberts, PhD
RL Enterprises
Brooklyn, NY
|
|
|
|
rbroberts |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/26/2006
Posts: 18
|
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 1:61B0A0A0AF Formatted Code ecl < SCRIPT PARAM1 PARAM2...
[/code:1:61b0a0a0af]
seems to not pass in the parameters.
[code:1:61b0a0a0af]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>
[/code:1:61b0a0a0af]
Roland B. Roberts, PhD
RL Enterprises
Brooklyn, NY
|
|
|
|
fitz |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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.[code:1:72e2f29c09]#!/iraf/iraf/bin.redhat/ecl.e -f[/code:1:72e2f29c09]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
|
|
|
|
iwold |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/28/2006
Posts: 9
|
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:[code:1:68d9b31069]imcopy dev$pix newpix
ERROR: cannot open pixel file (newpix)[/code:1:68d9b31069]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
|
|
|
|
fitz |
04/20/2006 05:21AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
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
|
|
|
|