From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: async.el: A simple asynchronous framework for Emacs Date: Tue, 19 Jun 2012 19:20:16 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1340151682 12986 80.91.229.3 (20 Jun 2012 00:21:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 20 Jun 2012 00:21:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 20 02:21:22 2012 Return-path: Envelope-to: ged-emacs-devel@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 1Sh8fh-0006gy-4Q for ged-emacs-devel@m.gmane.org; Wed, 20 Jun 2012 02:21:21 +0200 Original-Received: from localhost ([::1]:51251 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh8fg-0000Pl-U2 for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2012 20:21:20 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh8fe-0000Pa-Bk for emacs-devel@gnu.org; Tue, 19 Jun 2012 20:21:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sh8fc-0006mA-Kv for emacs-devel@gnu.org; Tue, 19 Jun 2012 20:21:17 -0400 Original-Received: from mail-gh0-f169.google.com ([209.85.160.169]:62393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh8fc-0006lr-Ds for emacs-devel@gnu.org; Tue, 19 Jun 2012 20:21:16 -0400 Original-Received: by ghrr18 with SMTP id r18so5983570ghr.0 for ; Tue, 19 Jun 2012 17:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:mail-followup-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=LXOx6nWP5U5vZRGPw8eKqpyW36QrlmcVEAlSbdoPhSk=; b=n8cnSu/zad7MGSWyCRr3IdrwLcMuVwdeQrvG2hC0/eHD3jy3qsHsNNPd9aj80UOJEv T0d5hLSNIV0omn1FsOc3q0OnrAnZrMJU/QPjjggzTrioULLY9PEierkz5Zkz0SeX4Fey ab5ZZCFiZCOknbXXi/Qb7hmL2G6L1+KwH+Nndqm22h0jjf4IMmmWan9QO14zMDqq1h7j znt2mkkN53XFpfNCabV5gDdrBfHz4OnaZQGrV2ntHy+9V4RGI75aI9BpXFI1i176PLu6 /k3Mt789F1X9CU7rOT+wq9yBLTO1TuFSpmb6qiZGHX+ovSfQwPDQ8FPoc9IqTDENHlF1 O99Q== Original-Received: by 10.50.158.130 with SMTP id wu2mr2928652igb.32.1340151673781; Tue, 19 Jun 2012 17:21:13 -0700 (PDT) Original-Received: from vulcan.local (c-98-215-105-167.hsd1.il.comcast.net. [98.215.105.167]) by mx.google.com with ESMTPS id z8sm13611372igi.5.2012.06.19.17.21.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jun 2012 17:21:12 -0700 (PDT) Original-Received: by vulcan.local (Postfix, from userid 501) id DEEABEFBE888; Tue, 19 Jun 2012 19:20:16 -0500 (CDT) Mail-Followup-To: emacs-devel@gnu.org In-Reply-To: (Stefan Monnier's message of "Tue, 19 Jun 2012 17:46:15 -0400") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (darwin) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.160.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:151037 Archived-At: Just a note, I've generalized async.el a bit further so that I can also have async-start-process -- which uses a different process that Emacs, but keeps the rest of the functionality the same. So, asynchronous invocation of a lambda with callback is the same as before: (async-start (lambda () ... in child process ...) (lambda (ret) ... handle return value from lambda ...)) Now I can get the same sort of functionality with other processes too: (async-start-process "cp" "/bin/cp" (lambda (proc) ... use proc to get exit code ...) "file1" "file2") Further, as with `async-start', if the callback function is nil you'll get a closure that you can inspect when you're ready. I've also added two new functions for working with these futures: (async-ready FUTURE) ; returns t if `async-get' would not block (async-wait FUTURE) ; waits for FUTURE to become ready, returns nil (async-get FUTURE) Lastly, you can call `async-get' now even if you did provide a callback, it will simply always return nil in that case (since the return value went to the callback). My motivation for `async-start-process' is that I want dired-async.el to use native cp/mv/rm if all files are local (file-remote-p == nil). But I want to keep the same infrastructure, i.e., the simple-to-specify callbacks for manipulating the dired buffer once the operation is complete. Updates are on GitHub. John