dsill@ophiuchi.nswc.navy.mil (Dave Sill) (12/07/89)
Here's what I get when I try to run xps: % adb xps core file = core -- program ``xps'' SIGBUS 10: bus error $c _HardwareExtent(0x4f537,0x1fb40,0x4,0x0,0x0,0x0) + 1c _InitDevices(0x4e61c,0xffffefb4,0x5310,0x80,0x3,0x0) + d8 _Init(0x4ec08,0x4ebfe,0xf7ffffe0,0x80,0x3,0xf779a05c) + 2e8 _main(0x3,0xf7fffe7c,0xf7fffe8c,0x4e000,0x0,0x0) + a0 (Compiled with GCC 1.36 on SPARCstation-1 running 4.0.3c and MIT sample server) Anybody else have trouble getting xpr to work on a sparc? Dave Sill (dsill@relay.nswc.navy.mil)
brtmac@maverick.ksux.ksu.edu (Brett McCoy) (12/07/89)
dsill@ophiuchi.nswc.navy.mil (Dave Sill) writes: >% adb xps >core file = core -- program ``xps'' >Anybody else have trouble getting xpr to work on a sparc? Yep, I compiled it on a SparcStation 1 with cc and it core dumps whenever I try to run it. I haven't tried using different -O settings or using dbx on it to find where it crashes at yet. -- The XTrek Demi-God | God is real, unless declared integer Brett McCoy | brtmac@ksuvm.ksu.edu | If you don't get caught, brtmac@maverick.ksu.ksu.edu | did you really do it?
stolcke@icsib2.Berkeley.EDU (Andreas Stolcke) (12/07/89)
My experience with xrn on sparcs was that the only way to get it to work was to make floats into doubles and turn off global optimization. This produced a working binary with the Sun cc compiler. I found no way to get it working with gcc. Try the putting the following in the top-level Imakefile: #define PassCDebugFlags 'CDEBUGFLAGS=$(CDEBUGFLAGS)' #if SunOSPlatform && OSMajorVersion == 4 CDEBUGFLAGS = -O1 -Dfloat=double #endif ---- Andreas Stolcke International Computer Science Institute stolcke@icsi.Berkeley.EDU 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126
peter@memex.co.uk (Peter Ilieve) (12/08/89)
In article <1989Dec6.163746.20598@relay.nswc.navy.mil> Dave Sill writes: >Here's what I get when I try to run xps: >% adb xps >core file = core -- program ``xps'' >SIGBUS 10: bus error >$c >_HardwareExtent(0x4f537,0x1fb40,0x4,0x0,0x0,0x0) + 1c > ... >(Compiled with GCC 1.36 on SPARCstation-1 running 4.0.3c and MIT >sample server) It dies in the same place with cc as well. The problem is something to do with returning structures. It works here, using cc, if you compile just x11.x without -O. I don't know enough about gcc to know if you would need -fpcc_struct_return as well. Peter Ilieve peter@memex.co.uk
tpf@jdyx.UUCP (Tom Friedel) (12/14/89)
peter@memex.co.uk (Peter Ilieve) writes: >In article <1989Dec6.163746.20598@relay.nswc.navy.mil> Dave Sill writes: >>Here's what I get when I try to run xps: After adding return NULL to the end of InitHardware in X11.c things worked a lot better for me. Tom -- Tom Friedel (404) 320-7624 tpf@jdyx.UUCP CIS: 71131,3234 also: tpf@jdyx.atlanta.ga.us ...gatech!emory!jdyx!tpf Unix BBS: (404) 325-1719 <= 2400 ; (404) 321-5020 >= 2400 "Live simply, so that others may simply live."
weening@Gang-of-Four.Stanford.EDU (Joe Weening) (12/15/89)
Here's a reposting of some things that I fixed in xps. (The original
message was <11869@polya.Stanford.EDU> on 20 Sep 89.) There is still
a serious problem in the "fill" operation, that shows up in some
versions of the "rosette" test file, depending on the rounding of
certain coordinates to integer values. I tracked it down to where it
appears to require major reworking of the fill algorithm, and gave up
there. Does anyone maintain this program?
--------------------
I'm not completely sure these fixes are the best ones, so please
followup to this message if you see a better way. Here is an
explanation of the problems that are fixed.
1. In stroke.c, the function LineSegment() could call atan2(0.0,0.0),
which is meaningless and causes an error on some systems. I have it
check for this case and return 0.0 instead of calling atan2.
2. In X11.c, the program seems to expect that black = 1 and white = 0
on the display. There is a comment by the author that "it's OK on
Suns" but this isn't a help for those of us who have the colors
reversed. (Note that the comment gets them backwards but the meaning
is clear.) I think I've fixed this below, but perhaps not in the most
elegant way.
What causes the problem is that the program uses some boolean
operations (such as AND and OR), whose effect depends on whether black
and white are 0 and 1 or vice versa. E.g., if the background is white
and black is 1, then an OR of a black pixel and the background will be
black, while if black is 0, the result of the OR will be white.
As far as I can see, a program that wants to use boolean functions
must decide which ones to use based on the numerical values of the
black and white pixels. This seems ugly to me. Does X11 have a less
machine-dependent way of doing this?
3. The program doesn't have a real event loop; it calls XNextEvent
just once to get the initial expose event. This doesn't work when
using twm because of the window manager's reparenting of the window,
so I stuck in a sleep(1) to wait for this. (An ugly kludge; is there
a better way?)
Here are the diffs:
diff -c2 stroke.c.old stroke.c
*** stroke.c.old Sat Oct 22 16:35:31 1988
--- stroke.c Wed Sep 20 13:32:46 1989
***************
*** 316,321 ****
float LineSegment (p, new, ehere, enow, width, last_angle, last_type) Path p, new; Point ehere, enow; float width, last_angle; enum pelem_type last_type;
{
! float angle = atan2 (enow.y - ehere.y, enow.x - ehere.x),
! length = sqrt ((enow.y - ehere.y) * (enow.y - ehere.y) + (enow.x - ehere.x) * (enow.x - ehere.x));
Matrix old;
--- 316,323 ----
float LineSegment (p, new, ehere, enow, width, last_angle, last_type) Path p, new; Point ehere, enow; float width, last_angle; enum pelem_type last_type;
{
! float dy = enow.y - ehere.y,
! dx = enow.x - ehere.x,
! angle = (dx == 0.0 && dy == 0.0) ? 0.0 : atan2 (dy, dx),
! length = sqrt (dy * dy + dx * dx);
Matrix old;
diff -c2 X11.c.old X11.c
*** X11.c.old Tue Jul 4 01:00:08 1989
--- X11.c Wed Sep 20 13:39:24 1989
***************
*** 122,125 ****
--- 122,132 ----
XGCValues values;
int i;
+ /* The program expects black = 1, white = 0. This is the array of
+ boolean functions to use if they are reversed. */
+ static char inv_rop[16] = {
+ ROP_TRUE, ROP_OR, ROP_ORNOT, ROP_SOURCE,
+ ROP_NOTOR, ROP_DEST, ROP_NXOR, ROP_AND,
+ ROP_NAND, ROP_XOR, ROP_NOTDEST, ROP_ANDNOT,
+ ROP_NOTSOURCE, ROP_NOTAND, ROP_NOR, ROP_FALSE };
if ((dpy = XOpenDisplay(dpy)) == NULL)
Punt("Could not open display");
***************
*** 127,136 ****
/* This defines our screen as being 11 inches high, no matter what its */
/* real size. What a hack. */
! values.foreground = AllPlanes;
for (i=0 ; i<16 ; i++) {
! values.function = i;
fillgc[i] = XCreateGC(dpy, RootWindow(dpy, SCREEN),
! GCFunction | GCForeground, &values);
}
}
/*
--- 134,146 ----
/* This defines our screen as being 11 inches high, no matter what its */
/* real size. What a hack. */
! values.foreground = BlackPixel(dpy, SCREEN);
! values.background = WhitePixel(dpy, SCREEN);
for (i=0 ; i<16 ; i++) {
! values.function = (values.background == 0) ? i : inv_rop[i];
fillgc[i] = XCreateGC(dpy, RootWindow(dpy, SCREEN),
! GCFunction | GCForeground | GCBackground,
! &values);
}
+ return NULL;
}
/*
***************
*** 218,221 ****
--- 228,234 ----
XSelectInput(dpy, hard->w, ExposureMask);
XMapWindow(dpy, hard->w);
+ /* Give the window manager time to reparent and reexpose our window. */
+ XFlush(dpy);
+ sleep(1);
XNextEvent(dpy, &event);
XSelectInput(dpy, hard->w, 0);
***************
*** 606,610 ****
void HardUpdate ()
{
! XFlush(dpy, 0);
}
/*
--- 619,623 ----
void HardUpdate ()
{
! XFlush(dpy);
}
/*
--
Joe Weening Computer Science Dept.
weening@Gang-of-Four.Stanford.EDU Stanford University