AW: vc-state always calls heuristic function

AW: vc-state always calls heuristic function

[klaus.berndl]

[-- Attachment #1.1: Type: text/plain, Size: 2663 bytes --]

sorry for sending this again - but until now i got
no answer to my question about the current state of
while-no-inmput - see below - maybe you have forgotten to
answer... ;-)

Klaus


-----Ursprüngliche Nachricht-----
Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org im Auftrag von klaus.berndl@sdm.de
Gesendet: Mi 24.11.2004 15:44
An: monnier@iro.umontreal.ca
Cc: emacs-devel@gnu.org
Betreff: RE: vc-state always calls heuristic function
 
Stefan Monnier wrote:
>> and between each pass of the loop it is interruptable..well, but of
>> course there remains the problem - how to interrupt if one pass
>> takes long 
>> time...
> 
> Google for `while-no-input'.

Done - after reading the whole thread i can say: I agree at 100% with you and Kim.
Such a macro would be very important especially for a program like Emacs which
has still not thread-feature like Java, C++ et. al. IMHO this is one of the
most important any annoying lacks of emacs-lisp and for programmers...
And i agree with Kim that especially people working with remote-paths and
packages which makes this completely transparent (like tramp, ange-ftp and efs)
would profite a lot from such a macro like while-no-input - 

The current discussion how to enable tools like ECB to display some state-value
for files (as the VC-state-values) where the computation could be expensive
is IMHO a good example to demonstrate the need of such feature - so we have no
threads avaliable in emacs-lisp to perform such expensive tasks in the background
without blocking the user of Emacs but we could at least offer the users of
such tools a way how to easily (hitting C-g is not acceptable) interrupt also
"atomic" calls as call of call-process etc...

Well, Stefan - this thread was discussed in 2002 - what is current state of
this while-no-input???

>> Hmm, now i'm confused... ECB needs a function how to get the
>> VC-state. Well, the user can customize which function ECB should
>> use.  But if he should 
>> not use `vc-recompute-state' how he should get fresh-but-slow state??
> 
> Oh, you're right I got confused: vc-cvs-heuristic-state doesn't pay
> attention to vc-cvs-stay-local.  Hmmm....
> I guess VC could/should provide a function like vc-recompute-state or
> vc-check-for-updates.  Currently this operation is only provided as
> part of vc-next-action, but it might be nice to decouple the two.

Yes, see my discussion with Andre about this...

Klaus

> 
> 
>         Stefan



_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel


[-- Attachment #1.2: Type: text/html, Size: 3523 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: AW: vc-state always calls heuristic function

[Kim F. Storm]

Current state is that RMS rejected Stefan's implementation of while-no-input.

No further progress was made, as Stefan didn't want to pursue the
issue further and I didn't quite understand how RMS wanted to
implement it using a signal.

Too bad!!   It would be a very nice feature to have!



<klaus.berndl@sdm.de> writes:

> sorry for sending this again - but until now i got
> no answer to my question about the current state of
> while-no-inmput - see below - maybe you have forgotten to
> answer... ;-)
>
> Klaus
>
>
> -----Ursprüngliche Nachricht-----
> Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org im Auftrag von klaus.berndl@sdm.de
> Gesendet: Mi 24.11.2004 15:44
> An: monnier@iro.umontreal.ca
> Cc: emacs-devel@gnu.org
> Betreff: RE: vc-state always calls heuristic function
>  
> Stefan Monnier wrote:
>>> and between each pass of the loop it is interruptable..well, but of
>>> course there remains the problem - how to interrupt if one pass
>>> takes long 
>>> time...
>> 
>> Google for `while-no-input'.
>
> Done - after reading the whole thread i can say: I agree at 100% with you and Kim.
> Such a macro would be very important especially for a program like Emacs which
> has still not thread-feature like Java, C++ et. al. IMHO this is one of the
> most important any annoying lacks of emacs-lisp and for programmers...
> And i agree with Kim that especially people working with remote-paths and
> packages which makes this completely transparent (like tramp, ange-ftp and efs)
> would profite a lot from such a macro like while-no-input - 
>
> The current discussion how to enable tools like ECB to display some state-value
> for files (as the VC-state-values) where the computation could be expensive
> is IMHO a good example to demonstrate the need of such feature - so we have no
> threads avaliable in emacs-lisp to perform such expensive tasks in the background
> without blocking the user of Emacs but we could at least offer the users of
> such tools a way how to easily (hitting C-g is not acceptable) interrupt also
> "atomic" calls as call of call-process etc...
>
> Well, Stefan - this thread was discussed in 2002 - what is current state of
> this while-no-input???
>
>>> Hmm, now i'm confused... ECB needs a function how to get the
>>> VC-state. Well, the user can customize which function ECB should
>>> use.  But if he should 
>>> not use `vc-recompute-state' how he should get fresh-but-slow state??
>> 
>> Oh, you're right I got confused: vc-cvs-heuristic-state doesn't pay
>> attention to vc-cvs-stay-local.  Hmmm....
>> I guess VC could/should provide a function like vc-recompute-state or
>> vc-check-for-updates.  Currently this operation is only provided as
>> part of vc-next-action, but it might be nice to decouple the two.
>
> Yes, see my discussion with Andre about this...
>
> Klaus
>
>> 
>> 
>>         Stefan
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

while-no-input

[Richard Stallman]

    Current state is that RMS rejected Stefan's implementation of while-no-input.

    No further progress was made, as Stefan didn't want to pursue the
    issue further and I didn't quite understand how RMS wanted to
    implement it using a signal.

I don't remember the discussion, but if you tell me what month it was,
I can search for the messages.

Re: while-no-input

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Current state is that RMS rejected Stefan's implementation of while-no-input.
>
>     No further progress was made, as Stefan didn't want to pursue the
>     issue further and I didn't quite understand how RMS wanted to
>     implement it using a signal.
>
> I don't remember the discussion, but if you tell me what month it was,
> I can search for the messages.

October/November 2002


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: while-no-input

[Richard Stallman]

Here's where the discussion ended up:

    The problem is that we need while-no-input to be able to encapsulate
    _UNMODIFIED_ code (such as ange-ftp and tramp) so that user input
    transparently "interrupts" (or quits) that code.

    Obviously, the code we need to encapsulate must already have been
    written to intercept the "quit" signal to be able to properly clean-up
    network connections etc. due to a keyboard-quit.

    Therefore, the most obvious solution -- once you see it -- to
    implement while-no-input is to use the quit signal as an indication
    of pending user input.  That way, the existing code to handle
    the quit signal will make while-no-input work transparently out of
    the box!


    In contrast, using throw/catch instead of Stefan's `annotated' quit
    signal _DOES_NOT_WORK_ since the code we really want to encapsulate,
    such as ange-ftp and tramp, is not written to expect a non-local exit
    due to non-quit events!

I doubt that argument.  Usually the way to arrange to clean something
up is with unwind-protect, and that will handle any nonlocal exit.
The only thing programs do to control quitting is to bind inhibit-quit
on and off.  That is not relevant to handling with-no-input, so I think
there is really no advantage in using signals.

Can you find any real code where using a quit signal would work better
than using throw?

Re: while-no-input

[Stefan Monnier]

> The only thing programs do to control quitting is to bind inhibit-quit
> on and off.  That is not relevant to handling with-no-input, so I think

Could you substantiate that claim?
AFAIK inhibit-quit is used to get more-or-less-atomic behavior in places
where it matters.  while-no-input should very clearly obey inhibit-quit
since it also causes non-local exits at places where it can't be predited
(just like quit).
Don't forget that the code within while-no-input is usually code that was
not specifically designed for while-no-input (otherwise it would already use
input-pending-p instead).

Here is another way to say the ame thing: of all the non-local exits we have
right now, `quit' is the only one that's asynchronous.  `while-no-input'
introduces another form of asynchronous signalling and is thus much more
like `quit' than like `throw'.


        Stefan

Re: while-no-input

[Richard Stallman]

    > The only thing programs do to control quitting is to bind inhibit-quit
    > on and off.  That is not relevant to handling with-no-input, so I think

    Could you substantiate that claim?
    AFAIK inhibit-quit is used to get more-or-less-atomic behavior in places
    where it matters.  while-no-input should very clearly obey inhibit-quit

I am not sure about that point, but the issue at hand is how to do the
nonlocal exit.  If while-no-input's implementation looks at
inhibit-quit, that is orthogonal to how do to the nonlocal exit.  So
let me make my statement more precise:

The only thing programs do to control quitting is to bind inhibit-quit
on and off.  Since inhibit-quit has no effect on what either Fsignal
or Fthrow does when it is called, using Fthrow instead of Fsignal is
entirely orthogonal to anything user programs do to control quitting.

    Here is another way to say the ame thing: of all the non-local
    exits we have right now, `quit' is the only one that's
    asynchronous.

The setting of Vquit_flag is asynchronous, but I don't see that
that relates to the issue.  Quitting itself can be done asynchronously
in a few primitives, but usually it occurs synchronously in a place
that checks for it and does QUIT.

The operational difference between signal and throw is that the former
is caught by `condition-case' while the latter is caught by `catch'.
So the way to decide the issue is based on whether `condition-case'
ought to catch this.  If the definition of with-no-input is that
it alone catches this, then it has to use `catch'.

So here's my simpler proposal for how to implement this.


