From: Tom Tromey <tromey@redhat.com>
To: Paul Koning <Paul_Koning@Dell.com>
Cc: jimb@red-bean.com, bauerman@br.ibm.com, gdb@sourceware.org
Subject: Re: repo to work on python scripting support
Date: Tue, 25 Mar 2008 20:18:00 -0000 [thread overview]
Message-ID: <m363vaoe8s.fsf@fleche.redhat.com> (raw)
In-Reply-To: <18409.18988.613477.542099@pkoning-laptop.equallogic.com> (Paul Koning's message of "Tue\, 25 Mar 2008 14\:53\:32 -0400")
>>>>> "Paul" == Paul Koning <Paul_Koning@Dell.com> writes:
Paul> An obvious Pythonic way of doing this is with default arguments, which
Paul> allows a call to omit some of the arguments defined for the function.
Paul> For example:
Paul> def foo (arg1, arg2=None):
Paul> if arg2 is None:
Paul> arg2 = raw_input ("please supply arg2: ")
I think default arguments are part of the solution, but not the whole
solution.
The basic problem is that we have a syntax for embedding a python call
in an expression that looks like $(stuff).
Now, internally to gdb, "stuff" is just a string. But, most of the
time, the implementation of this function, whatever it is, won't want
just a string -- it will want an expression, or a file name, or
something.
So, what Jim and Daniel want, I think, is a declarative way for the
Python code (which implements the given function) to tell gdb's core
how to parse this string.
I think the hope here is that we avoid the mess of gdb commands, which
really do get just a plain string and then proceed to be inconsistent
with each other and just generally hard to modify.
It would be interesting to see if we could enumerate the core
possibilities for argument types.
Tom
next prev parent reply other threads:[~2008-03-25 19:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-16 0:42 Thiago Jung Bauermann
2008-03-16 2:55 ` Tom Tromey
2008-03-24 17:16 ` Thiago Jung Bauermann
2008-03-25 11:45 ` Tom Tromey
2008-03-25 13:53 ` Daniel Jacobowitz
2008-03-25 18:37 ` Jim Blandy
2008-03-25 18:52 ` Daniel Jacobowitz
2008-03-25 18:53 ` Jim Blandy
2008-03-25 19:18 ` Tom Tromey
2008-03-27 6:41 ` Jim Blandy
2008-03-27 17:57 ` Paul Koning
2008-03-25 19:31 ` Paul Koning
2008-03-25 20:18 ` Tom Tromey [this message]
2008-03-25 20:31 ` Paul Koning
2008-03-26 3:23 ` Tom Tromey
2008-03-26 12:55 ` Jim Blandy
2008-03-26 17:29 ` Paul Koning
2008-03-26 17:58 ` Daniel Jacobowitz
2008-03-26 18:41 ` Tom Tromey
2008-03-26 20:04 ` Paul Koning
2008-03-26 22:45 ` Jim Blandy
2008-03-26 18:05 ` Doug Evans
2008-03-26 18:13 ` Daniel Jacobowitz
2008-03-26 18:25 ` Tom Tromey
2008-03-26 18:41 ` Daniel Jacobowitz
2008-03-26 18:55 ` Tom Tromey
2008-03-26 20:57 ` Daniel Jacobowitz
2008-03-26 21:01 ` Thiago Jung Bauermann
2008-03-27 14:11 ` Jim Blandy
2008-03-27 16:49 ` Paul Koning
2008-03-26 18:23 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m363vaoe8s.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=Paul_Koning@Dell.com \
--cc=bauerman@br.ibm.com \
--cc=gdb@sourceware.org \
--cc=jimb@red-bean.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox