print | sgraph
Robert Janusz wrote on Nov 10, 2009
I have an IRAF user task based on the ttables which uses a lot (in a loop) construction:
print(x,y) | sgrap(app+)
But it crashes very often in an unpredictable way. Restarting allows to run it without troubles but after changing some parameters it crashes again and so on. The flpr does not help at all. Could you help me please with work around this strange behaviour.
rj
print(x,y) | sgrap(app+)
But it crashes very often in an unpredictable way. Restarting allows to run it without troubles but after changing some parameters it crashes again and so on. The flpr does not help at all. Could you help me please with work around this strange behaviour.
rj
Robert Janusz wrote on Nov 10, 2009
Doing some more exercises on the problem, the task which uses constraction:
print(x,y) | sgraph(app+)
when crushes, gives the following informations:
xgterm: warning, error event received:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 38028
Current serial number in output stream: 38028
xgterm: warning, error event received:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 38032
Current serial number in output stream: 38032
xgterm: warning, error event received:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 38036
Current serial number in output stream: 38036
...
Does anybody know, what is going on? The language construction is OK, but there must be a bug, I think.
rj
print(x,y) | sgraph(app+)
when crushes, gives the following informations:
xgterm: warning, error event received:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 38028
Current serial number in output stream: 38028
xgterm: warning, error event received:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 38032
Current serial number in output stream: 38032
xgterm: warning, error event received:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 38036
Current serial number in output stream: 38036
...
Does anybody know, what is going on? The language construction is OK, but there must be a bug, I think.
rj
Mike Fitzpatrick wrote on Nov 10, 2009
The error messages are presumably coming from XGterm (i.e. the 'it' in "it crashes") and not either the CL or the SGRAPH task. Is there more to the script, e.g. each point is drawn in a different color? Are you using SGRAPH to append to an image display and the 'it' refers to ximtool/ds9??
Without knowing what platform your using (OS version, etc) I can't really comment other than to say this appears to be some problem in the colormap allocation. I'm not aware on any known similar problems with XGterm and would need to reproduce it. The output of an 'xdpyinfo' command to list your X server settings would help.
-Mike
Without knowing what platform your using (OS version, etc) I can't really comment other than to say this appears to be some problem in the colormap allocation. I'm not aware on any known similar problems with XGterm and would need to reproduce it. The output of an 'xdpyinfo' command to list your X server settings would help.
-Mike
Robert Janusz wrote on Nov 10, 2009
My OS is Debian (Lenny) - and it works very good with IRAF. There is only this problem with the script zx.cl:
The data zx.dat is like this:
but has ca 2000 lines. When I run the script once there is no problem, but running it for the 2nd time, xgterm window with IRAF ecl (last version) disapears.
The GNOME gives this message:
and the xdpyinfo gives:
Thank you.
procedure zx
# task zx=home$zx.cl
int n=3 { prompt="Sets" }
real scale=10. { prompt="Scale" }
real sxy=1.25 { prompt="Scale X/Y" }
begin
tables
tinfo("zx.dat")
k=tinfo.nrows
print("We have ",k," rows")
printf("%4.1f %4.1f\n%4.1f %4.1f\n",-sxy*scale,-scale,sxy*scale,scale) |
sgraph(plt.crvc=9,marker="point",app-)
#for (i=1; i<=n; i+=1) sgraph("z.dat c"//(2*i-1)//" c"//(2*i),
# app+,marker="point",plt.crvc=i)
for (j=1; j<=k; j+=1) {
printf(" %4d",j)
if (access("zx.tmp")) del("zx.tmp")
tprint("zx.dat",showr-,showh-,rows=j,>"zx.tmp")
for (i=1; i<=n; i+=1) sgraph("zx.tmp c"//(2*i-1)//" c"//(2*i),
app+,marker="box",plt.crvc=i)
# scan(j)
}
if (access("zx.tmp")) del("zx.tmp")
end
The data zx.dat is like this:
0.000 0.000 1.300 0.000 1.500 0.000
0.000 -0.005 1.299 0.050 1.496 0.090
0.000 -0.010 1.297 0.100 1.485 0.179
0.001 -0.015 1.293 0.150 1.468 0.265
0.001 -0.020 1.288 0.199 1.445 0.348
0.002 -0.025 1.282 0.249 1.416 0.427
0.003 -0.030 1.274 0.298 1.384 0.501
0.004 -0.035 1.264 0.347 1.348 0.571
0.005 -0.039 1.253 0.395 1.310 0.637
0.006 -0.044 1.241 0.443 1.270 0.698
but has ca 2000 lines. When I run the script once there is no problem, but running it for the 2nd time, xgterm window with IRAF ecl (last version) disapears.
The GNOME gives this message:
Nautilius can't be used now, due to an unexpected error.
Nautilus can't be used now, due to an unexpected error from Bonobo when
attempting to locate the factory. Killing bonobo-activation-server and
restarting Nautilus may help fix the problem.
and the xdpyinfo gives:
name of display: :0.0
version number: 11.0
vendor string: The X.Org Foundation
vendor release number: 10402000
X.Org version: 1.4.2
maximum request size: 16777212 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: window 0x3e00024, revert to PointerRoot
number of extensions: 33
BIG-REQUESTS
Composite
DAMAGE
DOUBLE-BUFFER
DPMS
Extended-Visual-Information
GLX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
RANDR
RECORD
RENDER
SECURITY
SGI-GLX
SHAPE
SYNC
TOG-CUP
X-Resource
XAccessControlExtension
XC-APPGROUP
XC-MISC
XFIXES
XFree86-Bigfont
XFree86-DGA
XFree86-DRI
XFree86-Misc
XFree86-VidModeExtension
XINERAMA
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number: 0
number of screens: 1
screen #0:
dimensions: 1280x1024 pixels (511x409 millimeters)
resolution: 64x64 dots per inch
depths (7): 24, 1, 4, 8, 15, 16, 32
root window id: 0x6e
depth of root window: 24 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x20
default number of colormap cells: 256
preallocated pixels: black 0, white 16777215
options: backing-store NO, save-unders NO
largest cursor: 64x64
current input event mask: 0xfa8033
KeyPressMask KeyReleaseMask EnterWindowMask
LeaveWindowMask ExposureMask StructureNotifyMask
SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask
PropertyChangeMask ColormapChangeMask
number of visuals: 17
default visual id: 0x23
visual:
visual id: 0x23
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
visual:
visual id: 0x24
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
visual:
visual id: 0x25
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
visual:
visual id: 0x26
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
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
visual:
visual id: 0x28
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
visual:
visual id: 0x29
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
visual:
visual id: 0x2a
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
visual:
visual id: 0x2b
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2c
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2d
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2e
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2f
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x30
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x31
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x32
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x6c
class: TrueColor
depth: 32 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
Thank you.
Robert Janusz wrote on Nov 10, 2009
I tried the same script with Linux/Debian 5, Windowmaker, and PyRaf. PyRaf runs the script much slower and it crushes as well near the same position of the data on the second run as the xgterm/ecl (with Windowmaker). At least the window does not disapear with PyRaf. The PyRaf error after the crush is:
Can someone figure out what is going on with this very simple sgraph?
rj
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 12 (X_ConfigureWindow)
Value in failed request: 0x0
Serial number of failed request: 3639658
Current serial number in output stream: 3639670
Can someone figure out what is going on with this very simple sgraph?
rj
Mike Fitzpatrick wrote on Nov 10, 2009
The error messages are coming from the X11 system and not from IRAF, the task or Pyraf. My suspicion is that this is a bug in the window manager or desktop system and not IRAF related at all, but I don't have a similar machine to test this on.
You can try using Xterm instead of XGterm and run under the ECL as before, if you get the same kind of crash we know it's not an XGterm problem. You can try reworking the script to use e.g. GRAPH instead of SGRAPH to rule out problem in the graphics task (e.g. the FIELDS task can be used to extract the columns you want so you can still plot the three sets separately). Lastly, try just logging in under KDE or some bare-bones X system to see if you see the same problem. Unfortunately, there's not much else I can recommend without being able to reproduce the problem.
-Mike
You can try using Xterm instead of XGterm and run under the ECL as before, if you get the same kind of crash we know it's not an XGterm problem. You can try reworking the script to use e.g. GRAPH instead of SGRAPH to rule out problem in the graphics task (e.g. the FIELDS task can be used to extract the columns you want so you can still plot the three sets separately). Lastly, try just logging in under KDE or some bare-bones X system to see if you see the same problem. Unfortunately, there's not much else I can recommend without being able to reproduce the problem.
-Mike
Robert Janusz wrote on Nov 10, 2009
This is not an X11 problem. When I run "xterm" (Not "xgterm") and in the "login.cl" there is a line:
I am able to run the task WITHOUT any problem; I can not see any color in the "tektronix(Tek)" window, of course, but I can run the task several times and the widnow does not crush at all; everything is as it should be. I have the problem with "xgterm" only.
stty xterm
I am able to run the task WITHOUT any problem; I can not see any color in the "tektronix(Tek)" window, of course, but I can run the task several times and the widnow does not crush at all; everything is as it should be. I have the problem with "xgterm" only.
Mike Fitzpatrick wrote on Nov 10, 2009
I have the problem with "xgterm" only.
Not quite, you also have a problem when running PyRAF which does not use the XGterm graphics (it has its own graphics system). The error messages about colormap issue may just mean this is an X11 problem related to color that you won't see in XTerm that doesn't do color. Note you can run an XGterm window and still do a "stty xterm" to see the plot in B&W, if that works then the problem may indeed be color related, but since you also see a X_ConfigureWindow error it may be related to how the graphics are initialized.
Using just the sample dataset you provided I can repeatedly run the script just fine under KDE. If you want to send me the full file I'll try that but there's little I can do without being able to reproduce the problem. Did you try using KDE or rewriting the script? If all you want is a hardcopy then try setting the device parameter to 'stdplot' to send it to the printer directly, append will still work but you'll need to issue a 'gflush" when done to flush the appended graphics.[/quote]
Robert Janusz wrote on Nov 10, 2009
...you also have a problem when running PyRAF which does not use the XGterm graphics (it has its own graphics system)...
I have ask the PyRAF people but they said:
...Unfortunately we do not support questions related to IRAF packages and scripts. Please refer to http://www.iraf.net/ for help regarding your question...
I tried the step as in the suggestion:
...you can run an XGterm window and still do a "stty xterm" to see the plot in B&W, if that works then the problem may indeed be color related...
and everything is OK: When I run xgterm with 'stty xterm' there is no problem, I can run the script several times as it should be; I can not see any color, of course.
I tried KDE, GNOME, WindowMaker, TWM and the script makes the xgterm widnows (all) disappear. It does not depend on the data. One can have 2000 lines:
0.000 0.000 1.300 0.000 1.500 0.000
...
and at the 2nd run of the data, ca 1250 line makes the crush.
I was trying to compile the x11iraf from sources but I get errors like:
In file included from HTML-PSformat.c:57:
/usr/lib/gcc/i486-linux-gnu/4.3.2/include/varargs.h:4:2: error: #error "GCC no longer implements <varargs.h>."
/usr/lib/gcc/i486-linux-gnu/4.3.2/include/varargs.h:5:2: error: #error "Revise your code to use <stdarg.h>."
HTML-PSformat.c: In function âPSprintfâ:
HTML-PSformat.c:230: error: expected declaration specifiers before âva_dclâ
HTML-PSformat.c:272: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âunsignedâ
HTML-PSformat.c:272: error: declaration for parameter âflushâ but no such parameter
HTML-PSformat.c:278: error: âvalâ undeclared (first use in this function)
HTML-PSformat.c:278: error: (Each undeclared identifier is reported only once
HTML-PSformat.c:278: error: for each function it appears in.)
It is not important personally for me to have the solution of the problem. I am able to work it around. I try to resolve it because is would be nice to have bug free software.
Mike Fitzpatrick wrote on Nov 10, 2009
Using both v1.5 and the more recent v2.0 of XGterm I'm still able to run your script on a test file of 2000 lines multiple times without seeing any error. If you have access to another machine you might try the same experiment, unfortunately I don't currently have access to a Debian Lenny system.
As for the PyRAF response: They might be more convinced if you rewrote the script in python, but I can assure you this is not an iraf or scripting problem, it is strictly on the X side of things.
As for the PyRAF response: They might be more convinced if you rewrote the script in python, but I can assure you this is not an iraf or scripting problem, it is strictly on the X side of things.
Robert Janusz wrote on Nov 10, 2009
Thak you for the infos.
rj
PS
I tried the same IRAF binaries and the script on the Fedora Linux and it works without any crush. I was also able to compile x11iraf by setting in the obm/ObmW/HTML-PS... the "USE_STDARG" by force.
rj
PS
I tried the same IRAF binaries and the script on the Fedora Linux and it works without any crush. I was also able to compile x11iraf by setting in the obm/ObmW/HTML-PS... the "USE_STDARG" by force.
Last post on Nov 10, 2009