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: Wed, 11 Feb 2015 13:26:34 +0900 Message-ID: <87mw4lnked.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1423628836 19056 80.91.229.3 (11 Feb 2015 04:27:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Feb 2015 04:27:16 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 11 05:27:07 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 1YLOtG-0005ra-IC for ged-emacs-devel@m.gmane.org; Wed, 11 Feb 2015 05:27:06 +0100 Original-Received: from localhost ([::1]:43171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLOtF-0002HA-CV for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 23:27:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLOt1-0002Gx-25 for emacs-devel@gnu.org; Tue, 10 Feb 2015 23:26:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLOsz-00007K-Ca for emacs-devel@gnu.org; Tue, 10 Feb 2015 23:26:50 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:41807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLOst-0008VP-PM; Tue, 10 Feb 2015 23:26:44 -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 4F4381C3902; Wed, 11 Feb 2015 13:26:35 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 22BAA1A26E3; Wed, 11 Feb 2015 13:26:35 +0900 (JST) In-Reply-To: <874mqtsoqy.fsf@fencepost.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:182861 Archived-At: > Eli Zaretskii writes: > > When LLDB gets anywhere near GDB in functionality and usability, > > let alone surpasses it, maybe then I might get interested. Your personal preference for GNU software is well-known. But your preference doesn't help explain, let alone fight, the increasing popularity of LLVM that Richard perceives as a potential threat to software freedom, AIUI because of the legal and technical ease with which portions of LLVM could be replaced with proprietary software. BTW, in my usage, the only thing that lldb lacks that gdb has is my muscle memory (lldb's command set is much more regular, but therefore *different* and I haven't memorized it yet, partly because muscle- memory-compatible aliases are provided for the most common commands like "run", "backtrace", and "break"). I'm not a "power debugger" in C, so it doesn't surprise me that you find lldb less satisfactory. But this difference indicates you should be careful to worry about the "innovator's dilemma", where an inferior product is "cheaper" (in some sense) and takes over the non-power-user market, and in that way gains the resources needed to improve rapidly and decisively. David Kastrup writes: > Seems you missed where people stated that its willingness to talk > about values that can only be deduced by cooperation with the > compiler was making a crucial difference in usability over gdb. That's not really fair, David, for the same reasons. I was reporting personal experience and personal preference. Note that on Mac "Yosemite" the default compiler is clang, and gdb may not yet be so clued in to clang's idioms in DWARF or whatever debugging it emits, by comparison to its understanding of GCC. In other words, it's somewhat unfair to compare clang + gdb to clang + lldb[1], and I suspect that Richard may consider that "unfairness" to be a mitigating factor, because lldb would not be likely to infect the GNU world so quickly. > At any rate, you seem to be _totally_ on the other side of Richard on > this one. You want to start thinking about LLDB when it is getting more > useful than GDB, he wants to stop people from thinking about LLDB when > it is getting more useful than GDB. Touche! But they're really saying the same thing in different ways. Eli, again: > > For now, it's a niche debugger, not unlike dbx. Hardly. True, from one point of view Mac OS X itself is a niche OS. But from the same point of view, Emacs itself is a niche app. > > Why should we care so much if LLDB support will land today, next > > week, or next year? We shouldn't burn so much energy on even > > discussing it. Perhaps not discussing the philosophy on this list. But there are a *lot* of people using Emacs who are also using clang (essentially all Mac developers who use Emacs, for example). LLVM support is important to some of us, and it *is* *free* software. My take is that Stefan is correct: Just Do It. Among other things, somebody (David?) said something like "this kind of decision needs to be made many times by many maintainers, the rule needs to be clear and simple." Support for free software that Emacs users are already committed to should not be a problem, while Emacs functionality that advertises superior capabilities of non-GNU software should be avoided.[2] IMHO, Richard should spend his energy on the hard, important problems, like whether gcc and gdb need a good ass-kicking to address these usability issues (from what you write, the issue may not exist for that combination), or whether gdb should try to compete with lldb even when the compiler isn't gcc. > Well, GNU does not turn on a dime. So there is nothing wrong with > thinking ahead. It's absolute essential, actually, since Richard's preference is for core GNU tools to be monolithic so their main functionalities cannot be easily replaced (or in some cases even accessed) without large investment. That, while most competing projects have made agility of development a core value. > >> > Free Software is about freedom of developers as well. > >> > >> Not at its core. > > > > Yes, at its core: the freedom to change the code requires a developer > > who can actually do that. > > > > You'll find that wherever conflicts of interest between users and > programmers are considered, Richard puts the users' interests first. Gag me! I find it very sad that free software advocates are making a distinction between users and developers. Footnotes: [1] Nor have I compared gcc + gdb to gcc + lldb! [2] I think the "deliberate attack" possibility is a red herring. And I disagree with Richard and Stefan on another issue: as much as I think the *existence* and *availability* of Excorporate is a good thing, I think it would be a strategically good idea to remind its users that GNU is not here to support them in that usage. I don't see any advantage to free software in having Emacs distribute it, even as part of ELPA. I somehow doubt that the availability of Excorporate will cause any Outlook users to switch to Gnus, although it might catch some Thunderbird users. OTOH, users of gud.el will be able to switch from lldb to gdb more easily, and I find that more plausible (especially on a case-by-case basis).