• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: data formatters (still) unreliable?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: data formatters (still) unreliable?


  • Subject: Re: data formatters (still) unreliable?
  • From: Jerry <email@hidden>
  • Date: Thu, 11 Jun 2009 08:14:06 +0100

I've never tried writing a data formatter, but custom summary formats hardly ever work, so much so that I never even bother trying to use them any more. You can get them to work once just to tantalize you and cause you to waste loads of time, but then they never work again. I just use "View as Memory" or use the debugger console to print stuff out. The Expressions window would be potentially useful here but it's just too annoying - half the time you get the dreaded "Out of scope" and if you mistype, you can't select an existing expression and edit it, you have to type it all over again. In the console you've got editing built in so it's much easier.

Jerry

On 10 Jun 2009, at 20:03, Sam Deane wrote:

I sent a message on this topic originally in 2006 (the text is pasted below). At that point I was using XCode 2.4, and the response I got from two other subscribers seemed to confirm that data formatters in XCode were, indeed, unreliable.

I'm now using XCode 3.1 (ish). I've just revisited my unicode formatter plugin and I still seem to be getting exactly the same sort of random behaviour - except that I don't see any warnings from gdb.

I hesitate to ask, but has any work been done on this area of XCode in the intervening years? Does anyone have any clues as to how I can get it to work reliably?


Original Mail: ------------------

I've been trying to use some custom summary formats and data formatters to make my debugging experience a bit saner. Potentially, this is a very handy feature of XCode, but instead it seems to be driving me further towards the edge!

I have a formatter plugin based on the wchardataformatter sample code. When I test this plugin using the small test program provided, it works fine.

When I test it in my own code (spread over 3 projects incidentally - an application linked to two static libraries), and look at wchar_t* strings, it _sometimes_ works, and sometimes doesn't - with no obvious explanation as to why.

When I test it in my own code using custom types derived from wchar_t and wchar_t*, I can't get it to work at all, although I did tantalisingly get it to work once!

Are there any known issues with this stuff? Does it work reliably for everyone else? Are there any project settings that need to be given certain values - e.g. using DWARF instead of Stabs, or turning Fix & Continue off, or something similarly obscure.

I occasionally get "warning: Attempt to use a type name as an expression." appearing in the gdb debug console.

I'm using XCode 2.4 on intel macs (a MacBookPro and a MacPro) using 10.4.8.

Yours in frustration...

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@huxtable.com


This email sent to email@hidden


_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: data formatters (still) unreliable?
      • From: Sam Deane <email@hidden>
References: 
 >data formatters (still) unreliable? (From: Sam Deane <email@hidden>)

  • Prev by Date: problem with Xcode and applescript
  • Next by Date: Re: data formatters (still) unreliable?
  • Previous by thread: data formatters (still) unreliable?
  • Next by thread: Re: data formatters (still) unreliable?
  • Index(es):
    • Date
    • Thread