Welcome to iraf.net Monday, December 18 2017 @ 12:55 PM GMT


 Forum Index > Help Desk > Systems New Topic Post Reply
 V2.13 Beta-2 Now Available
   
fitz
 04/20/2006 05:21AM (Read 29630 times)  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3989
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

 
Profile Email
 Quote
emiliano
 04/20/2006 05:21AM  
+++--
Chatty

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.

 
Profile Email
 Quote
fitz
 04/20/2006 05:21AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3989
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

 
Profile Email
 Quote
emiliano
 04/20/2006 05:21AM  
+++--
Chatty

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

 
Profile Email
 Quote
fitz
 04/20/2006 05:21AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3989
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

 
Profile Email
 Quote
antonism
 04/20/2006 05:21AM  
+----
Newbie

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 Smile

Antonis Manousakis
 
Profile Email
 Quote
fitz
 04/20/2006 05:21AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3989
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

 
Profile Email
 Quote
antonism
 04/20/2006 05:21AM  
+----
Newbie

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
 
Profile Email
 Quote
dougmink
 04/20/2006 05:21AM  
++---
Junior

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)

 
Profile Email Website
 Quote
fitz
 04/20/2006 05:21AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3989
You need to install the XCode package from the OSX install DVD (scroll down the screen and you'll see the developers stuff).-Mike

 
Profile Email
 Quote
dougmink
 04/20/2006 05:21AM  
++---
Junior

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

 
Profile Email Website
 Quote
pakuliak
 04/20/2006 05:21AM  
+----
Newbie

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

 
Profile Email
 Quote
fitz
 04/20/2006 05:21AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3989
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

 
Profile Email
 Quote
rbroberts
 04/20/2006 05:21AM  
++---
Junior

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
 
Profile Email Website
 Quote
fitz
 04/20/2006 05:21AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3989
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

 
Profile Email
 Quote
rbroberts
 04/20/2006 05:21AM  
++---
Junior

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
 
Profile Email Website
 Quote
rbroberts
 04/20/2006 05:21AM  
++---
Junior

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 &lt; SCRIPT PARAM1 PARAM2...
[/code:1:61b0a0a0af]

seems to not pass in the parameters.

[code:1:61b0a0a0af]469 roland&gt; diff -uw cl.csh cl.csh.~1~
--- cl.csh      2006-09-29 23&#58;22&#58;08.000000000 -0400
+++ cl.csh.~1~  2006-09-27 22&#58;23&#58;49.000000000 -0400
@@ -17,7 +17,6 @@
 else if &#40;$#argv &gt; 0&#41; then
     if &#40;&quot;$argv&#91;1&#93;&quot; == &quot;-old&quot; || &quot;$argv&#91;1&#93;&quot; == &quot;-o&quot;&#41; then
         set cl_binary  = &quot;cl.e&quot;
-        shift
     endif
 endif
 
@@ -73,11 +72,10 @@
         else
             setenv mach macosx
         endif
-    else if &#40; $?os_mach &#41; then
-        if &#40;$os_mach == &quot;cygwin&quot;&#41; then
+    else if &#40;$os_mach == &quot;cygwin&quot;&#41; then
             setenv mach cygwin
         endif
-    endif
+
 
     if &#40;-e $iraf/bin.$mach/$cl_binary&#41; then
        set MACH = $mach
@@ -179,4 +177,4 @@
 set file = $&#123;IRAFBIN&#125;$cl_binary
 
 # Run the desired CL.
-exec $file $*
+exec $file
470 roland&gt;
[/code:1:61b0a0a0af]

Roland B. Roberts, PhD RL Enterprises Brooklyn, NY
 
Profile Email Website
 Quote
fitz
 04/20/2006 05:21AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3989
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

 
Profile Email
 Quote
iwold
 04/20/2006 05:21AM  
+----
Newbie

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

 
Profile Email
 Quote
fitz
 04/20/2006 05:21AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3989
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

 
Profile Email
 Quote
   
Content generated in: 1.22 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login