backport ctypes to relbr64

[hamish]

placeholder ticket for discussing backporting ctypes to the 6.4 branch.

---

IMHO solid python scripting is an important feature to get working for end-users in the 6.4 branch after the next point release. lots of users want it.

(Although in 6.x-stable I'd totally oppose replacing the existing shell scripts/ with their many many years of testing & stabilization)

Hamish

[martinl]

Replying to hamish:

(Although in 6.x-stable I'd totally oppose replacing the existing shell scripts/ with their many many years of testing & stabilization)

my opinion is different as I mentioned earlier, you are right that bash scripts could be more stable than their python version. Anyway we are discovering new and new bugs in bash scripts (which is normal), some of them are hard to fix, see e.g. #1310. Unfortunately most of them are quite critical. Some of them are remaining open, generally speaking maintaining bash scripts for winGRASS is a big pain. Bearing in mind our man power in GRASS developer team I think it would be better solution to replace bash scripts by python in devbr6. Fix bugs which has been introduced during conversion from Bash script (which is easy). Make them solid and working on Windows. And later to backported them to relbr64. It's just my opinion. I would be happy to hear also other devs from the community.

[martinl]

Replying to hamish:

placeholder ticket for discussing backporting ctypes to the 6.4 branch.

---

IMHO solid python scripting is an important feature to get working for end-users in the 6.4 branch after the next point release. lots of users want it.

I agree that ctypes are needed to be backported to relbr64, at least there are two wxGUI extensions which are depending on ctypes (digitizer and 3d view). I took liberty to backport ctypes in r45937

[hamish]

Replying to 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 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