hedrick@geneva.rutgers.edu (Charles Hedrick) (11/10/88)
I've been using the new psterm from the Grasshopper group since about
5 minutes after we got the posting. (I was desperate for a reasonable
terminal emulator.) I appreciate the work, and I'm generally very
pleased with the way it works. However I've got a few problems, and
I'm curious whether anybody knows what's going on.
First, it feels slow. I'm not all that concerned about how long NeWS
takes to do complex operations. However when I type I'm very
sensitive to echo delay. The old psterm and Gnu Emacs with NeWS
support don't cause me any trouble, but the new psterm causes just
enough echo delay to be annoying.
Second, I have trouble exiting. With the old psterm, and all other
NeWS programs, when I kill the program, the window goes away. With
the new psterm, I can't get rid of the window. Neither exiting from
the shell inside it, doing "zap" in the menu, nor killing the process
helps. I can make "zap" work by modifying psterm.ps, but I still
can't make it go away if I exit from the shell. The modification
to make zap work is to add the two lines with /Mapped false below:
/destroy {
/Scrollbar null def
IconCanvas /Mapped false put
FrameCanvas /Mapped false put
/destroy super send
} def
Finally, if I try it with retained windows disabled, results are a bit
odd. As long as the window is on top, things work fine. But if it's
occluded, I tend to have whole lines of text missing.sjs@jcricket.ctt.bellcore.com (Stan Switzer) (11/10/88)
hedrick@geneva.rutgers.edu (Charles Hedrick) writes: > First, it feels slow. I'm not all that concerned about how long NeWS > takes to do complex operations. However when I type I'm very > sensitive to echo delay. The old psterm and Gnu Emacs with NeWS > support don't cause me any trouble, but the new psterm causes just > enough echo delay to be annoying. I don't exactly like to look a gift horse in the mouth, but I'd have to agree. Don't take this too hard Grasshopper, but the extended psterm isn't really any closer to "production quality" than the original was. True, the new features are nifty, but it's still rough around the edges. > .... I can make "zap" work by modifying psterm.ps, but I still > can't make it go away if I exit from the shell. The modification > to make zap work is to add the two lines with /Mapped false below: > /destroy { > /Scrollbar null def > IconCanvas /Mapped false put > FrameCanvas /Mapped false put > /destroy super send > } def I STRONGLY recommend against this. It cures the symptom but not the disease. If the canvas stays visible it is because some reference remains, and if, as you said later, the canvas is retained, then there is a good bit of memory tied up in that canvas--especially in color. Unless you actually lose every reference, you are just hiding a massive memory leakage. Probably there is a reference loop among the dictionaries used in the program. I'd whip out Don's Hopkins' amazing "Pseudo-Scientific Visualizer" (the class browser for the other half of your brain) to debug this one if I were you. But I'm not -- I have other fish to fry. Oh, and while I'm at it, here's one more person who'd LOVE to have someone from Adobe post a technical summary of the new features in Display Postscript. I mean, unless you post some actual information, you are just as bad as the Eiffel partisans sniping in the C++ newsgroup. (Too bad, too, Eiffel is a decent language, though you'd never know it from the postings.) You guys at Adobe do good work -- let us in on it. Stan Switzer sjs@ctt.bellcore.com "A verb, Senator Kennedy, we need a verb!"
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (11/11/88)
In article <Nov.9.21.34.45.1988.2890@geneva.rutgers.edu>, hedrick@geneva.rutgers.edu (Charles Hedrick) writes: > [...] > First, it feels slow. I'm not all that concerned about how long NeWS > takes to do complex operations. However when I type I'm very > sensitive to echo delay. The old psterm and Gnu Emacs with NeWS > support don't cause me any trouble, but the new psterm causes just > enough echo delay to be annoying. Depending on what you're doing, this my be partially due to the "fast repaint" junk which stores up screen changes and does them all at once when they come in to fast. Mabee emacs is writing a whole bunch of characters for every one you type in, and psterm is waiting for the stream to finish. Try turning fast repaint off from the Config...Toggles...Fast Repaint menu selection. I haven't had any trouble with this, but who knows... > Second, I have trouble exiting. With the old psterm, and all other > NeWS programs, when I kill the program, the window goes away. With > the new psterm, I can't get rid of the window. Neither exiting from > the shell inside it, doing "zap" in the menu, nor killing the process Hmm, I haven't had this problem at all, although I've heard of such problems under both the old psterm and under nterm. What flavor of NeWS are you running? We're under 1.1. Other bugs that we've fixed around here are the ignoring of command line font size requests, and the reversing of x and y when giving coordinates on the command line. We've also implemented color cursors so you can see where the cursor is when the terminal is displaying reverse video. These fixes will probably be posted/sent to Grasshopper in the near future (once we're convinced it's all stable). -- Christopher J. Calabrese AT&T Bell Laboratories att!ulysses!cjc cjc@ulysses.att.com
ajk@goanna.oz (Alan Kent) (11/14/88)
I have had problems with its screen redrawing. If I get a full page of output before it starts to draw it, it seems to just not bother doing any output. Quite often I do a ls -l but all I get out is the next prompt, or a few lines of output if I am lucky. I only have 4megs on a Sun 3/60 (and NeWS 1.1) so NeWS runs pretty slow (it pages to death). When I rlogin to a faster machine its quite easy to get large backlogs in output. vi on the remote machines also messes up quite frequently (probably due to same reason). I have not tried toggling the fast-redraw option yet, but it would be better if psterm worked properly in the first place. Overall it looks good, but still a little buggy. Alan Kent Dept. of Comp. Sci, RMIT, ACSnet: ajk@goanna.cs.rmit.oz.au GPO BOX 2476 V, ARPA: ajk%goanna.cs.rmit.oz.au@uunet.uu.net Melbourne, 3001 CSNET: ajk%goanna.cs.rmit.oz.au@australia AUSTRALIA UUCP: ...!uunet!goanna.cs.rmit.oz.au!ajk
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (11/16/88)
In article <1773@goanna.oz>, ajk@goanna.oz (Alan Kent) writes: | I have had problems with its screen redrawing. If I get a full page of | output before it starts to draw it, it seems to just not bother doing | any output. Quite often I do a ls -l but all I get out is the next | prompt, or a few lines of output if I am lucky. I only have 4megs on a | Sun 3/60 (and NeWS 1.1) so NeWS runs pretty slow (it pages to death). | When I rlogin to a faster machine its quite easy to get large backlogs | in output. vi on the remote machines also messes up quite frequently | (probably due to same reason). I have not tried toggling the | fast-redraw option yet, but it would be better if psterm worked properly | in the first place. The problem your're having is definitely with the fast-redraw algorithm. We've found that the fast-redraw works really well when you receive a very large ammount of input very quickly (like 'cat /etc/termcap'). In these instances it simply draws random gargabe until things have died down, then it correctly draws the last screen. When things come in slow enough to have it trip in and out of the fast repaint mode, you have problems such as not drawing all the input, leaving copies of the cursor around the screen, etc. -- Christopher J. Calabrese AT&T Bell Laboratories att!ulysses!cjc cjc@ulysses.att.com
spock@ihlpf.ATT.COM (Weiss) (04/06/89)
I had to give up on playing with NeWS for a while, and so I was just saving sources off the net. Now I discover that I don't have all of the Grasshopper psterm. Can someone send it to me? Can I have all the patches also? -- Ed Weiss "I thought it was generally accepted, sir, that att!ihlpf!spock vulcans are an advanced and most honorable race." "They are, they are. And damn annoying at times."