From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: vc-*-root finctions Date: Fri, 22 Feb 2008 11:02:14 -0800 Message-ID: <200802221902.m1MJ2ECs006265@sallyv1.ics.uci.edu> References: <87skzn3mq9.fsf@ambire.localdomain> <87mypvxzd2.fsf@ambire.localdomain> <200802201850.m1KIofIk000198@sallyv1.ics.uci.edu> <87tzk2xr2q.fsf@ambire.localdomain> <200802211835.m1LIZcZ5005055@sallyv1.ics.uci.edu> <87ablt3vfx.fsf@ambire.localdomain> <200802221542.m1MFgSre027158@sallyv1.ics.uci.edu> <87skzk3nfa.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1203707294 32748 80.91.229.12 (22 Feb 2008 19:08:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Feb 2008 19:08:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Thien-Thi Nguyen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 22 20:08:29 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JSdCo-0002Sz-Lm for ged-emacs-devel@m.gmane.org; Fri, 22 Feb 2008 20:05:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JSdCI-0001bq-He for ged-emacs-devel@m.gmane.org; Fri, 22 Feb 2008 14:04:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JSdCC-0001YB-69 for emacs-devel@gnu.org; Fri, 22 Feb 2008 14:04:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JSdCB-0001Wy-73 for emacs-devel@gnu.org; Fri, 22 Feb 2008 14:04:31 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JSdCB-0001Wj-1m for emacs-devel@gnu.org; Fri, 22 Feb 2008 14:04:31 -0500 Original-Received: from sallyv1.ics.uci.edu ([128.195.1.109]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1JSdCA-0002fR-CP for emacs-devel@gnu.org; Fri, 22 Feb 2008 14:04:30 -0500 X-ICS-MailScanner-Watermark: 1204311736.11397@wd0DJjId3xfATHbT0e7HaA Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by sallyv1.ics.uci.edu (8.13.7+Sun/8.13.7) with ESMTP id m1MJ2ECs006265; Fri, 22 Feb 2008 11:02:14 -0800 (PST) In-Reply-To: <87skzk3nfa.fsf@ambire.localdomain> (Thien-Thi Nguyen's message of "Fri, 22 Feb 2008 18:34:33 +0100") Original-Lines: 88 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.363, required 5, autolearn=disabled, ALL_TRUSTED -1.44, TW_SV 0.08) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:90000 Archived-At: Thien-Thi Nguyen writes: > () Dan Nicolaescu > () Fri, 22 Feb 2008 07:42:28 -0800 > > Because if forces a backend implementor to read two things > instead of one. > > Not really. All you need to know to implement is in the > Commentary. The rationale doesn't add any more information, > just design background. I asked what is KICKP because it's not a familiar predicate name and you referred to the commentary in the code. > Well, you are effectively introducing two functions, but > squeezing them into one with a very weird interface. Explain > how is that allows for less maintenance. > > Look at the overall picture. In the present system, each > backend must decide synchronicity, do scratch buffer and > subprocess maintenance, compute the result, and do a function > call. You make it sound like it's a big deal, it's not. > This can be error prone (vc-svn-dir-status from vc-svn.el 1.71 leaks > buffers, e.g). Because it's still work in progress, Tom will surely take care of that when he gets a chance. > In the proposed system, the backend need only decide synchronicity > and compute its result; vc-status-refresh does the rest. Looking at this again: the KICKP silliness is completely unnecessary, you might as well have 2 functions: vc-BACKEND-start-vc-status-command and vc-BACKEND-process-status-result. They are 2 different things, why obfuscate them by putting them in the same function? The problem is that your scheme breaks if the backend needs to run more than one process to compute the status. Like, for example, vc-git-dir-state does. When doing the current design I considered putting vc-exec-after in vc-refresh, but decided not to precisely for that reason: not wanting to constrain the backend to run a single command. So yes, the current system where to vc core asks the backend "compute the status result and tell me when you are done" has some reasoning behind it. (And it's nothing new, that how most asynchronous work gets implemented). All the synchronicity stuff is completely orthogonal to this. > True, vc-status-refresh becomes more complex, but the overall > reduction in (redundant) complexity is a win. > > How about way too complex? > > Just stick w/ the Commentary, then; that explains the interface > requirements. Lots of things are complex in the core so that > the interfaces are simple and regular. This is one of them. I disagree that overall model is less complex in your case. > Can you please explain what you mean rather than hand wave? > > Given that you are replacing existing working code, it would > be nice if you'd explain what problem you are trying to > solve, and why the approach you took is the right way to > solve the problem (other than applying the NIH principle). > > I have tried to explain it but since i don't know where you fail > to understand things, i don't know how to explain it better. This is the first time you explained "why" not only "what", it would have been a lot easier if you would have done that from the start. Not adding so many unrelated issues would have helped too. I gave you the benefit of the doubt that you might have uncovered some unseen problem, but not it's clear that you have not. More, the proposed design has other core problems. > When i fixed the vc-svn.el 1.71 bug, that was when i started to What bug is that? Not sure what are you referring to, 1.71 is my commit that helps implement a missing feature...