search

Interlisp / medley

The main repo for the Medley Interlisp project. Wiki, Issues are here. Other repositories include maiko (the VM implementation) and Interlisp.github.io (web site sources)
https://Interlisp.org
MIT License
373 stars 19 forks source link

Corrupted text in TEdit when printing long output to TEXTSTREAM #1697

Open pamoroso opened 5 months ago

pamoroso commented 5 months ago

Describe the bug Suppose you create a TEXTSTREAM and associate it with a new TEdit window. If you print at least several dozen lines of output to the TEXTSTREAM, the text eventually ends up corrupted in the TEdit window.

To Reproduce Steps to reproduce the behavior:

  1. sign into your Interlisp Online account
  2. under Initial Exec, select Interlisp
  3. click Run Medley
  4. evaluate (SETQ TS (OPENTEXTSTREAM))
  5. evaluate (TEDIT TS)
  6. evaluate (FOR I FROM 1 TO 200 DO (PRINTOUT TS "Line no. " I T))

Expected behavior All the text appears in the TEdit window with no corruption or alterations.

Screenshots The TEdit window:

textstream1

The full desktop:

textstream2

Context (please complete the following information):

Additional context Sometimes the text corruption appears when printing only a couple dozen lines of text. The issue occurs also when printing to the TEXTSTREAM from Common Lisp, for example with format.

pamoroso commented 5 months ago

Does OPENTEXTSTREAM require the first argument, i.e. a stream? Can it be omitted?

pamoroso commented 5 months ago

Passing a stream to OPENTEXTSTREAM like this makes no difference as the corrupted text issue still occurs:

(SETQ S (OPENSTREAM '{NODIRCORE} 'BOTH))

(SETQ TS (OPENTEXTSTREAM S))
rmkaplan commented 5 months ago

Thanks for finding this so clearly, I’ve seen this sporadically but haven’t been able to track it down.

It was an order of execution error in an early attempt to speed up the case of appending to the end of a stream. When it was updating the window as well as just updating the text, it was not properly reasserting the file position when the line formatter was trying to determine whether it was running off the bottom of the window.

Appending to a text in an open window is still much to slow. One issue is that the inherited algorithms for formatting and in particular displaying at the end of a stream are proportional to the length of the preceding characters on the line, and maybe even in the paragraph. A substantial speed up for appending would, among other things, make it feasible for TRACE to print to a text stream so that the trace output would be scrollable.

On May 5, 2024, at 8:17 AM, Paolo Amoroso @.***> wrote:

Passing a stream to OPENTEXTSTREAM like this makes no difference as the corrupted text issue still occurs:

(SETQ S (OPENSTREAM '{NODIRCORE} 'BOTH))

(SETQ TS (OPENTEXTSTREAM S)) — Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1697#issuecomment-2094847535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKG5KSXXKVZ4NMLEADZAZEO7AVCNFSM6AAAAABHHUPFB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJUHA2DONJTGU. You are receiving this because you are subscribed to this thread.

pamoroso commented 5 months ago

I noticed the slowness and was indeed wondering. TEDIT.INSERT is much faster and has no corruption issues.

pamoroso commented 5 months ago

Never mind, I'm getting text corruption issues or an error that something is not a file descriptor also when adding text with TEDIT.INSERT, deleting all of the text with (TEDIT.DELETE TS 1 (TEDIT.NCHARS TS)), adding some different text, and deleting everything again with TEDIT.DELETE. I'm trying to reproduce the issue.

rmkaplan commented 5 months ago

Hmm, I tried some simple sequences, both with printing and with editing, and it hasn’t failed. I hope you can find it.

In terms of printing speed, printing and insertion uses the same primitive operation to manipulate the stream structures, that’s fast. The slowness is in the way it deals with the line formatting and display, if you have an associated window.

You should currently see an enormous difference between the sequence

(SETQ TS (OPENTEXTSTREAM)) print your stuff (TEDIT TS big-window)

and

(SETQ TS (OPENTEXTSTREAM)) (TEDIT TS big-window) print your stuff

For your 200 line example (even though it produces garbage after it fills a window high enough to hold 70 lines), TIME shows shows .05 seconds for the first order and 86 seconds for the second. 1700 times slower.

It turned out that for lines below the window the algorithm was not using the formatting infomation for already displayed lines. So it was reformatting everything on every character. (Maybe something I did along the way, can’t blame Venue for everything).

I fixed that: in the next Tedit merge the time for the second case is reduced from 86 seconds to 0.7 seconds, now the display is costing ony a factor of 14.

I’m going to create another issue for discussion about the behavior of BOUT (other than speed) that are still carried forward from Venue:

On May 6, 2024, at 4:48 AM, Paolo Amoroso @.***> wrote:

Never mind, I'm getting text corruption issues or an error that something is not a file descriptor also when adding text with TEDIT.INSERT, deleting all of the text with (TEDIT.DELETE TS 1 (TEDIT.NCHARS TS)), adding some different text, and deleting everything again with TEDIT.DELETE. I'm trying to reproduce the issue.

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1697#issuecomment-2095826221, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJK2R76Q4MPIWUUCET3ZA5UXFAVCNFSM6AAAAABHHUPFB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJVHAZDMMRSGE. You are receiving this because you commented.

pamoroso commented 5 months ago

I managed to trigger the error ARG NOT LINEDESCRIPTOR when calling TEDIT.DELETE (it wasn't about file descriptors, I misremembered). Here's the session:

tedit-delete

rmkaplan commented 5 months ago

Thanks, got it.

It wasn’t the insert, it was in the screen update after deleting everything.

On May 6, 2024, at 12:19 PM, Paolo Amoroso @.***> wrote:

I managed to trigger the error ARG NOT LINEDESCRIPTOR when calling TEDIT.DELETE (it wasn't about file descriptors, I misremembered). Here's the session:

tedit-delete.png (view on web) https://github.com/Interlisp/medley/assets/10342479/7306aa72-2a38-4b57-8862-9a7186abc98e — Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1697#issuecomment-2096735887, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJOTADVSAPXCAEBZHV3ZA7JSVAVCNFSM6AAAAABHHUPFB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWG4ZTKOBYG4. You are receiving this because you commented.