RE: GDB and scripting languages - which

RE: GDB and scripting languages - which

[Kaz Kylheku]

Jim Blandy wrote:
> I would prefer that GDB use a single extension language, and that that
> language be Python. 

I think it would be best to have a libgdb.so shared library with a
well-defined API. Then people can write their own bindings to call it
from whatever programming environment suits them.

I think Python is a retarded pile of crap and won't use it; moreover, I
don't care to discuss the reasons why.

But I don't want to get in your way of using it if you want, because
that would be bad engineering.

> talents in Guile.  But Guile has had more than enough time to attract
> uses and users on its own merits, and compared to Python, it hasn't
> worked out.  It's time to cut our losses.)

Guile is not even particularly attractive people who are already Scheme
programmers. For serious Scheme work, there are better implementations
out there. 

> Maintaining such libraries for multiple extension languages would be
> wasted work, and python is good enough.

It would be fine if a binding library for a just a single language were
maintained, but if there was a separation between that and a clean API,
rather than too much reliance on the internals. For instance, it would
not be very nice if the API relied some internal data structures of a
particular interpreter, and used that representation for passing values
back and forth.

Re: GDB and scripting languages - which

[Eli Zaretskii]

> Date: Mon, 15 Jan 2007 10:29:24 -0800
> From: "Kaz Kylheku" <kaz@zeugmasystems.com>
> 
> Jim Blandy wrote:
> > I would prefer that GDB use a single extension language, and that that
> > language be Python. 
> 
> I think it would be best to have a libgdb.so shared library with a
> well-defined API. Then people can write their own bindings to call it
> from whatever programming environment suits them.

Aren't we talking about a scripting language to allow decent scripting
_inside_ GDB, i.e. about extension _to_ GDB, as opposed to making GDB
an extension of other programs?

> Guile is not even particularly attractive people who are already Scheme
> programmers. For serious Scheme work, there are better implementations
> out there. 

Aren't we talking about a language for extending GDB, as opposed to a
language ``for serious Scheme work''?

Re: GDB and scripting languages - which

[Kip Macy]

>
> Aren't we talking about a scripting language to allow decent scripting
> _inside_ GDB, i.e. about extension _to_ GDB, as opposed to making GDB
> an extension of other programs?
>

Yes. The comments are not germane to the current discussion.

 -Kip

Re: GDB and scripting languages - which

[Jim Blandy]

"Kaz Kylheku" <kaz@zeugmasystems.com> writes:
> Jim Blandy wrote:
>> I would prefer that GDB use a single extension language, and that that
>> language be Python. 
>
> I think it would be best to have a libgdb.so shared library with a
> well-defined API. Then people can write their own bindings to call it
> from whatever programming environment suits them.

This would be the right design, if we were writing from scratch.  But
it's a very large effort.

Also, one of the consequences of C being a low-level language is that
interfaces are more sensitive to changes to the library's internals.
It's much easier to design a (say) Python interface that allows us to
continue to improve GDB's architecture internally without breaking
clients.

> Guile is not even particularly attractive people who are already Scheme
> programmers. For serious Scheme work, there are better implementations
> out there. 

Yep.

RE: GDB and scripting languages - which

[Kaz Kylheku]

Eli Zaretskii:
> Aren't we talking about a scripting language to allow decent scripting
> _inside_ GDB, i.e. about extension _to_ GDB, as opposed to making GDB
> an extension of other programs?

I don't see a significant difference between these situations. I'm only
thinking about a process image, in which I simultaneously have GDB and
the run-time of some programming language. Who gets the main entry point
when that image is started is largely irrelevant.

If GDB is packaged in such a way that it can be used as a component in
other programs, the behavior of an extended GDB can be easily achieved.
Simply link GDB to a small driver program which passes control back to
GDB. that small driver program also attaches to the programming language
run-time of choice, initializes it, and registers some hooks in GDB to
be able to use it.

> > Guile is not even particularly attractive people who are 
> already Scheme
> > programmers. For serious Scheme work, there are better 
> implementations
> > out there. 
> 
> Aren't we talking about a language for extending GDB, as opposed to a
> language ``for serious Scheme work''?

Extending GDB could be serious work, and if that work is done in Scheme,
then it is serious Scheme work.

Re: GDB and scripting languages - which

[Jim Blandy]

"Kaz Kylheku" <kaz@zeugmasystems.com> writes:
>> > Guile is not even particularly attractive people who are 
>> already Scheme
>> > programmers. For serious Scheme work, there are better 
>> implementations
>> > out there. 
>> 
>> Aren't we talking about a language for extending GDB, as opposed to a
>> language ``for serious Scheme work''?
>
> Extending GDB could be serious work, and if that work is done in Scheme,
> then it is serious Scheme work.

I think Kaz's intention was simply to agree with me that Guile is a
poor choice.

Scheme, even an implementation other than Guile, is a contentious
choice; pushing it will probably result in nothing at all happening,
which I think would be sad.  This has happened in the past.  I want to
have something, rather than the (almost) nothing I have had for the
last seventeen years.

> Eli Zaretskii:
>> Aren't we talking about a scripting language to allow decent scripting
>> _inside_ GDB, i.e. about extension _to_ GDB, as opposed to making GDB
>> an extension of other programs?

What Kaz is really asking for is a C API for GDB.  I'm very concerned
about exporting C interfaces from GDB.  I think they will age poorly,
and constrain our ability to improve GDB.

GDB and scripting languages - which

[Daniel Jacobowitz]

First, disclaimer: this particular topic is a classic source of
bikeshedding.  I'd like to avoid a prolonged discussion of scripting
language pros and cons on this list.  So, please, limit on-list
followups to the question of single versus multiple bindings and the
use of guile, OK?  If you want to rant at me about my heretic selection
of languages, feel free, but please don't reply to the list in that
case.

Basically, my question is whether we should support one language or
many, and if only one, which.  The GNU coding standards have this
to say:

  The standard extensibility interpreter for GNU software is GUILE
  (http://www.gnu.org/software/guile/), which implements the language
  Scheme (an especially clean and simple dialect of Lisp). We don't
  reject programs written in other scripting languages such as Perl and
  Python, but using GUILE is very important for the overall consistency
  of the GNU system.

So the obvious thing to do would be to have just one and have it be
guile.  I'm not sure how much consistency that really adds - I could
only find a handful of GNU programs embedding guile.  And it presents
another problem for me: I'm a pretty much incompetent Scheme
programmer.  I'm a lot more inspired to add a scripting language
that I can really use.

Python would be my first choice, today.  Mostly this is because I know
it.  However (comparing to guile only here), my impression is that the
user community and library of supporting modules is much stronger than
guile's.  For instance, while this isn't the most meaningful statistic,
there are eighteen times as many python-related packages in Debian as
guile-related.  A whole lot of those are reusable modules.

The advantage of adding multiple language bindings is that users will
have the choice of whichever is more familiar for them; I know that
various people have locally added guile, python, and perl in the past.
The disadvantage, of course, is the required amount of code
(maintenance, testing).  And if GDB comes with a library of useful
routines to load from user scripts, they'll be different for each
language.  And if programs ship their own handy scripts for developers
of those programs to use, they'll be in an assortment of different
languages.

So the short version is that if I were making the decision, for my own
benefit and independent of the GNU project and GDB's users, I'd add
only Python support.  For GDB's place in the GNU project, we should
probably have guile.  And I feel like the user convenience of a
selection of languages will outweigh the extra work of multiple
language bindings.

Accordingly, I am inclined to use multiple bindings, to include at
least Python and GUILE.  My current design relies on GDB/MI for most
control of GDB; I might put the MI parser on the C side of the
interface to allow MI results to be easily converted to lists / tuples
/ et cetera in each supported language, but other than that it
would be a fairly thin interface on top of MI.

(MI isn't the most convenient interface for scripting - I'm still
trying to figure out how it will interact with GDB's value objects, but
it will probably build on top of varobj to do so.  The symmetry is
nice; what you can do in scripts you ought to be able to do in a
GUI front end to GDB too so any MI extensions useful for one
are likely useful to the other.  However, this is the subject of
a later discussion, not this one.)

I'd really appreciate hearing what others think.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and scripting languages - which

[Kip Macy]

> Accordingly, I am inclined to use multiple bindings, to include at
> least Python and GUILE.  My current design relies on GDB/MI for most
> control of GDB; I might put the MI parser on the C side of the
> interface to allow MI results to be easily converted to lists / tuples
> / et cetera in each supported language, but other than that it
> would be a fairly thin interface on top of MI.
>
> (MI isn't the most convenient interface for scripting - I'm still
> trying to figure out how it will interact with GDB's value objects, but
> it will probably build on top of varobj to do so.  The symmetry is
> nice; what you can do in scripts you ought to be able to do in a
> GUI front end to GDB too so any MI extensions useful for one
> are likely useful to the other.  However, this is the subject of
> a later discussion, not this one.)


This is what I did to add perl support and it worked fairly well. Some
work will be needed to handle exceptions gracefully on the scripting
library side. I prefer python too. However, I think it is more
important that there be *a* scripting language than that it be the
"right" one. Getting bogged down in bike-shedding is counter to
everyone's interests.

 -Kip

Re: GDB and scripting languages - which

[Daniel Jacobowitz]

On Mon, Jan 08, 2007 at 02:39:28PM -0800, Kip Macy wrote:
> This is what I did to add perl support and it worked fairly well.

Right.  In case I forget to credit you in the future: I still have a
copy of your patches, and though I didn't reuse any of it, I definitely
consulted and appreciated them.

At the moment I have a very rough prototype using Guile and GDB/MI.

> Some work will be needed to handle exceptions gracefully on the
> scripting library side. I prefer python too. However, I think it is
> more important that there be *a* scripting language than that it be
> the "right" one. Getting bogged down in bike-shedding is counter to
> everyone's interests.

Amen.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and scripting languages - which

[Kip Macy]

On 1/8/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Jan 08, 2007 at 02:39:28PM -0800, Kip Macy wrote:
> > This is what I did to add perl support and it worked fairly well.
>
> Right.  In case I forget to credit you in the future: I still have a
> copy of your patches, and though I didn't reuse any of it, I definitely
> consulted and appreciated them.
>
> At the moment I have a very rough prototype using Guile and GDB/MI.

Cool. I never considered my work in any way a finished product. It was
intended to serve as  a rough draft / proof of concept of how a
general purpose scripting interface could work using MI. I had hoped
to get more feedback than I did, but I am happy to hear that it ended
up serving its purpose.

I look forward to seeing this functionality in GDB.

 -Kip

Re: GDB and scripting languages - which

[Bob Rossi]

> I'd really appreciate hearing what others think.

Hi Daniel,

I've also had as a personal long term goal to add scripting support to
GDB. My approach is going to be to create a libgdbmi, which deals with
parsing MI and creating C data structures. I think there can also be
higher level functions in this library that keep the state of the GDB 
connection and other things for whoever is using the library.  Then each 
scripting language can create an extension which exports these
functions or improves upon them. This should allow any scripting language 
to work with GDB. This is the approach I think would work best.

Bob Rossi

Re: GDB and scripting languages - which

[Jim Blandy]

I would prefer that GDB use a single extension language, and that that
language be Python.  Python has more momentum than Guile in almost any
way one might measure it:

- number of users who are familiar with it
- body of large programs written in it
- number of modules available for reuse
- number of programs embedding it
- number of books available for learning it

(I was the maintainer of Guile for several years, and I say this with
much kind regard for the people who have invested their time and
talents in Guile.  But Guile has had more than enough time to attract
uses and users on its own merits, and compared to Python, it hasn't
worked out.  It's time to cut our losses.)

It takes a lot of effort to pull together a useful interface for an
application.  Sustaining that effort for several different extension
languages would be a substantial burden.  I understand that it's a
quick weekend's work to implement a Guile or Python function that
passes MI requests and responses back and forth between Guile and GDB.
But this is just a bare stub of an interface.  An extension language
interface needs to provide higher-level functions:

- create and delete breakpoints, with callbacks when hit
- look up symbols
- enumerate object files, compilation units, functions, local variables
- pattern-match and construct types
- map between source locations and machine code locations
- represent container types like C++ map<> and vector<> in terms of
  their interface, not their implementation: a map<> is a key/value
  mapping, not a red-black tree; a vector<> is an ordered series of
  elements, not a length, size, and content pointer, or however it's
  done

All these things can be done via MI (perhaps with some extensions),
but it would be silly to have everyone writing their own functions to
send MI back and forth; there should be a library of functions to do
all this for you, so script authors can concentrate on what they
actually want GDB to do, instead of managing the details of MI.

Maintaining such libraries for multiple extension languages would be
wasted work, and python is good enough.

Re: GDB and scripting languages - which

[Bob Rossi]

On Tue, Jan 09, 2007 at 12:11:50PM -0800, Jim Blandy wrote:
> 
> I would prefer that GDB use a single extension language, and that that
> language be Python.  Python has more momentum than Guile in almost any
> way one might measure it:
> 
> - number of users who are familiar with it
> - body of large programs written in it
> - number of modules available for reuse
> - number of programs embedding it
> - number of books available for learning it

There is one issue I think that makes using TCL a good scripting
language for GDB. I'm not sure how important this is however. If the 
language is TCL, it'll be very easy to test in GDB's test suite.

Bob Rossi

Re: GDB and scripting languages - which

[Paul Koning]

>>>>> "Bob" == Bob Rossi <bob_rossi@cox.net> writes:

 Bob> On Tue, Jan 09, 2007 at 12:11:50PM -0800, Jim Blandy wrote:
 >>  I would prefer that GDB use a single extension language, and that
 >> that language be Python.  Python has more momentum than Guile in
 >> almost any way one might measure it:
 >> 
 >> - number of users who are familiar with it - body of large
 >> programs written in it - number of modules available for reuse -
 >> number of programs embedding it - number of books available for
 >> learning it

 Bob> There is one issue I think that makes using TCL a good scripting
 Bob> language for GDB. I'm not sure how important this is however. If
 Bob> the language is TCL, it'll be very easy to test in GDB's test
 Bob> suite.

I would think it's good to stay away from TCL.  I won't say more
because I don't want to start a language war.  Python can certainly be
scripted, and it has good support for testsuite type things.

	  paul

Re: GDB and scripting languages - which

[Daniel Jacobowitz]

On Tue, Jan 09, 2007 at 04:37:40PM -0500, Paul Koning wrote:
>  Bob> There is one issue I think that makes using TCL a good scripting
>  Bob> language for GDB. I'm not sure how important this is however. If
>  Bob> the language is TCL, it'll be very easy to test in GDB's test
>  Bob> suite.
> 
> I would think it's good to stay away from TCL.  I won't say more
> because I don't want to start a language war.  Python can certainly be
> scripted, and it has good support for testsuite type things.

[thanks]

More relevantly, TCL won't make it easier or harder to test in the
testsuite - it can't share files since dejagnu needs expect and
GDB won't be linked to that.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and scripting languages - which

[Nick Roberts]

 > I would think it's good to stay away from TCL.  I won't say more
 > because I don't want to start a language war.  Python can certainly be
 > scripted, and it has good support for testsuite type things.

TCL is what Totalview uses for it's CLI; it's quite adequate for basic
programming.  How complex will these scripts be?  Generally .gdbinit is
just a series of small functions.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: GDB and scripting languages - which

[Daniel Jacobowitz]

On Wed, Jan 10, 2007 at 10:48:02AM +1300, Nick Roberts wrote:
>  > I would think it's good to stay away from TCL.  I won't say more
>  > because I don't want to start a language war.  Python can certainly be
>  > scripted, and it has good support for testsuite type things.
> 
> TCL is what Totalview uses for it's CLI; it's quite adequate for basic
> programming.  How complex will these scripts be?  Generally .gdbinit is
> just a series of small functions.

I am actually expecting something much more complicated: for instance,
functions which know how to walk data structures and prettyprint them.
Folks already do that in .gdbinit, but the functions they use can
sometimes be mammoth.  The worst one I'm aware of uses "shell awk"
and "set logging" :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and scripting languages - which

[Nick Roberts]

 > I am actually expecting something much more complicated: for instance,
 > functions which know how to walk data structures and prettyprint them.
 > Folks already do that in .gdbinit, but the functions they use can
 > sometimes be mammoth.  The worst one I'm aware of uses "shell awk"
 > and "set logging" :-)

Will asynchronous operation be part of this project?  If so I can send a
new patch updated to current sources.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: GDB and scripting languages - which

[Daniel Jacobowitz]

On Thu, Jan 11, 2007 at 05:30:54PM +1300, Nick Roberts wrote:
>  > I am actually expecting something much more complicated: for instance,
>  > functions which know how to walk data structures and prettyprint them.
>  > Folks already do that in .gdbinit, but the functions they use can
>  > sometimes be mammoth.  The worst one I'm aware of uses "shell awk"
>  > and "set logging" :-)
> 
> Will asynchronous operation be part of this project?  If so I can send a
> new patch updated to current sources.

