zsh-workers
 help / color / mirror / code / Atom feed
* Commit 137b15a fails X02zlevi test
@ 2014-02-08 20:13 Bart Schaefer
  2014-02-08 22:45 ` Bart Schaefer
  0 siblings, 1 reply; 14+ messages in thread
From: Bart Schaefer @ 2014-02-08 20:13 UTC (permalink / raw)
  To: zsh-workers

Not sure if this is bad test data or if workers/32342 broke "print -z".

*** /tmp/zsh.ztst.out.9646      Sat Feb  8 11:59:52 2014
--- /tmp/zsh.ztst.tout.9646     Sat Feb  8 11:59:52 2014
***************
*** 1,2 ****
! BUFFER: beforeafterafter
! CURSOR: 15
--- 1,3 ----
! BUFFER: after
! after
! CURSOR: 10
Test ../../zsh-5.0/Test/X02zlevi.ztst failed: output differs from expected as shown above for:
  comptesteval 'print -z before'
  zletest $'after\e.'
Was testing: repeat initial edit with non-blank starting line


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-08 20:13 Commit 137b15a fails X02zlevi test Bart Schaefer
@ 2014-02-08 22:45 ` Bart Schaefer
  2014-02-09 18:53   ` Bart Schaefer
  0 siblings, 1 reply; 14+ messages in thread
From: Bart Schaefer @ 2014-02-08 22:45 UTC (permalink / raw)
  To: zsh-workers

On Feb 8, 12:13pm, Bart Schaefer wrote:
} Subject: Commit 137b15a fails X02zlevi test
}
} Not sure if this is bad test data or if workers/32342 broke "print -z".

OK, it's neither of those.  If I rearrange the tests to put that one
first, it works and the next test that begins with "comptesteval ..."
fails instead.

The problem stems from the same zpty used for all the tests, and there
is something about the "zletest" function that leaves the zpty in a
bad state for a subsequent "comptesteval".  Oddly, two "zletest" calls
in a row do not encounter whatever situation this is.

For some reason, the command that ends "comptesteval", which is

  . /tmp/comptest.$$

is being executed *again* at the beginning of zletest, which produces
an error such as

  .: no such file or directory: /tmp/comptest.16194

I haven't figured out how to tell whether this means the comptest.$$
file is never read, or if it is read but the buffer is being cleared
when that error occurs and therefore is in the wrong state when the
actual test input is executed.

The only obvious difference between "comptesteval" and "zletest" is
that the former uses

  zpty -w zsh ". $tmp"

where the latter uses

  zpty -n -w zsh "$input"$'\C-M'

in which the ^M is supposed to invoke the zle-finish widget.

I note that the zle-finish widget uses "zle send-break" and then tries
to do "zle -R" after it.  That won't work, "zle send-break" causes an
implicit return from the widget in which it is executed.  But it ought
to reset ZLE to viins mode, even without the "zle -K main", so I remain
puzzled why the subsequent comptesteval would fail given that the first
one (before any zletest call) succeeds.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-08 22:45 ` Bart Schaefer
@ 2014-02-09 18:53   ` Bart Schaefer
  2014-02-09 21:00     ` Peter Stephenson
  2014-02-09 22:30     ` Oliver Kiddle
  0 siblings, 2 replies; 14+ messages in thread
From: Bart Schaefer @ 2014-02-09 18:53 UTC (permalink / raw)
  To: zsh-workers

On Feb 8,  2:45pm, Bart Schaefer wrote:
} Subject: Re: Commit 137b15a fails X02zlevi test
}
} The problem stems from the same zpty used for all the tests, and there
} is something about the "zletest" function that leaves the zpty in a
} bad state for a subsequent "comptesteval".  Oddly, two "zletest" calls
} in a row do not encounter whatever situation this is.

I've been repeatedly running

    make check TESTNUM=X02

and have decided that it fails nondeterministically.  Sometimes the
slave side of the zpty is able to read parts of its input twice and
other times it is not.  Every now and then it will go through all
tests succeeding and then on the next attempt a random one of the
tests will fail.  It's never the very first test; most often but not
always, it's the first test among the second or later that begins
with a call to "comptesteval".

I've tried:

 - adding "sleep" at various places to try to resolve race conditions;

 - setting BUFFER="" in zle-finish and making sure "zle -R" is called
   before send-break;

 - changing the key binding of zle-finish (and correspondingly the
   character written by zletest) so that comptesteval can't trip
   zle-finish accidentally on end of line;

 - adding "zle -t -r ..." in various places to be sure all output to
   the pty has been consumed between tests.

None of these resolve it.  The last one produces successful tests more
often, but seems to increase the randomness of which test fails the
rest of the time.  I've run out of ideas ...


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-09 18:53   ` Bart Schaefer
@ 2014-02-09 21:00     ` Peter Stephenson
  2014-02-09 22:30     ` Oliver Kiddle
  1 sibling, 0 replies; 14+ messages in thread
