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
|
|
2
(1) |
3
(1) |
4
|
5
|
6
|
7
|
8
|
|
9
|
10
(1) |
11
(1) |
12
|
13
|
14
|
15
(1) |
|
16
(1) |
17
(1) |
18
|
19
|
20
(2) |
21
(1) |
22
|
|
23
(4) |
24
(1) |
25
(7) |
26
(3) |
27
|
28
|
|
|
From: Josef W. <Jos...@gm...> - 2003-02-03 10:44:00
|
On Sunday 02 February 2003 11:29, Nicholas Nethercote wrote: > On Wed, 29 Jan 2003, Josef Weidendorfer wrote: > > But this makes the process of distributing valgrind skins separate from > > valgrind core impossible. > > I think the valgrind core is much like a library for skins, and we should > > allow developing skins on a machine with a binary installation of > > valgrind. > > > > You already made skin development independent from valgrind versions by > > introducing a skin interface version. Thus, skins should be distributable > > independent from valgrind releases. > > Yes, you're right. I was forgetting about binary distributions. > > It would be good for skin packing/installing to be as simple as possible. For the installer of my source package, it's a "configure;make install". For me as a packager, making a new skin version involves incrementing the version number in configure.in and doing a "make distcheck". This is easy enough. To get a skin developer started, we could provide a script "valgrind_make_example_skin <name>", copying a separate version of the example skin (i.e. a autoconf/automake version). > Preferably, that would require only a Makefile.am plus the skin's source > (in order to do a installation from source) but I don't know if we can > get away with that little. Writing a configure.in is an unfortunate pain, > as is the requirement of having aclocal.m4, AUTHORS, NEWS, and other > mandatory files. Yes. From a puristic viewpoint, autoconf/automake is a overkill for small source packages. Using autoconf/automake, source distributions must be selfcontained. I.e. you can't assume autoconf or automake to be installed. I know this pain from KDE: Using the qmake system from QT, the original QT-only kcachegrind was only around 80 KB of packed sources. Making a KDE package out of it, the size was around 400 KB. Thats the smallest source package you can get for a simple KDE version of "hello world" :-( FYI: I made my skin check for Valgrind 1.9.x so it won't be used with a Valgrind 2.x version. All the purpose was to see if there is any problem with separate skin packages... My configure.in is quite short. I check for the valgrind version and assume that my skin will run when valgrind was able to be installed on that machine. I'm not sure if this is a valid assumption, though. With include files on the machine, I *only* would check for a skin interface version compatible with my skin, i.e. all 1.x skin interfaces. Jeremy once suggested a valgrind-devel package with the include files. I think this is not our concern, as the distributors should provide these separate binary package splitting of valgrind. At least Suse is doing this splitting for all libraries. > Installing a binary version of a skin could be as simple as copying the > vgskin_xxx.so into the appropriate directory, no? Yes. But the installer has to know the target dir. At least for RPM. (I'm not sure about position independent packages) Thus, binary distributions will be distribution dependend. Another somewhat standard way is to provide a short "valgrind-config" script. A lot of packages provide this one (i.e. gnome-config, kde-config). It's kind of a easy way to provide parameters of a installed package. Installing a binary skin would be cp vgskin_xxx.so `valgrind-config --prefix`/lib/valgrind > As for the include/ files (vg_skin.h, vg_constants_skin.h, > vg_kerneliface.h), would it be possible for the skin to reuse the > installed Valgrind's copies? Ie. by assuming that the skin will be > installed under the valgrind/ directory? Yes. If they don't match, the configure script will complain. Note: Even with my current separate skin, there is no problem: If the installed valgrind doesn't match the include files of my package, the skin will compile but there will be a run time error. > I'm not too familiar with all this stuff, if you have any suggestions for > making the process simpler they would be welcome. Regarding a minimum size for third-party skins I don't know. For easy skin developing, a example template (see above) would be fine. > > You don't have to have multiple startup scripts. With 'basename $0' as > > skin it would be enough to make (hard or soft) symlinks to the valgrind > > script named by the skin. > > [...] > > I only thought about a solution to forward the name of a startup script > > to the valgrind core... > > Why do you want to forward the name of the script to the core? Only for a correct help message. But perhaps this is bogus. Josef |