You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(1) |
2
(8) |
3
(7) |
4
(16) |
5
|
|
6
(3) |
7
(4) |
8
(1) |
9
(1) |
10
(4) |
11
(5) |
12
(1) |
|
13
|
14
(4) |
15
(2) |
16
|
17
(2) |
18
(9) |
19
(5) |
|
20
(9) |
21
(7) |
22
(9) |
23
(5) |
24
|
25
(1) |
26
|
|
27
|
28
(1) |
29
(11) |
30
(6) |
31
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2002-10-30 16:07:36
|
On 30 Oct 2002, Jeremy Fitzhardinge wrote: > The main reason for pre_mutex_lock is that locking can block, so you may > want to do something before that happens. Unlock doesn't block, so pre_ > or post_ doesn't matter much. I didn't bother with pre_mutex_unlock > because it would be redundant. Ok, a brief comment explaining this in vg_skin.h would be good then :) N |
|
From: Jeremy F. <je...@go...> - 2002-10-30 16:07:06
|
On Wed, 2002-10-30 at 02:31, Nicholas Nethercote wrote:
Thinking about this some more, seems to me like every skin is going to
identically do:
details->core_interface = VG_IF_VERSION;
In which case why not just put:
const Char* core_interface = VG_IF_VERSION;
[ Well, SK_(core_interface) ]. Yes, that would work.
in vg_skin.h, which every skin #includes. That way, the skin doesn't have
to mention anything about version numbers, and assuming we get the X.Y
binary (in)compatibility numbering right, everything will work as desired.
(Thinking some more: it would be better to have VG_MINOR_IF_VERSION and
VG_MAJOR_IF_VERSION integers rather than a string, just to make
comparisons simpler.)
Yes, then you can do CPP checking:
#if VG_MAJOR_IF_VERSION < 3
#error Need Valgrind version 3
#endif
And not expose the fields of the struct in vg_skin.h. That way even if the
structs were totally reordered in core, an old skin would still work fine
with it.
Yes, that would be better. A little more cumbersome, but it could be
prettied up with a macro perhaps.
J
|
|
From: Jeremy F. <je...@go...> - 2002-10-30 16:03:20
|
On Wed, 2002-10-30 at 07:38, Nicholas Nethercote wrote:
Hi,
Jeremy: I saw your patch #33 which adds a pre_mutex_lock event. I think
it's a good thing to add to core. Would you mind augmenting your patch so
that it adds a pre_mutex_unlock() event too? It would be good to have for
completeness but I'm not sure where the hooks need to go -- my
understanding of the scheduler and threads stuff is poor.
The main reason for pre_mutex_lock is that locking can block, so you may
want to do something before that happens. Unlock doesn't block, so pre_
or post_ doesn't matter much. I didn't bother with pre_mutex_unlock
because it would be redundant.
J
|
|
From: Nicholas N. <nj...@ca...> - 2002-10-30 15:38:56
|
Hi, Jeremy: I saw your patch #33 which adds a pre_mutex_lock event. I think it's a good thing to add to core. Would you mind augmenting your patch so that it adds a pre_mutex_unlock() event too? It would be good to have for completeness but I'm not sure where the hooks need to go -- my understanding of the scheduler and threads stuff is poor. Thanks. -- Nick Nethercote nj...@ca... |
|
From: Nicholas N. <nj...@ca...> - 2002-10-30 13:33:25
|
On 29 Oct 2002, Jeremy Fitzhardinge wrote: > One of the problems with the output from Helgrind (and memcheck) is that > the results are somewhat opaque. They talk about raw memory locations > rather than programmer-visible objects. If you're lucky, the location > is associated with a symbol, but mostly they're just offsets into > allocated memory, which isn't all that useful. > > I'm thinking the best way of making this useful is by getting more > information out of the debug info (stabs or dwarf). > [...] > So, does anyone have a feel for how hard this actually is? No idea. But it would be a very useful thing; I can see this facility would definitely go in the core, as it could be useful for many skins. N |
|
From: Nicholas N. <nj...@ca...> - 2002-10-30 10:31:57
|
On some days, Jeremy Fitzhardinge wrote:
> I think a better scheme would be to have the core export a preprocessor
> define called something like VG_IF_VERSION. The skins would then simply
> do:
>
> details->core_interface = VG_IF_VERSION;
>
> If the core makes an incompatible change to its skin interface, then
> increment the IF_VERSION. You could use a string in X.Y format, where
> changes in X are completely incompatible, but Y indicates a backwards
> compatible change.
>
> This way the association between skin binary and core is checked by the
> compiler and then built into the skin automatically.
Thinking about this some more, seems to me like every skin is going to
identically do:
details->core_interface = VG_IF_VERSION;
In which case why not just put:
const Char* core_interface = VG_IF_VERSION;
in vg_skin.h, which every skin #includes. That way, the skin doesn't have
to mention anything about version numbers, and assuming we get the X.Y
binary (in)compatibility numbering right, everything will work as desired.
(Thinking some more: it would be better to have VG_MINOR_IF_VERSION and
VG_MAJOR_IF_VERSION integers rather than a string, just to make
comparisons simpler.)
> Not exposing structures as part of the interface is a really good
> idea (OpenGL is a really nice example of an API which is extremely good
> at maintaining long-term binary compatibility, partly because it exposes
> no structures more complex than arrays of ints or floats).
Interesting. Maybe I should change the way `details', `needs' and
`trackable events' are set, using functions instead? Eg. change this:
details->name = "foo";
details->version = "1.1.1";
details->description = "blah blah blah";
details->copyright_author =
"Copyright (C) 2002, and GNU GPL'd, by Nicholas Nethercote.";
details->bug_reports_to = "nj...@ca...";
needs->basic_block_discards = True;
needs->command_line_options = True;
track->new_mem_heap = & my_new_mem_heap;
track->die_mem_heap = & my_die_mem_heap;
to this:
VG_(details_name)("foo");
VG_(details_version)("1.1.1");
...
VG_(set_needs_basic_block_discards)();
VG_(set_command_line_options)();
/* could have corresponding VG_(unset_command_line_options)() etc */
VG_(track_new_mem_heap)(& my_new_mem_heap);
VG_(track_die_mem_heap)(& my_die_mem_heap);
And not expose the fields of the struct in vg_skin.h. That way even if the
structs were totally reordered in core, an old skin would still work fine
with it.
The only complication with this is that a skin could call these functions
at any time... but that could possibly be desirable (eg. start/stop
tracking new_mem_heap events if something happens) and it's also currently
possible anyway since VG_(needs) etc. are all global anyway. By using
functions I could add some sanity checking, eg. complain if a skin tries
to set a need after startup which would screw things up (eg. shadow_regs,
which affects the baseBlock initialisation and thus can't be turned on
halfway through execution).
There are some other exposed structs in the interface... I might have a
look through and see how else it can be better future-proofed.
Thanks for the good suggestions.
N
|