Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Paul Hilfinger <hilfingr@gnat.com>
Cc: brobecker@gnat.com, gdb@sources.redhat.com
Subject: Re: Ada's formats
Date: Wed, 04 Aug 2004 14:41:00 -0000	[thread overview]
Message-ID: <4110F576.7000102@gnu.org> (raw)
In-Reply-To: <20040804090425.B2400F2A00@nile.gnat.com>

> Andrew,
> 
> You wrote:
> 
>>> Can "we" (I hate this abuse of the Queens English) delete the existing, 
>>> broken code then? With that resolved, its possible to move onto the next 
>>> Ada problem. 
> 
> 
> Joel wrote:
> 
>>> Could you explain which part of the code you're refering to? 
> 
> 
> You then wrote:
> 
>>> Uses of the struct language_format_info in core GDB (which 
>>> translates to local_.*_format macros). Rip that out and I suspect that 
>>> you'll find adding ada's formatting using method rather than 
>>> printf formats is trivial.
> 
> 
> I've finally been able to look at this seriously, and am
> afraid we're still not clear on what is "broken" that needs fixing.
> AFAICS, the language_format_info approach generally works in a purely
> functional sense, and back when we (briefly) used it to apply Ada's
> language formats for hex and octal strings, it worked just fine for
> us.  (Currently, I see that m2-lang.c and scm-lang.c use non-C-like
> values for their language_format_info entries; is the mechanism working for 
> them?)

I was asking if we should even support the feature of being able to 
print values in a language specific way.  Or to approach this from 
another angle, in addition to supporting cut'n'paste of source code 
expressions into GDB, should we support cut'n'paste of GDB's output 
values into the source code?

The conclusion was a resounding ``maybe''.

Knowing that m2 is effectively dead, and that JimB (the ex Scheme 
maintainer) was recommending scm's removal, this leaves us with ``maybe 
useful'' (read dead) code (well unless that ``maybe'' gets upgraded to a 
``yes'' :-).

Also knowing that the code is problematic (grep for 32x64), this tells 
us that it's time to cut our losses.

> So I am assuming that you are referring mainly to a bogosity in the
> design aesthetics.  I am willing to do the necessary cleanup here as
> community service, even though we have no need of it for the Ada
> language module, but first I would like to make quite sure I have a
> clear picture of what your idea of the right solution is.  Is it
> simply a matter of replacing the language_format_info format strings
> with functions, or did you have something else entirely in mind?

If you're willing to overhaul the code in that way, and then use it for 
Ada, would be very much appreciated!  I was putting forward that the 
code simply be removed.

enjoy,
Andrew



  reply	other threads:[~2004-08-04 14:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-04  9:04 Paul Hilfinger
2004-08-04 14:41 ` Andrew Cagney [this message]
2004-08-11 10:38   ` Paul Hilfinger
     [not found]     ` <411AA0A9.3060506@gnu.org>
     [not found]       ` <55713.204.151.174.7.1094055261.squirrel@websd.u-strasbg.fr>
2004-09-02  7:16         ` Paul Hilfinger
2004-09-03 21:30     ` Andrew Cagney
2004-09-03 21:54       ` Paul Hilfinger
  -- strict thread matches above, loose matches on Subject: below --
2004-07-08 22:25 Andrew Cagney
2004-07-09  1:56 ` Paul Hilfinger
2004-07-14 20:00   ` Andrew Cagney
2004-07-16  1:14     ` Joel Brobecker
2004-07-16  2:02       ` Andrew Cagney
2004-07-16  4:09         ` Joel Brobecker
2004-07-16 14:20           ` Andrew Cagney
2004-07-16 16:27             ` Joel Brobecker
2004-07-16 21:54               ` Andrew Cagney

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=4110F576.7000102@gnu.org \
    --to=cagney@gnu.org \
    --cc=brobecker@gnat.com \
    --cc=gdb@sources.redhat.com \
    --cc=hilfingr@gnat.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