[GRASS-dev] Fwd: [GRASS-SVN] r56709 - grass/branches/develbranch_6/raster/r.li/r.li.setup

[Hamish]

Markus Neteler wrote:
> this one looks like an urgent backport candidate for me?
> 
> I think that one of my doctorate students just complained to
> me that digitizing failed for him (I need to ask).
>
> In any case, this should go then into relbranch64 before it
> is forgotten (and it is also more relevnt than the other r.li
> cleanup fixes done in dev6branch.
> 
> What do you think?

Hi Markus,

that was just a first commit of a bigger r.li cleanup which I have
started locally but not yet committed to the dev branches. I wanted
to commit those various small fixes now to get them out of the way
since my 'svn diff' was getting a bit cluttered. I am not surprised
things failed really, to work well it will still need some commits I
haven't made yet (I am just working through the code so far: completely
untested), e.g. for that r.digit call related to the circle.txt file
in the commit it will need the output map name passed on the command
line since I changed r.digit into a "normal" G_parser() module 7+ years
ago.

For grass7 there is Luca's g.gui.rlisetup.py (I am not totally
convinced about the g.gui.* naming), I am just keeping the raster/r.li
r.li.setup dir in sync to avoid older code being in the "newer"
branches. Much of r.li.setup will be deleted in trunk eventually since
it needs Xmons, tcl/tk, shell scripts, etc. and is replaced by the
wxPy version.

So I think r.li.setup is too much broken to worry about for 6.4.3; I
look to make one fix and see three more. Let's get 6.4.3 out the door
asap and keep an improved r.li as a goal for 6.4.4. I looked at the
list of r.li bugs in the trac system earlier, it is in need of some
care. AFAICT it's nothing fatal, just many small fixes to work through.


regards,
Hamish