iraf.net

Some of the URLs are incorrect.Also, the posting of comments is currently broken. The comments.php file is missing.The redhat binary for ximtool gives me the following error but the ximtool-alt and ximtool-old binaries work.
[code:1:e7d6d23379]
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 8137
Current serial number in output stream: 8149
[/code:1:e7d6d23379]
Jason

These work:[code:1:b454037a62]Source Distribution: ftp://iraf.noao.edu/iraf/x11iraf/x11iraf-v2.0BETA-src.tar.gzPre-built Binaries: ftp://iraf.noao.edu/iraf/x11iraf/x11iraf-v2.0BETA-bin.redhat.tar.gz
ftp://iraf.noao.edu/iraf/x11iraf/x11iraf-v2.0BETA-bin.macosx.tar.gz
ftp://iraf.noao.edu/iraf/x11iraf/x11iraf-v2.0BETA-bin.macintel.tar.gz
[/code:1:b454037a62]
I deleted my previous incorrect comment...James.

Hi Mike,I get the following error when I try to start ximtool, using the pre-built redhat binary on Ubuntu 6.06:[quote:69c9530fd9] X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 7904
Current serial number in output stream: 7916
[/quote:69c9530fd9]
I'm trying to build it from source instead but am currently battling some missing headers and dependencies.Update: Ah, I see Jason added the same comment to his post whilst I was editing this! For the record, I get the error with both ximtool and ximtool-alt but not ximtool-old (which I had assumed was my existing binary but apparently is also v2).I notice that v2 ximtool-old seems slower than before -- 1s lag to blink frames on my laptop, compared with almost instantaneous for v1.3.1 on an old Sun.Thanks,James.

Just FYI, Inger tells me that "it works on Tiger but not on Leopard as far as I can figure out. On Leopard it does not start at all.". I know that doesn't provide much info. for now, but I hope Kathleen or another Mac user will look at it and send some more details.Cheers,James.

The distribution was just updated to fix the BadAlloc error some people have been seeing, please try downloading them again.As for the problem under Leopard: Is there any sort of error message? Is this a PPC or Intel system? Laptop? On Mac, the X11 Preferences should be set so the colors are either explicitly "Millions" or "From Display", the 'xdpyinfo' command should be used to verify you do indeed have a 24-bit default visual (32-bit should work, 16-bit is still TBD). I can verify the binary does indeed work under Leopard for me.....-Mike

All three start now... some give nasty sounding errors just doing simple stuff. Below is a direct console log of me running (in order) ximtool, ximtool-alt, and ximtool-old and executing only "display dev$pix 1" from IRAF and then quitting ximtool via the File->Quit.What are the differences between the three versions? I haven't noticed any yet.[code:1:521475756d]
jquinn@aries>ls
ism_wcspix.e* resize* xgterm* ximtool-alt* xtapemon*
obmsh* vximtool* ximtool* ximtool-old*
jquinn@aries>./ximtool
Warning: cannot open /dev/imt1o
jquinn@aries>./ximtool-alt &
[2] 14560
jquinn@aries>tail: cannot open `+99' for reading: No such file or directory
Error in message to server, line 1: invalid command name: "==>"
while executing
"==> ./ximtool-alt <=="
Warning: cannot open /dev/imt1oPANIC in `ism_wcspix.e': Memory has been corrupted[2] Done ./ximtool-alt
jquinn@aries>./ximtool-old &
[2] 14568
jquinn@aries>tail: cannot open `+79' for reading: No such file or directory
Error in message to server, line 1: invalid command name: "==>"
while executing
"==> ./ximtool-old <=="
Warning: cannot open /dev/imt1oPANIC in `ism_wcspix.e': Memory has been corrupted[2] Done ./ximtool-old
[/code:1:521475756d]The "Warning: cannot open /dev/imt1o" is legit because (for whatever reason) that pipe was apparently never made during my install and doesn't exist. I haven't had any problems with image display however.Jason

