Summary

parley seems to insert the same sexpression to the reader again when getting input while sleeping

Metadata

• Id: d5282ba61784834a60267dba569a2eed7e639645
• Trac id: 1180
• Type: defect
• Reporter: ckeen
• Owner: ckeen
• Cc:
• Status: assigned
• Component: extensions
• Estimated difficulty:
• Resolution:
• Priority: major
• Milestone: someday
• Version: 4.9.x
• Changetime: 2017-10-14 16:59:19 UTC
• Created: 2015-02-17 12:56:53 UTC
• Keywords: parley input type ahead bug

Description

See http://paste.call-cc.org/paste?id=1f10cc1f4285e1b1a4de027bc05a3ae30652121b

Changes and comments

[2017-09-13 20:54:05 UTC] LemonBoy removed difficulty

[2017-09-13 20:54:05 UTC] LemonBoy wrote:

There are a few problems here:

• In `parley` we get a non-false `prev-input` with the contents of the typeahead buffer in it so we have to process every element one by one before reading from the "real" prompt. Now, the `(eof-object? (peek-char in)` condition doesn't make any sense because you want to process `in` until an `#!eof` occurs and then switch to `real-in-port` as soon as the typeahead buffer has been completely processed. The `#<unspecified>` value you see in the trace comes from the other arm of the `if`.
• The use of `object-copy` is dangerous, especially when the `state` record contains references to `port` objects. With the adjustments outlined above I found that parley would crash the csi instance due to heap exhaustion while it was trying to copy such an object.
• `(parley "")` gives an error, this is not really a problem but it could give a better error.

[2017-10-14 16:59:19 UTC] ckeen wrote:

Should be addressed and fixed with commit 9a33e2b971a956ba710c3438b87c4db46b080b84