[GRASS-dev] Unused files

tlaronde at polynum.com tlaronde at polynum.com
Mon Apr 16 18:58:53 EDT 2007

On Mon, Apr 16, 2007 at 11:21:02PM +0100, Glynn Clements wrote:
> Markus Neteler wrote:
> > These imagery functions, if really unused, are probably
> > delete candidates.
> Apart from that, it would be nice to start 7.x with "rm -rf imagery/",
> and telling people to clean stuff up before they put it back in.
> If I'm making the same change to every file which uses a particular
> function, I know I've reached the imagery directory when I start
> seeing almost exactly the same file over and over again. E.g.:
> 	imagery/i.ortho.photo/photo.2image/analyze.c
> 	imagery/i.ortho.photo/photo.2target/analyze.c
> 	imagery/i.points/analyze.c
> 	imagery/i.vpoints/analyze.c
> or:
> 	imagery/i.ortho.photo/photo.2image/ask_mag.c
> 	imagery/i.ortho.photo/photo.2target/ask_mag.c
> 	imagery/i.points/ask_mag.c
> 	imagery/i.vpoints/ask_mag.c
> or:
> 	imagery/i.ortho.photo/photo.2image/call.c
> 	imagery/i.ortho.photo/photo.2target/call.c
> 	imagery/i.points/call.c
> 	imagery/i.vpoints/call.c
> or:
> 	[well, you get the idea.]

FWIW, it is indeed a nightmare. I have already---in KerGIS---extracted
the duplicates in a dedicated library, but trying to fix the only 3
imargery modules that are left (for the complete resurrection of the
CERL GRASS), I have, one more time, to rework everything because they
are slighty different, with some modifications in the choice of colors
etc. Not to mention that the C programming skills are the lowest I have
ever seen (with even comments saying that "this function returns 
something so that the program doesn't exit".

I have the finger on the trigger and a _huge_ temptation, but in this
case I will nuke the externally produced additions of imagery, and keep
the CERL original programs (Shapiro).

I'm at the moment simplifying v.digit(1) to put the curses interface
apart (to allow to throw, supplementary to it, an Athena and a Motif)
and I will come back to this... thing after that to see if I feel
courageaous enough.

Just to say that Glynn may seem rough, but I have the exact same feeling
and I think it is the correct solution (but keeping original modules
from CERL---at least that's what I will do in KerGIS; these are not 
difficult to clean and fix and they are so much better written)!

Cleaning the CERL code, and understanding how it worked (and
reorganizing etc.) has, finally, taken me less time (or at least less
headache and no discouragement). And everytime I see the name of the
responsible for this in a module, life expectancy of the module drops

Well, seing that I have "lost" almost one year without being able to
finish this, I do think I will nuke the imagery additions.

Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

More information about the grass-dev mailing list