It won't be - but I intend for that to be part of the next release,
anyway.  The last patch you've posted should be enough, unless you've
made changes to it since you posted.

Sorry for taking so long; I hoped I'd have that reviewed by now.  I'm
going to put that on top of my review queue.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and scripting languages - which

[Eli Zaretskii]

> Date: Tue, 9 Jan 2007 16:53:37 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> I am actually expecting something much more complicated: for instance,
> functions which know how to walk data structures and prettyprint them.
> Folks already do that in .gdbinit, but the functions they use can
> sometimes be mammoth.  The worst one I'm aware of uses "shell awk"
> and "set logging" :-)

If someone is interested, Emacs has some examples of walking data
structures in .gdbinit.  Another example is in etc/emacs-buffer.gdb.

Re: GDB and scripting languages - which

[Kip Macy]

On 1/9/07, Nick Roberts <nickrob@snap.net.nz> wrote:
>  > I would think it's good to stay away from TCL.  I won't say more
>  > because I don't want to start a language war.  Python can certainly be
>  > scripted, and it has good support for testsuite type things.
>
> TCL is what Totalview uses for it's CLI; it's quite adequate for basic
> programming.  How complex will these scripts be?  Generally .gdbinit is
> just a series of small functions.

My intent when I added perl support to GDB (not my choice, its what
the company I was working at prefers), was to automate some fairly
complex triage. My personal experience with tcl would lead me to
believe that tcl is underpowered. Although with tcl it would be
possible, whereas with gdb's macro language it really isn't. I think
gdb's current macro support is more than adequate for .gdbinit.

    -Kip


         -Kip

Re: GDB and scripting languages - which

[Robert Dewar]

Paul Koning wrote:

> I would think it's good to stay away from TCL.  I won't say more
> because I don't want to start a language war.  Python can certainly be
> scripted, and it has good support for testsuite type things.

I agree that avoiding TCL is a good idea. In my experience,
TCL has proved hard to maintain.

Re: GDB and scripting languages - which

[Robert Dewar]

Robert Dewar wrote:
> Paul Koning wrote:
> 
>> I would think it's good to stay away from TCL.  I won't say more
>> because I don't want to start a language war.  Python can certainly be
>> scripted, and it has good support for testsuite type things.
> 
> I agree that avoiding TCL is a good idea. In my experience,
> TCL has proved hard to maintain.

I would support Python as a choice of scripting language, unlike
many other so-called scripting languages, it is a well designed
and engineered language from a syntactic and semantic point of view.

Re: GDB and scripting languages - which

[Mark Kettenis]

> From: Jim Blandy <jimb@codesourcery.com>
> Date: Tue, 09 Jan 2007 12:11:50 -0800
> 
> I would prefer that GDB use a single extension language, and that that
> language be Python.  Python has more momentum than Guile in almost any
> way one might measure it:
> 
> - number of users who are familiar with it
> - body of large programs written in it
> - number of modules available for reuse
> - number of programs embedding it
> - number of books available for learning it

This is certainly true in my little corner of the world.  It's fairly
easy to teach astronomers some basic python in two hours or so.

> Maintaining such libraries for multiple extension languages would be
> wasted work, and python is good enough.

Yes, we should spend the limited resources we have wisely.

Re: GDB and scripting languages - which

[Eli Zaretskii]

> Date: Mon, 8 Jan 2007 17:20:05 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> So the short version is that if I were making the decision, for my own
> benefit and independent of the GNU project and GDB's users, I'd add
> only Python support.  For GDB's place in the GNU project, we should
> probably have guile.

I think adding Python would be a useful first step.  It could be the
last, or we could later consider Guile as well.

Re: GDB and scripting languages - which

[Eli Zaretskii]

> Date: Sat, 13 Jan 2007 10:31:51 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> CC: gdb@sourceware.org
> 
> I think adding Python would be a useful first step.  It could be the
> last, or we could later consider Guile as well.

