From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: What's the problem? Date: Wed, 10 Dec 2003 10:36:54 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <4nzne0n0q1.fsf@collins.bwh.harvard.edu> References: <4nllpt3hr3.fsf@lockgroove.bwh.harvard.edu> <5bad69zd43.fsf@lister.roxen.com> <4noeuon378.fsf@lockgroove.bwh.harvard.edu> <4ny8tsgxy6.fsf@lockgroove.bwh.harvard.edu> <4nhe0ggv0u.fsf@lockgroove.bwh.harvard.edu> <4nk75bwjaf.fsf@lockgroove.bwh.harvard.edu> <4nsmjv8d32.fsf@collins.bwh.harvard.edu> <87iskpbloe.fsf@mail.jurta.org> Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AU6TV-0003QY-00 for ; Wed, 10 Dec 2003 16:42:05 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AU6TV-0002Xs-00 for ; Wed, 10 Dec 2003 16:42:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AU7Nj-0002AN-1O for emacs-devel@quimby.gnus.org; Wed, 10 Dec 2003 11:40:11 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AU7NI-00021s-A8 for emacs-devel@gnu.org; Wed, 10 Dec 2003 11:39:44 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AU7Ml-0001on-6L for emacs-devel@gnu.org; Wed, 10 Dec 2003 11:39:42 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AU7Mk-0001oN-Lu for emacs-devel@gnu.org; Wed, 10 Dec 2003 11:39:10 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AU6PI-0005Dz-00 for ; Wed, 10 Dec 2003 16:37:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AU6PH-0005Dr-00 for ; Wed, 10 Dec 2003 16:37:43 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AU6PH-0007nb-00 for ; Wed, 10 Dec 2003 16:37:43 +0100 Original-Lines: 38 Original-X-Complaints-To: usenet@sea.gmane.org 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" User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v) Cancel-Lock: sha1:LXKoDG4Ku5cOCmvu7LNuHYzceV4= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18618 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18618 On 10 Dec 2003, miles@lsi.nec.co.jp wrote: > IOW, it's annoying for the gnus programmer, but very easy for the > emacs implementation. Well, that's the rub, isn't it? Simon and I, being Gnus programmers, would like Emacs to provide something better than the current framework so the pain will be spread out instead of concentrated on us. I think that improvements to Emacs would be beneficial to far more people than improvements to Gnus, also. > Some questions are (1) are there only a few points within gnus that > represent most of the annoying delays Hashtable lookups, list traversals, and arithmetic. Those three show up all over the place, and they are generally not mutually dependent when done on separate articles. > (2) do these places have fairly simple code structures that could be > split up into pieces like the above example, Generally yes, but sometimes they can get pretty complex (depending on the number of references in an article or on the number of scoring rules, for instance). > (3) do these pieces not depend on the long-term consistency of > any global state. I think so. > I don't know. A framework like the above could pretty simply handle > the I/O bound portion too, though. Remember the auto-save (over NFS or Tramp) problem I mentioned. I don't think it can be done the way you propose, but I'll be happy to be proven wrong. Ted