https://bugs.kde.org/show_bug.cgi?id=371916
Philippe Waroquiers changed:
What|Removed |Added
Status|CONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #22 from Julian Seward ---
Can this be closed now? In the NEWS file it is listed as being closed.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #21 from Philippe Waroquiers ---
(In reply to Julian Seward from comment #18)
> * I assume there are no regressions with correctness or performance
> with this, yes? Could you do a self-host Memcheck run at some point?
Massif functional b
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #20 from Philippe Waroquiers ---
(In reply to Josef Weidendorfer from comment #17)
> I just wondered if the xtree API could work without having to pass
> add/sub_data_fn handlers to make it simpler. I see that the add
> handler is used for c
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #19 from Josef Weidendorfer ---
(In reply to Julian Seward from comment #18)
> + Copyright (C) 2016-2016 Philippe Waroquiers
>
> For m_xtree.c, if there is a lot of code in there which has been moved
> from massif and/or callgrind, and is
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #18 from Julian Seward ---
Some comments on the v3 patch:
Mostly it looks fine. Below [1] some small comments.
Larger comments:
* I assume there are no regressions with correctness or performance
with this, yes? Could you do a self-ho
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #17 from Josef Weidendorfer ---
(In reply to Philippe Waroquiers from comment #16)
> > About the changes in the malloc
> > wrappers, I think it would be better if the tool can register handlers,
> > and these handlers then call e.g. VG_
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #16 from Philippe Waroquiers ---
(In reply to Josef Weidendorfer from comment #15)
> Hi Philippe, nice patch!
>
> I think it is good to move functionalty from tools to the core, if it
> can make other tools better or easier to write. Attach
https://bugs.kde.org/show_bug.cgi?id=371916
Josef Weidendorfer changed:
What|Removed |Added
CC||josef.weidendor...@gmx.de
--- Comment #15
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #14 from Philippe Waroquiers ---
(In reply to Ivo Raisr from comment #13)
> Thanks for addressing my comments. Especially for providing hints on Xtree
> usage!
> I am happy with the documentation and pub_tool_xtree.h interface.
> However not
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #13 from Ivo Raisr ---
Thanks for addressing my comments. Especially for providing hints on Xtree
usage!
I am happy with the documentation and pub_tool_xtree.h interface.
However note I have not reviewed any implementation files.
The last r
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #12 from Philippe Waroquiers ---
Thanks for the comments, should be handled in attached v3 patch.
For what concerns function names etc, I have (tried to more) systematically
use a prefix (such as XT_, or XT_Memory or XT_massif_... followed b
https://bugs.kde.org/show_bug.cgi?id=371916
Philippe Waroquiers changed:
What|Removed |Added
Attachment #101950|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #10 from Philippe Waroquiers ---
(In reply to Ivo Raisr from comment #8)
> Sometimes the function name follows pattern: "XTthing_operation",
> sometimes "operationXT" and sometimes something completely different.
Fair enough. I will do a pas
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #9 from Ivo Raisr ---
As for the documentation, the concept is explained very well. Thank you for
this!
I found just few typos:
When set to none, no memory execution
- tree is be produced.
+ tree is produced.
When
https://bugs.kde.org/show_bug.cgi?id=371916
Ivo Raisr changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |C
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #7 from Philippe Waroquiers ---
(In reply to Ivo Raisr from comment #3)
> 5. I wonder why VG_(init_XtAllocs)(), VG_(add_XtAllocs)(),
> VG_(sub_XtAllocs)() and VG_(img_XtAllocs)() do not use structure XtAllocs
> instead of 'void *'? Am I mis
https://bugs.kde.org/show_bug.cgi?id=371916
Philippe Waroquiers changed:
What|Removed |Added
Attachment #101932|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #5 from Philippe Waroquiers ---
Thanks for the comments, here is some feedback.
I will attach a new patch version, with an updated pub_tool_xtree.h.
(In reply to Ivo Raisr from comment #3)
> Thank you for this patch, Philippe.
> I was conce
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #4 from Ivo Raisr ---
The idea of associating some data to execution contexts reminds me of an
aggregation and quantization capabilities of DTrace in Solaris/illumos when
applied to stack traces... Oh, the world is so small!
--
You are rec
https://bugs.kde.org/show_bug.cgi?id=371916
Ivo Raisr changed:
What|Removed |Added
CC||iv...@ivosh.net
--- Comment #3 from Ivo Raisr ---
https://bugs.kde.org/show_bug.cgi?id=371916
--- Comment #2 from Philippe Waroquiers ---
Created attachment 101933
--> https://bugs.kde.org/attachment.cgi?id=101933&action=edit
new image file, to save as docs/images/kcachegrind_xtree.png to produce the
doc
The doc will not build without this f
https://bugs.kde.org/show_bug.cgi?id=371916
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
23 matches
Mail list logo
