bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-apl] Seeking clues regarding quote-quad prompt


From: David B. Lamkins
Subject: [Bug-apl] Seeking clues regarding quote-quad prompt
Date: Sat, 23 Aug 2014 22:12:39 -0700

Back on the subject of aplwrap integration:

I'm seeing a GNU APL behavior that I don't understand, and would
appreciate some hints on where to look. I don't necessarily consider the
following behavior to be buggy, I just want to be able to figure out how
and why it's happening so I can dig into the code.

Quick background: aplwrap spawns GNU APL with pipes for stdin, stdout
and stderr. Pretty much everything works as expected, except for some
puzzling behavior w.r.t. a ⍞ prompt followed by a ⍞ input.

What I'm seeing (by dumping stdout and stderr) is that the prompt is
showing up on both stdout and stderr.

>From what I've been able to read so far, I think this is how it happens:

With --rawCIN, get_user_line() calls no_readline() with the prompt text.
no_readline() then ungetc()s the entire prompt so it'll be available for
⍞ input.

I think that aplwrap must see the pushed-back prompt and echo it to
stdout. That's fine. I can deal with that.

But then almost the same prompt appears on stderr. I can't figure out
how that happens. I say "almost the same" because the prompt text on
stderr may have pad characters in place of blanks, assuming that the
prompt used a nested vector. For that reason, I'm convinced that aplwrap
isn't somehow involved; the stderr prompt must from GNU APL.

What I can't understand is how the ⍞ prompt *ever* shows up on stderr.
>From what I've read, it looks like the prompt always goes to COUT.

Clues will be much appreciated...





reply via email to

[Prev in Thread] Current Thread [Next in Thread]