From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Async package.el Date: Tue, 07 Apr 2015 04:19:30 +0300 Message-ID: <552330A2.1090406@yandex.ru> References: <55228FD2.3080501@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1428369599 20566 80.91.229.3 (7 Apr 2015 01:19:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Apr 2015 01:19:59 +0000 (UTC) Cc: emacs-devel To: bruce.connor.am@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 07 03:19:54 2015 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 1YfIBF-0002bV-Iq for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2015 03:19:53 +0200 Original-Received: from localhost ([::1]:42486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfIBE-0002mC-Ea for ged-emacs-devel@m.gmane.org; Mon, 06 Apr 2015 21:19:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfIB1-0002lr-2Y for emacs-devel@gnu.org; Mon, 06 Apr 2015 21:19:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfIAw-00042p-1a for emacs-devel@gnu.org; Mon, 06 Apr 2015 21:19:39 -0400 Original-Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:33545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfIAv-00042L-Pu for emacs-devel@gnu.org; Mon, 06 Apr 2015 21:19:33 -0400 Original-Received: by wiax7 with SMTP id x7so173070wia.0 for ; Mon, 06 Apr 2015 18:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BdsEUJpQbseKf4HUalCS0ImwNz732Kp8JM5o7dd/iD4=; b=QO8duWftLGz9bmgRA5dSqx/IOFy8vyfgcU8eVLMD/+V9E/kTvq4m0DbBPTZNrzR3m3 1C5HF9wFjabj1XSlnCld3IcjJFYtvAes0i1V6uQwZWbFOC+SVQfvj7afCG5slPdhtI8G qboNsy2SVZeQF6dsbIE3IkUTgd+XwZjyJ0DQNALCuS1WrjThitUdXZoq/UtWT0jZwRqZ 9gFPjiIenHC5zzuy2zyq8me1wTQAclrXtETRUi63XRv/NVlhrMcX4k9QB63+dEfXBa4j FUlzg/1INEIqv5IC4xmZttPUSRhUaZ8OrKNt7qZ3zxcGLFKc5qguKQYwmGo3nR1U6nwh JqCw== X-Received: by 10.180.92.138 with SMTP id cm10mr1507609wib.51.1428369573159; Mon, 06 Apr 2015 18:19:33 -0700 (PDT) Original-Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id w3sm8724413wiz.5.2015.04.06.18.19.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Apr 2015 18:19:32 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22a 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:185059 Archived-At: On 04/06/2015 05:32 PM, Artur Malabarba wrote: > Yes. I'm fixing it now. Thank you. > I agree. I'd also prefer to revert to use the sentence case (non-caps). b6610d55470c7e835472a581977ab6fad537c8b6 did that change, despite having the word "refactor" in its message. :P > Yes. I'm still trying to figure out how to do async tests. Currently all > package.el tests use a local directory as the repository, but the async > functions only kick-in for remote repositories. > Should I use GNU Elpa for the tests? Might that cause hydra to > unexpectedly complain due to random connection issues? I think ideally you'd run a small package archive server locally, launched with a tiny Python script. > I agree that's annoying and I have some similar plans. We can change the > package-installation logic to first download all files simultaneously, > and then unpack/compile all of them in the proper order. So large > upgrades would have a significant speed improvement. Right, that should be optimal, but the requires changes are probably non-trivial. To take this further (and forgive the negativity), maybe we should back-pedal on adding the asynchronous interface to downloading package archives, too. While doing it in parallel is great, refreshing the table of packages right under the user's nose is bound to create problems. Here's one: M-x list-packages, press `i' in the displayed list, wait for the refresh to be done, see the `I' disappear. Can you imagine something like Ubuntu Software Center doing this and updating the packages list while the user's interacting with the interface? Aside from it being confusing, the more interface elements there are, the higher are the odds of this kind of update breaking something. While `list-packages' is far from complexity of analogous tools, maybe we should walk in that direction without having to support the complexity of asynchronously updating the packages list. The slowness of `list-packages' launch could be tackled in different ways. We want to have up-to-date information, but we don't have to: - Update it each time `M-x list-packages' is run. Doing it only once a day, by default, should be sufficient for most uses. GNU ELPA is updated less often than that anyway. - Wait until the user invokes `M-x list-packages' to update it. We could do it while Emacs is idle. Of course, we user might end up not doing anything the packages in the current session anyway, so it'll require some experimenting. Maybe check that `M-x list-packages' was called at least once since the idle update, and, conversely, still perform the synchronous update at the beginning of `list-packages' if the archives haven't been updated for a while. Both approaches should also lower the packages archives' server load, at the cost of being slightly less up-to-date.