My 2c worth is to give g.xlist and g.xremove sufficient testing to make sure that they work OK and then simply replace g.mlist and g.mremove with the new C versions. Having g.list, g.mlist, g.xlist, g.remove, g.mremove, and g.xremove is confusing.
Furthermore, for GRASS 7, I'd recommend merging what are now g.list with g.xlist and g.remove with g.xremove.
Michael
On Sep 6, 2008, at 11:15 PM, <grass-dev-request@lists.osgeo.org> <grass-dev-request@lists.osgeo.org > wrote:
Date: Sun, 7 Sep 2008 02:15:01 -0400
From: Huidae Cho <grass4u@gmail.com>
Subject: Re: [GRASS-dev] Re: [GRASS-user] g.xlist/g.xremove addons (C
version of g.mlist/g.mremove)
To: Glynn Clements <glynn@gclements.plus.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID: <20080907061501.GA31420@geni.home>
Content-Type: text/plain; charset=us-asciiOn Sat, Sep 06, 2008 at 10:05:08PM +0100, Glynn Clements wrote:
Huidae Cho wrote:
If we decide to keep the script versions as a fallback, those will be
replaced with Python versions in 7.x, so they can be changed to use
extended REs (the shell script uses sed, which only supports basic
REs). Or we can make the C versions use basic REs for -r and add e.g.
-e for extended REs.FWIW, I've done this; -r uses basic REs, -e uses extended REs.
I didn't mean whether or not we need to keep the script versions; I
doubt the need for fallback versions. What I suggest is to remove the
script versions (already done)The script versions are still there, and should be kept until we're
sure that there aren't any problems with the C versions (e.g. whether
the configure checks for the regex functions are sufficient).and "rename" the C version of
g.mlist/g.mremove to g.xlist/g.xremove as its current name g."m"list
(modified g.list) is somewhat awkward compared to g."x"list (extended
g.list).Renaming them means that any scripts which use them will need to be
changed, documentation needs to be changed, etc, which seems like
gratuitous incompatibility.I don't think it's a good idea to have two flags for basic and extended
REs unless grass7 should keep backward compatibility.We don't have to keep compatibility, but that doesn't mean that we
break things without reason.Original g.xlist/g.xremove are not compatible with their script versions
because these modules support only extended REs with -r flag and I
didn't see the need for two regex flags. Having one flag for just
extended REs would be simple and straightforward, and could be a good
reason for incompatibility. Just my two cents.AFAICT, the new modules provide exactly the same functionality (and
with the same names) as the existing scripts. Anything that worked
before with the scripts should continue to work with either the
scripts or the C modules.If we decide to have fallback scripts, yes, the both versions should
provide the same functionality. If we decide to drop the scripts, I'm
not sure why we cannot have just one flag for extended REs and break
things for the above reason.Except for one thing: the g.mremove script has dview= rather than
3dview=. The C modules has 3dview=, and both versions of g.mlist use
type=3dview. I'm not sure if there's a reason for this, or if it was
just a typo.The very first version had 3dview=, but I don't know when it changed.
Probably, when we added g.parser's GIS_OPT_ feature?Huidae
------------------------------
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-devEnd of grass-dev Digest, Vol 29, Issue 16
*****************************************