From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daimrod Newsgroups: gmane.emacs.bugs Subject: bug#14820: 24.3; elisp manual: How to write good idle timer worker functions? Date: Thu, 11 Jul 2013 15:39:52 +0200 Message-ID: <87ppup2p1z.fsf@tanger.home> References: <51DABDE6.10904@orcon.net.nz> <50216.121.99.89.166.1373470285.squirrel@mail.orcon.net.nz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1373549777 13785 80.91.229.3 (11 Jul 2013 13:36:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Jul 2013 13:36:17 +0000 (UTC) Cc: 14820@debbugs.gnu.org To: "Phil Sainty" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 11 15:36:18 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UxH2g-0002BO-4I for geb-bug-gnu-emacs@m.gmane.org; Thu, 11 Jul 2013 15:36:18 +0200 Original-Received: from localhost ([::1]:47364 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxH2c-00036f-OK for geb-bug-gnu-emacs@m.gmane.org; Thu, 11 Jul 2013 09:36:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxH2W-00031G-HD for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2013 09:36:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UxH2R-0006X9-B2 for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2013 09:36:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxH2R-0006X2-8L for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2013 09:36:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1UxH2Q-0004yL-ET for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2013 09:36:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <51DABDE6.10904@orcon.net.nz> Resent-From: Daimrod Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Jul 2013 13:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14820 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14820-submit@debbugs.gnu.org id=B14820.137354972919013 (code B ref 14820); Thu, 11 Jul 2013 13:36:02 +0000 Original-Received: (at 14820) by debbugs.gnu.org; 11 Jul 2013 13:35:29 +0000 Original-Received: from localhost ([127.0.0.1]:47288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UxH1s-0004wa-0L for submit@debbugs.gnu.org; Thu, 11 Jul 2013 09:35:28 -0400 Original-Received: from mail-wg0-f43.google.com ([74.125.82.43]:40504) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UxH1o-0004wF-IR for 14820@debbugs.gnu.org; Thu, 11 Jul 2013 09:35:25 -0400 Original-Received: by mail-wg0-f43.google.com with SMTP id z11so6930575wgg.34 for <14820@debbugs.gnu.org>; Thu, 11 Jul 2013 06:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; bh=6k8KKPvv14jfcyh+pqm+B9s9G6ZpQbBU3FxIL/YcwRo=; b=c8U1C8daqHq9PWsOJERNc13ufmZ4Blh8XhATcteKL0vQcQI8fACa68dn25YNnOWIpg UtNE96HFa/uosMeg0Te5LFj7uR0kc8daIGiVa/oNTT8breGUc9B4QnScdygBLbsFCLVF KnGeB1qGjcAuK1c8W0HHGFG5qwNeQcVIAmNEz6rthzs0NYmlvjT3CkkcfWmqT9E2g1Oz BikDnd3S77F8Ugf1USU2xtGJB1Mme3DNHIgFvXiuPT7Xf6fA++B3NVMaB0F6RbTIko6y HYfEd5wjT71ey7BZHM7233K6BvGvg2rinopwntsu2rk1d8fq+/3TeqS1CNmXM6rwwIFY U1gg== X-Received: by 10.194.24.40 with SMTP id r8mr20981804wjf.7.1373549718742; Thu, 11 Jul 2013 06:35:18 -0700 (PDT) Original-Received: from localhost (ANantes-653-1-79-227.w109-211.abo.wanadoo.fr. [109.211.170.227]) by mx.google.com with ESMTPSA id h8sm42282396wie.1.2013.07.11.06.35.17 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 11 Jul 2013 06:35:18 -0700 (PDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:76216 Archived-At: "Phil Sainty" writes: > Stefan Monnier wrote: >> Currently, Emacs doesn't support such "background tasks" well. >> Documentation could help, but I think it's not really worth the >> trouble. Better come up with a package that provides support >> for it. > > Well surely you'd agree that writing such a package is going to be > more much difficult without documentation? That is essentially the > problem I ran into here, after all. > > At the absolute minimum, that page definitely needs to mention > `sit-for' / "(elisp) Waiting" and `accept-process-output' / > "(elisp) Accepting Output". After all, when specific pit-falls > are mentioned, I think that the available facilities for working > around them warrant at least a passing mention. > > (Honestly, the merest mention of these two functions after the > description of the problems of blocking other timers and processes > would have saved me many hours, so it's worth it just for the > potential to save someone else from being similarly stumped. I'd > simply never had cause to use them before, so it wasn't *at all* > obvious where to look.) > > Having found my way to the latter, and run some experiments with > generating output from a shell while running my idle timer code, > I've managed to answer my own question about `sit-for' (which is > that it does not solve the problem of accepting process output), but > determined that (unsurprisingly) calling `(accept-process-output)' > does provide a solution, so I believe I'm on my way to resolving my > original issue. > > I do still think that if there were some nice easy-to-use wrappers > around the functionality that Emacs *does* provide, we could say > something a little more positive about the situation -- that > *despite* not supporting "background tasks" well, Emacs makes > it easy to fake them! > > >> IIRC someone posted some packages that try to provide support >> for related issues, but I can't find the corresponding email. > > Ah, that's a shame; but thank you for looking. Maybe someone > else remembers what those were? > > Failing that, if I end up with something that seems useful and > generic, I'll submit it for consideration. A bit of background: I'm GSoC student working on the XWidget branch and I wanted to add test to it. But I've encountered two problems while trying to write "classic" ERT tests. One is that since I'm working on the C side on an experimental branch, sometimes Emacs crashes. The second problem is that some tests needs to be run in a graphical Emacs. So I can't run the tests in batch mode to circumvent the first problem. I've wrote a package, emacs-parallel[1], (the API isn't very clean but it's good enough for my current needs) to eval some stuff in another Emacs process. I've been heavily inspired by emacs-async[2], but I've made differents choices: - it can start a graphical Emacs (not Batch Mode); - it communicates through a Unix socket instead of standard I/O stream (because, AFAIK, it is not possible to use them without Batch Mode); - you can send data from the remote process while the process isn't finished instead of just sending the result of the call; - the main entry point is a function, not a macro; - it tells you whether the process terminated normally, and if not, what happens (exit code or signal number). - it handles timeout (you can stop the remote instance after X seconds); I haven't wrote much doc yet (I've started it monday) so maybe emacs-async is a better choice (ATM) if you don't need an graphical Emacs or if you don't need to send data without interrupting the remote process. (parallel-start (lambda () (parallel-send 42) (sleep-for 3) 12) :post-exec (lambda (results _status) (message "%s" results))) (emacs-async equivalent) (async-start (lambda () (sleep-for 3) (list 12 42)) (lambda (result) (message "%s" result))) => after 3 sec it displays (12 42) However, since those packages simulate parallel/async jobs with another Emacs instance, you cannot execute code with side effects. Well, you can, but it won't have any effect in your current Emacs instance, only on the remote. You have to isolate the side effects and to put them in a function to be executed once the computation (free of side effect) is done (`finish-func' in `async-start' or `:post-exec' in `parallel-start'). > -Phil > > p.s. Although I *think* I now know what I'm doing here, I don't > want to close this issue just yet. I'm very interested in any and > all comments on this subject, if any other people wish to chip in > with their thoughts? [1] https://github.com/daimrod/emacs-parallel.git [2] https://github.com/jwiegley/emacs-async.git -- Daimrod/Greg