Jason,The three versions are just a matter of GUI differences and are a holdover of the old project where there were two GUI versions: The 'alt' GUI (with the toolbars) is now the default and so 'ximtool' and 'ximtool-alt' are the same. The 'ximtool-old' uses the same binary but loads a different GUI, most users won't use this. The -alt and -old are actually scripts that dump a GUI file and startup the binary, but the behavior of the 'tail' command used has changed so these will need to be modified (or even removed) before the final release.The warning about the fifo pipes can be silenced by using the '-unix_only' flag on the command-line, setting the 'input_fifo' resource to be 'none', or simply create the pipes (the display will use the unix socket so these will be unused). On the list of things from years ago is still a small change to silently just ignore the pipes if they are present (I'll take care of that today).The ism_wcspix.e is a separate binary used to do real-time pixel/wcs readouts and if it is crashing is probably something data-specific. Can you send me/post a url to an example image so I can investigate? Do you see similar from dev$pix?? Using the 'ISM' button on the toolbar can toggle this on/off and restart the process.-Mike

Bryan is seeing the following error message when trying to start today's ximtool v2 (downloaded 1-2 hours ago) on Mac OS 10.5.5 (Intel CPU laptop) with the X server XQuartz 2.3.1:[quote:ea58451bd7]bin/ximtool &
[1] 80384
Vela:~ bmiller$ X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 91 (X_QueryColors)
Value in failed request: 0x2f4f4f
Serial number of failed request: 263
Current serial number in output stream: 263
[/quote:ea58451bd7]
Typing xdpyinfo shows that the root window has 24 planes. The preferences are set to "from display".Thanks,James.

[quote:1451561867="fitz"]Jason,
The ism_wcspix.e is a separate binary used to do real-time pixel/wcs readouts and if it is crashing is probably something data-specific. Can you send me/post a url to an example image so I can investigate? Do you see similar from dev$pix?? Using the 'ISM' button on the toolbar can toggle this on/off and restart the process.
-Mike[/quote:1451561867]I only used dev$pix for the tests. It generated the error.Jason

Thanks, my error message has indeed gone away with the new Linux binary and I have my -alt GUI back :-). Excellent.The install script didn't initially work in Ubuntu because there is no bin.linux, but ximtool seems fine after editing the script to install the redhat binary. Presumably that can be taken care of easily enough for the final release.When I rescale the intensity with the right mouse button, only a little square in the middle of the image changes until I let go of the mouse button -- is that a new feature?Cheers,James.

James,[quote:6de4f743f2]Bryan is seeing the following error message when trying to start today's ximtool v2 (downloaded 1-2 hours ago) on Mac OS 10.5.5 (Intel CPU laptop) with the X server XQuartz 2.3.1:[/quote:6de4f743f2]I was able to reproduce this problem, but only when setting the default output to bew 'Thousands' and then what I see is a 15-plane TrueColor visual. It's not only the depth, but the type of visual as well: Be sure the 'default visual id' is at least a 24-bitTrueColor, there may be as many as 40-50 other visuals listed but the default is the important one.[quote:6de4f743f2]When I rescale the intensity with the right mouse button, only a little square in the middle of the image changes until I let go of the mouse button -- is that a new feature? [/quote:6de4f743f2]What's new is the slider at the bottom of the display that lets you control the size of that box so that you get refreshes at a reasonable rate. By default it should update the entire screen, but I notice that e.g. with a large frame buffer zoomed all the way out what's being updated are pixel in a box in image space, not the display screen space. Add another bug to the list .....-Mike

Jason,I can't reproduce any problem with ism_wcspix.e and dev$pix. Is there anything you might be doing, e.g. a really large frame buffer, printing ecliptic coordinates etc that I might not be testing? Do you notice the crash when e.g. you go off the end of the image, does it crash immediately or does it take a while?? I tried a number of platforms, all seem to work for me.-Mike

Any chance that Jason has a problem related to the IMTOOLRC setting?

[quote:69d2bb1879]I was able to reproduce this problem, but only when setting the default output to bew 'Thousands' and then what I see is a 15-plane TrueColor visual. It's not only the depth, but the type of visual as well: Be sure the 'default visual id' is at least a 24-bitTrueColor, there may be as many as 40-50 other visuals listed but the default is the important one.
[/quote:69d2bb1879]
Thanks for the clarification, but Bryan has that setting at "millions" and his "default visual id" says TrueColor. Here is an extract from his xdpyinfo output with the default visual id at the bottom:[quote:69d2bb1879]screen #0:
print screen: no
dimensions: 1440x900 pixels (486x293 millimeters)
resolution: 75x78 dots per inch
depths (7): 24, 8, 15, 1, 4, 16, 32
root window id: 0x53
depth of root window: 24 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x21
default number of colormap cells: 256
preallocated pixels: black 0, white 16777215
options: backing-store NO, save-unders NO
largest cursor: 32x32
current input event mask: 0x1a0000
StructureNotifyMask SubstructureNotifyMask
SubstructureRedirectMask
number of visuals: 17
default visual id: 0x27
visual:
visual id: 0x27
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
[/quote:69d2bb1879]
I assume the significant bits is per-RGB-component.[quote:69d2bb1879]What's new is the slider at the bottom of the display that lets you control the size of that box so that you get refreshes at a reasonable rate.
[/quote:69d2bb1879]
Ah, thanks. By the way, when I said that blinking is slower than before, it seems to depend on how the window is resized -- it's a bit faster with the default window size, but I find that a bit small to work with.James.

