Number: 183

Date: 19-Mar-84 16':38':24

Submitter: Sannella.PA

Source: MASINTER.PA

Subject: History #s wrong when multiple processes

Assigned To: 

Attn: Masinter.pa

Status: Open

In/By: 

Problem Type: Bug

Impact: Annoying

Difficulty: 

Frequency: Intermittent

Priority: Perhaps

System: Programming Environment

Subsystem: History

Machine: 

Disk: 

Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["Masinter" "21-Aug-84 14':18':10" Description':]'
["Sannella.PA" "28-Aug-84 09':51':30" Description':]

Description: '
Date': 18 MAR 84 17':40 PST'
From': MASINTER.PA'
Subject': Please enter AR': PROMPT#FLG yields confusing display when multiple processes have history events or under break'
To':   LispSupport'
'
In the normal typin window, you can get a prompt of the form'
'
16←'
'
meaning that it is waiting for event 16. If another process breaks or otherwise goes thru LISPX, you get another prompt for the same event, e.g.'
'
16':'
'
If you do something in that other process (which can be spawned by something as simple as a mouse-click), and then go back to the executive window, you will still see the prompt for'
'
16←'
'
sitting there when in fact the event will be assigned a later number.'
'
In brief': the event number is printed before the event, but doesn''t actually get used up until after the event.'
'
This wasn''t a problem when there was a single typeout stream for event prompts. It is less an artifact of multiple processes than it is of multiple windows.'
'
Bug, Annoying, Possibly, Intermittent.'
'
-----'
'
Date': 12 AUG 84 23':17 PDT'
From': MASINTER.PA'
Subject': prompt#flg and processes'
To':   lispcore↑'
'
I''m soliciting ideas for how to resolve the prompt# dilemma (dispair not accepted)':'
'
the prompt# on a line is printed, and the process sits and waits for input.'
The user then bugs something in another window, which causes a break to pop up, using the same prompt #. When you get back to the first window, the prompt# shows one value, but the event is in fact another event number. I''m not explaining this too well, but you''ve all seen it, I''m sure.'
'
Possible solutions':'
'
a) turn off history -- "it doesn''t work"'
b) turn off prompt numbers '
'
c) somehow fix TTYIN to print the prompt numbers AFTER the event has been enterd into the history list'
'
d) give each process a separate history list'
'
e) make the prompt#s history relative, p1.1 p1.2 p1.3 '
'
f) document it as a "feature"'
'
'
'
your suggestions solicited.'
'
(reply-to': Masinter )'
'
Larry'
'
-----'
'
Date': 12 Aug 84 23':35 PDT'
From': acuff.pa'
Subject': Re': prompt#flg and processes'
In-reply-to': MASINTER.PA''s message of 12 AUG 84 23':17 PDT'
To': MASINTER.PA'
'
   How about fixing the TTY.ENTRYFN of processes that are doing this sort of "shared history" to reprint the prompt #?  The hard part would be making this co-exist with TTYIN, I imagine, since there might be problems of changing how many digits are displayed, but that can probably be solved.'
'
	-- Rich'
'
-----'
'
Date': 12 Aug 84 23':43 PDT'
From': Roach.pa'
Subject': Re': prompt#flg and processes'
In-reply-to': MASINTER.PA''s message of 12 AUG 84 23':17 PDT'
To': MASINTER.PA'
'
     I could go for (d) & (e).  You could consider a prompt# to be allocated even it''s associated event has not completed.  You could break in event 14, do events 15-18 (rather than 14-17) in your break window, then finish 14.  Then REDO 14 would redo the right event.'
'
'


Workaround: 

Test Case: 

Edit-By: Sannella.PA

Edit-Date: 28-Aug-84 09':51':30