From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: GnuTLS for W32 Date: Tue, 03 Jan 2012 08:06:51 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87aa659bpw.fsf@lifelogs.com> References: <87ty4fbje8.fsf@lifelogs.com> <83ehvjs8t5.fsf@gnu.org> <87pqf3bcom.fsf@lifelogs.com> <83boqns68o.fsf@gnu.org> <87liprazr1.fsf@lifelogs.com> <83wr9bqez3.fsf@gnu.org> <87y5tr9dwv.fsf_-_@lifelogs.com> <87k45alwgb.fsf@wanadoo.es> <87fwfyltm1.fsf@wanadoo.es> <87boqmlrma.fsf@wanadoo.es> <87ty4e9j19.fsf@lifelogs.com> <83obumqa0v.fsf@gnu.org> <87ipktag2e.fsf@lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1325596042 14325 80.91.229.12 (3 Jan 2012 13:07:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2012 13:07:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 03 14:07:19 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ri45G-00018Q-2z for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2012 14:07:18 +0100 Original-Received: from localhost ([::1]:44882 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri45F-0000IG-Ib for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2012 08:07:17 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri45C-0000I9-OQ for emacs-devel@gnu.org; Tue, 03 Jan 2012 08:07:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ri45B-0008Eu-2h for emacs-devel@gnu.org; Tue, 03 Jan 2012 08:07:14 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:47574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri45A-0008Eo-Hr for emacs-devel@gnu.org; Tue, 03 Jan 2012 08:07:13 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ri457-00012V-5g for emacs-devel@gnu.org; Tue, 03 Jan 2012 14:07:09 +0100 Original-Received: from c-76-28-40-19.hsd1.vt.comcast.net ([76.28.40.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jan 2012 14:07:09 +0100 Original-Received: from tzz by c-76-28-40-19.hsd1.vt.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jan 2012 14:07:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 122 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-76-28-40-19.hsd1.vt.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) Cancel-Lock: sha1:Y39y+W87u9nyuX/9T+93/SUx9kg= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:147206 Archived-At: On Tue, 03 Jan 2012 02:14:19 -0500 Eli Zaretskii wrote: >> From: Ted Zlatanov >> Date: Mon, 02 Jan 2012 17:35:21 -0500 >> EZ> It makes sense, but how is ELPA easier than any other download EZ> address? All that's needed is to download a single zip archive and EZ> unzip it. Why does it matter if it comes from ELPA or from EZ> elsewhere? >> >> ELPA updates can be done entirely from within Emacs. EZ> See below: currently, using this for anything not Lisp-based, like EZ> installing a new dynamic library, is a pipe dream. (Actually, even EZ> downloading a new version of a Lisp library into a running session has EZ> its problems, as discussed here recently; but I digress.) You're taking current technical limitations and applying them to a UI comparison. The package.el UI is far superior to a download+unzip process, especially if that process needs to happen more than once and for more than one package. >> Downloading and unzipping a file is a nuisance. Imagine if you >> asked GNU/Linux users to do the same. "But they have package >> managers..." Exactly! And so does Emacs, now that package.el is >> here! EZ> And I thought only Windows users were spoiled enough to demand EZ> one-click installations. "Downloading and unzipping is a EZ> nuisance"... sheesh. It's 2012. Emacs must be compared with Firefox and Chrome, not with vi/vim. If you don't see how passing the download+unzip burden to the user is a nuisance to them and consider it "spoiling," I think that's unfortunate. >> Can Emacs modify the DLL search path on W32 so it can install some DLL >> from ELPA and then activate it dynamically? Or does it require a >> restart and modifying the global PATH? Either way, can the process be >> automated? EZ> We currently lack infrastructure to replace a DLL that is already used EZ> by a running Emacs process. The code that loads a DLL and initializes EZ> the function pointers used to access its APIs assumes this will be EZ> done only once in a given session, so currently we do need a restart. EZ> To be able to replace a DLL without restarting Emacs, we would need to EZ> add code to free and unload a used DLL from the Emacs process, and EZ> then load the new one. This might be complicate if there are data EZ> structures lying around that use the DLL facilities, like an existing EZ> connection using GnuTLS or an image displayed using an image DLL. We EZ> will need to shut down the relevant Emacs features before replacing EZ> the DLL. EZ> There will also be complications with this if another Emacs process EZ> runs the same binary and uses the same DLL, because I don't think you EZ> can overwrite the DLL from under the feet of that other process. EZ> If you are thinking about a limited goal of installing for the first EZ> time a DLL that does not yet exist and is not loaded into Emacs, then EZ> it can be done, although some code will need to be written for that as EZ> well, and I'm not sure package.el is designed to handle such EZ> "packages". Moreover, I'm not sure such a limited goal would be in EZ> the spirit of package managing, since upgrading an installed package EZ> is an important part of that, perhaps more important than the initial EZ> installation. OK, so let's do a restart after a DLL package install or upgrade. It's better than nothing. Can this process be reused for other DLLs like the libxpm DLL? Can we activate the new DLL after Emacs restarts, so the old one will remain active as long as Emacs is using it and the user is not forced to restart immediately? I'm not sure if multiple Emacs processes are an important use case. I would guess it's an edge case on W32 and can probably be handled by scanning the process table and insisting that all Emacs instances be shut down. JB> But anyway, the issue is not just monitoring. Someone has to build JB> updated binary GnuTLS packages for Windows. That Eli just did it does JB> not mean we can burden him with the task forever. >> >> We can automate that. EZ> Who exactly are "we" in this sentence? emacs-devel; at least me specifically. >> Eli and Nicos have done the hard part, I think. EZ> I did nothing of the kind. I just configured and built the stock EZ> distribution, and fought whatever problems I found that prevented the EZ> build and the test suite to run to completion. The record of that EZ> fight includes 18 "issues" which I will be reporting to GnuTLS EZ> developers soon; until those are resolved, the build I did is anything EZ> but an automatic thing. And I don't see how anyone else's build can EZ> be fully automated, unless the "issues" I bumped into are due to my EZ> own misunderstandings. EZ> In any case, my experience indicates that having a steady feed of EZ> regular updates of Windows builds of any non-trivial package can never EZ> be based on a single individual, no matter if his/her name is Eli, EZ> Nicos, or something else. People invest in this some time for as long EZ> as they have it or are interested, and then go away to pursue other EZ> interests or go on with their lives. You cannot build a reliable EZ> infrastructure on something that is not part of your project. I'm not sure what you and Juanma want to say. That because we don't have salaried positions for tracking GnuTLS updates to Emacs, it's a burden? Or that we shouldn't even do it? Or that we need more people to run the Emacs infrastructure? What's the problem and how can we solve it? EZ> Bottom line, I feel that letting users download and unzip DLLs is by EZ> far more practical for this purpose than what you suggest. It also EZ> has the advantage of already working. It certainly is easier for us, the developers. But I think it's not the best solution we can offer to the users. Ted