RWMIRA01@ULKYVX.BITNET (Rob Miracle) (03/22/88)
I must support the MACRO author for three main reasons.
1) The requestor asked for a single character input for VMS, no other operating
system. MACRO-32 is available on EVERY VMS system. The MACRO routine can
be used everywhere.
2) The BASIC INKEY function is horridly slow (as is the rest of VAX-11 BASIC.
It is also a new function to BASIC 4.2 (I beleive). Sites with an earlier
version do not have that luxury.
3) The screen management facilities are also a little annoying to use because
a) the perform the same parsing as INKEY and
b) you have to define a virtual keyboard to use SMG$READ_KEYSTROKE.
From my experience as a System Programmer on a VMS system prior to my current
job of being a computer bozo, I found a small MACRO routine is far easier to
comprehend than SMG.
There are some problems with the MACRO procedure. First is a problem inherent
to VAX-Pascal. VAX-Pascal buffers its output until a READ, CLOSE, exit function
is called or the buffer fills up. I am not sure how the author got his routine
to work with Pascal because it should not have. I only glanced at the code for
a bit, but SYS$QIO does not normally flush the output buffer. I will get the
routine and test it. It might be a simple case of adding the prompt carrige
control to the call to QIO.
The second thing is that while it conforms to VMS calling standards, the
routing may have been better implemented as a function, not as a procedure.
This may be nit picky, but if you declare it as a procedure, then you can not
test the result of the routine so there is no need to return stuff via R0.
In my version of get key, I return the numeric value of the key input since
I dont have to worry about things and I can use it in a function like:
'C' 'Pascal'
switch(getkey()) if getkey = 27 THEN ...
{
.
.
.
}
By the way, the entire function is implemeted with VMS system services which
can be called from any language. Here is a quick kludge in 'C' (I know, it
isnt Pascal, but I dont have a Pascal version on hand at the moment)
#include <descrip.h>
#include <iodef.h>
#include <ssdef.h>
int getkey()
{
unsigned int Status;
unsigned short Key_Channel;
char buf;
$DESCRIPTOR(Device_Name,"TT:");
Status = SYS$Assign(&Device_Name,
&Key_Channel,
0, 0);
Status = SYS$QIOW(0,
Key_Channel,
IO$_READVBLK | IO$M_NOECHO | IO$M_NOFILTR,
0,
0, 0,
&buf,
1,
0, 0, 0, 0);
Status = SYS$DASSGN(Key_Channel);
return(buf);
}
This version while it continuousily reassinges the terminal uses the logical
name TT instead of SYS$INPUT so the user can use it in a command file without
having to define sys$input to be sys$command.
This should wet the appetite for those not interested in MACRO.
+-------------------------+---------------------------------------------------+
|Rob Miracle | Bitnet : RWMIRA01@ULKYVX or RWMIRA01@ULKYVM |
|Programmer/Analyst-II | CompuServe: 74216,3134 |
|University of Louisville | GEnie Mail: MIRACLERW |
+-------------------------+ UUCP : ...psuvax1!ulkyvx.bitnet!rwmira01 |
|"I'm so good, I dont need| INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu|
|an ego." -- Anton Devious| : |
+-------------------------+---------------------------------------------------+mithomas@bsu-cs.UUCP (Michael Thomas Niehaus) (03/23/88)
In article <8803220235.AA25151@jade.berkeley.edu>, RWMIRA01@ULKYVX.BITNET (Rob Miracle) writes: > 2) The BASIC INKEY function is horridly slow (as is the rest of VAX-11 BASIC. > It is also a new function to BASIC 4.2 (I beleive). Sites with an earlier > version do not have that luxury. First, who cares if the function is slow. The use for such a function should be something like getting a menu choice or some other interactive, simple application. It would not be suitable to, say, write an editor in Pascal. A half second doesn't really matter. Would you cease to use a terminal because it didn't couldn't write a screen of output in a second because it was too slow? > 3) The screen management facilities are also a little annoying to use because > a) the perform the same parsing as INKEY and What if you want parsing? Most people do not like to work with escape codes and the such. > b) you have to define a virtual keyboard to use SMG$READ_KEYSTROKE. > From my experience as a System Programmer on a VMS system prior to my current > job of being a computer bozo, I found a small MACRO routine is far easier to > comprehend than SMG. I whole-hearted agree that MACRO is much easier to implement than SMG. But you are a systems programmer, so you are biased to MACRO. Although I too personally hate SMG routines... [C program deleted] > This should wet the appetite for those not interested in MACRO. Amen. > |Rob Miracle | Bitnet : RWMIRA01@ULKYVX or RWMIRA01@ULKYVM > |Programmer/Analyst-II | CompuServe: 74216,3134 > |University of Louisville | GEnie Mail: MIRACLERW Michael Niehaus Ball State University UUCP: ..{uunet,pur-ee,iuvax}!bsu-cs!mithomas
mhg@mitre-bedford.arpa (Mark H. Granoff) (03/23/88)
>... >2) The BASIC INKEY function is horridly slow (as is the rest of VAX-11 BASIC. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > It is also a new function to BASIC 4.2 (I beleive). Sites with an earlier > version do not have that luxury. >... *FLAME ON* I feel compelled to take offense at this statement. I do not think that VAX BASIC can be lumped in and judged together with other BASIC compilers for other machines. One of the beauties of VAX/VMS is its ability to execute code generated from any source langauge. For all intents and purposes, all source code (regardless of language) is compiled down to the same machine code. (For just about every compiler, you can specify /MACHINE on the command line which generates a file containing the MACRO-32 code for the higher level code). VAX BASIC happens to be a *very* versatile and robust language, as powerful as any other language on a VAX. While it can't do *everything* that every other language can do (e.g. true linked lists), it is not "BASIC" in the *old* sense of the language. The fact that the INKEY function you refer to is "horridly slow" is not the fault of the VAX or the VAX BASIC compiler, but of the source code. If you write bad/slow source code, you get bad/slow/(worse) machine code. It suffices to say that I am suitably pissed off at your arrogance. Before you make a broad, sweeping statement like "VAX-11 BASIC is horridly slow," check your facts. *FLAME OFF* Thank you. Mark H. Granoff Member of the Technical Staff VMS Systems The MITRE Corporation mhg@mitre-bedford.ARPA