[quote:3174dc3b20]Any chance that Jason has a problem related to the IMTOOLRC setting?[/quote:3174dc3b20]I wouldn't think so, even if the imtoolrc file missing there is an "internal table" that's used as a backup so e.g. imt4400 is still recognized by the configuration number. What the ISM does is map a screen (x,y) position to the image pixel position, then it reads the image and applies the WCS.The default window and frame buffer are 512x512, using a different stdimage, displaying with 'fill', etc all will affect the positions used. What I need is a reproducible case that e.g. using default works, using a bigger frame buffer with fill on/off breaks it.-Mike

[quote:0e90640e73="fitz"][quote:0e90640e73]Any chance that Jason has a problem related to the IMTOOLRC setting?[/quote:0e90640e73]I wouldn't think so, even if the imtoolrc file missing there is an "internal table" that's used as a backup so e.g. imt4400 is still recognized by the configuration number. What the ISM does is map a screen (x,y) position to the image pixel position, then it reads the image and applies the WCS.The default window and frame buffer are 512x512, using a different stdimage, displaying with 'fill', etc all will affect the positions used. What I need is a reproducible case that e.g. using default works, using a bigger frame buffer with fill on/off breaks it.-Mike[/quote:0e90640e73]I am using [code:1:0e90640e73]
set stdimage = imt8192
[/code:1:0e90640e73]That is the only thing I can think of that might make a difference. All I am doing is displaying dev$pix and then quitting. The error is printed the moment I choose "Quit". It's somewhat unpredictable. I just tried again and it did it with "ximtool", when earlier it only did it for "ximtool-alt" and "ximtool-old".Jason

[quote:8fc2e1965a]
bin/ximtool &
[1] 80384
Vela:~ bmiller$ X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 91 (X_QueryColors)
Value in failed request: 0x2f4f4f
Serial number of failed request: 263
Current serial number in output stream: 263
[/quote:8fc2e1965a]I still haven't been able to reproduce this, but I find the value '2f4f4f' interesting since it appears only when setting the default background for the cut-plot windows. What I don't know is how/why this would be an issue.In any case, you can change this color to see if the problem goes away with a command like:[code:1:8fc2e1965a]
% ximtool -defgui | sed -e 's/2f4f4f/000000/g' > test.gui
% ximtool -gui test.gui
[/code:1:8fc2e1965a]This will reset the color to be black which should be more "standard". Anyway, let me know if this makes a difference.The only other thing is that colors are specified using the (now deprecated) syntax of e.g. "#2f4f4f" instead of "rgb:2f/4f/4f" -- maybe there's something in the Leopard X code that doesn't like this.-Mike

[quote:b31b85ab98]Any chance that Jason has a problem related to the IMTOOLRC setting?[/quote:b31b85ab98]I'm using imt8192 if that makes any difference.Jason

[quote:009acf8dd6]I'm using imt8192 if that makes any difference. [/quote:009acf8dd6]Since it happens at the 'Quit' I suspect this is a different version of a long-standing shutdown problem: The XImtool client is supposed to send a 'quit' message to the ISM, but if this doesn't get delivered before the client quits the ISM sees a broken pipe on its communications socket (and normally you'd see a "bad fd" message). Either this same problem is causing a memory corruption or the SIGPIPE is being misinterpreted.Either way a crash in the middle of a session is more critical, I can trap the error and/or tweak the shutdown to ignore this so it doesn't cause concern. I'd forgotten about the error since when XImtool et al are started from a .xinitrc file there normally isn't a terminal for the error message, but it is obvious when starting from the commandline. I'll look into it some more....-Mike