[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):

 If the tcl/tk version is 95% there in GRASS 6 and the wx replacement only
 50% there in GRASS 7
 I don't mind to spend some time to make the GRASS 6 version complete
 before moving on.

 Markus wrote:
 > Do you have an estimated time for this?

 With the renewed user interest in these modules, I'm a working a little
 bit on it each day now to complete & commit my earlier cleanups & rewrite.
 Expect good things through the coming week.

 With the exception of the small r.li.shape patch below, it's only
 r.li.setup that I'm working on now, so that's the only module I ask
 for communication and coordination on.

 fyi for sync'ing between branches I'm checking with:
  $ kdiff3 relbr_6_4/raster/r.li/ devbr_6/raster/r.li/

 (with some custom filters to ignore .svn files and $Date$ timestamps)


 Hamish wrote:
 > > please commit to the dev branch first then backport to the stable
 > > branch only once the change is fully tested

 (mostly I was concerned with r58878 which was committed out of order to
 the release branch but not the dev branch [thanks for now fore-porting
 that M])

 > Matteo is intensively testing things in the view of GRASS 6.4.4RC1.

 I am glad to hear it. To avoid the need for double-testing, or testing
 code which is
 about to be replaced, it will be much better to test the new commits for
 r.li.setup in devbr6, since they will be extensive and happen there first.
 The r.li.setup code currently in 6.4 is not quoted for spaces and has a
 number of other problems, so not safe especially for Macs, and I would
 support to backport the current work for the 6.4.4 release.

 fyi r.li.setup is still in a state of flux in devbr6, I would not be
 surprised by some typos and half-commits for the next few days.


 > From lessions learned we improve with Rashad's and Luca's support
 > also r.li.setup in G7 which is completely different (programming
 > language and wizard style).

 I am glad for it too, since I am not very familiar with that new tool yet.


 > Please let's get this done, at least in GRASS 6.

 I'm happy to keep on working on the r.li.setup shell scripts, one thing
 which would help is if someone could work on the free()s in the r.li C
 modules. In some of my earlier patches I looked to add some, I note in
 Rashad's patch some have been commented out. It's obviously a trouble
 spot & a reason I allowed to set workers to 1 via an enviro var. &
 suggested Valgrind. for example:

 ??

 {{{
 Index: r.li/r.li.shape/main.c
 ===================================================================
 --- r.li/r.li.shape/main.c      (revision 58891)
 +++ r.li/r.li.shape/main.c      (working copy)
 @@ -89,6 +89,7 @@
                 }
             }
         }
 +       free(mask_buf);
      }

      /* calculate distance */
 }}}


 ----
 with respect to the recent patches, a question about
 sample_area_vector.sh-

 I don't object to it, but am curious to learn the reason why 'v.build
 cdump'
 was replaced by 'v.category print'? Does it do something different/better?
 Also, what is a reasonable maximum number of
 cats to expect? (i.e. to know if the list should be kept in a file or in
 memory)

 with respect to v.extract, note that @mapset isn't needed for output= map
 names, since it is only allowed to write new maps to the current mapset.


 thanks,
 Hamish

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