Re: [gamin] monitoring of links
- From: Daniel Veillard <veillard redhat com>
- To: TomPh <tpgww onepost net>
- Cc: gamin-list gnome org
- Subject: Re: [gamin] monitoring of links
- Date: Fri, 26 Aug 2005 10:12:15 -0400
On Fri, Aug 26, 2005 at 11:28:46PM +1000, TomPh wrote:
> > On Fri, Aug 26, 2005 at 08:11:23PM +1000, TomPh wrote:
> > Well I don't think it makes sense to add test if we know they would
> > fail and we don't have a good idea of what the actual behaviour
> > should be.
> Indeed. I was hoping that some of the crew with more history than me
> would think about and comment on what the results should be, before
> anyone takes a shot at making gamin pass the tests that we end up with.
> > > The link-test patch provides for making links, and changing their
> > > ownership (to get around prohibitions on changing link permissions).
> > > Incidentally, it adds a test for more-reports-than-expected, which
> > > shows up one or two of the existing basic test-cases, but not
> > > fatally so.
> > I don't know if this is what you meant, but applying your patch
> > makes "make tests" fail while it was passing before. So well, I won't
> > apply it. You can split the part adding the new commands which is a
> > good idea. For the other part forcing failures on existing tests,
> > suggest separately the patch and explain why you think "make tests"
> > should be breaking from the very first test... I have a hard time
> > understanding how this can be a good idea.
> Too-many reports can be just as damaging for a client as not-enough, as
> you will well understand. Particularly with the link-related tests, the
> prospect of superfluous reporting is increased. Hence the addition of a
> check for that outcome.
> With that check in effect and running 'make tests', here I see extra
> reports for basic test 10 only, as follows:
> running test 10
> *** ../tests/result/10 2005-05-12 21:38:22.000000000 +1000
> --- result.10 2005-08-26 23:00:07.000000000 +1000
> *** 6,14 ****
> --- 6,16 ----
> 1: /tmp/test_gamin Exists: NULL
> 1: subdir Exists: NULL
> 1: /tmp/test_gamin EndExist: NULL
> + expect line 7: expected 2 events but got 3
> monfile /tmp/test_gamin/subdir/foo 1
> 2: /tmp/test_gamin/subdir/foo Exists: NULL
> 2: /tmp/test_gamin/subdir/foo EndExist: NULL
> + expect line 10: expected 1 events but got 2
> cancel 0 2
> 1: /tmp/test_gamin Acknowledge: NULL
> append /tmp/test_gamin/subdir/foo
> Both of those extra reports look to me like they are right, and
> indicate a problem with the results file, not with gamin's performance.
> So fix the results file ...
expects X means 'there is at least X events to come'
You changed the behaviour of expect. The history of this are the
expect scripts which were looking at lines from tty when communicating by
modems, catching some input to switch to a new state.
If you want to modify the behaviour of teh expect command fine, but then
also make sure this won't break "make tests"
> > > And it no longer stops the test when the no. of events is wrong.
> > > That occasionally caused havoc when thing(s) created in a test were
> > > not cleaned up at the end of the test.
> > "make tests" was removing remains that was okay.
> Basic test 11 does not exit cleanly when run against --disable-kernel.
> In turn, that stuffs up most of the rest of the basic tests in that
I'm off for 4 days, no reply from me till Wednesday is normal.
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev