ESCAPE processing in YottaDB I/O

[Kevin Toppenberg]

I have run into another issue with yottadb IO, when ESCAPE option is enabled.

In the GUI world, when navigating menus of an application, typically UP/Down/Left/Right will move the selection around, ENTER will cause an action of the selected item, and ESCAPE will cause the menu to close.

In YottaDB, enabling escape processing, e.g. USE $P:ESCAPE, will cause yottadb to read the entire escape sequence and return it to the user in $ZB.  This is a very nice feature.  The only problem is that if the user types just ESCAPE, then any IO read hangs until some additional input is provided to satisfy the escape-sequence reader.   And then the user's intended ESC is lost. 

This is a problem because to provide the same interface in menus found in GUIs, as described above, the user should be able to enter both arrow keys, which are communicated from the terminal program to yottadb io as escape sequences, AND also to be able to enter an isolated ESC key.

As I have been poking around the IO code in yottadb, I have discovered why yottadb hangs after an isolated ESC, and i think I have a relatively straightforward fix.  The code that reads the expected full escape sequence does not have any timeout ability built in.  It should be fairly easy to add this.  If the terminal sends an escape sequence (say, for transmitting an UP key), then there shouldn't be any delay between the starting ESC and the rest of the sequence.  Thus if one just adds a timeout, then problem solved.

Can anyone see any problems with this approach?  I.e. any unintended consequences on other programs?

Kevin

[Maury Pepper]

What you are proposing is exactly what I have found with other MUMPS implementations. The timer needs to be device dependent e.g. for serial lines, it must allow at least one character time plus a pinch for interrupt overhead. This is a simple calculation and the time in msec could be stored in a device table.

--
You received this message because you are subscribed to the Google Groups "Everything MUMPS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to everythingmum...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/everythingmumps/b19fd8c2-e40d-4cf6-86d9-085f42743ee9n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Toppenberg]

On Friday, January 3, 2025 at 12:44:59 AM UTC-5 Maury Pepper wrote:

What you are proposing is exactly what I have found with other MUMPS implementations.

Thank you Maury for looking into this. 

Are you saying that because this same issue is present in other MUMPS implementations, that it should be left alone?  Or that everyone has the same issue and everyone ought to fix it?

 

The timer needs to be device dependent e.g. for serial lines, it must allow at least one character time plus a pinch for interrupt overhead. This is a simple calculation and the time in msec could be stored in a device table.

Consider this code:

USE $P:ESCAPE READ *X W !,X,! ZWR $ZB

vs

USE $P:ESCAPE READ *X:0.1 W !,X,! ZWR $ZB

In the first code, because a timeout value is not specified, yottadb provides a timeout value that is large.  In this case, I think the timeout value would need to be shortened.  100 ms should be sufficient in my estimation for any modern serial line.  300 baud is roughly 30 chars/sec or 33 ms/char.

In the second case, a timeout of 100 ms is specified, and that should be sufficient.  If the user had specified *X:0.01, then I think it is on them as to whether that would exceed the communication abilities.  

Kevin 

[Maury Pepper]

To your first question: Neither. I'm saying that on some others they do recognize the difference between an escape sequence and a solitary escape. It seemed clear to me that there was some sort of timing being used.

Regarding your use case of a starred, un-timed read vs. a starred, timed read:
  - A star read is, to best of my knowledge, a raw read and a single character read so one should not expect any escape sequence processing.
  - AFAIK, an un-timed read will never time out. I'm surprised that yottadb "provides a timeout value that is large."
  - The "other" MUMPS implementations followed the standard and only allowed whole second timing so sub-second timeouts were not an issue.
  - The wait time to see if an escape is followed by a legit escape sequence must be dependent on the particular device, its baud rate (if any) and other overhead factors. An example of what can cause headaches: some terminals can be programmed to not exceed a given character rate. (i.e., there may be time added between characters. The reasons for this will be covered next semester. ;-)  )  Another example: Telnet packets splitting up an escape sequence.

To view this discussion visit https://groups.google.com/d/msgid/everythingmumps/f4d82fd6-9d91-49b6-9e96-8f56d8c3ff91n%40googlegroups.com.

[Kevin Toppenberg]

See below

On Monday, January 6, 2025 at 12:18:06 PM UTC-5 Maury Pepper wrote:

To your first question: Neither. I'm saying that on some others they do recognize the difference between an escape sequence and a solitary escape. It seemed clear to me that there was some sort of timing being used.

Regarding your use case of a starred, un-timed read vs. a starred, timed read:
  - A star read is, to best of my knowledge, a raw read and a single character read so one should not expect any escape sequence processing.

As far as I can tell, if ESCAPE mode is enabled, then *X will read 1 character (27, ESCAPE), but it will also put the rest of the escape sequence in $ZB

 

  - AFAIK, an un-timed read will never time out. I'm surprised that yottadb "provides a timeout value that is large."

I went back and looked at the code.  If no timeout it provided, it sets the wait time to 100 seconds. This is the value passed to a c-code select() function.  But if the user doesn't return a value within that time, the code loops back to call select() and wait again.  So from the user's point of view, it would actually never time out.  I misspoke before.

 

  - The "other" MUMPS implementations followed the standard and only allowed whole second timing so sub-second timeouts were not an issue.

 

  - The wait time to see if an escape is followed by a legit escape sequence must be dependent on the particular device, its baud rate (if any) and other overhead factors. An example of what can cause headaches: some terminals can be programmed to not exceed a given character rate. (i.e., there may be time added between characters. The reasons for this will be covered next semester. ;-)  )  Another example: Telnet packets splitting up an escape sequence.

If this was attempted, then yottadb itself would have to know about the device timing factors. That would require a large library of values for every different device.  I wouldn't know how to go about that. 

Kevin