From: Peter Stephenson @ 2014-02-09 21:00 UTC (permalink / raw)
  To: zsh-workers

On Sun, 09 Feb 2014 10:53:43 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> None of these resolve it.  The last one produces successful tests more
> often, but seems to increase the randomness of which test fails the
> rest of the time.  I've run out of ideas ...

Something forking and doing things in slightly different orders to the
zpty in different cases where we need to ensure some top-level cleanup
is the last thing to happen...?

Not very concrete, sorry.

pws


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-09 18:53   ` Bart Schaefer
  2014-02-09 21:00     ` Peter Stephenson
@ 2014-02-09 22:30     ` Oliver Kiddle
  2014-02-11  7:37       ` Bart Schaefer
  1 sibling, 1 reply; 14+ messages in thread
From: Oliver Kiddle @ 2014-02-09 22:30 UTC (permalink / raw)
  To: zsh-workers

Bart wrote:
> I've been repeatedly running
> 
>     make check TESTNUM=X02
> 
> and have decided that it fails nondeterministically.  Sometimes the

On my desktop it never seems to fail. I just tried on my NAS box and
it appears to reliably fail there. I don't think the send-break is an
issue because the combination of kill-buffer and accept-line also
exhibit the problem. For the test to be relevant, it needed a new line.

The problem seems somewhat similar to the problems I have with Felix's
incremental search tests except that is failing more consistently for
me. I've attached my modified patch for them in case it provides you
with any clues. They seem to always fail on tests that would produce a
"failing bck-i-search". I'm fairly stuck on trying to understand that
too. Probably need to try to trace the zsh instance that's running under
zpty.

Oliver

