On Sat, 2008-03-01 at 21:15 +0100, Julian Seward wrote:
> On Friday 29 February 2008 16:54, Ashley Pittman wrote:
> > I've been looking at my output aggregation tool again this week and have
> > spotted a problem with the new output qualifier, in the old system with
> >
On Mon, 2008-03-03 at 17:01 +0100, Julian Seward wrote:
> On Monday 03 March 2008 16:51, Ashley Pittman wrote:
> > I'm trying a VPATH build of valgrind and have found that omega doesn't
> > build when using VPATH, it appears omega is the only tool to try and
>
I'm trying a VPATH build of valgrind and have found that omega doesn't
build when using VPATH, it appears omega is the only tool to try and
include pub_core_options.h and a extra -I{top_srcdir} is needed
somewhere, if only I could work out auto-make foo!
The steps to reproduce this from a clean c
I've been looking at my output aggregation tool again this week and have
spotted a problem with the new output qualifier, in the old system with
the --log-file-qualifier option the name and value of the variable are
put into the xml file, under the new system this information is no
longer availabl
On Wed, 2008-02-27 at 11:49 +0100, Julian Seward wrote:
> > Maybe I should have made myself more clear. The comment in
> > tests/vg_regtest.pl.in explains that stdout.exp files only can have a
> > numeric suffix ([0-9]*), while stderr.exp files can have any suffix
> > (*). If I understood the test
On Wed, 2008-02-20 at 08:15 +0100, Bart Van Assche wrote:
> On Feb 19, 2008 10:09 PM, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
> > But programmers should know in advance which bits of memory should be
> > shared. Perhaps some client requests could be used which say "this section
> > of memo
On Thu, 2008-01-10 at 17:54 +, [EMAIL PROTECTED] wrote:
> This makes Memcheck able to issue errors like this
>
> Uninitialised byte(s) found during client check request
> at 0x4005FE: croak (dsyms2.c:23)
> by 0x40066D: main (dsyms2.c:49)
> Address 0x601043 is 7 bytes inside global
On Sat, 2007-12-08 at 19:30 +0100, Julian Seward wrote:
> We can fix Memcheck by falling back to the reference version, but I'd
> like to see if there is a way to get the correct behaviour without
> the extra conditionals.
Perhaps you could right shift the value before putting it into the tree?
On Mon, 2007-12-03 at 12:17 +0100, Julian Seward wrote:
> Please test it on platforms that are important to you, and let me know
> of any problems (and successes!). If no serious problems show up,
> 3.3.0 final will be available in about a week from now.
I've unfortunately had minimal time for
On Sun, 2007-11-18 at 01:38 +0100, Julian Seward wrote:
> > Another possibility: %qVAR
>
> That would be good, in the sense that the shell can't screw it up.
> Problem is there's no way to know where the env var ends and we move
> back to ordinary command line text.
>
> Maybe %qVAR% or %qVAR%q ?
On Sat, 2007-11-10 at 09:52 +1100, Nicholas Nethercote wrote:
> On Sat, 3 Nov 2007, Josef Weidendorfer wrote:
>
> > I do not understand the benefit of QUAL above. Do I understand correctly,
> > and you specify the name of an environment variable here that is substituted
> > in the file name? Why
11 matches
Mail list logo
