[GRASS-dev] backporting new v.digit to the 6.2 branch

Thu Apr 26 15:43:02 EDT 2007

Hamish wrote:
>> Hamish wrote:
>>> Can anyone point to **specific bug reports that cause a crash or
>>> data loss, and are fixed in the 6.3-CVS version**?
>>>
>>> https://intevation.de/rt/webrt?q_status=open&q_queue=grass&q_subject=v.digit
> 
> Maciej wrote:
>> Issues resolved in 6.3 CVS but present in 6.2, AFAIK, [1],[2],[3]:
> 
> 
>> [1]https://intevation.de/rt/webrt?serial_num=4110
>> 1. One can't use encodings besides ISO-8859-1 in data tables [1].
> 
> Certainly annoying for non-English folks, but this is a feature enhancement

No. It's a bug. v.digit provides UTF-8 encoding but it does not work -
when I enter non-English characters, I get garbage symbols in v.digit
attribute editor window. However, the national characters *are* stored
 in the table in spite of this - eg. v.db.select in terminal properly
returns the national chars which I entered in v.digit; only that I
can't see in v.digit what I enter :).

> - not a critical bug - so not a backport candidate.
> Does the same issue exist for "d.what.vect -e"?

Yes.

>> [2]https://intevation.de/rt/webrt?serial_num=4454
>  "v.digit: 'Digitize new point' tool is activated by default"
>  "It shouldn't. None other tool should either."
> 
> This is more of a wish/annoyance than a bug, certainly not a serious bug.
> Not a backport candidate.

OK.

>> [3]http://grass.itc.it/pipermail/grassuser/2007-February/038176.html
>> 2. One can't digitize areas [3].
>> The issue [3] was never reported in the tracker but it's present in
>> 6.2 and fixed in 6.3, AFAICT.
> 
> Ok, this one is a backport candidate if we can isolate it & fix it.
> But I can't reproduce it. I tried:

You are correct. I can't reproduce it anymore myself. Great. Must have
been a fix commited. The last time I tried (and before), ie. until Feb
2 2007 the bug was present in 6.2 CVS.

On a related note - I have thought that bug
http://intevation.de/rt/webrt?serial_num=4429 was fixed only for 6.3
CVS. After playing around with d.what.vect -e I can see now it is OK in
6.2 CVS too.

>> [4]https://intevation.de/rt/webrt?serial_num=5127

> Was this mentioned on the mailing list in just the last day or two?

Yes, and I provided a link to this bug report in the thread.

>> [5]https://intevation.de/rt/webrt?serial_num=2962
> [v.digit changes the WIND file instead of setting up a WIND_OVERRIDE
> setting or similar] Also might not use "g.region -a" alignment during
> zooming/panning so underlayed raster at coarse res may appear to shift
> about under the vector line leading to inexact digitization.
> from the bug report:
> "Hamish: This bug should be kept open as the v.digit code should a) not
> be changing the WIND file (if that's possible with mixed Tcl + C) and
> b) use "g.region -a" like code when zooming so as not to corrupt
> background raster resampling."
> Note that it now restores the startup region upon clean exit.

Anyway this is a long standing and serious bug.

> So it boils down to issue [3] "can't digitize centroids".
> But this works fine for me in 6.2.1, so .....?

Same for me now, as I explain above. In that case if the encoding issue
could be fixed in 6.2, v.digit in 6.2 and 6.3 would be on a par.

> what's more, v.digit in GRASS 6.3 segfaults on startup for me currently.

Oh. For me it works OK in 6.3.

> Not an encouraging sign for the 6.3 version being mature enough to
> backport.

> g.region rast=roads
> v.digit -n test_dig_area
> New empty map created.
> ###wish gui flashes up then disappears###
> Segmentation fault
> 
> gdb:
> G63> gdb `which v.digit`
> ..
> (gdb) run -n test_map1
> Starting program: /usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/bin/v.digit -n test_map1
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 9024)]
> New empty map created.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 9024)]
> 0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1
> 
> (gdb) where
> #0  0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1
> #1  0x406e5a77 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
> #2  0x406e5967 in Tcl_EvalTokens () from /usr/lib/libtcl8.3.so.1
> #3  0x406e5ad8 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
> #4  0x406e5ead in Tcl_Eval () from /usr/lib/libtcl8.3.so.1
> #5  0x0805074f in get_window (t=0xbfffdddc, b=0xbfffddd8, l=0xbfffddd4, r=0xbfffddd0) at driver.c:58
> #6  0x08050811 in setup () at driver.c:73
> #7  0x0805091c in driver_open () at driver.c:101
> #8  0x0804f9cd in tool_centre () at centre.c:50
> #9  0x0804e9b7 in c_tool_centre (cdata=0x0, interp=0x8069248, argc=1, argv=0xbfffdf40) at c_face.c:159
> #10 0x406ad7ab in TclInvokeStringCommand () from /usr/lib/libtcl8.3.so.1
> #11 0x406e529c in TclExpandTokenArray () from /usr/lib/libtcl8.3.so.1
> #12 0x406e5b3d in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
> #13 0x406dca0e in Tcl_EvalFile () from /usr/lib/libtcl8.3.so.1
> #14 0x40609774 in Tk_MainEx () from /usr/lib/libtk8.3.so.1
> #15 0x08055102 in main (argc=3, argv=0xbffff6b4) at main.c:171
> 
> 
> same thing starting with:
> G63> GRASS_WISH=wish8.4  v.digit -n test_map2

FWIW I build and run against tcl/tk 8.4.12. No crashes here.

> We seem to have agreed (yes?) that backporting the new EPSG code search
> tool in violation of the "fixes for serious bugs only" rule is ok, as
> it is a non-critical component and the new version is really really nice.
> So I hope I'm not seeming to be unfair in playing conservative with
> v.digit while at the same time pushing for the new EPSG picker.

I don't have a strong position on this.

Maciek