Proposal for a new mechanism for delayed stuff

Proposal for a new mechanism for delayed stuff

[Lars Ingebrigtsen]

Gnus does a lot of stuff that it doesn't really know how long it'll take
to do.  For instance, connecting to a mail server, and rendering
complex HTML.

If Gnus were to output "Connecting to foo", "sending retrieval
commands", "waiting for foo to finish outputting" (which are usually
done asynchronously, intermingled between many servers), Gnus would spew
an inordinate number of messages.

And sometimes the user should know what's taking so long, so that the
user can decide what to do about it.

So the ideal would be if we could say "display a message if things take
too long".

The idea I had yesterday was to make this totally general:

(with-timeout-forms
   (progn
     (bla)
     (bla))
  (1.5 (message "This is sure taking a lot of time..."))
  (10 (message "This is sure taking forever!")))

A la condition-case and stuff, although here we have forms that are
run if the main form takes too long.  So after 1.5 seconds we trigger
the first, and after 10 we trigger the second.

And perhaps it would also be possible to have a special thing in the
timeout forms that would conclude the entire main form?  Like `return'
or something.

So it's like `with-timeout', only that it doesn't end executing the
body.  And it would hopefully be possible to implement it such a way
that a looping body form would also be "pre-emptible".  

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Lars Magne Ingebrigtsen

Re: Proposal for a new mechanism for delayed stuff

[Xue Fuqiao]

On Tue, 25 Dec 2012 14:20:31 +0100
Lars Ingebrigtsen <larsi@gnus.org> wrote:

> So the ideal would be if we could say "display a message if things take
> too long".

That's good for many packages and features, such as ispell-buffer, nxml, some TeX-related packages, replace+, ERC, W3 and so on.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: Proposal for a new mechanism for delayed stuff

[Karl Fogel]

Lars Ingebrigtsen <larsi@gnus.org> writes:
>Gnus does a lot of stuff that it doesn't really know how long it'll take
>to do.  For instance, connecting to a mail server, and rendering
>complex HTML.
>
>If Gnus were to output "Connecting to foo", "sending retrieval
>commands", "waiting for foo to finish outputting" (which are usually
>done asynchronously, intermingled between many servers), Gnus would spew
>an inordinate number of messages.
>
>And sometimes the user should know what's taking so long, so that the
>user can decide what to do about it.
>
>So the ideal would be if we could say "display a message if things take
>too long".
>
>The idea I had yesterday was to make this totally general:
>
>(with-timeout-forms
>   (progn
>     (bla)
>     (bla))
>  (1.5 (message "This is sure taking a lot of time..."))
>  (10 (message "This is sure taking forever!")))
>
>A la condition-case and stuff, although here we have forms that are
>run if the main form takes too long.  So after 1.5 seconds we trigger
>the first, and after 10 we trigger the second.
>
>And perhaps it would also be possible to have a special thing in the
>timeout forms that would conclude the entire main form?  Like `return'
>or something.
>
>So it's like `with-timeout', only that it doesn't end executing the
>body.  And it would hopefully be possible to implement it such a way
>that a looping body form would also be "pre-emptible".  

I think that's a great generalization idea.  And `with-timeout' could
then be (re)implemented using `with-timeout-forms', presumably.

Re: Proposal for a new mechanism for delayed stuff

[Ted Zlatanov]

On Tue, 25 Dec 2012 14:20:31 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> The idea I had yesterday was to make this totally general:

 (with-timeout-forms
    (progn
      (bla)
      (bla))
   (1.5 (message "This is sure taking a lot of time..."))
   (10 (message "This is sure taking forever!")))

LI> A la condition-case and stuff, although here we have forms that are
LI> run if the main form takes too long.  So after 1.5 seconds we trigger
LI> the first, and after 10 we trigger the second.

I like it.

LI> And perhaps it would also be possible to have a special thing in the
LI> timeout forms that would conclude the entire main form?  Like `return'
LI> or something.

You could use 'finally?

Ted

Re: Proposal for a new mechanism for delayed stuff

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > You could use 'finally?

