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
(4) |
2
(17) |
3
(9) |
4
(14) |
5
(10) |
6
(11) |
7
(8) |
|
8
(9) |
9
(11) |
10
(29) |
11
(27) |
12
(29) |
13
(36) |
14
(8) |
|
15
(18) |
16
(30) |
17
(25) |
18
(6) |
19
(16) |
20
(13) |
21
(10) |
|
22
(16) |
23
(7) |
24
(8) |
25
(13) |
26
(14) |
27
(14) |
28
(5) |
|
29
(6) |
30
(21) |
31
(14) |
|
|
|
|
|
From: Filipe C. <fi...@gm...> - 2009-03-27 18:52:20
|
Hi,
I have mig, I have that file (mach_vm.defs) and the makefile in
coregrind has the instructions to create it... but somehow it isn't
getting created...
Found it! I didn't have (or I have deleted...) /usr/bin/cc (which mig
calls, I guess). I created a symlink to gcc and now coregrind built happily.
Thanks :-)
F
Greg Parker wrote:
> On Mar 27, 2009, at 5:52 AM, Nicholas Nethercote wrote:
>> On Fri, Mar 27, 2009 at 3:53 AM, Filipe Cabecinhas <fi...@gm...>
>> wrote:
>>>
>>> I'm having some problems compiling valgrind (DARWIN). Coregrind can't
>>> build because gcc can't find the file coregrind/m_mach/mach_vmUser.c
>>>
>>> I see there are *.Po files with vmUser on the name but they all seem to
>>> be dummy files.
>>>
>>> Does valgrind compile on DARWIN or not yet? (I have this bug since a few
>>> weeks ago, at least)
>>
>> It does, I've been working on it frequently in the past few weeks.
>>
>> The coregrind/m_mach/*User.c files are generated by a program called
>> 'mig' (short for Mach Interface Generator, IIUC), see
>> coregrind/Makefile.am. So I would guess that there's a build system
>> problem, especially if you've had this problem for weeks. Have you
>> tried a fresh check-out and build?
>
> mig generates mach_vmUser.c from /usr/include/mach/mach_vm.defs. Do you
> have that file? If not, try reinstalling or upgrading Apple's developer
> tools (the Xcode package).
>
>
|
|
From: Greg P. <gp...@ap...> - 2009-03-27 17:46:48
|
On Mar 27, 2009, at 5:52 AM, Nicholas Nethercote wrote: > On Fri, Mar 27, 2009 at 3:53 AM, Filipe Cabecinhas > <fi...@gm...> wrote: >> >> I'm having some problems compiling valgrind (DARWIN). Coregrind can't >> build because gcc can't find the file coregrind/m_mach/mach_vmUser.c >> >> I see there are *.Po files with vmUser on the name but they all >> seem to >> be dummy files. >> >> Does valgrind compile on DARWIN or not yet? (I have this bug since >> a few >> weeks ago, at least) > > It does, I've been working on it frequently in the past few weeks. > > The coregrind/m_mach/*User.c files are generated by a program called > 'mig' (short for Mach Interface Generator, IIUC), see > coregrind/Makefile.am. So I would guess that there's a build system > problem, especially if you've had this problem for weeks. Have you > tried a fresh check-out and build? mig generates mach_vmUser.c from /usr/include/mach/mach_vm.defs. Do you have that file? If not, try reinstalling or upgrading Apple's developer tools (the Xcode package). -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Ashley P. <as...@pi...> - 2009-03-27 13:52:04
|
On Fri, 2009-03-27 at 08:03 -0500, Nicholas Nethercote wrote: > On Tue, Mar 17, 2009 at 6:26 AM, Ashley Pittman <as...@pi...> wrote: > > > > Julian et al. > > > > I've been looking at Valgrind again recently and have noticed the VPATH > > build is broken again, this patch fixes it so configure/make/make > > install works, there are still problems with the regtests however. > > > > I'll admit it's not particularly tidy so if there are other ways to > > achieve the same result they may be prefrable, one way might be to > > rename the supp files supp.in and add them to AC_OUTPUT in configure.in > > > > The change of name to default.supp.new and renaming the file is to make > > the build consistent, if the file is created but the cat fails causing > > make to abort and then the user calls make again no attempt is made to > > re-generate the file without this change. > > Looks like there's a typo: at one point it says default.supp.net, > which I guess should be default.supp.new. There was, I thought I'd regenerated that diff after I made that change and before I sent it but perhaps not. > This keeps breaking because none of the developers (AFAIK) use VPATH > builds and we don't test them... perhaps we should. I almost always use it as it allows me to test the same tree with different configure options, it keeps source code separate from compiled code which makes it clear which if any files need adding to version control. If one of the test scripts could be migrated to use VPATH then that would probably help, this patch isn't a complete fix however, configure/make/make install all work with it but there are further problems remaining with IIRC make regtest. I can take a look at them if you want me to. Ashley, |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-27 13:04:00
|
On Tue, Mar 17, 2009 at 6:26 AM, Ashley Pittman <as...@pi...> wrote: > > Julian et al. > > I've been looking at Valgrind again recently and have noticed the VPATH > build is broken again, this patch fixes it so configure/make/make > install works, there are still problems with the regtests however. > > I'll admit it's not particularly tidy so if there are other ways to > achieve the same result they may be prefrable, one way might be to > rename the supp files supp.in and add them to AC_OUTPUT in configure.in > > The change of name to default.supp.new and renaming the file is to make > the build consistent, if the file is created but the cat fails causing > make to abort and then the user calls make again no attempt is made to > re-generate the file without this change. Looks like there's a typo: at one point it says default.supp.net, which I guess should be default.supp.new. This keeps breaking because none of the developers (AFAIK) use VPATH builds and we don't test them... perhaps we should. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-27 12:58:28
|
On Thu, Mar 26, 2009 at 2:43 PM, Ehab Ababneh <eha...@gm...> wrote: > > what I would like to do is some probably something similar to what was > described here: > http://www.inesc-id.pt/ficheiros/publicacoes/4867.pdf > > However, with little differences: in this paper the code produced by > Valgrind was optitmized. And I am looking at adding some redundant > instructions. > > lets say we have a block (I1, I2, ..., In). I would like to add my own > instructions Ax to the block while preserving the sequence of original > instructions. So, it would look like something like this (I1, I2, A1, A2, > I3, A3,....In). > And what are these A instructions anyways? they are sometimes repetitions of > some of the original instructions (so, may be I1 = A1 but writing to > different registers) and sometimes comparison instructions (may be something > like content(dist(I1)) ?= content(dist(A1))). > > So, basically I am not looking at only collecting some statistics about the > program being executed. I am also trying to play with the instruction stream > being executed. The paper you cited focused on improving the code generated by Valgrind's back-end. It sounds like you want to simply instrument a program's original code with additional code, ie. write a normal tool. In which case understand the Vex IR is crucial. I'd recommend reading this paper if you haven't already: http://www.valgrind.org/docs/valgrind2007.pdf Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-27 12:52:54
|
On Fri, Mar 27, 2009 at 3:53 AM, Filipe Cabecinhas <fi...@gm...> wrote: > Hi, > > Disclaimer: I know the DARWIN branch is unstable ;-) > > I'm having some problems compiling valgrind (DARWIN). Coregrind can't > build because gcc can't find the file coregrind/m_mach/mach_vmUser.c > > I see there are *.Po files with vmUser on the name but they all seem to > be dummy files. > > Does valgrind compile on DARWIN or not yet? (I have this bug since a few > weeks ago, at least) It does, I've been working on it frequently in the past few weeks. The coregrind/m_mach/*User.c files are generated by a program called 'mig' (short for Mach Interface Generator, IIUC), see coregrind/Makefile.am. So I would guess that there's a build system problem, especially if you've had this problem for weeks. Have you tried a fresh check-out and build? Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-27 12:46:32
|
On Thu, Mar 26, 2009 at 9:10 PM, Greg Parker <gp...@ap...> wrote: > > Merging a Windows port to the existing repository would take time and > effort. In particular, the portability infrastructure would need to be built > up in some places where all current ports happen to be the same. To give you an idea, I've been working on merging Greg's Darwin port for about 2 months now, with a couple of weeks of help from Julian, and I would estimate we are roughly half way towards merging it with the trunk. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-27 12:45:05
|
On Thu, Mar 26, 2009 at 9:10 PM, Greg Parker <gp...@ap...> wrote: > > Porting to Windows or Haiku or some other OS > that is fundamentally not-a-Unix would be a big step up in difficulty. > (Also, kernel and C library source code is invaluable. That would be another > obstacle on Windows in particular.) Another problem with Windows, AIUI, is that the syscall interface between the kernel and user-space isn't well defined (ie. not public and subject to change). Rather, what is well defined is the equivalent of libc. So writing syscall wrappers is problematic. A couple of years ago there was some more detailed discussion about a Windows port on the dev list. You might be able to find the thread with some searching. I couldn't find it, but I could find this: http://www.mail-archive.com/val...@li.../msg01402.html which suggests that getting Valgrind working with Wine would be much easier. Nick |
|
From: Filipe C. <fi...@gm...> - 2009-03-27 08:54:22
|
Hi, Disclaimer: I know the DARWIN branch is unstable ;-) I'm having some problems compiling valgrind (DARWIN). Coregrind can't build because gcc can't find the file coregrind/m_mach/mach_vmUser.c I see there are *.Po files with vmUser on the name but they all seem to be dummy files. Does valgrind compile on DARWIN or not yet? (I have this bug since a few weeks ago, at least) What would this vmUser file do? Thanks in advance, F |
|
From: Bart V. A. <bar...@gm...> - 2009-03-27 08:21:33
|
Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) started at 2009-03-27 02:00:02 EDT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 407 tests, 36 stderr failures, 9 stdout failures, 0 post failures == exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) helgrind/tests/hg05_race2 (stderr) memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/linux/mremap (stderr) none/tests/linux/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 407 tests, 37 stderr failures, 9 stdout failures, 0 post failures == drd/tests/pth_create_chain (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) helgrind/tests/hg05_race2 (stderr) memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/linux/mremap (stderr) none/tests/linux/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Mar 27 03:10:28 2009 --- new.short Fri Mar 27 04:21:14 2009 *************** *** 8,11 **** ! == 407 tests, 37 stderr failures, 9 stdout failures, 0 post failures == ! drd/tests/pth_create_chain (stderr) exp-ptrcheck/tests/bad_percentify (stderr) --- 8,10 ---- ! == 407 tests, 36 stderr failures, 9 stdout failures, 0 post failures == exp-ptrcheck/tests/bad_percentify (stderr) |
|
From: Tom H. <th...@cy...> - 2009-03-27 04:34:15
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-03-27 03:05:12 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 478 tests, 4 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) |
|
From: Tom H. <th...@cy...> - 2009-03-27 04:28:14
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-03-27 03:20:12 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 487 tests, 0 stderr failures, 0 stdout failures, 0 post failures == |
|
From: Tom H. <th...@cy...> - 2009-03-27 03:52:13
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-03-27 03:10:13 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 484 tests, 4 stderr failures, 1 stdout failure, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) none/tests/linux/mremap2 (stdout) |
|
From: Greg P. <gp...@ap...> - 2009-03-27 02:11:05
|
On Mar 26, 2009, at 2:05 AM, Tor Lillqvist wrote: >> For example, Greg Parker spent about 4 years >> working on the Mac OS X port in his spare time before it got >> incorporated onto a branch. > > Is this the DARWIN branch? > > Was this four year wait just because of modesty or secrecy on his > side, or do the main developers in principle oppose allowing new ports > even onto a branch until they are "finished" and actually work, or > something? Copyright issues did delay the release. But note that after 30,000 lines of changes, it's still not a "finished" port. And Mac OS X is a relatively friendly porting environment for Valgrind - much of it is Unix so much of the Linux code can be reused. Porting to Windows or Haiku or some other OS that is fundamentally not-a-Unix would be a big step up in difficulty. (Also, kernel and C library source code is invaluable. That would be another obstacle on Windows in particular.) > So I am just wondering, if I start doing this in earnest, will I > forever have to just keep my stuff in a local tree (and offer as > separate patched source tarballs, if ever it gets so far that others > could sensibly help), or would it be allowed onto a branch, or as > properly ifdeffed etc, even trunk? Merging a Windows port to the existing repository would take time and effort. In particular, the portability infrastructure would need to be built up in some places where all current ports happen to be the same. The natural path is probably something like what the Darwin port followed. Start with an entirely separate tree that you can mangle at your leisure. Later move to patches then a branch then the trunk, as your changes settle down and you add any necessary multi-platform infrastructure. The Darwin port had two ground-up restarts in its first two years, as various experiments came and went. You really don't want to be anywhere near trunk when your change rate looks like that. -- Greg Parker gp...@ap... Runtime Wrangler |