[GRASS-dev] [GRASS GIS] #2024: r.li.setup generates incomplete r.li conf file

[GRASS GIS]

#2024: r.li.setup generates incomplete r.li conf file
------------------------+---------------------------------------------------
 Reporter:  matmar      |       Owner:  rashadkm           
     Type:  defect      |      Status:  assigned           
 Priority:  normal      |   Milestone:  6.4.4              
Component:  Raster      |     Version:  svn-releasebranch64
 Keywords:  r.li.setup  |    Platform:  Linux              
      Cpu:  x86-64      |  
------------------------+---------------------------------------------------

Comment(by hamish):

 Hi,

 I still have a lot of changes to commit to the r.li.setup shell scripts in
 devbr6 (the patches are over 650 lines long), so I would ask a little time
 to merge those before making any more changes and diverging the code. I
 will sync with your patch and look+learn closely at it. I don't have a fix
 for the bashism, but I haven't looked to closely at it or if it will
 conflict with my changes. I'll sync my changes with what's in svn now, no
 need to revert if it's working; my fault for leaving it so long. I
 probably shouldn't spend any more time on this today, but I'll look at
 syncing the new patch with trunk as a top priority if no one else has done
 it first.

 (how's the status of wx-r.li.setup in trunk? is the tcl/shell version in
 trunk still needed as a reference?)


 fwiw I had not backported the num_workers code before because it wasn't
 well tested or what I consider properly finished (see comment:1), but I
 guess now it is done we'll have to do some more serious testing. i.e. I
 wouldn't be surprised if a little more work will be needed, but the
 situation should on the whole be better than before, so we're still moving
 forward..

 for some sort of coordinated plan, I would suggest to focus on trunk to
 work on r.li C modules, and devbr6 to work on the r.li.setup tcl/bash
 code. I would suggest any new major development to happen in trunk first.


 there seemed to be common issues with the C modules around free()ing
 memory, I see you've come across the same. All these modules need a good
 run through Valgrind.

 wrt the 'raster_' variable, my main point is please use self-documenting
 variable names. so -> raster_fqn if that's what it is. if there is code
 which is not handling map at mapset or without @mapset in the usual grass way
 (e.g. the imagery library long had issues with that), we should open new
 tickets for that and fix it too instead of cluttering the code by patching
 around 3rd party bugs.


 thanks both Rashad & Markus for taking it up, r.li has been waiting for
 this work for some time!


 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2024#comment:13>
GRASS GIS <http://grass.osgeo.org>