diff --git a/Test/X01isearch.ztst b/Test/X01isearch.ztst
new file mode 100644
index 0000000..d683242
--- /dev/null
+++ b/Test/X01isearch.ztst
@@ -0,0 +1,167 @@
+%prep
+  if ( zmodload -i zsh/zpty ) >/dev/null 2>&1; then
+    . $ZTST_srcdir/comptest
+    mkdir zle.tmp
+    cd zle.tmp
+    print -lr date 'echo xyz three' 'echo xyz two' 'echo 123 abc' \
+	'echo abc abcdef' 'echo abc' 'echo xyz' 'echo date' "echo '*OH NO*'" \
+	"echo '\n'" 'echo "*WHAT?*"' > historyX01
+    comptestinit -z $ZTST_testdir/../Src/zsh
+  else
+    ZTST_unimplemented="the zsh/zpty module is not available"
+  fi
+
+%test
+# Tests to add:
+#  case-insesitivity
+#  ignoring duplicate lines
+#  special keys
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-Rabc'
+0q:Verify incremental search first match
+>echo <FG 2><BG 1>abc<FG 9><BG 9>
+>bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-Rabcd\C-H'
+0q:Verify incremental search first match via backspace
+>echo <FG 2><BG 1>abc<FG 9><BG 9>
+>bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\n\C-Rabc\C-R'
+0q:Verify incremental search second match
+>echo abc <FG 2><BG 1>abc<FG 9><BG 9>def
+>bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-Rabc\C-R\C-R'
+0q:Verify incremental search third match
+>echo <FG 2><BG 1>abc<FG 9><BG 9> abcdef
+>bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-Rabc\C-R\C-R\C-R'
+0q:Verify incremental search fourth match
+>echo 123 <FG 2><BG 1>abc<FG 9><BG 9>
+>bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-Rabc\C-R\C-R\C-R\C-R'
+0q:Verify incremental search failed fifth match
+>echo 123 abc
+>failing bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-Rabc\C-R\C-R\C-Rd'
+0q:Verify incremental search pass something
+>echo 123 abc
+>failing bck-i-search: abcd_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-Rabc\C-R\C-R\C-Rd\C-H\C-H\C-Hd'
+0q:Verify incremental search pass, backup, and find again.
+>echo abc <FG 2><BG 1>abcd<FG 9><BG 9>ef
+>bck-i-search: abcd_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-Rabcd\C-T'
+0q:Verify incremental search pass, then use search forward to find.
+>echo abc <FG 2><BG 1>abcd<FG 9><BG 9>ef
+>fwd-i-search: abcd_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-R^date'
+0q:Verify incremental search bol pattern
+><FG 2><BG 1>date<FG 9><BG 9>
+>bck-i-search: ^date_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-R\\'
+0q:Verify incremental search backslash
+>echo '<FG 2><BG 1>\<FG 9><BG 9>n'
+>bck-i-search: \_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XR\\*'
+0q:Verify incremental search backslash star
+>echo "*WHAT?<FG 2><BG 1>*<FG 9><BG 9>"
+>bck-i-search: \*_
+
+############# incremental pattern search
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XRabc'
+0q:Verify incremental pattern search first match
+>echo <FG 2><BG 1>abc<FG 9><BG 9>
+>bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XRabcd\C-H'
+0q:Verify incremental pattern search first match via backspace
+>echo <FG 2><BG 1>abc<FG 9><BG 9>
+>bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\n\C-XRabc\C-XR'
+0q:Verify incremental pattern search second match
+>echo abc <FG 2><BG 1>abc<FG 9><BG 9>def
+>bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XRabc\C-XR\C-XR'
+0q:Verify incremental pattern search third match
+>echo <FG 2><BG 1>abc<FG 9><BG 9> abcdef
+>bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XRabc\C-XR\C-XR\C-XR'
+0q:Verify incremental pattern search fourth match
+>echo 123 <FG 2><BG 1>abc<FG 9><BG 9>
+>bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XRabc\C-XR\C-XR\C-XR\C-XR'
+0q:Verify incremental pattern search failed fifth match
+>echo 123 abc
+>failing bck-i-search: abc_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XRabc\C-XR\C-XR\C-XRd'
+0q:Verify incremental pattern search pass something
+>echo 123 abc
+>failing bck-i-search: abcd_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XRabc\C-XR\C-XR\C-XRd\C-H\C-H\C-Hd'
+0q:Verify incremental pattern search pass, backup, and find again.
+>echo abc <FG 2><BG 1>abcd<FG 9><BG 9>ef
+>bck-i-search: abcd_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XRabcd\C-XT'
+0q:Verify incremental pattern search pass, then use search forward to find.
+>echo abc <FG 2><BG 1>abcd<FG 9><BG 9>ef
+>fwd-i-search: abcd_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XR^date'
+0q:Verify incremental pattern search bol pattern
+><FG 2><BG 1>date<FG 9><BG 9>
+>bck-i-search: ^date_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XR\\'
+0q:Verify incremental pattern search backslash
+>echo '<FG 2><BG 1>\<FG 9><BG 9>n'
+>bck-i-search: \_
+
+ comptesteval 'fc -R historyX01'
+ termtest $'\C-XR\\*'
+0q:Verify incremental pattern search backslash star
+>echo "*WHAT?<FG 2><BG 1>*<FG 9><BG 9>"
+>bck-i-search: \*_
+
+%clean
+  zmodload -ui zsh/zpty
diff --git a/Test/comptest b/Test/comptest
index f1c5af0..8a11ca9 100644
--- a/Test/comptest
+++ b/Test/comptest
@@ -18,10 +18,10 @@ comptestinit () {
   done
   (( OPTIND > 1 )) && shift $(( OPTIND - 1 ))
 
-  export PS1="<PROMPT>"
+  export PS1="<PROMPT>" PS2="" RPS1="" RPS2=""
   zpty zsh "$comptest_zsh -f +Z"
 
-  zpty -r zsh log1 "*<PROMPT>*" || { 
+  zpty -r zsh log1 "*<PROMPT>*" || {
     print "first prompt hasn't appeared."
     return 1
   }
@@ -32,6 +32,7 @@ comptestinit () {
 "export ZDOTDIR=$ZTST_testdir" \
 "module_path=( $module_path )" \
 "fpath=( $fpath )" \
+"zle_highlight=(bg_start_code:'\<BG ' bg_end_code:'\>' fg_start_code:'\<FG ' fg_end_code:'\>' isearch:bg=1,fg=2)" \
 "bindkey -$comptest_keymap" \
 'LISTMAX=10000000
 stty 38400 columns 80 rows 24
@@ -62,6 +63,14 @@ list-choices-with-report () {
   zle clear-screen
   zle -R
 }
+tcfunc() {
+  if [[ -n $2 ]]; then
+    REPLY="<tc=$1,arg=$2>"
+  else
+    REPLY="<tc=$1>"
+  fi
+}
+zle -T tc tcfunc
 comp-finish () {
   print "<WIDGET><finish>"
   zle kill-whole-line
@@ -73,18 +82,30 @@ zle-finish () {
   (( region_active )) && print -lr "MARK: $MARK"
   zle -K main
   zle clear-screen
+  zle -R
   zle send-break
+}
+term-finish () {
+  zle kill-buffer
+  zle clear-screen
+  print "<finish>"
   zle -R
 }
 zle -N expand-or-complete-with-report
 zle -N list-choices-with-report
 zle -N comp-finish
+zle -N term-finish
 zle -N zle-finish
 bindkey "^I" expand-or-complete-with-report
 bindkey "^D" list-choices-with-report
-bindkey "^Z" comp-finish
-bindkey "^M" zle-finish
-bindkey -a "^M" zle-finish
+bindkey "^T" history-incremental-search-forward
+bindkey "^XR" history-incremental-pattern-search-backward
+bindkey "^XT" history-incremental-pattern-search-forward
+bindkey -r "^M"
+bindkey "^Mc" comp-finish
+bindkey "^Mt" term-finish
+bindkey "^Mz" zle-finish
+bindkey -a "^Mz" zle-finish
 '
 }
 
@@ -102,7 +123,7 @@ comptesteval () {
 
 comptest () {
   input="$*"
-  zpty -n -w zsh "$input"$'\C-Z'
+  zpty -n -w zsh "$input"$'\C-Mc'
   zpty -r -m zsh log "*<WIDGET><finish>*<PROMPT>*" || {
     print "failed to invoke finish widget."
     return 1
@@ -136,10 +157,26 @@ comptest () {
 
 zletest () {
   input="$*"
-  zpty -n -w zsh "$input"$'\C-M'
+  zpty -n -w zsh "$input"$'\C-Mz'
   zpty -r -m zsh log "*<WIDGET><finish>*<PROMPT>*" || {
     print "failed to invoke finish widget."
     return 1
   }
   print -lr "${(@)${(ps:\r\n:)log##*<WIDGET><finish>}[1,-2]}"
 }
+
+termtest () {
+  input="$*"
+  zpty -n -w zsh "$input"
+  # clear screen, to clear out control sequences
+  zpty -n -w zsh $'\C-L'
+  # send trailing output to scrape off.
+  zpty -n -w zsh $'\C-Mt\C-U'
+  zpty -r -m zsh log "*<finish>*<PROMPT>" || {
+    print "failed to invoke finish widget."
+    return 1
+  }
+  # there might be multiple <PROMPT>'s in log, grab the last one
+  # generated after the clear screen.
+  print -lr -- ${${(f)${log%%<finish>*}##*<PROMPT>}%%<tc=c?>*}
+}


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-09 22:30     ` Oliver Kiddle
@ 2014-02-11  7:37       ` Bart Schaefer
  2014-02-13  5:49         ` Bart Schaefer
  0 siblings, 1 reply; 14+ messages in thread
From: Bart Schaefer @ 2014-02-11  7:37 UTC (permalink / raw)
  To: zsh-workers

On Feb 9, 11:30pm, Oliver Kiddle wrote:
} Subject: Re: Commit 137b15a fails X02zlevi test
}
} Bart wrote:
} > I've been repeatedly running
} > 
} >     make check TESTNUM=X02
} > 
} > and have decided that it fails nondeterministically.
} 
} On my desktop it never seems to fail. I just tried on my NAS box and
} it appears to reliably fail there.

After some futher fooling around ... I created this function:

    zpty_flush() {
      local junk
      if zpty -r -t zsh junk \*; then
	print -n -u $ZTST_fd "$*: ${(V)junk}"
	while zpty -r -t zsh junk \*
          do print -n -u $ZTST_fd "${(V)junk}"; done
	print -u $ZTST_fd ''
      fi
    }

and then added calls to that in comptesteval, comptest, and zletest.

For Y02completion, the output looks like this, repeated once per test
with no blank lines:

------------
After comptesteval: ^[[K
After comptest: ^[[K
------------

For X02zlevi, the output is unpredictable, but usually looks like this:

------------
Before zletest: ^[[K
After zletest: end^[[K^M^M

Before zletest: ^[[1m^[[7m%^[[m^[[1m^[[0m
^M ^M
Before comptesteval: text^[[K^M^M
text^[[K^H^M^M

After comptesteval: ^[[K.^H. /tmp/comptest
Before zletest: .27823^M^M

After zletest: after^[[K^M^M
after^[[K^H^M^M

------------

The blank lines are really there, I did not add them for readability.

My conclusion is that being in viins mode causes ZLE to do much more
work updating the display, resulting in some words being overstruck,
extra cursor motions, etc.  Combine this with using "print -lr" to
try to send cursor position, etc., in-band at the end of each test,
and confusion results.  Now, why this would *sometimes* not happen is
quite the mystery -- I would have thought that e.g. the "stty 38400"
thrown in there would make it behave at least consistently, but no.

The one that reads

After comptesteval: ^[[K.^H. /tmp/comptest
Before zletest: .27823^M^M

is quite interesting, because it indicates that the prompt is being
redrawn in the midst of the string ". /tmp/comptest.27823" which is
written to the pty by comptesteval and expected to be executed as a
command.  I think that has to do with using \C-M as the binding for
zle-finish.

The following reformulation works more than 90% of the time for me,
but still fails occasionally, and still not always on the same test.

If I remove "zle -I", it becomes less reliable.

If I remove "zle redisplay" it fails every time.

If I change the zle-finish binding back to ^M it fails every time.

Calling zpty_flush in comptest is not really needed ... by I don't
know why it's not needed there, which bothers me.


diff --git a/Test/comptest b/Test/comptest
index f1c5af0..4a23e89 100644
--- a/Test/comptest
+++ b/Test/comptest
@@ -69,12 +69,15 @@ comp-finish () {
   zle -R
 }
 zle-finish () {
-  print -lr "<WIDGET><finish>" "BUFFER: $BUFFER" "CURSOR: $CURSOR"
-  (( region_active )) && print -lr "MARK: $MARK"
-  zle -K main
+  local buffer="$BUFFER" cursor="$CURSOR" mark="$MARK"
+  (( region_active)) || unset mark
+  BUFFER=""
+  zle -I
   zle clear-screen
-  zle send-break
-  zle -R
+  zle redisplay
+  print -lr "<WIDGET><finish>" "BUFFER: $buffer" "CURSOR: $cursor"
+  (( $+mark )) && print -lr "MARK: $mark"
+  zle accept-line
 }
 zle -N expand-or-complete-with-report
 zle -N list-choices-with-report
@@ -83,30 +86,45 @@ zle -N zle-finish
 bindkey "^I" expand-or-complete-with-report
 bindkey "^D" list-choices-with-report
 bindkey "^Z" comp-finish
-bindkey "^M" zle-finish
-bindkey -a "^M" zle-finish
+bindkey "^X" zle-finish
+bindkey -a "^X" zle-finish
 '
 }
 
+zpty_flush() {
+  local junk
+  if zpty -r -t zsh junk \*; then
+    (( ZTST_verbose > 2 )) && print -n -u $ZTST_fd "$*: ${(V)junk}"
+    while zpty -r -t zsh junk \* ; do
+      (( ZTST_verbose > 2 )) && print -n -u $ZTST_fd "${(V)junk}"
+    done
+    (( ZTST_verobse > 2 )) && print -u $ZTST_fd ''
+  fi
+}
+
 comptesteval () {
   local tmp=/tmp/comptest.$$
 
   print -lr - "$@" > $tmp
+  zpty_flush Before comptesteval
   zpty -w zsh ". $tmp"
   zpty -r -m zsh log_eval "*<PROMPT>*" || {
     print "prompt hasn't appeared."
     return 1
   }
+  zpty_flush After comptesteval
   rm $tmp
 }
 
 comptest () {
   input="$*"
+  zpty_flush Before comptest
   zpty -n -w zsh "$input"$'\C-Z'
   zpty -r -m zsh log "*<WIDGET><finish>*<PROMPT>*" || {
     print "failed to invoke finish widget."
     return 1
   }
+  zpty_flush After comptest
 
   logs=(${(s:<WIDGET>:)log})
   shift logs
@@ -136,10 +154,12 @@ comptest () {
 
 zletest () {
   input="$*"
-  zpty -n -w zsh "$input"$'\C-M'
+  zpty_flush Before zletest
+  zpty -n -w zsh "$input"$'\C-X'
   zpty -r -m zsh log "*<WIDGET><finish>*<PROMPT>*" || {
     print "failed to invoke finish widget."
     return 1
   }
+  zpty_flush After zletest
   print -lr "${(@)${(ps:\r\n:)log##*<WIDGET><finish>}[1,-2]}"
 }


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-11  7:37       ` Bart Schaefer
@ 2014-02-13  5:49         ` Bart Schaefer
  2014-02-13  9:32           ` Peter Stephenson
  2014-02-13 16:17           ` Jun T.
  0 siblings, 2 replies; 14+ messages in thread
From: Bart Schaefer @ 2014-02-13  5:49 UTC (permalink / raw)
  To: zsh-workers

On Feb 10, 11:37pm, Bart Schaefer wrote:
}
} The following reformulation works more than 90% of the time for me,
} but still fails occasionally, and still not always on the same test.

Anyone object if I commit/push this?


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-13  5:49         ` Bart Schaefer
@ 2014-02-13  9:32           ` Peter Stephenson
  2014-02-13 16:17           ` Jun T.
  1 sibling, 0 replies; 14+ messages in thread
From: Peter Stephenson @ 2014-02-13  9:32 UTC (permalink / raw)
  To: zsh-workers

On Wed, 12 Feb 2014 21:49:22 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Feb 10, 11:37pm, Bart Schaefer wrote:
> }
> } The following reformulation works more than 90% of the time for me,
> } but still fails occasionally, and still not always on the same test.
> 
> Anyone object if I commit/push this?

Certainly appears to be the best there is at the moment.

pws


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-13  5:49         ` Bart Schaefer
  2014-02-13  9:32           ` Peter Stephenson
@ 2014-02-13 16:17           ` Jun T.
  2014-02-13 17:39             ` Bart Schaefer
  1 sibling, 1 reply; 14+ messages in thread
From: Jun T. @ 2014-02-13 16:17 UTC (permalink / raw)
  To: zsh-workers

(Sorry I've been too busy for testing recent patches.)

Today I did a few test with zsh-5.0.5-40-gba58bfe, and found that
X02zlevi.ztst always fails on Mac OS X (10.9.1) and FreeBSD 10.0.
All the test which use comptesteval seem to fail.

With the Bart's zpty_flush patch in 32377, it succeeds about 50%
on Mac but still fails 100% on FreeBSD.
On Both systems, the failure is at
  comptesteval 'bindkey -a "^R" redo'
  zletest $'123\C-_\e\C-r
and all the other tests pass.
(if I set ZTST_verbose=3 then the above test also succeeds always).

I don't know exactly what is causing this failure, but anyway replacing
^R with ^K (or some other keys) seems to work on both Mac and FreeBSD. 

# I noticed that 'stty -a' shows 'reprint' is set to '^R',
# and if I change the comptesteval to
#   comptesteval 'stty reprint "^K";bindkey -a "^R" redo'
# then the test always succeeds on Mac. But this doesn't work on FreeBSD;
# moreover, on Fedora20, X02zlevi.ztst alway succeeds but '^R' is also
# used for reprint. So this may not be related with the failure.




diff --git a/Test/X02zlevi.ztst b/Test/X02zlevi.ztst
index fe55d8a..60f878e 100644
--- a/Test/X02zlevi.ztst
+++ b/Test/X02zlevi.ztst
@@ -49,8 +49,8 @@
 >BUFFER: z
 >CURSOR: 1
 
-  comptesteval 'bindkey -a "^R" redo'
-  zletest $'123\C-_\e\C-r'
+  comptesteval 'bindkey -a "^K" redo'
+  zletest $'123\C-_\e\C-k'
 0:undo in insert mode, redo in command
 >BUFFER: 123
 >CURSOR: 2




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-13 16:17           ` Jun T.
@ 2014-02-13 17:39             ` Bart Schaefer
  2014-02-14 15:59               ` Jun T.
  0 siblings, 1 reply; 14+ messages in thread
From: Bart Schaefer @ 2014-02-13 17:39 UTC (permalink / raw)
  To: zsh-workers

On Feb 14,  1:17am, Jun T. wrote:
}
} With the Bart's zpty_flush patch in 32377, it succeeds about 50%
} on Mac but still fails 100% on FreeBSD.
} On Both systems, the failure is at
}   comptesteval 'bindkey -a "^R" redo'
}   zletest $'123\C-_\e\C-r
} and all the other tests pass.
} (if I set ZTST_verbose=3 then the above test also succeeds always).

Hmm.  This suggests a race condition where some multi-character
sequence is being mis-interpreted.  I suspect that what happens is
that terminal control sequences are being sent by the on-pty zsh
to update the display, but the pty-master zsh is consuming e.g. the
leading ESC character first, so the "terminal" ignores the rest and
leaves it to be misinterpred later by one shell or the other.

A "sleep 1" at the top of zpty_flush may take care of this.

} # I noticed that 'stty -a' shows 'reprint' is set to '^R',

We should try to avoid characters that clash with the stty controls.
comptestinit should probably clear most of those at the same time it
sets the baud rate, etc., so that the tests are free to use anything
they like (except ^M ...)  I won't be able to look at this until this
evening at the earliest.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-13 17:39             ` Bart Schaefer
@ 2014-02-14 15:59               ` Jun T.
  2014-02-15  1:42                 ` Bart Schaefer
  0 siblings, 1 reply; 14+ messages in thread
From: Jun T. @ 2014-02-14 15:59 UTC (permalink / raw)
  To: zsh-workers

On my Fedora 17 and 20, X02zlevi.ztst always succeeds even without
the zpty_flush patch, and on my Mac OS X 10.8/10.9 and FreeBSD 9/10
it succeeds with the zpty_flush patch (already committed) plus my
previous patch (bind undo to ^K instead of ^R).

2014/02/14 02:39, Bart Schaefer <schaefer@brasslantern.com> wrote:
> A "sleep 1" at the top of zpty_flush may take care of this.

It seems adding 'sleep 1' at the END of zpty_flush works (i.e.,
the test succeeds with the zpty_flush patch but undo is bound to ^R).
But this makes the test very slow.
Actually, adding a 'sleep 1' after the

  zpty_flush Before zletest

in zle_test() seems to be enough (at least on my systems and for the
current set of tests), but the test is still rather slow.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-14 15:59               ` Jun T.
@ 2014-02-15  1:42                 ` Bart Schaefer
  2014-02-15 17:07                   ` Jun T.
  0 siblings, 1 reply; 14+ messages in thread
From: Bart Schaefer @ 2014-02-15  1:42 UTC (permalink / raw)
  To: zsh-workers

On Feb 15, 12:59am, Jun T. wrote:
} Subject: Re: Commit 137b15a fails X02zlevi test
}
} On my Fedora 17 and 20, X02zlevi.ztst always succeeds even without
} the zpty_flush patch, and on my Mac OS X 10.8/10.9 and FreeBSD 9/10
} it succeeds with the zpty_flush patch (already committed) plus my
} previous patch (bind undo to ^K instead of ^R).

s/undo/redo/

This is curious.  If the collision of the redo binding with the stty
reprint character were relevant, it should cause a problem no matter
when the key binding occurred.  That may mean that the real problem
is that ^R is bound to "redisplay" by default ... but then I would
still expect ^K to fail as well, since the implication is that the
comptesteval isn't working properly.  Does it really require BOTH
zpty_flush plus and ^K in the FreeBSD case?

} 2014/02/14 02:39, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > A "sleep 1" at the top of zpty_flush may take care of this.
} 
} It seems adding 'sleep 1' at the END of zpty_flush works (i.e.,
} the test succeeds with the zpty_flush patch but undo is bound to ^R).

This is also curious.  My hypothesis is that the master zsh reads some
of the tty control sequences send by the pty-zsh.  At least every now
and then, the "zpty -t -r ..." in zpty_flush should be that culprit.
Putting the sleep at the beginning is meant to prevent that, and then
the flush itself should leave a clean slate for whatever comes next.

} But this makes the test very slow.

Yes, something less than a full 1 second sleep is needed.

} Actually, adding a 'sleep 1' after the
} 
}   zpty_flush Before zletest
} 
} in zle_test() seems to be enough (at least on my systems and for the
} current set of tests), but the test is still rather slow.

That seems to imply that it's more important to pause after comptesteval
than anywhere else, though it's still odd that it would not be needed
*before* the zpty_flush.

What happens if you insert "sleep 1" at the end of comptesteval only?

Actually for my own system I can *remove* _all_ zpty_flush calls from
zle_test and it still works.  This makes some sense because the most
commonly failing cases are "comptesteval;zle_test" in succession, so
there will have been a zpty_flush at the end of comptesteval before
zle_test begins.

One bit that is clear is that ZLE is outputting "^[[K" (which must be
clear-to-eol) after printing the prompt, but both comptesteval and
zle_test are only reading up through the prompt itself, leaving those
last three characters behind.  If subsequent zpty read/write by the
master zsh can get mingled with those characters, bad things happen.

Other things that appear to be happening are PROMPT_CR and PROMPT_SP 
(PROMPT_EOL_MARK) output; both of those are options that post-date
the writing of Test/comptest.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-15  1:42                 ` Bart Schaefer
@ 2014-02-15 17:07                   ` Jun T.
  2014-02-15 21:35                     ` Bart Schaefer
  0 siblings, 1 reply; 14+ messages in thread
From: Jun T. @ 2014-02-15 17:07 UTC (permalink / raw)
  To: zsh-workers

2014/02/15 10:42, Bart Schaefer <schaefer@brasslantern.com> wrote:
> This is curious.  If the collision of the redo binding with the stty
> reprint character were relevant, it should cause a problem no matter
> when the key binding occurred.  That may mean that the real problem
> is that ^R is bound to "redisplay" by default ... but then I would
> still expect ^K to fail as well, since the implication is that the
> comptesteval isn't working properly.

I'm not sure whether I have understood your point correctly, but
I guess 'bindkey -a "^R" redo' itself isn't causing a trouble.
The problem is the '^R' sent by zletest $'123\C-_\e\C-r'.
The slave-side zsh should set its tty input into non-canonical mode
when Zle is active, but I suspect that it fails (or delays) to do so
and the ^R does has a effect of reprint.

>  Does it really require BOTH
> zpty_flush plus and ^K in the FreeBSD case?

Yes, both on Mac and FreeBSD.
Without the zpty_flush patch, all the tests which use comptesteval
fail (unless the test is the 1st test in X02zlevi.ztst).
With the zpty_flush patch, only the test with 'bindkey -a "^R" redo'
fails. This test succeeds if ^R is replaced by ^K.

> What happens if you insert "sleep 1" at the end of comptesteval only?

Works on FreeBSD but not on Mac (about 50% failure). I don't know why.

But adding 'sleep 1' at the beginning of zletest() seems to work on
both Mac and FreeBSD (adding it after the 'zpty_flush Before zletest'
is also OK).

# Adding 'sleep 1' is to make the last failing test (^R-redo test) to
# succeed (with zpty_flush patch applied but redo is bound to ^R).

> Actually for my own system I can *remove* _all_ zpty_flush calls from
> zle_test and it still works.

Maybe the only call of zpty_flush necessary is
'zpty_flush After comptesteval'
in comptesteval(); all the other zpty_flush call can be removed.
With this single call of zpty_flush and ^R --> ^K, all the test pass
on Mac and FreeBSD (without adding sleep anywhere).



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Commit 137b15a fails X02zlevi test
  2014-02-15 17:07                   ` Jun T.
@ 2014-02-15 21:35                     ` Bart Schaefer
  0 siblings, 0 replies; 14+ messages in thread
From: Bart Schaefer @ 2014-02-15 21:35 UTC (permalink / raw)
  To: zsh-workers

On Feb 16,  2:07am, Jun T. wrote:
} Subject: Re: Commit 137b15a fails X02zlevi test
}
} The problem is the '^R' sent by zletest $'123\C-_\e\C-r'.
} The slave-side zsh should set its tty input into non-canonical mode
} when Zle is active, but I suspect that it fails (or delays) to do so
} and the ^R does has a effect of reprint.

Ah!  That makes sense.  I was assuming character were lost because
the master was reading while the slave was writing, but it's just as
likely that the master writes while the slave is busy.  I wan't
thinking about how stty controls affect "typeahead".

} Maybe the only call of zpty_flush necessary is
} 'zpty_flush After comptesteval'
} in comptesteval(); all the other zpty_flush call can be removed.
} With this single call of zpty_flush and ^R --> ^K, all the test pass
} on Mac and FreeBSD (without adding sleep anywhere).

