From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christopher Schmidt Newsgroups: gmane.emacs.devel Subject: Re: async 1.0 Date: Mon, 25 Jun 2012 15:53:39 +0100 (BST) Message-ID: <87wr2vzbm7@ch.ristopher.com> References: <87vcij7rvi.fsf@mithlond.arda> <82d34r8ej9.fsf@gmail.com> <87r4t4zr9l@ch.ristopher.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1340636042 17863 80.91.229.3 (25 Jun 2012 14:54:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2012 14:54:02 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 25 16:54:01 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 1SjAfv-00089L-V6 for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2012 16:54:00 +0200 Original-Received: from localhost ([::1]:49221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjAfv-0002z5-W0 for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2012 10:53:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjAfn-0002xp-4e for emacs-devel@gnu.org; Mon, 25 Jun 2012 10:53:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SjAfg-0004QO-Ex for emacs-devel@gnu.org; Mon, 25 Jun 2012 10:53:50 -0400 Original-Received: from ristopher.com ([146.185.21.93]:39864 helo=saturn.ch.ristopher.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjAff-0004Q1-Us for emacs-devel@gnu.org; Mon, 25 Jun 2012 10:53:44 -0400 Original-Received: by saturn.ch.ristopher.com (Postfix, from userid 0) id 15F1020B18; Mon, 25 Jun 2012 15:53:40 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ch.ristopher.com; s=mail; t=1340636020; bh=pMwCszoguVO5TyAftMxtkvpCyOur5UFT0CUqKsBaB2I=; h=From:To:Subject:In-Reply-To:References:Message-ID:MIME-Version: Content-Type:Date; b=G/IHNMC+b8GVSLtPp+Cq7Od5hiMwf8qhAnMcLYOYCqMVL3RFX2m0XI0lpuzblFv3h Pu47aYRC32m6ZtRI+hw0bNbCkD5oLwrIo/ZZU4YrcNjHiOO1xYMeS7nrbYVDialXvD ecwn7gwqhIefrDRl7lEFVL1Rt8h6qPo59w6pdXro= In-Reply-To: (John Wiegley's message of "Sun, 24 Jun 2012 16:01:16 -0500") Mail-Followup-To: emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 146.185.21.93 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:151155 Archived-At: John Wiegley writes: >>>>>> Christopher Schmidt writes: [...] > I think that it should definitely be a core service, but _of course_, > "opt-in" until it is discovered that each particular use of async.el > cannot break in any way (and I'm open to the thought that this may > never be true, and it will be opt-in forever). You did not mention that before. [...] > Further, even though enabling `dired-use-async' purports to make dired > async, it doesn't really. The user has to additionally install async > through ELPA for that variable to become meaningful. This is a > needless burden on the user, not all of whom are familiar and > comfortable with installing packages through ELPA. Async should be > something people can just turn on, not something they have to jump > through hoops to get. I was not arguing in favour of making async.el a GNU ELPA package rather than a core GNU Emacs package. I did not question asynchronous beef-ups of dired or smtpmail per se. [...] >> smtpmail-async would break my setup. It would break my setup in a >> way very hard to fix. > > Can you explain that a bit more? Otherwise, it sounds like FUD. This is off-topic. Executive summary: I rewrote the network stack of Emacs in order to perform certificate pinning and OCSP verification. This is integrated into a setup where user-visible mutable state (this is fuzzy!) is stored persistently on a per-frame basis - frames bound to distinct modes and instances - with these instances keeping track off all file and network activity. This stuff is integrated into my OS environment, with Emacs modifying firewall rules whenever necessary. >> Other than that, GNU Emacs has excellent asynchronous process and >> network facilities already. Why not use them? > > And these would be? I'm not aware of any core service that lets me > asynchronously call lambdas. I do not like that you snipped context out of my quotes. Other than that, GNU Emacs has excellent asynchronous process and network facilities already. Why not use them? In this case one does not loose customisation, progress, error, debugging and bidirectional communication functionality. Of course this would require some development effort, but in the end there are only very few core packages (tramp, dired, mail sending, anything else?) that benefit from a true asynchronous dispatch-and-forget implementation anyway. [...] When it comes to side-effect free CPU work that does not require user feedback this [async.el] is the way to go. (I have no actual example for this use-case, though.) When it comes to I/O, and this is what all posts in this thread are about, async.el IMO totally undermines everything Emacs stands for. Why do you want complex forms to be called asynchronously out of the context of the original Emacs process? Does the advantage of an easy and little intrusive implementation in comparison to Masashi's deferred.el or the use of manual async primitives outweigh the loss of "customisation, progress, error, debugging and bidirectional communication functionality"? Does it outweigh that a minority of end-users would have to fiddle with async to translate their customizations into child emacsen? Is there any non-I/O (non-tramp) related use-case for async.el? The point I was trying to make is that async.el can make development and actual end-user usage both simpler and harder. Some issues could be avoided by using non-forking asynchronous I/O in the first place. "A nice short-term solution with severe long-term consequences." (Now that I looked up 'severe' in a dictionary, I think it is the wrong term. I wanted to say that async.el can cause unexpected surprises.) [...] >> If async.el somehow finds its way on my machine, the very first form >> in my init.el will be responsible for redefining all >> `async-'-functions to unconditionally signal an error. > > Again, a bit FUD-y. I am sorry. That comment was not appropriate, it does not matter. Implementing asynchronous smtp on top of smtpmail within 19 LOC is impressive. No doubt whatsoever. This is a great opt-in feature. You did not mention opt-in-ness before and to me it was not obvious from the context, especially because AFAICT dired-async.el unconditionally redefines dired internals to use async.el. John, I have no intention to spread FUD. I am sorry for offending you if that is the case. I have lots of respect for your work.[1] I am not a GNU Emacs developer and I do not want to be one. I was just brainstorming, raising a few points that went through my head, from an Emacs user point of view, when I read the messages regarding async.el. I was under the impression that you would use async.el to revamp the core packages of Emacs, one after another, wreaking havoc upon my precious customizations. Greetings, Christopher [1] I borrowed some stuff from your dotemacs. Eshell is featured in a Hollywood movie and your work on git modularization should make Boost fun again. I loved your OpenGenera blog post ;) This is great stuff!