On second thought, what about Lua (http://www.lua.org/)?  It looks
like a language designed specifically for extending software packages.

(Sorry for answering after such a long delay.)

Re: GDB and scripting languages - which

[Pedro Alves]

Eli Zaretskii escreveu:
>> Date: Sat, 13 Jan 2007 10:31:51 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> CC: gdb@sourceware.org
>>
>> I think adding Python would be a useful first step.  It could be the
>> last, or we could later consider Guile as well.
>>     
>
> On second thought, what about Lua (http://www.lua.org/)?  It looks
> like a language designed specifically for extending software packages.
>
> (Sorry for answering after such a long delay.)
>
>   

What about TCL ?  Doesn't Insight make the job already half done?

Cheers,
Pedro Alves

Re: GDB and scripting languages - which

[Daniel Jacobowitz]

On Sat, Feb 10, 2007 at 02:28:09PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 13 Jan 2007 10:31:51 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > CC: gdb@sourceware.org
> > 
> > I think adding Python would be a useful first step.  It could be the
> > last, or we could later consider Guile as well.
> 
> On second thought, what about Lua (http://www.lua.org/)?  It looks
> like a language designed specifically for extending software packages.
> 
> (Sorry for answering after such a long delay.)

Jim wrote:

> Python has more momentum than Guile in almost any way one might
> measure it:

> - number of users who are familiar with it
> - body of large programs written in it
> - number of modules available for reuse
> - number of programs embedding it
> - number of books available for learning it

I found that very persuasive, and it applies to Lua, though not as
strongly - I see a bit more done with Lua than with Guile, but it
doesn't compare to Python.  Also, I know Python, and I think a few
others on this list do - I don't know if anyone here knows Lua.

I spent a while reading the LuaVersusPython wiki page on the Lua Users
wiki.  I can't say that I found it very persuasive in either direction
for our situation.  Getting Python to work at all is likely to be more
trouble, but not much more trouble, and I'm willing to take care of
that myself.  And GDB isn't a lightweight program, which is where much
of Lua's advantage seems to be.

Anyway, just my two cents.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and scripting languages - which

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Sat, Feb 10, 2007 at 02:28:09PM +0200, Eli Zaretskii wrote:
>> > Date: Sat, 13 Jan 2007 10:31:51 +0200
>> > From: Eli Zaretskii <eliz@gnu.org>
>> > CC: gdb@sourceware.org
>> > 
>> > I think adding Python would be a useful first step.  It could be the
>> > last, or we could later consider Guile as well.
>> 
>> On second thought, what about Lua (http://www.lua.org/)?  It looks
>> like a language designed specifically for extending software packages.
>> 
>> (Sorry for answering after such a long delay.)
>
> Jim wrote:
>
>> Python has more momentum than Guile in almost any way one might
>> measure it:
>
>> - number of users who are familiar with it
>> - body of large programs written in it
>> - number of modules available for reuse
>> - number of programs embedding it
>> - number of books available for learning it
>
> I found that very persuasive, and it applies to Lua, though not as
> strongly - I see a bit more done with Lua than with Guile, but it
> doesn't compare to Python.  Also, I know Python, and I think a few
> others on this list do - I don't know if anyone here knows Lua.

I agree with all this.

There's a lot about Lua I like.  However, it doesn't have exceptions.
My personal three language essentials are:

- type-safety (programs get errors, not segfaults)
- automatic storage management (I don't need to call 'free'), and
- exception handling (I don't need to check for an error return code
  if my response will be to simply report it up to my caller)

That said, I'll bet every GDB developer reading this message had some
amendments they'd like make to my list.  No matter what I write, some
reasonable programmer will have different feelings.  So while I think
it's fine for us to talk about language characteristics to help each
other understand our options better, please don't feel I'm trying to
rule out Lua; if I have that right, then everyone else does, and I
think we'll collectively rule everything out. :)

This is why I've talked about secondary qualities that indicate the
breadth of general acceptance of the language: number of applications,
books, conferences, libraries and so on.  If we can identify a "rough
consensus" language that almost everyone feels would not be the end of
the world, that general agreement effectively brings each person's
judgement on the specifics to bear on the choice.

Re: GDB and scripting languages - which

[Eli Zaretskii]

> From: Jim Blandy <jimb@codesourcery.com>
> Date: Mon, 12 Feb 2007 09:25:09 -0800
> 
> There's a lot about Lua I like.  However, it doesn't have exceptions.

I think you are mistaken: Lua does have exceptions, it just calls them
``fallbacks''.

> My personal three language essentials are:
> 
> - type-safety (programs get errors, not segfaults)
> - automatic storage management (I don't need to call 'free'), and
> - exception handling (I don't need to check for an error return code
>   if my response will be to simply report it up to my caller)

By type-safety, do you mean that variables can hold different types of
objects, and programs that apply operators to operands of wrong types
are treated gracefully, then I think Lua qualifies.

Anyway, two advantages of Lua are:

  . It was designed from ground up to be primarily an extension
    language, not a general-purpose language that just happens to have
    C bindings for its interpreter; therefore it is small and
    efficient (by a large factor compared to Tcl, for example).

  . It's typeless and generally lacks the clutter that more
    ``complete'' programming languages require: type declarations,
    memory allocations, initialization before use, etc.

Re: GDB and scripting languages - which

[Robert Dewar]

Eli Zaretskii wrote:

> Anyway, two advantages of Lua are:
> 
>   . It was designed from ground up to be primarily an extension
>     language, not a general-purpose language that just happens to have
>     C bindings for its interpreter; therefore it is small and
>     efficient (by a large factor compared to Tcl, for example).
> 
>   . It's typeless and generally lacks the clutter that more
>     ``complete'' programming languages require: type declarations,
>     memory allocations, initialization before use, etc.

To me, the fundamental requirement for a language to be used for
writing gdb scripts (I refuse to use the bogus term scripting
language :-)) is that it be widely used and widely familiar
as well as being a decently designed language. To me Python
meets these criteria, Lua does not. Mere technical arguments
are not enough for a choice in a case like this.

Re: GDB and scripting languages - which

[Daniel Jacobowitz]

On Mon, Feb 12, 2007 at 04:42:12PM -0500, Robert Dewar wrote:
> To me, the fundamental requirement for a language to be used for
> writing gdb scripts (I refuse to use the bogus term scripting
> language :-)) is that it be widely used and widely familiar
> as well as being a decently designed language. To me Python
> meets these criteria, Lua does not. Mere technical arguments
> are not enough for a choice in a case like this.

By the way, if it weren't for this concern, I think I'd (slightly)
prefer Lua.  It would probably be a little easier to embed and lower
footprint.  But I think it would be overall less useful.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and scripting languages - which

[Robert Dewar]

Daniel Jacobowitz wrote:

> By the way, if it weren't for this concern, I think I'd (slightly)
> prefer Lua.  It would probably be a little easier to embed and lower
> footprint.  But I think it would be overall less useful.

Right, please do not consider my comment to in any way be a
technical judgment on the language merits or suitability
for purpose from a technical point of view, it is not!

Re: GDB and scripting languages - which

[Jim Blandy]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Jim Blandy <jimb@codesourcery.com>
>> Date: Mon, 12 Feb 2007 09:25:09 -0800
>> 
>> There's a lot about Lua I like.  However, it doesn't have exceptions.
>
> I think you are mistaken: Lua does have exceptions, it just calls them
> ``fallbacks''.

When I search the manual at http://www.lua.org/manual/5.1/, I don't
see any references to 'fallbacks'.  The Lua HISTORY file mentions
them, but they seem to be an operator overloading mechanism, not an
exception-handling mechanism.  Where can I find documentation on
these?

>> My personal three language essentials are:
>> 
>> - type-safety (programs get errors, not segfaults)
>> - automatic storage management (I don't need to call 'free'), and
>> - exception handling (I don't need to check for an error return code
>>   if my response will be to simply report it up to my caller)
>
> By type-safety, do you mean that variables can hold different types of
> objects, and programs that apply operators to operands of wrong types
> are treated gracefully, then I think Lua qualifies.

The second clause: "programs that apply operators to operands of wrong
types are treated gracefully".  Lua does qualify as a type-safe
language, and it does provide automatic storage management.  (All the
scripting languages I've seen do.)

> Anyway, two advantages of Lua are:
>
>   . It was designed from ground up to be primarily an extension
>     language, not a general-purpose language that just happens to have
>     C bindings for its interpreter; therefore it is small and
>     efficient (by a large factor compared to Tcl, for example).
>
>   . It's typeless and generally lacks the clutter that more
>     ``complete'' programming languages require: type declarations,
>     memory allocations, initialization before use, etc.

I agree with both of these.

Even if the exception issue is worked out, though, I'm still concerned
that Lua doesn't have as much momentum as Python.  Python's wealth of
other libraries available (gui; graphing; networking) brings a lot of
potential with it.  And there are a lot of programmers out there who
could just start scripting GDB the day Python support is committed.

Re: GDB and scripting languages - which

[Eli Zaretskii]

> Cc: gdb@sourceware.org
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Tue, 13 Feb 2007 11:00:39 -0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> From: Jim Blandy <jimb@codesourcery.com>
> >> Date: Mon, 12 Feb 2007 09:25:09 -0800
> >> 
> >> There's a lot about Lua I like.  However, it doesn't have exceptions.
> >
> > I think you are mistaken: Lua does have exceptions, it just calls them
> > ``fallbacks''.
> 
> When I search the manual at http://www.lua.org/manual/5.1/, I don't
> see any references to 'fallbacks'.  The Lua HISTORY file mentions
> them, but they seem to be an operator overloading mechanism, not an
> exception-handling mechanism.  Where can I find documentation on
> these?

Here:

     http://www.lua.org/spe.html

I don't know why this feature isn't mentioned in the current manual,
maybe it was renamed.

> Even if the exception issue is worked out, though, I'm still concerned
> that Lua doesn't have as much momentum as Python.  Python's wealth of
> other libraries available (gui; graphing; networking) brings a lot of
> potential with it.  And there are a lot of programmers out there who
> could just start scripting GDB the day Python support is committed.

Python is a full-fledged programming language, not a language created
for extending other programs.  Do you really think we need networking,
graphics, and GUI in GDB scripts?  That sounds like an awful overhead.

As for familiarity with it, the GDB scripting language we have now is
even less widespread than Lua.

Re: GDB and scripting languages - which

[Paul Koning]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

 Eli> Python is a full-fledged programming language, not a language
 Eli> created for extending other programs.  Do you really think we
 Eli> need networking, graphics, and GUI in GDB scripts?  That sounds
 Eli> like an awful overhead.

Overhead how?  It takes up some disk space.  Big deal.  And then only
if the user installed Python specifically for use with gdb (as opposed
to having it installed already).

Having a full-fledged language is a good thing.  That way you're not
as likely to run into the "this simple extension language isn't
powerful enough to do the things I need" problem.  Isn't that one of
the reasons for adding to what we have already?  If simple scripting
were all we want then we could just keep what we have and not add to
it.

	paul

Re: GDB and scripting languages - which

[Eli Zaretskii]

> Date: Wed, 14 Feb 2007 10:49:53 -0500
> From: Paul Koning <pkoning@equallogic.com>
> Cc: jimb@codesourcery.com,
>     gdb@sourceware.org
> 
> Overhead how?

Overhead in GDB size and complexity.

> Having a full-fledged language is a good thing.  That way you're not
> as likely to run into the "this simple extension language isn't
> powerful enough to do the things I need" problem.

Lua isn't a simple extension language, either.

Re: GDB and scripting languages - which

[Daniel Jacobowitz]

On Wed, Feb 14, 2007 at 05:41:06PM +0200, Eli Zaretskii wrote:
> > Even if the exception issue is worked out, though, I'm still concerned
> > that Lua doesn't have as much momentum as Python.  Python's wealth of
> > other libraries available (gui; graphing; networking) brings a lot of
> > potential with it.  And there are a lot of programmers out there who
> > could just start scripting GDB the day Python support is committed.
> 
> Python is a full-fledged programming language, not a language created
> for extending other programs.  Do you really think we need networking,
> graphics, and GUI in GDB scripts?  That sounds like an awful overhead.

None of that's in the core of Python, you'll notice.  It's all in
modules.  Some of those for networking are standard modules, but none
of it would be linked in to GDB.  But in any case those aren't the
ones I had in mind: I was thinking of things like XML, text
processing, and high-performance numerics.

And Python is widely used as an extension language nowadays - which
may not be true when the paper you reference was written, eleven years
ago.

Based on this discussion, I think we probably won't convince you that
Python is the best choice.  Do you think that Python would be a bad
choice with serious negative consequences?

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and scripting languages - which

[Eli Zaretskii]

> Date: Wed, 14 Feb 2007 10:56:20 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Jim Blandy <jimb@codesourcery.com>, gdb@sourceware.org
> 
> On Wed, Feb 14, 2007 at 05:41:06PM +0200, Eli Zaretskii wrote:
> > > Even if the exception issue is worked out, though, I'm still concerned
> > > that Lua doesn't have as much momentum as Python.  Python's wealth of
> > > other libraries available (gui; graphing; networking) brings a lot of
> > > potential with it.  And there are a lot of programmers out there who
> > > could just start scripting GDB the day Python support is committed.
> > 
> > Python is a full-fledged programming language, not a language created
> > for extending other programs.  Do you really think we need networking,
> > graphics, and GUI in GDB scripts?  That sounds like an awful overhead.
> 
> None of that's in the core of Python, you'll notice.  It's all in
> modules.  Some of those for networking are standard modules, but none
> of it would be linked in to GDB.

I only talked about them because Jim did, and I assumed that he
mentioned those because he thought it was important to have them in
GDB.

> But in any case those aren't the
> ones I had in mind: I was thinking of things like XML, text
> processing, and high-performance numerics.

More details would help make this discussion more constructive.  How
``high-performance'' should our numerics be, and why?  Do you have any
quantitative criteria?

As for text processing, what features do you think we need,
specifically?

> Based on this discussion, I think we probably won't convince you that
> Python is the best choice.

Why do you think so?  I certainly didn't dismiss anyone's arguments as
easily as others dismiss mine.  The only real argument in favor of
Python that I heard was that it's widely used and known.  That's not a
lot to become convinced, since what I'm suggesting is not some unknown
language either, or something invented just now.

> Do you think that Python would be a bad choice with serious negative
> consequences?

Python is an excellent language, so choosing it cannot possibly be bad
or have serious negative consequences.

Re: GDB and scripting languages - which

[Daniel Jacobowitz]

On Wed, Feb 14, 2007 at 07:46:27PM +0200, Eli Zaretskii wrote:
> > But in any case those aren't the
> > ones I had in mind: I was thinking of things like XML, text
> > processing, and high-performance numerics.
> 
> More details would help make this discussion more constructive.  How
> ``high-performance'' should our numerics be, and why?  Do you have any
> quantitative criteria?
> 
> As for text processing, what features do you think we need,
> specifically?

I don't know the answers to these questions.  They are things which I
think will be useful.  We don't have the faintest idea what we will
make possible by doing this work, or what users will come up with.
That's my goal - enabling entirely new uses.

> > Based on this discussion, I think we probably won't convince you that
> > Python is the best choice.
> 
> Why do you think so?

Based solely on the tone of the discussion, and five years working
with this group of people on this mailing list through past
discussions with similar tone.  I'm looking for something that won't
make anyone furious; we rarely manage to make everyone happy, but we
routinely manage to find conclusions that no one is too upset with.

I apologize if that sounds overly cynical of me.

I said at the very top of this thread that I thought bikeshedding over
which programming language to use was the worst possible use of our
time, and asked followups not to do so.  I can't say that I'm
surprised by the portion of the followups that were specifically about
the choice of language.  I think a suitable language that
(conservatively) ten times as many people know is clearly more useful
than a suitable language that far fewer people know.

You mentioned in another message that you considered things like
networking and graphics support to be excessive and wasted weight.
They are modules completely separate from the interpreter, and would
not be part of GDB's "footprint" unless someone wrote scripts which
used them.  And Lua has similar modules.  I see both a socket library
and GTK+ bindings for GUI use.

Have you used either Lua or Python in other projects?  Do you have
impressions of them from the script writer's perspective?

> I certainly didn't dismiss anyone's arguments as
> easily as others dismiss mine.  The only real argument in favor of
> Python that I heard was that it's widely used and known.  That's not a
> lot to become convinced, since what I'm suggesting is not some unknown
> language either, or something invented just now.

Neither are any of the others we've considered.  I don't think I can
say this any differently than I already have: the order of magnitude
more people that work in Python make it more useful, and the existing
GDB contributors with Python experience make Python more feasible.

I am not dismissing your arguments, but personally I have not found
them compelling.  I have seen no language features in Lua that make it
a better choice than Python.  For instance, you made a comment about
"complete" programming languages requiring type declarations and memory
allocation -- certainly that is not the case in Python, which is a
typical scripting language in those respects.

(I'm not sure what you meant by "initialization before use".  You'll
get a catchable exception in Python if you use something before you
initialize it, instead of a default empty value as you would in shell
scripting.)

I do not have any evidence that the extra "weight" of a Python
interpreter would be a problem, and I believe (as I said above) that
it is a priceless feature.  Here is the subset of the Python modules
installed on my system which seem clearly useful from GDB.

  python-ctypes, for interaction with other C support libraries
  python-gdbm (and others), for managing program trace data stored
    in databases
  python-numeric, vector and matrix calculations, e.g. to record
    and analyze the results of computation in the debuggee.
  python-stats, similarly.
  python-xml, for translating data both to and from XML for
    interaction with other tools

And that's just off the top of my head - if we enable some sort of
threads or graphics, then custom data browsers might be an interesting
option for people who otherwise want to use a text-only debugger.  And
so forth.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and scripting languages - which

[Robert Dewar]

Eli Zaretskii wrote:

> Python is a full-fledged programming language, not a language created
> for extending other programs.  Do you really think we need networking,
> graphics, and GUI in GDB scripts?  That sounds like an awful overhead.

It might *sound* like an "awful overhead", but that's really pure FUD
unless you document exactly what your concern here is. Python is used
successfully in this context in many tools. It is not as though GDB
is a tiny program you are trying to squeeze into 8K bytes!

> As for familiarity with it, the GDB scripting language we have now is
> even less widespread than Lua.

That's not an argument, you can't say "what we have now is bad, so
we don't need any better" :-)

Re: GDB and scripting languages - which

[Eli Zaretskii]

> Date: Wed, 14 Feb 2007 11:01:39 -0500
> From: Robert Dewar <dewar@adacore.com>
> CC: Jim Blandy <jimb@codesourcery.com>,  gdb@sourceware.org
> 
> that's really pure FUD

Thanks, this kind of attitude really helps to facilitate free
expression of opinions on this list.

Re: GDB and scripting languages - which

[Robert Dewar]

Eli Zaretskii wrote:
>> Date: Wed, 14 Feb 2007 11:01:39 -0500
>> From: Robert Dewar <dewar@adacore.com>
>> CC: Jim Blandy <jimb@codesourcery.com>,  gdb@sourceware.org
>>
>> that's really pure FUD
> 
> Thanks, this kind of attitude really helps to facilitate free
> expression of opinions on this list.

Well my use of the term FUD here was
considered. You were arguing that Python would
introduce excessive overhead, but with absolutely
no supporting data, or detailed argument. To me
a claim like that is definitely in the general
fear-uncertainty-doubt category, and is not
very helpful ... simple opinions are not very
useful unless they are grounded in some clear
facts.

My experience with Python (mostly in the context
of its use as a scripting language for GPS), is
that it is powerful, easy to use, and does not
introduce excessive overhead. The organization
of Python is modalar, lots of the capability is
in libraries which you only get if you access,
and having a python interpretor installed seems
like a more and more reasonable thing, given
the increasing popularity of this language for
many things.

Re: GDB and scripting languages - which

[Eli Zaretskii]

> Date: Wed, 14 Feb 2007 13:00:14 -0500
> From: Robert Dewar <dewar@adacore.com>
> CC:  jimb@codesourcery.com,  gdb@sourceware.org
> 
> Eli Zaretskii wrote:
> >> Date: Wed, 14 Feb 2007 11:01:39 -0500
> >> From: Robert Dewar <dewar@adacore.com>
> >> CC: Jim Blandy <jimb@codesourcery.com>,  gdb@sourceware.org
> >>
> >> that's really pure FUD
> > 
> > Thanks, this kind of attitude really helps to facilitate free
> > expression of opinions on this list.
> 
> Well my use of the term FUD here was
> considered. You were arguing that Python would
> introduce excessive overhead

I was arguing that features like networking, graphics, and GUI,
mentioned by Jim as an argument for Python's better suitability (or so
I understood), would be excessive overhead in the GDB scripting
language.

Maybe in the future you should consider a possibility that you
misunderstand what is written, _before_ you consider throwing the term
FUD at your opponents.

Re: GDB and scripting languages - which

[Robert Dewar]

Eli Zaretskii wrote:

> I was arguing that features like networking, graphics, and GUI,
> mentioned by Jim as an argument for Python's better suitability (or so
> I understood), would be excessive overhead in the GDB scripting
> language.

Can you more clearly explain what you mean by "excessive overhead".
I really don't understand this at all. networking for example only
costs you if you use it. Are you saying people should be prevented
from paying this price.

What overhead?

And by what quantitative criterion excessive?

Re: GDB and scripting languages - which

[Jim Blandy]

Robert Dewar <dewar@adacore.com> writes:
> Well my use of the term FUD here was
> considered.

Well, whatever its precise meaning might be, "FUD" is an emotionally
charged word.  Whether or not you feel it was an appropriate choice,
it wasn't helpful in keeping the conversation on track.

Folks, we're deliberating a very important question here.  If you see
someone say something emotional, please take care to make your
response less emotional, and more constructive, than theirs.  If you
read a personal affront, do the right thing, and let it pass.

If people with valuable insights drop out of the discussion because of
the tone, we will have screwed another attempt to make a huge, vastly
overdue improvement in GDB.  I know each of you value the time you've
already invested in GDB; this is a chance to make that effort pay off
handsomely.

Re: GDB and scripting languages - which

[Robert Dewar]

Jim Blandy wrote:
> Robert Dewar <dewar@adacore.com> writes:
>> Well my use of the term FUD here was
>> considered.
> 
> Well, whatever its precise meaning might be, "FUD" is an emotionally
> charged word.  Whether or not you feel it was an appropriate choice,
> it wasn't helpful in keeping the conversation on track.

OK, sorry, for me technical discussions never have any emotional
content (I never see the point of expending emotional energy on
something as unimportant as a technical argument), but I do
understand that others can get involved, so again apologies.

Once again, my position is as follows. The non-technical
arguments for Python are very strong. It would take VERY
convincing technical arguments for another language to
overcome them. In fact Python is a technically strong
choice as well, so the barrier to finding some better
choice is pretty high. Lua does not begin to meet that
challenge. I actually don't think Lua is technically
superior to Python, but even if it were it would have
to be oustandingly superior, and that is clearly not
the case.

Re: GDB and scripting languages - which

[Jim Blandy]

Robert Dewar <dewar@adacore.com> writes:
> Once again, my position is as follows. The non-technical
> arguments for Python are very strong. It would take VERY
> convincing technical arguments for another language to
> overcome them. In fact Python is a technically strong
> choice as well, so the barrier to finding some better
> choice is pretty high. Lua does not begin to meet that
> challenge. I actually don't think Lua is technically
> superior to Python, but even if it were it would have
> to be oustandingly superior, and that is clearly not
> the case.

I might put more weight here and less there, but this pretty much sums
up my feelings as well.

Re: GDB and scripting languages - which

[Jim Blandy]

Some rough info on resource consumption.  The "VSZ" column says how
much virtual memory the process is consuming, and the "RSS" column
says how much is actually in physical memory at the moment.  RSS is a
better indicator of the actual impact a program is having.

In the tests shown here, Python uses about 2.4x as much memory as Lua,
and 4% as much memory as GDB does debugging itself, having set and hit
a breakpoint on main.

I think both Python and Lua's resource consumption is reasonable for
our application.

$ cd ~/uberbaum/build-cvs-out/gdb
$ ./gdb gdb
GNU gdb 6.6.50.20070130-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x8087612: file /home/jimb/uberbaum/cvs-out/gdb/utils.c, line 819.
Breakpoint 2 at 0x80c2ea5: file /home/jimb/uberbaum/cvs-out/gdb/cli/cli-cmds.c, line 201.
(top-gdb) b main
Breakpoint 3 at 0x807eb65: file /home/jimb/uberbaum/cvs-out/gdb/gdb.c, line 30.
(top-gdb) run
Starting program: /home/jimb/uberbaum/build-cvs-out/gdb/gdb 

Breakpoint 3, main (argc=
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x807eb62.
1, argv=0xbffb2f74) at /home/jimb/uberbaum/cvs-out/gdb/gdb.c:30
30        memset (&args, 0, sizeof args);
(top-gdb) ps uww -C gdb
Undefined command: "ps".  Try "help".
(top-gdb) shell ps uww -C gdb
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
jimb      8104  5.7  2.6  59116 54032 pts/2    S+   12:44   0:00 ./gdb gdb
jimb      8107  0.0  0.0   5208   500 pts/2    T    12:44   0:00 /home/jimb/uberbaum/build-cvs-out/gdb/gdb
(top-gdb) quit
The program is running.  Exit anyway? (y or n) y
$ python
Python 2.4.4 (#1, Oct 23 2006, 13:58:00) 
[GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
[1]+  Stopped                 python
$ ps uww -C python
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
jimb      8071  0.0  0.1   6240  2632 pts/2    T    12:41   0:00 python
$ lua
Lua 5.1.1  Copyright (C) 1994-2006 Lua.org, PUC-Rio
> 
[2]+  Stopped                 lua
$ ps uww -C lua
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
jimb      8074  0.0  0.0   4548  1116 pts/2    T    12:41   0:00 lua
$ 

Re: GDB and scripting languages - which

[Robert Dewar]

Jim Blandy wrote:

> In the tests shown here, Python uses about 2.4x as much memory as Lua,
> and 4% as much memory as GDB does debugging itself, having set and hit
> a breakpoint on main.

Thanks Jim for getting some quantitative data into this
discussion.
> 
> I think both Python and Lua's resource consumption is reasonable for
> our application.

Indeed, I think these figures show that resource consumption is
not a factor in the decision.

Re: GDB and scripting languages - which

[Jim Blandy]

Eli Zaretskii <eliz@gnu.org> writes:
>> When I search the manual at http://www.lua.org/manual/5.1/, I don't
>> see any references to 'fallbacks'.  The Lua HISTORY file mentions
>> them, but they seem to be an operator overloading mechanism, not an
>> exception-handling mechanism.  Where can I find documentation on
>> these?
>
> Here:
>
>      http://www.lua.org/spe.html
>
> I don't know why this feature isn't mentioned in the current manual,
> maybe it was renamed.

The 'fallbacks' described in that paper aren't exceptions; they're a
mechanism for customizing the built-in operations of Lua, to adapt it
to new applications.

I'm using the term "exception" as it's used in ML, Scheme, C++, Java,
Python, Ruby, PHP, and probably others.  In fact, in the introduction,
after explaining that Lua is an extension language, they say:

    * extension languages are not for writing large pieces of
      software, with hundreds of thousands lines. Therefore,
      mechanisms for supporting programming-in-the large, like static
      type checking, information hiding, and exception handling, are
      not essential

> Python is a full-fledged programming language, not a language created
> for extending other programs.  Do you really think we need networking,
> graphics, and GUI in GDB scripts?  That sounds like an awful overhead.

As others have said, those are examples of the kind of facilities that
are available off-the-shelf to Python users; but as loadable modules,
they wouldn't be present in a Python-extended GDB unless a script
author did use them.

I think the quality of the body of libraries available for use
off-the-shelf with an extension language is an important measure.  For
example, who would have thought XML would matter to a debugger until
Daniel started using it to describe target registers?  And at CSL
we've got other stuff in the pipeline that would have been a pain
without XML.

In the broadest terms, debugging is about watching your programs run.
There are so many possible things people might want to do with that.
To address the three things I mentioned:
- Some kind of remote monitoring would need network support.
- Debugging performance problems would benefit from graphing.
- GUI facilities could broaden the audience of almost anything.

The lesson of GNU Emacs is that you just don't know what people are
going to do with something.  People were shocked to see news and mail
readers, development environments, symbolic calculators, and the like
implemented in Emacs.

Choosing an extension language for GDB with a rich set of libraries
would be a hugely wonderful thing.

> As for familiarity with it, the GDB scripting language we have now is
> even less widespread than Lua.

Definitely true.  Lua would be an improvement over what we have now.
But is it the best choice we could make?

Re: GDB and scripting languages - which

[Gaius Mulley]

Jim Blandy <jimb@codesourcery.com> writes:

> In the broadest terms, debugging is about watching your programs run.
> There are so many possible things people might want to do with that.
> To address the three things I mentioned:
> - Some kind of remote monitoring would need network support.
> - Debugging performance problems would benefit from graphing.
> - GUI facilities could broaden the audience of almost anything.

Hi,

I confess to be enthusiastic about Python in gdb.  Other libraries
such as 'pexpect' are pretty useful as well.  Over Christmas I had to
write a python script which ran two gdb's debugging stage2 and stage3
GNU Modula-2 compiler binaries (the later was broken somewhere).  The
script instantiated two classes controlling the gdbs, ran to a known
break point and then single stepped each a.out until the line numbers
or source files differed.  Lazy debugging, but useful over the holiday
period.

regards,
Gaius

Re: GDB and scripting languages - which

[Eli Zaretskii]

> Cc: gdb@sourceware.org
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Wed, 14 Feb 2007 11:45:07 -0800
> 
> The 'fallbacks' described in that paper aren't exceptions; they're a
> mechanism for customizing the built-in operations of Lua, to adapt it
> to new applications.
> 
> I'm using the term "exception" as it's used in ML, Scheme, C++, Java,
> Python, Ruby, PHP, and probably others.

Maybe I misunderstand what that means.  Are you looking for `pcall'
(http://www.lua.org/manual/5.1/manual.html#pdf-pcall)?

> In the broadest terms, debugging is about watching your programs run.
> There are so many possible things people might want to do with that.
> To address the three things I mentioned:
> - Some kind of remote monitoring would need network support.
> - Debugging performance problems would benefit from graphing.
> - GUI facilities could broaden the audience of almost anything.
> 
> The lesson of GNU Emacs is that you just don't know what people are
> going to do with something.  People were shocked to see news and mail
> readers, development environments, symbolic calculators, and the like
> implemented in Emacs.

Maybe we should have a more clear idea of what is the scope and
purpose of using a scripting language in GDB.  I don't think it was
ever stated in this whole discussion, so it's quite possible different
people have different ideas about that.

You mention Emacs: are we really going to base our model on Emacs?
Most of Emacs is actually implemented in Lisp, so much so that Lisp
can no longer be seen in Emacs as just an extension language.  The
only parts of Emacs that are not in Lisp are the Lisp interpreter and
the minimal interface to the OS: display, file I/O, memory, etc.  If
the OS could talk Lisp, the C parts of Emacs could be simply thrown
away.

Is this what we intend to do in GDB?  For example, are we going to
rewrite the GDB application level in the scripting language?  Will we
begin accepting general-purpose GDB features that are written entirely
in the scripting language?  If that's the intent, then I agree that an
extension language such as Lua is not going to be good enough.

My impression was that we want a scripting language to do what we do
with it today: prepare canned sequences of commands for batch-style
execution, or defining customized commands that are too specialized to
be included in the upstream distribution.  I thought the bulk of GDB
will remain to be in C, as it is today.  Was I mistaken?

Re: GDB and scripting languages - which

[Daniel Jacobowitz]

On Sat, Feb 17, 2007 at 03:15:56PM +0200, Eli Zaretskii wrote:
> Is this what we intend to do in GDB?  For example, are we going to
> rewrite the GDB application level in the scripting language?  Will we
> begin accepting general-purpose GDB features that are written entirely
> in the scripting language?  If that's the intent, then I agree that an
> extension language such as Lua is not going to be good enough.
> 
> My impression was that we want a scripting language to do what we do
> with it today: prepare canned sequences of commands for batch-style
> execution, or defining customized commands that are too specialized to
> be included in the upstream distribution.  I thought the bulk of GDB
> will remain to be in C, as it is today.  Was I mistaken?

I don't think we entirely know how we're going to use this yet.  I
have no plans to move C parts to a scripting language - I think that
the scripting language should be optional, at least for one release,
until we've seen how useful it is.  What happens after that is harder
to say.

My first goal is somewhere between your two extremes.  What I've
always wanted is to be able to ship scripts with my application or
library that explain how the debugger should display my custom data
types - things like C++ STL containers, or like GDB's "struct
expression", or GCC's "struct tree".  Things where just displaying the
underlying language type is not useful enough.

There's no way to do that with our CLI scripting today.  You need a
language that has some other basic concepts, like strings as opposed
to our current strings that live in target memory, and hierarchical
data types.  I imagine you could do it in either Lua or Python, once
we figure out what the interface to GDB should look like.

Of course, if we do this sufficiently well, it may become a vital
feature for users.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB and scripting languages - which

[Robert Dewar]

Daniel Jacobowitz wrote:

> I don't think we entirely know how we're going to use this yet.  I
> have no plans to move C parts to a scripting language - I think that
> the scripting language should be optional, at least for one release,
> until we've seen how useful it is.  What happens after that is harder
> to say.

Seems reasonable to me. In the long run, we may end up implementing
new features in GDB in the scripting language if that is more
convenient, so it may end up not being just a user feature.

Re: GDB and scripting languages - which

[Jim Blandy]

Robert Dewar <dewar@adacore.com> writes:
> Daniel Jacobowitz wrote:
>
>> I don't think we entirely know how we're going to use this yet.  I
>> have no plans to move C parts to a scripting language - I think that
>> the scripting language should be optional, at least for one release,
>> until we've seen how useful it is.  What happens after that is harder
>> to say.
>
> Seems reasonable to me. In the long run, we may end up implementing
> new features in GDB in the scripting language if that is more
> convenient, so it may end up not being just a user feature.

Incremental changes are the way to go; I don't see that reimplementing
any part of GDB needs to be part of the original plan.

That said: my long-term test of whether an extension language's
integration has been done right is that you *prefer* to implement new
features in the extension language over C whenever possible, just
because it's so much easier and cleaner, and because it doesn't carry
significant disadvantages for users.  In GNU Emacs that's definitely
the case: if you don't need to muck about with redisplay internals or
process control or any of the other essentials, it's obvious that you
do it in Lisp.

That condition holds when the fundamental facilities of the
application (in Emacs: buffers, strings, windows; in GDB: lexical
blocks, source code locations, types, variables, values, frames,
threads) are well-exported enough that you *can* get the job done, and
that the extension language bindings are clean enough that it's
*easier* to get the job done.

The folks doing the first Python Subversion bindings were surprised to
find that simply exporting the C functions to Python in a direct way
produced an interface that just didn't feel right in Python: you were
always worried about managing storage and so on.  Good extension
language bindings preserve the scripting language's common idioms.
(For example: if you're managing reference counts in your scripts,
something is wrong.  If buggy scripts segfault, something is wrong.)