OK, same here -- let's go with this, then.


diff --git a/Test/X02zlevi.ztst b/Test/X02zlevi.ztst
index fe55d8a..60f878e 100644
--- a/Test/X02zlevi.ztst
+++ b/Test/X02zlevi.ztst
@@ -49,8 +49,8 @@
 >BUFFER: z
 >CURSOR: 1
 
-  comptesteval 'bindkey -a "^R" redo'
-  zletest $'123\C-_\e\C-r'
+  comptesteval 'bindkey -a "^K" redo'
+  zletest $'123\C-_\e\C-k'
 0:undo in insert mode, redo in command
 >BUFFER: 123
 >CURSOR: 2
diff --git a/Test/comptest b/Test/comptest
index 42fe651..48b6cdf 100644
--- a/Test/comptest
+++ b/Test/comptest
@@ -106,7 +106,7 @@ comptesteval () {
   local tmp=/tmp/comptest.$$
 
   print -lr - "$@" > $tmp
-  zpty_flush Before comptesteval
+  # zpty_flush Before comptesteval
   zpty -w zsh ". $tmp"
   zpty -r -m zsh log_eval "*<PROMPT>*" || {
     print "prompt hasn't appeared."
@@ -118,13 +118,11 @@ comptesteval () {
 
 comptest () {
   input="$*"
-  zpty_flush Before comptest
   zpty -n -w zsh "$input"$'\C-Z'
   zpty -r -m zsh log "*<WIDGET><finish>*<PROMPT>*" || {
     print "failed to invoke finish widget."
     return 1
   }
-  zpty_flush After comptest
 
   logs=(${(s:<WIDGET>:)log})
   shift logs
@@ -154,12 +152,12 @@ comptest () {
 
 zletest () {
   input="$*"
-  zpty_flush Before zletest
+  # zpty_flush Before zletest
   zpty -n -w zsh "$input"$'\C-X'
   zpty -r -m zsh log "*<WIDGET><finish>*<PROMPT>*" || {
     print "failed to invoke finish widget."
     return 1
   }
-  zpty_flush After zletest
+  # zpty_flush After zletest
   print -lr "${(@)${(ps:\r\n:)log##*<WIDGET><finish>}[1,-2]}"
 }


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2014-02-15 21:35 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-08 20:13 Commit 137b15a fails X02zlevi test Bart Schaefer
2014-02-08 22:45 ` Bart Schaefer
2014-02-09 18:53   ` Bart Schaefer
2014-02-09 21:00     ` Peter Stephenson
2014-02-09 22:30     ` Oliver Kiddle
2014-02-11  7:37       ` Bart Schaefer
2014-02-13  5:49         ` Bart Schaefer
2014-02-13  9:32           ` Peter Stephenson
2014-02-13 16:17           ` Jun T.
2014-02-13 17:39             ` Bart Schaefer
2014-02-14 15:59               ` Jun T.
2014-02-15  1:42                 ` Bart Schaefer
2014-02-15 17:07                   ` Jun T.
2014-02-15 21:35                     ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).