Path: utzoo!utgpu!attcan!uunet!l5comp!scotty From: scotty@l5comp.UUCP (Scott Turner) Newsgroups: comp.unix.microport Subject: Re: Bell Tech W.G.E. use with Microport Summary: Alternate universe postings, X10R4 arrives, outbitmap bug fix Message-ID: <453@l5comp.UUCP> Date: 25 Oct 88 03:03:15 GMT References: <438@l5comp.UUCP> <446@l5comp.UUCP> <287@belltec.UUCP> Reply-To: scotty@l5comp.UUCP (Scott Turner) Organization: L5 Computing, Edmonds, WA Lines: 67 Well I was patient, I held back my anger, I had a firm grasp on reality and I knew it would come to my rescue. Dimitri it seems is living in an alternate universe and his posting somehow made a hop into this universe. In this other universe I'm evidently not a very nice person, attacking people and abusing them, asking them to provide support for things they aren't supposed to provide support for. And above all, no one at Bell Tech wants to help this alternate universe "me". I'm happy to say I live in *THIS* universe (this message is not making any trans-universe hops to reach you), and in this universe all the above is a crock. And I'm glad. The complete X10R4 disk set arrived Friday. We're all happy, the extra source code provided has allowed for a couple bug fixes to some annoying problems (such as outbitmap -err core dumping) and provided usage information for others. We're still eagerly searching for those new impressive images Dimitri said we'd find in the latest release, so far no sightings but there is alot to dig through. I guess I can now say we're *HAPPY* with the W.G.E. under Microport Unix System V/386 3.0e. There are, as with a rose, a few thorns, but I hope Dimitri will allow sharing of information about fixing/avoiding them to continue. Without the crap from his alternate universe residence. For example: How to keep outbitmap -err from core dumping... (not core dumping for you you say? Well read on...) The -err flag turns on an error propogation algorithm that forwards the error from converting the current pixel to the three pixels immediately to the right and underneath the pixel being converted. The problem lies in that the routine scans ALL pixels in the bitmap... When scanning the rightmost pixel the routine accesses the first pixels on the next scan lines, tacky but not fatal. However, when scanning the pixels on the last scan line the routine access two totally non-malloc'd scan lines. Depending on the size of the image these last two scan lines may, or may not, fit within the "slop" in the last allocated data page. If they don't you get a core dump. If they do you get a picture with a potentially tacky lefthand side. The fix, go into /usr/new/image/outbitmap.c and patch the two for loops inside errprop() to scan to "y < (h-1)" and "x < (w-1)". X10R4 memory usage under Microport System V/386 3.0e. When NBUF is set back to 400K on a 4Meg system, with three xterms running /bin/sh, and some spawned getty's sar -r reports: 19:40:01 149 15072 (out of 16800 swap space blocks) Running GNU Emacs 18.52 and DOSMerge 386 1.1U at the same time results in swapping when you move the mouse from one window to the other. Often emacs will sit there for several seconds before responding to keyboard commands. 8 meg is looking REAL attractive as the memory size to go with. Especially since X11 is rumored to be a real porker on all systems supporting it so far. Looking for: xterm converted to simulate being a "scan-code" terminal. Where to post WGE X10R4 toys (GIF/IFF -> X5 bitmap convertors etc...) Online System V/386 man pages. :) Scott Turner scotty@l5comp -or- uunet!l5comp!scotty