[GRASS-dev] Re: [GRASS GIS] #1345: backport ctypes to relbr64

[GRASS GIS]

#1345: backport ctypes to relbr64
----------------------------+-----------------------------------------------
  Reporter:  hamish         |       Owner:  martinl            
      Type:  task           |      Status:  closed             
  Priority:  major          |   Milestone:  6.4.2              
 Component:  Python ctypes  |     Version:  svn-releasebranch64
Resolution:  fixed          |    Keywords:                     
  Platform:  All            |         Cpu:  All                
----------------------------+-----------------------------------------------
Changes (by hamish):

  * status:  assigned => closed
  * resolution:  => fixed


Comment:

 Replying to [comment:2 martinl]:
 > I took liberty to backport ctypes in r45937

 thanks. I really feel this will be a good thing.


 ----
  I believe the rest of this conversation belongs on the -dev list, so I'll
 state my piece and get out; closing the bug.

 Replying to [comment:1 martinl]:
 > my opinion is different as I mentioned earlier, you are right that bash
 scripts
 > could be more stable than their python version.

 uber-irrelevant nit-pick: technically bourne scripts, not bash scripts.
 (-> component renamed)

 > Anyway we are discovering new and new bugs in bash scripts (which is
 normal),

 No, really not many at all- most of the scripts have been in use for 5-15+
 years now. Maybe a few more bugs than libgis or the older raster modules,
 but still very few.  Of the 15 or so edits to shell scripts in the last 6
 months, most are either edits to relatively new additions (v.db.*,
 r.in.w{m|f}s, simple quoting of variables for WinGrass), or long
 known/forgotten bugs (yesterday I applied a 3 yr old patch from Brad to
 v.in.mapgen and fixed a quite rare one which survived for 9 years without
 notice until last week).


 > some of them are hard to fix, see e.g. #1310. Unfortunately most of them
 are
 > quite critical. Some of them are remaining open,

 ** those are not bugs in the shell scripts. The shell scripts themselves
 are mature, very well tested, and mostly bug free (AFAWK). 'Til now we
 have not had to compromise the stability of the linux/mac stable branches
 to please MS Windows. IMHO it would be a rotten bother to start that now.


 The bugs you refer to are in the build system (.bat wrappers), wxGUI,
 MSys, and general MS Windows weirdness. WinGrass users new to the command
 line will need to learn to "quote" path names regardless of bourne/python
 scripts, due to the ubiquitous space in path names. If the \slash trouble
 went away instantly, the space problem would still confound argc,argv[].
 The solution to that 'bug' is educating users that path names always have
 to be quoted.


 > generally speaking maintaining bash scripts for winGRASS is a big pain.

 I think that's because hardly anyone is working on the problem, not
 because the problems are especially or fundamentally deep. It's not a
 question of devpower, it's a question of focusing/encouraging volunteers
 to spend some time on chores which don't immediately benefit them (but
 certainly do in the long run). As for me, I've been neglecting it for
 months, but for my part can jump back into this effort sometime in early
 May (go qemu-kvm!). i.e. while problematic, I am not convinced the
 WinGrass + .sh issues are fatal or even that deep. The solution to this
 'bug' is to educate ourselves more about Windows's weirdness, which will
 be useful knowledge anyway.


 And even if it is a pain, we should bear it and deal with it -- one of the
 tenets of a having a stable branch is that you can trust the code stays in
 a known state, warts and all. You work around the ugliness and fix bugs
 along the path of least change in an effort to minimize the chance of
 unintended consequences, and maximizing experience of the behavior.
 Swapping out all the scripts is just too huge a leap in the codebase.

 > Bearing in mind our man power in GRASS developer team

 as far as manpower goes, as long as grass 6 is maintained, and probably
 after, I'll help maintain the shell scripts (luckily they don't need
 much), and lend a hand as I can to help the small wingrass team deal with
 msys troubles (but then next few weeks are insane for me).


 > I think it would be better solution to replace bash scripts by python in
 devbr6.

 ** This is a stable branch. devbr6 (IMNSHO) is for getting things ready
 and testing before backporting to 6.4.x. If the decision has not been made
 for something to eventually go into 6.4, then it does not belong in 6.5.
 Moving something into 6.5 as a wedge to get it into 6.4 later is not
 behavior I ever hope to find in GRASS, as it will be the end of the
 project being fun for me.


 > Fix bugs which has been introduced during conversion from Bash script
 (which is
 > easy).

 It is hard. It doesn't matter how good you are or how much cleaner the new
 language is -- you simply can't replace a decade of widespread testing on
 a huge diversity of systems just like that. It takes time, lots of it.
 When grass7 is ready, they'll be rock solid. I'd so much rather be having
 this conversation about how best to implement a new/future improvement in
 trunk, or doing detective work on specific bugs.


 thanks,
 Hamish

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