[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: restructure patch for review [bug-grep]

From: Claudio Fontana
Subject: Re: restructure patch for review [bug-grep]
Date: Mon, 7 Mar 2005 19:07:12 +0100 (CET)

> > lib/ should be really updated. 
> > I've encountered trouble with modules 'error' (big
> > trouble) and 'savedir' too.
> > 
> > I will post the savedir fix I have made separately
> > too,
> > until lib/ is updated.

I should correct myself here. Updating lib/ might not
be so easy at least for savedir, since the savedir
proto has been changed for grep (ChangeLog entry
2001-02-16  Alain Magloir) to take two additional
parameters (for exclude/include).

I would suggest against keeping the "patched version"
of savedir in lib/ (with a different proto), because
it leads to the confusion we're experiencing now (it
it the gnulib savedir?), and instead (to keep speedup
advantage) suggest a custom savedir_exclude() similar
to current savedir to put in src/ instead of lib/

For changes to savedir required to extend exclusion
and inclusion to directories, see patch for bug

I would second the need for info on gnulib "default"
usage. I only have this info from README in the gnulib
source package:
We will be developing a testsuite for these
applications.  The goal is
to have a 100% firm interface so that maintainers can
feel free to
update to the code in CVS at *any* time and know that
application will not break.  This means that before
any change can be
committed to the repository, a test suite program must
be produced
that exposes the bug for regression testing.  All
experimental work
should be done on branches to help promote this.

So this would again point against custom savedir
modifications, because updating gnulib from cvs does
break grep.
> > To be able to set search options in grepopt.c
> though I
> > would need an interface to your search struct
> > (search.h) to set matcher, match_*, eolbyte.
> Yes.  There are two possibilities here:
>   -- you have direct access to the variable that
>      would be of my "struct match_spec" type, or
>   -- you also put them in your "struct
>      grepopt" o variable and src/grep.c does
>      the copying/adaptation from there to a
>      "struct match_spec" variable.

I agree to the second. Just a thought: instead of
handcrafting the struct in grep.c directly, we could
call an initialization function you expose, something
like init_search(params); params are exactly (or built
from) the options I keep in o. Just for the eye.

> Maybe I should also rename "match_spec" to
> "search_spec" to correspond to the file name
> before even publishing a first version.

Seems nicer.

> > I see a priority
> > in going for a heavy restructure to make grep more
> > maintenable, and is what I am offering my help
> > for.
> Yes.  I support this fully,

I'm so glad to hear that.

> but since it can
> be quite an undertaking maybe there should be
> an interim 2.5.2 release just to get some known
> and easy bug fixes out the door while the rest
> would go in a 2.6.0 (or even a planned sequence
> of 2.6.*).

It would be so nice to start 2.6.0 with a clean new

> In addition to our respective work, the current
> Red Hat performance-enhancing patches seem to
> be non-trivial as well.

Ah, why are those patches been kept separate from
those in savannah?
Where can I get a comprensive list of those, and how
are they related to patches in savannah?

Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, 
Giochi, Rubrica… Scaricalo ora! 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]