(defmacro while-no-input (&rest body)
  "Execute BODY only as long as there's no pending input.
If input arrives, that ends the execution of BODY."
  (declare (debug t) (indent 0))
  (let ((catch-sym (make-symbol "input")))
    `(with-local-quit
       (catch ',catch-sym
	 (let ((throw-on-input ',catch-sym))
	   (when (sit-for 0 0 t)
	     ,@body))))))

#define QUIT						\
  do {							\
    if (!NILP (Vquit_flag) && NILP (Vinhibit_quit))	\
      {							\
        Lisp_Object flag = Vquit_flag;			\
	Vquit_flag = Qnil;				\
	if (EQ (Vthrow_on_input, flag))			\
	  Fthrow (Vthrow_on_input, Qnil);		\
	Fsignal (Qquit, Qnil);				\
      }							\
    else if (interrupt_input_pending)			\
      handle_async_input ();				\
  } while (0)
    



Index: keyboard.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/keyboard.c,v
retrieving revision 1.708
diff -u -u -b -r1.708 keyboard.c
--- keyboard.c	27 Sep 2002 17:03:46 -0000	1.708
+++ keyboard.c	1 Oct 2002 21:15:14 -0000
@@ -3374,6 +3402,9 @@
 }
 #endif
 
+
+Lisp_Object Vthrow_on_input;
+
 /* Store an event obtained at interrupt level into kbd_buffer, fifo */
 
 void
@@ -3501,6 +3538,14 @@
       ASET (kbd_buffer_gcpro, idx + 1, event->arg);
       ++kbd_store_ptr;
     }
+  
+  /* If we're in a section that requested to be interrupted as soon
+     as input comes, then set quit-flag to cause an interrupt.  */
+  if (!NILP (Vthrow_on_input)
+      && event->kind != FOCUS_IN_EVENT
+      && event->kind != HELP_EVENT
+      && event->kind != DEICONIFY_EVENT)
+    Vquit_flag = Vthrow_on_input;
 }
 
 
@@ -11038,6 +11029,12 @@
 	       doc: /* *How long to display an echo-area message when the minibuffer is active.
 If the value is not a number, such messages don't time out.  */);
   Vminibuffer_message_timeout = make_number (2);
+
+  DEFVAR_LISP ("throw-on-input", &Vthrow_on_input,
+	       doc: /* If non-nil, any keyboard input throws to this symbol.
+The value of that variable is passed to `quit-flag' and later causes a
+peculiar kind of quitting.  */);
+  Vthrow_on_input = Qnil;
 }
 
 void

Re: while-no-input

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> So here's my simpler proposal for how to implement this.

I tried it -- but I don't have SYNC_INPUT defined, so I used this:

#define QUIT						\
  do {							\
    if (!NILP (Vquit_flag) && NILP (Vinhibit_quit))	\
      {							\
        Lisp_Object flag = Vquit_flag;			\
	Vquit_flag = Qnil;				\
	if (EQ (Vthrow_on_input, flag))			\
	  Fthrow (Vthrow_on_input, Qnil);		\
	Fsignal (Qquit, Qnil);				\
      }							\
  } while (0)


I then ran this code (in my normal emacs with cua-mode enabled):

(while-no-input
  (while t
    (prin1 "x")
    (sit-for 0)))

and hit space after a few seconds.  Got a crash:


Breakpoint 1, abort () at emacs.c:442

(gdb) xbacktrace
"cua--post-command-handler"
"run-hooks"
(gdb) bt
#0  abort () at emacs.c:442
#1  0x08182ae9 in Feval (form=140121845) at eval.c:2015
#2  0x081819e0 in Fcondition_case (args=145132605) at eval.c:1329
#3  0x081b7204 in Fbyte_code (bytestr=144710763, vector=144806556, maxdepth=24) at bytecode.c:864
#4  0x08184383 in funcall_lambda (fun=144661804, nargs=0, arg_vector=0xbfffd608) at eval.c:2959
#5  0x08183dcb in Ffuncall (nargs=1, args=0xbfffd604) at eval.c:2820
#6  0x081836c8 in run_hook_with_args (nargs=1, args=0xbfffd604, cond=to_completion) at eval.c:2440
#7  0x081834bc in Frun_hooks (nargs=1, args=0xbfffd6d4) at eval.c:2308
#8  0x08183b46 in Ffuncall (nargs=2, args=0xbfffd6d0) at eval.c:2753
#9  0x0818386b in call1 (fn=137798905, arg1=137754665) at eval.c:2566
#10 0x0810cf01 in safe_run_hooks_1 (hook=0) at keyboard.c:2034
#11 0x08181b06 in internal_condition_case (bfun=0x810cee7 <safe_run_hooks_1>, handlers=137698537, hfun=0x810cf06 <safe_run_hooks_error>) at eval.c:1382
#12 0x0810cf9c in safe_run_hooks (hook=137754665) at keyboard.c:2062
#13 0x0810c25b in command_loop_1 () at keyboard.c:1801
#14 0x08181b06 in internal_condition_case (bfun=0x810adbb <command_loop_1>, handlers=137764305, hfun=0x810a900 <cmd_error>) at eval.c:1382
#15 0x0810ac33 in command_loop_2 () at keyboard.c:1309
#16 0x081815cc in internal_catch (tag=137756753, func=0x810ac14 <command_loop_2>, arg=137698489) at eval.c:1143
#17 0x0810abe6 in command_loop () at keyboard.c:1288
#18 0x0810a67f in recursive_edit_1 () at keyboard.c:981
#19 0x0810a7c0 in Frecursive_edit () at keyboard.c:1042
#20 0x0810911b in main (argc=3, argv=0xbfffdf04) at emacs.c:1742
#21 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) p handling_signal
$1 = 1
(gdb) p interrupt_input_blocked
$2 = 0
(gdb) 

Seems that we can break out of XTread_socket without restoring
handling_signal.

I don't know if it is sufficient to unwind protect it.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk