carlson@betelgeuse (Richard L. Carlson) (02/16/89)
In article <752@pccuts.pcc.amdahl.com> acs@pccuts.pcc.amdahl.com (Tony Sumrall) writes: >In article <9812@pasteur.Berkeley.EDU> carlson@ernie.Berkeley.EDU (Richard L. Carlson) writes: >> [stuff about VT100 not responding when getting lots of serial input] > >Well, I looked through the source for 2.8, 2.8A and the unreleased 2.9 and >can't find anything that could be considered to cause this problem. The >main loop is in vt100.c and processes at most two messages from the serial >port before checking for RAWKEY or MENU input. Yep. You're absolutely right. >What makes you say that it ignores input? Can you change any of your >settings via the menus? If so then VT100 is getting and processing input >from the keyboard. > >Tony Sumrall acs@pccuts.pcc.amdahl.com <=> amdahl!pccuts!acs No, Amiga-M and Amiga-N wouldn't do anything. Moving the mouse wouldn't move the mouse pointer. Ejecting and re-inserting a disk wouldn't cause DOS to examine it. (Until the serial input paused.) But note the past tense in the above paragraph. You guessed it; I can't duplicate the problem now. VT100 dutifully accepts and passes on any user input even in the midst of heavy data transfer. My only guess is that a memory bit somewhere lost a fight with an alpha particle, and caused my system to go just a bit goofy. I was doing no software development work, so I had no need to reboot for a week or two; now, having rebooted seems to have eliminated the problem. I guess there *are* some drawbacks to having system (and PD) software stable enough to run for days at a time without crashing :-). Also, I use dmouse. In retrospect, it seems probable that the goofiness had to do with, for example, the input handler getting set to such a low priority that user input never even got to VT100 while the system had other things to do. Oh well; I guess I'll never really know... >}Now, I found the source to VT100v2.8a, and I would try to find and squash >}this problem myself, except for one thing. I have Lattice 5.0, and when >}I compile VT100v2.8a, the compilation succeeds (no errors; just a few >}harmless-looking warnings) but the executable gurus immediately when it >}is started up (Guru #3 or #4, I think). This one's just as embarrassing. It turns out that I accidentally included "c.o" in BLINK's library list instead of the object file list. Moving it to the right place made the executable work just fine. This does bring up some corollary questions, however: - Why did BLINK generate incorrect code instead of producing an error message when I had c.o in the wrong place on BLINK's command line? - Why did CPR (the symbolic debugger) also guru during start-up when I tried to debug the erroneous VT100 executable? - (Although this doesn't relate to my problems, it does relate to another poster's problems in compiling v2.6) Wouldn't it be nice to have a BLINK option that would print warnings about any function names that are multiply defined? Sure, you don't want this to be the default, 'cause you often want to replace library functions; but this would be an invaluable aid for finding name conflict problems. Anyway, VT100 seems to work perfectly; my apologies for saying otherwise. And a hearty thank you to Dave, Tony, and all the others responsible for bringing us such a useful program. -- Richard {tektronix,dual,sun,decvax,...}!ucbvax!ernie!carlson carlson@ernie.berkeley.edu