Re: Contributing LLVM.org patches to gud.el

[Stephen J. Turnbull]

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".