In Python, "finally" has a different meaning, basically the same as
`unwind-protect' in Emacs.  Python usage is merely suggestive, but I
think that's more intuitive for "finally".

"break" seems to be the obvious choice of inline syntactic keyword.
Since this is Lisp, I guess its semantics would need to be extended to
"break and return value".

Alternatively, Emacs could adopt the Scheme call/cc convention and
have an "exit function", which if called would exit the
with-timeout-forms form and return the argument of the exit function.

Re: Proposal for a new mechanism for delayed stuff

[Vitalie Spinu]

  >> Lars Ingebrigtsen <larsi@gnus.org>
  >> on Tue, 25 Dec 2012 14:20:31 +0100 wrote:

[...]


  > (with-timeout-forms
  >    (progn
  >      (bla)
  >      (bla))
  >   (1.5 (message "This is sure taking a lot of time..."))
  >   (10 (message "This is sure taking forever!")))

(bla) (bla) are asynchronous forms, right?  I am probably missing
something, but there should be a callback, otherwise how do you know
when (bla) is finished? 


Should negative numbers signify a repeated task?

  (with-timeout-forms
     (progn ...
       )
    (-1 (do-something-every-second))
   )

Then you can pass an explicit callback:

  (with-timeout-forms
     (progn ...
       (bla bla)
       )
    (-.1 (if-job-is-finished-break-timeout-loop))
   )


  Vitalie   

Re: Proposal for a new mechanism for delayed stuff

[Achim Gratz]

Am 27.12.2012 05:08, schrieb Stephen J. Turnbull:
> "break" seems to be the obvious choice of inline syntactic keyword.
> Since this is Lisp, I guess its semantics would need to be extended to
> "break and return value".

All languages I know that have a syntactic "break" use it to modify 
local control flow.  Unless I missed some vital part of the discussion, 
we'd want to terminate an async process that has used up the time budget 
alotted to it.  So I don't see "break" as an obvious nor appropriate choice.


-- 
Achim.

(on the road :-)

Re: Proposal for a new mechanism for delayed stuff

[Lars Ingebrigtsen]

Vitalie Spinu <spinuvit@gmail.com> writes:

> (bla) (bla) are asynchronous forms, right? 

No.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Lars Magne Ingebrigtsen

Re: Proposal for a new mechanism for delayed stuff

[Stephen J. Turnbull]

Achim Gratz writes:

 > All languages I know that have a syntactic "break" use it to modify 
 > local control flow.

Point taken.  This is really more like a throw (but I don't trust my
intuition enough to suggest anything right now :-P )..

 > Unless I missed some vital part of the discussion, we'd want to
 > terminate an async process that has used up the time budget alotted
 > to it.

No, it's because Emacs is blocking that this timeout mechanism has
been suggested.  If the task were asynchronous there wouldn't be a
need for a separate timeout.  We would just sleep a bit and check a
buffer from Lisp code, and repeat a fixed number of times or until
success, whichever comes first.  It could used for any potentially
long-running synchronous task, whether I/O or a user-specified
Lisp computation.

Re: Proposal for a new mechanism for delayed stuff

[Stefan Monnier]

> (with-timeout-forms
>    (progn
>      (bla)
>      (bla))
>   (1.5 (message "This is sure taking a lot of time..."))
>   (10 (message "This is sure taking forever!")))

Maybe an alternative would be a `current-state-message' global variable,
which is then displayed once per second that Emacs is busy.


        Stefan

Re: Proposal for a new mechanism for delayed stuff

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> (with-timeout-forms
>>    (progn
>>      (bla)
>>      (bla))
>>   (1.5 (message "This is sure taking a lot of time..."))
>>   (10 (message "This is sure taking forever!")))
>
> Maybe an alternative would be a `current-state-message' global variable,
> which is then displayed once per second that Emacs is busy.

Sure, that would also handle the "tell the user what's going on" use
case, and we could have a convenience macro `with-current-state-message'
that would simply be an `unwind-protect' to clear out the state message.

But `with-timeout-form' would be kinda generally useful, I think.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Proposal for a new mechanism for delayed stuff

[Stefan Monnier]

> Sure, that would also handle the "tell the user what's going on" use
> case, and we could have a convenience macro `with-current-state-message'
> that would simply be an `unwind-protect' to clear out the state message.

Yes, the advantage is that the message can be displayed even if we're in
the middle of uninterruptible Elisp code.

> But `with-timeout-form' would be kinda generally useful, I think.  :-)

IIUC you can implement that in Elisp, right?


        Stefan

Re: Proposal for a new mechanism for delayed stuff

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Sure, that would also handle the "tell the user what's going on" use
>> case, and we could have a convenience macro `with-current-state-message'
>> that would simply be an `unwind-protect' to clear out the state message.
>
> Yes, the advantage is that the message can be displayed even if we're in
> the middle of uninterruptible Elisp code.

Well, presumably if we can display `current-state-message' in
uninterruptible Elisp code, we could also do the `with-timeout-forms'
things in the uninterruptible Elisp code?

Or is that too difficult?

Anyway, if `current-state-message' is easy to implement, I'm all for
getting that.   :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Proposal for a new mechanism for delayed stuff

[Stefan Monnier]

>>> Sure, that would also handle the "tell the user what's going on" use
>>> case, and we could have a convenience macro `with-current-state-message'
>>> that would simply be an `unwind-protect' to clear out the state message.
>> Yes, the advantage is that the message can be displayed even if we're in
>> the middle of uninterruptible Elisp code.
> Well, presumably if we can display `current-state-message' in
> uninterruptible Elisp code, we could also do the `with-timeout-forms'
> things in the uninterruptible Elisp code?

No, because that would mean running arbitrary code in the middle of
"uninterruptible Elisp code", which is contrary to the idea of
"uninterruptible".

> Anyway, if `current-state-message' is easy to implement, I'm all for
> getting that.   :-)

I don't know if it is.


        Stefan