From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Contributing LLVM.org patches to gud.el Date: Thu, 12 Feb 2015 14:41:58 +0900 Message-ID: <878ug3ofdl.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <87y4oavxcy.fsf@fencepost.gnu.org> <87d25juy8m.fsf@fencepost.gnu.org> <83iofa8lu2.fsf@gnu.org> <87wq3qrvjz.fsf@fencepost.gnu.org> <83386d92ox.fsf@gnu.org> <874mqtsoqy.fsf@fencepost.gnu.org> <87mw4lnked.fsf@uwakimon.sk.tsukuba.ac.jp> <83egpw78tp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1423719756 31906 80.91.229.3 (12 Feb 2015 05:42:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Feb 2015 05:42:36 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 12 06:42:29 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 1YLmXk-0001Eq-Li for ged-emacs-devel@m.gmane.org; Thu, 12 Feb 2015 06:42:28 +0100 Original-Received: from localhost ([::1]:48535 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLmXj-0006TD-U2 for ged-emacs-devel@m.gmane.org; Thu, 12 Feb 2015 00:42:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLmXg-0006T6-Oi for emacs-devel@gnu.org; Thu, 12 Feb 2015 00:42:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLmXf-0006ge-Fn for emacs-devel@gnu.org; Thu, 12 Feb 2015 00:42:24 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:43583) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLmXZ-0006U3-OD; Thu, 12 Feb 2015 00:42:18 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 4FF3D1C38DA; Thu, 12 Feb 2015 14:41:59 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 22DCF1A26E3; Thu, 12 Feb 2015 14:41:59 +0900 (JST) In-Reply-To: <83egpw78tp.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:182939 Archived-At: Eli Zaretskii writes: > I really doubt that people prefer using a debugger that lacks basic > features, like remote debugging, even on GNU/Linux, more so on > *BSD. If they do, perhaps printf debugging is a contender as well? Indeed it is. I use it all the time (in Python programs). > And what about all the advanced features, like fork-following, JIT > debugging, probe points, reverse execution, record and replay, etc.? What in the world are you talking about? ;-) At my level, I could care less. Furthermore, those features aren't discoverable unless you are enough of a specialist to need them. (I have to browse the gdb help almost every time I do any debugging, and this is the first I've heard of any of them.) That is precisely the point here. (BTW, a technical point: I wonder how many of them are inspired by the need to get at information that gcc could provide, but doesn't?) > IOW, the above is not just personal preference, it has at least some > basis in GDB features that LLDB lacks. Until it grows them, it is not > a serious contender, and not just for personal preference reasons. One man's feature is another man's YAGNI. It's just personal preference. A difference in terminology about "taste", that's all. But you seem to missing the point of the "innovator's dilemma," which is that by deliberately targeting "downmarket", you can acquire the resources to develop quickly. IOW, lldb *will* grow those advanced features. Furthermore, although academia does not encompass the whole "upmarket", it is an upmarket, and I suspect they may be just as demanding as you are, though for different features. What the LLVM devotees claim is that a better factored design for the whole toolchain allows extremely rapid development of features that the front-runner got only with great effort. Need proof? "GNU/Linux" (and Andy T will tell you that Linux is hardly "well-factored" :-). QED > If you mean that GDB development should not rest on its laurels, > then I very much agree. I don't see any signs that it does, > fortunately. No, that's not what I mean. What I mean is that it may very well be misdirecting its effort in concentrating on the most demanding use cases. I understand the issue of paid developers you refer to below. But surely they're a small minority of contributors, even if they likely have disproportionate "power" to direct development resources (often not limited to their own and their employers'). I'm sure there are plenty of resources to improve the "user experience" -- if those volunteers can be convinced to listen to the naive or occasional user. That's where the "jawbone" comes in. There's also the fact that apparently the LLVM *project* is better factored than the GNU Project. I get the impression that GDB's needs are not so high on GCC's priority list. > We are not talking about replacing Emacs with LLDB, so this analogy, > even if true, doesn't get us anywhere. We are talking about whether > we should rush to include LLDB support in Emacs. I say a niche > application of insufficient usability doesn't justify any rush. Who's *rushing*? There is *already* a patch, produced by interested volunteers. The issue is when will the *foot-dragging* *stop*? > Are you saying that GDB doesn't support clang on GNU/Linux well > enough, so LLDB is the only practical alternative for those who use > clang? Of course not. I'm saying exactly what I wrote: lldb satisfies my needs in some of my use cases better than gdb does. If that generalizes to other occasional users of debuggers, gdb may be suffering from the "innovator's dilemma". > I didn't say we should never include its support. I just said I > see no reason to consider waiting harmful in this case. Waiting isn't harmful. The reason for waiting is, and the possibility that the wait may be forever is. > If someone needs that yesterday, they can apply the patch submitted > here, it's a simple patch to a single Lisp file. I shall do so, and do the same favor for my downstream. Apparently Stefan intends to do the same. > Just read the LLDB's "Status" page and development list, and you > will see what I mean. We have created a tempest in a teapot. There's no "we" about it. And it's hardly a teapot. Think about it: Richard is trying to suppress free software distribution temporarily, in one special -- and especially important -- channel, because he's considering making that decision permanent. This is an issue of concern to all free software advocates. We need to understand what is happening here, or we're mere fanboys. There is plenty of half-baked software supported by Emacs, just because it *can* be supported. Subject to being free software, meeting code quality standards, and assignment (all of which appear to be satisfied, or would be satisfied soon), normally the actual push is automatic (although particularly marginal features and new full applications often get farmed out to ELPA). No? > At least in GDB case, development is to a large degree driven by > industry needs, since several core developers actually get paid for > their work. That is why GDB sees so many new features that support > advanced CPU and systems development by major vendors, like > SysTaps, MPX, etc. Good for GDB.[1] But that's irrelevant to the question of refusing to distribute copyleft software which supports free software, and is already produced. Especially if you are correct that lldb is no threat to gdb! Footnotes: [1] Except that it is a symptom often indicative of the "innovator's dilemma".