[PATCH] tracedump: add --help and --function-histogram
cworth at cworth.org
Thu Oct 20 09:18:37 PDT 2011
On Wed, 19 Oct 2011 23:34:57 -0400, Zack Rusin <zack at kde.org> wrote:
> Ah, that's very cool.
> I guess you probably broke the gui by changing the install paths of the
> objects, that's not a biggie though.
Ah, good point.
> It'd be nice if like gui the tool would
> prefer the built but not necessarily installed executables to the ones which
> have been installed, otherwise it's not very developer friendly.
Oh, right. I did a bunch of work so that it would at least be usable
before being installed, but I didn't think about the priority
here. Clearly it's not right if the uninstalled version keeps using the
old, installed stuff.
I'll think about this a bit since I wouldn't prefer the tool to prefer
doing the PATH-searching heuristic first.
> It doesn't seem like the talloc dependency is really necessary.
Fair enough. I've just started really enjoying talloc in all of my
programming lately and just naturally reached for it. Admittedly, it's
not really shining here, (particularly since there are still a bunch of
incremental talloc_free calls). Talloc really shines when you build up a
large tree of data and have almost no talloc_free calls throughout the
code, (nothing needed on cleanup paths etc.). I'll close my talloc plug
by saying that the implementation is really tiny so it's easy to bundle
But that's just me plugging talloc in general. I'm fine dropping it
> then lets just use the latter. BTW, you seem to really dislike c++ :) Using
> string's, standard algorithms, not having to declare variables at the top of
> the scope but close to where they're being used, not having to typedef
> structs... are all very useful.
It's not deliberate avoidance on my part—more just lack of
experience/comfort. I do use C primarily, and that shows.
I recognize that apitrace is a C++ project and I did try at least, (I
used a .cpp extension and iostream output at least). The rest I'll have
to just keep trying to use.
> Also, while we're not very good at following a consistent style, most spots
> use camel case for names with object names starting with uppercase, i.e.
> Command instead command_t.
> All of those are probably trivially fixable so I hope I don't sound too
> negative because I think that a toplevel tool is a great idea!
No problem at all. As I rebase this branch I'll shift things in those
Thanks for the feedback.
carl.d.worth at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the apitrace