STEIN@UCONNVM.BITNET (Alan Stein) (01/13/90)
How does one read a single key from the keyboard in Orca/Pascal? I tried the following: var c:char; read(c); but nothing happened until the return key was pressed. I want the program to wait until the <esc> key is pressed. I just received the most recent upgrade for Orca/Pascal and am finding it very flaky, especially the desktop. I wrote a very short (@20 line) program that refused to go through the second link pass under the desktop, but goes through without incident under the shell. Is anyone else having that sort of problem? Alan H. Stein | stein@uconnvm.bitnet Department of Mathematics | University of Connecticut | Compu$erve 71545,1500 32 Hillside Avenue | GEnie ah.stein Waterbury, CT 06710 | SNET (203) 757-1231
n8948315@unicorn.WWU.EDU (arthur morgan) (01/14/90)
In my experience with Pascal and Modula-2 (the son of pascal), I have found the following to be true. Whenever you do a read operation, whether it be a Read, ReadString, ReadInt, ReadReal, or whatever; the input all goes into an input buffer, and a return charaacter is required in order to tell the com- puter that the input operation is finished, and you are ready to have the computer do whatever it is supposed to do with the data. For this reason, when you do that 'Read(c);' with c being a variable of type CHAR, you MUST enter a return character in order to terminate the input operation and send the computer on to execute its next instruction. I hope this makes sense. :-)
anarch@eleazar.dartmouth.edu (The Anarch) (01/14/90)
In article <421@unicorn.WWU.EDU> n8948315@unicorn.WWU.EDU (arthur morgan) writes: >In my experience with Pascal and Modula-2 (the son of pascal), I have found >the following to be true. Whenever you do a read operation, whether it be a >Read, ReadString, ReadInt, ReadReal, or whatever; the input all goes into an >input buffer, and a return charaacter is required in order to tell the com- >puter that the input operation is finished, and you are ready to have the >computer do whatever it is supposed to do with the data. For this reason, >when you do that 'Read(c);' with c being a variable of type CHAR, you MUST >enter a return character in order to terminate the input operation and send >the computer on to execute its next instruction. I hope this makes sense. :-) This is indeed the case, but it is possible to get character by character input in Pascal using the 'get' command. This command reads in the character in the file window and advances the file window one space. Since keyboard input is just a file to Pascal, like stdin to C, this command will read a single typed character. -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-anarch@dartmouth.edu+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thy hand, great Anarch! lets the curtain fall, And universal darkness buries all. D I S C L A I M E R : E V E R Y T H I N G I W R I T E I S F A L S E
stowekeller@pro-carolina.cts.com (Stowe Keller) (01/15/90)
Re: STEIN@UCONNVM.BITNET (Alan Stein), Subject: Orca/Pascal Question > I just received the most recent upgrade for Orca/Pascal and am > finding it very flaky, especially the desktop. I wrote a very short > (@20 line) program that refused to go through the second link pass > under the desktop, but goes through without incident under the > shell. Is anyone else having that sort of problem? Yes, unfortunately, the Prizm desktop environment is very buggy, and ByteWorks readily admits this (but unfortunately shows little inclination to fix it anytime soon). Their usual advice is to use the text shell, which I usually prefer to avoid because I like most of Prizm's conceptual design. Another known bug involves using Prizm with debug code generation enabled, and compiling a Pascal program with optimize turned on: you'll often get a generic "Compiler Error" message as a result. Also, if you compile any program under Prizm with debug code generation on and then try to run the executable from the text shell, you are pretty much guaranteed to get a crash since the text shell does not know how to handle the debug code. (I think someone may have written a text shell-based debugger, but I don't know any details yet.) I recall some weird crashes with compiling certain files in the text shell and then trying to execute them under Prizm from the shell window. And other times I've had Prizm crash or hang after long sessions and for no good reason; I should point out, though, that this doesn't happen very often with Pascal, whereas it is far more common with ORCA/C, which is much more buggy (although Mike Westerfield has made tremendous progress fixing the bugs there and will be releasing ORCA/C 1.1 before too long). Other known Pascal problems according to ByteWorks: -avoid use of "byte" variables - ByteWorks recommends using integers instead until they fix the compiler. -"set" variables have problems, but I don't have any details. -The compiler apparently doesn't always catch bad parameters, as when you pass a value instead of a pointer. (Ideally the compiler would catch this as "invalid type" or whatever.) -And when writing CDA's, remember that you are limited to a 256 byte stack, which can easily be exceeded if you pass a lot of parameters and make nested subroutine calls. I, too, just upgraded from ORCA/Pascal 1.2 to 1.2.4 (or release 3 or whatever), and I've run into a strange problem: the ErrorExit and ErrorTrap sample files don't seem to work on my machine when I compile and run them (ie, no errors get trapped), yet the executables which came on the disk DO work as expected. I have no clue what might be wrong with my setup or the upgrade I performed - I've tried changing all kinds of things, making sure the library files are in alphabetical order (as required), removing all NDAs and CDAs except for the control panel, etc, and I still can't get it to work. I'm using GS/OS System 5.0.2, 2.25Meg of RAM, 7MHZ TWGS, Apple SCSI Rev C with Chinook 40Meg hard drive, one 3.5" apple drive. The person I talked to at ByteWorks was not aware of any problems like this and said they couldn't duplicate it. Anyone else run into this? Stowe Keller ------------------------------------------------------------------- Stowe Keller Author of ProDOS8 LIST utility CompuServe: 71540,725 GEnie: SKELLER BIX: stowekeller UUCP: [ sdcsvax nosc ] !crash!pro-carolina!stowekeller ARPA: crash!pro-carolina!stowekeller@nosc.mil INET: stowekeller@pro-carolina.cts.com ------------------------------------------------------------------------ Stowe Keller Author of ProDOS8 LIST utility CompuServe: 71540,725 GEnie: SKELLER BIX: stowekeller UUCP: [ sdcsvax nosc ] !crash!pro-carolina!stowekeller ARPA: crash!pro-carolina!stowekeller@nosc.mil INET: stowekeller@pro-carolina.cts.com
reeder@reed.UUCP (Doug Reeder) (01/17/90)
In article <421@unicorn.WWU.EDU- n8948315@unicorn.WWU.EDU (arthur morgan) writes:
-In my experience with Pascal and Modula-2 (the son of pascal), I have found
-the following to be true. Whenever you do a read operation, whether it be a
-Read, ReadString, ReadInt, ReadReal, or whatever; the input all goes into an
-input buffer, and a return charaacter is required in order to tell the com-
-puter that the input operation is finished, and you are ready to have the
-computer do whatever it is supposed to do with the data. For this reason,
-when you do that 'Read(c);' with c being a variable of type CHAR, you MUST
-enter a return character in order to terminate the input operation and send
-the computer on to execute its next instruction. I hope this makes sense. :-)
This is unfortunately true for many implementations of Pascal, however it is
not a bug of the language itself. The simplest workaround in such a
brain-damaged evironment is to always use readln(), which often is not what
you want to use.
--
Doug Reeder USENET: ...!tektronix!reed!reeder
from ARPA: tektronix!reed!reeder@berkeley.EDU BITNET: reeder@reed.BITNET
the Little Mermaid on materialism:
"I just don't see how a world that makes such wonderful things could be bad."