Sun-Spots-Request@Rice.edu (William LeFebvre) (10/10/88)
SUN-SPOTS DIGEST Thursday, 6 October 1988 Volume 6 : Issue 251 Today's Topics: Re: Rasterfile to rasterfile conversion filter (2) Re: Has anyone installed a CDC Wren V (620MB) Re: 386i compiler bug Re: Drawing system for Sun Re: Mathematica for Sun GNUPLOT sources 386i repaired & explained bug in scanf under 4.0 sun!sunbugs vs sun!hotline Popping up an independent window in SunView DNI Protocol Error question bad user stack message Problems with 3.5 and NFS? Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Mon, 3 Oct 88 10:07:16 PDT From: david@sun.com (David DiGiacomo) Subject: Re: Rasterfile to rasterfile conversion filter (1) Reference: v6n244 >Since my disk space was disappearing at an alarming rate, I decided to >convert all my rasterfile bitmaps to the compressed format. I whipped up >the following filter to convert Sun rasterfiles from one format to >another.... /usr/lib/rasfilters/convert.2 will do about the same thing. Source is included. -- David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@sun.com ------------------------------ Date: Mon, 3 Oct 88 13:09:14 PDT From: gandalf@csli.stanford.edu (Juergen Wagner) Subject: Re: Rasterfile to rasterfile conversion filter (2) Using compress(1) results in a much better compression of Sun rasterfiles. To read compressed images you can open a pipe to uncompress(1) which writes the uncompressed file to its stdout (basically, that's zcat(1)). There are two utilities in /usr/lib/rasfilters, called convert.0 and convert.2, which read RT_OLD, RT_STANDARD, RT_BYTE_ENCODED bitmaps, and convert them to RT_STANDARD or RT_BYTE_ENCODED bitmaps. Example (bitmap `fullmoon', 1152x900x1, the full moon on a black background with some stars): Rasterfile Rasterfile.Z RT_STANDARD 130kB 67kB RT_BYTE_ENCODED 54kB 57kB I think, that this ratio is fairly typical. Juergen "Gandalf" Wagner, gandalf@csli.stanford.edu Center for the Study of Language and Information (CSLI), Stanford CA PS: The Sun RT_BYTE_ENCODED format is different from MacPaint file encoding. MacPaint uses a run-length encoding scheme which collects runs longer than 3 into <count-1><byte>, and unencoded sequences into <count-1><data[count]>. Sun uses a scheme where runs longer than 3 are encoded as 80<count-1><byte>, and where unencoded sequences are just written as such (with the exception of the byte 80 which is written as 8000). ------------------------------ Date: Mon, 3 Oct 88 18:07:54 +0100 From: unido!focus!bigmac!jum@uunet.uu.net (Jens-Uwe Mager) Subject: Re: Has anyone installed a CDC Wren V (620MB) My CDC Wren V Manual states that this disk has 383.3 Mb unformatted capacity, may be Control Data uses a different numbering scheme in the US? Anyways, they have three models with slightly different cylinder/head layout. On model 94186-442 1412 cylinders and 15 heads, on model 94186-383 1412 cylinders and 13 heads and on model 94186-383H 1224 cylinders and 15 heads. Leaving the usual 6 cylinders for bad block handling I got this space on model -383H : bigmac# dkinfo sd2a Emulex MD21 controller at addr 140000, unit # 8 1218 cylinders 15 heads 34 sectors/track 621180 sectors (1218 cyls) starting cylinder 0 bigmac# The only problem I encountered is that on the new MD21 Controllers shipped by Emulex the firmware is not compatible to the sun drivers, although after copying the eprom from an original sun shoe box everything works fine. ------------------------------ Date: Mon, 3 Oct 88 17:35:01 EDT From: shenkin@cubsun.bio.columbia.edu (Peter Shenkin) Subject: Re: 386i compiler bug I tried to reply directly to the poster, but email couldn't get through; so here's more information; sorry it's not a solution! I compiled the following code on a Sun 3 running SunOS 3.4. It compiled without complaint. I also tried it on another Sun 3 running SunOS 4.0. Also no complaints. Since a foo.h file wasn't given, I supplied one that also includes the function definition. I'd like to see identical code tried on the 386i. If it works fine, the problem must lie elsewhere than in the fragment that was supplied. In either case, I'd like to hear what happens, since I have a 386i on order.... -P. Peter S. Shenkin, Department of Chemistry, Barnard College, Columbia University New York, NY 10027 Tel: (212) 280-5517 (work); (212) 829-5363 (home) shenkin@cubsun.bio.columbia.edu shenkin%cubsun.bio.columbia.edu@cuvmb.BITNET /************** start foo.h *** code supplied by shenkin@cubsun ***********/ typedef struct foo_tag { double d; float f; long l; int i; short s; char c; } *foo_type; foo_type f() { static foo_type joe; return joe; } /************** end foo.h ***************************************/ /************** start try.c **** code given by original poster **********/ #include "foo.h" main () { extern foo_type f(); /* foo_type is a pointer to a struct */ foo_type a, b, c, d; a = f (); b = f (); { c = f(); } d = f (); } /************** end try.c ***************************************/ ------------------------------ Date: Mon, 3 Oct 88 19:59:02 EDT From: scott%bu-ma.BU.EDU@bu-it.bu.edu (Scott Sutherland) Subject: Re: Drawing system for Sun Reference: v6n246 Some very nice drawing and painting programs come as part of the Publisher from ArborTeX -- you can use them standalone if you want. Send mail to help%arbortext@umix.cc.umich.edu for more information. The drawing and painting programs were originally done by Island Graphics Corp and called SolarDraw and SolarPaint. Scott Sutherland scott@bu-ma.bu.edu Boston University Math Department ------------------------------ Date: Mon, 3 Oct 88 13:23:11 CDT From: stevec@ncsa.uiuc.edu (Steve Christensen) Subject: Re: Mathematica for Sun Information on Mathematica for Sun Workstation should be obtainable from your local Sun sales rep. However, if the rep does not have the information, you can email Andy McRae at Sun at acm@sun.com. Wolfram Research's address is Wolfram Research, Inc. P.O. Box 6059 Champaign, IL 61821-9902 USA There are versions for the Sun-3, Sun-4 and Sun-386i. These are sold directly by Sun and not by Wolfram Research. The price for one copy retail is $1,800 and $1,200 for educational institutions. There are also versions for the Apple Macintosh, NeXT Machine, Ardent, Stellar, IBM RT, Silicon Graphics and others. Steve Christensen NCSA, University of Illinois at Urbana-Champaign ------------------------------ Date: Fri Sep 30 09:33:40 1988 From: sir-alan!mikes@vax.cs.pittsburgh.edu Subject: GNUPLOT sources The sources are in my comp.sources.{unix,misc} archive, accessible via anonymous uucp at 814 333 6728 (login pdsrc, no password, 1200/2400) or at 814 337 0894 (login pdsrc, no password, Telebit TB+ cycling 2400-BREAK-9600-BREAK-1200). I currently have on-line all of mod.sources/comp.sources.unix/comp.sources misc and much of net.sources. Michael L. Squires uucp: {necntc,cwjcc,hoptoad}!ncoast!peng!sir-alan!mikes Department of Political Science .!{pitt,uunet!convex}!sir-alan!mikes Allegheny College BITNET: mikes%sir-alan@pitt.UUCP (VAX) Meadville, PA 16335 MIKES AT SIR-ALAN!PITT.UUCP (IBM) Office: 814 724 3360 Internet: sir-alan!mikes@vax.cs.pittsburgh.edu Home: 814 337 5528 Data: 814 {333-6728,337-3159} login of "ubbs" for BBS ------------------------------ Date: Mon, 3 Oct 88 12:08:09 MDT From: dbd%benden@lanl.gov (Dan Davison) Subject: 386i repaired & explained The 386i problem that I noted here recently has been fixed. When the disk and CPU board was replaced the machine worked almost fine. The "almost" is because after two minutes of inactivity the keyboard and mouse would lock up and the only way to get it back was to power cycle the machine. A TSE from Albuquerue was around and stopped by, looked at it, said he thought that was screenblank, and sure enough it was. Removal of "screenblank -l" fixed the lockup. I also got a call from a local HW guy who pointed out that unless told otherwise, *repairs under 90-day warrantees are done at the factory*. That was news to me and others around here, and that may be part of the delay in getting the machine fixed. We put all our machines on service contract anyway, but not until *after* the 90-day period is up. My thanks to the people, both inside Sun and out, who contacted me about this problem. Now that the machine is back, boy it is wonderful! If I save my pennies from now to the end of time, maybe I can afford to have one at home... dan davison / theoretical biology / t-10 ms k710 / los alamos national lab. dd@lanl.gov / ...cmcl2!lanl!dd / dd@lanl.UUCP / los alamos, nm 87545 USA ------------------------------ Date: Mon, 3 Oct 88 10:39:07 MDT From: Matt Rosing <rosing@boulder.colorado.edu> Subject: bug in scanf under 4.0 The following program, when run under sun OS4.0, returns an incorrect value at EOF: main () { int stat; char x; /* loop until EOF? */ while ((stat = scanf ("%c", &x)) > 0) printf ("got: %c (%d)\n", x, stat); printf("terminated with: %d at EOF\n", stat); } At EOF the function scanf returns 0. The man page states "The constant EOF is returned upon end of input. Note: this is different from 0, which means that no conversion was done ..." Matt Rosing (rosing@boulder.colorado.edu ...hao!boulder!rosing ) ------------------------------ Date: Mon, 3 Oct 88 15:27:26 CDT From: reeder@emx.utexas.edu (William P. Reeder) Subject: sun!sunbugs vs sun!hotline I have seen others talking about sending bug reports to <sun!hotline>, but the docs I have from Sun say to send to <sun!sunbugs>. What's the difference? [[ I think that they recently (well, semi-recently) switched the customer service address from "sunbugs" to "hotline". I think that "sunbugs" is currently a black hole. --wnl ]] -- William "Wills" Reeder reeder@emx.utexas.edu, ..!uunet!cs.utexas.edu!ut-emx!reeder ------------------------------ Date: 3 Oct 88 18:04:28 GMT From: enea!front.se!per@uunet.uu.net (Per Lindberg) Subject: Popping up an independent window in SunView I want to write a function that pops up a window in SunView. a. The window should be "live", i.e. buttons and other notifier-based gadgets should work. b. The window should be non-blocking, i.e. the rest of the window system should not be "frozen" while this window is up and alive. c. The function should return when the window is destroyed. d. The function should work. Always. Regardless of any previous calls to SunView. Regardless if the program has a window up on the screen or not. Even if the program is inside a notifier event handler. (A possible exception might be window_loop(), which I understand locks the entire window system). Such a function would be useful for many things, e.g. at a bug halt. Some speculations. I may be wrong, I might have missed something in the manual; I really hope so. At this point, however, I have given up. 1. It is always possible to pop up a *blocking* window with window_loop(), but that freezes the rest of the window system, and I don't want that. 2. I can't just call window_main_loop(), because if the program already has called window_main_loop() the notifier will barf with "Invalid argument" (whatever that means). 3. Is there a method to get a pointer to the program's top frame (or NULL if there isn't any)? I could use that to incorporate my frame in the program's tree of frames. However, if the program already is executing inside a notify event handler (very likely), noting will happen until that event handler returns. (not likely). Any ideas? Proving this impossible is also a big help, of course. -- Per Lindberg (certified mad programmer) ------------------------------ Date: Mon, 3 Oct 88 14:53:48 EDT From: khai%amara.uucp@umix.cc.umich.edu (S. Khai Mong) Subject: DNI Protocol Error question We have installed Sunlink DNI software on our SUN machine. Very frequently, we get "protocol errors" when the dnalogin program is used to open a terminal session on VMS. A specific place where it happens is in the following situation: o I login to the SUN through a TTY port/modem from my computer at home. o I open a dnalogin session to a VMS host. o I run kermit, and request a file from VMS to my home computer. dnalogin crashes at the end of the file transfer with a message about protocol error. Does anybody have idea of what's happening and how it can be fixed? ------------------------------ Date: Mon, 3 Oct 88 15:22:03 EDT From: Alexander Dupuy <dupuy@columbia.edu> Subject: bad user stack message [Roy Smith asks what might cause a sendsig kernel message] The most common cause of this message is an infinite recursive loop in a program running out of stack space. The stack pointer is decremented, and the first attempt to reference the top of the stack generates a SIGSEGV, since the page is not accessible. Of course, since the stack can't be grown any more, the kernel's attempt to invoke the SEGV signal handler for the process fails with the message you saw. If the process had no SEGV handler, you would just get a core dump. Of course, it could also occur if the stack pointer had a random value. @alex ------------------------------ Date: Mon, 3 Oct 88 10:01:21 MDT From: liz@cgdra.ucar.edu (Liz Coolbaugh) Subject: Problems with 3.5 and NFS? I recently upgraded my Sun 3/280 to 3.5 and immediately started getting the following problems on my clients: syslog: cannot open /etc/syslog.conf (errno 13) cannot open /etc/syslog.conf (errno 13) NFS write error 13 on host cgdra NFS write error 13 on host cgdra NFS write error 13 on host cgdra NFS write error 13 on host cgdra I sent a message to hotline@sun and two days later got the following response: >errno 13 is EACCES (permission denied). It looks like what is happening is >that cgdra is defined as loghost (the machine where all syslog information >is sent), and the permissions on /etc/syslog.conf are not correct. Try >changing the permissions on syslog.conf to 666 and see if the problems >still persist. Changing the permissions on /etc/syslog.conf changed the message to: syslog: cannot open /usr/spool/log/syslog (errno 13) . . . So ... I changed the permissions on all the applicable files, /etc/syslog.conf, /use/spool/log/syslog and, for good measure, /usr/spool/log. Now I receive no mention of a specific file, but the "NFS write error 13" messages continue to appear. I sent this information back to the hotline but have not received any response. In any case, I'm not happy about "fixing" a problem by making those directories write accessible to the world! Has anyone seen this problem under 3.5? Have any clues to what could be causing the problem? Any information or help will be appreciated. p.s. The response time from Sun is currently horrible. I was ready to accept a day to day and a half slowdown which they mentioned last week because my problems were not critical. They told me that software services is "swamped". But my response time from hotline@sun has been at least a two day turnaround, while it has been four working days since I logged a call via 1-800-USA-4SUN and I still have not received a call from Sun! Does anyone have an idea why Software Services is so bogged down? Too few people for an expanding company? Too many people putting up a very buggy 4.0? Some combination? Whatever the reason, I hope it clears up soon or Sun's reputation for reasonable support will be totally lost. Liz Coolbaugh National Center for Atmospheric Research (303) 497 1327 liz@cgdra.ucar.edu ..ncar!cgdra!liz ------------------------------ End of SUN-Spots Digest ***********************