Hi,
Roberto Flor and me have fixed the bug
"v.digit: Could not set Tcl system encoding"
http://intevation.de/rt/webrt?serial_num=4110
Please test. I'll backport it to 6.2.x then.
Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2
but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work.
Maybe my installation...
Markus
Markus Neteler wrote:
Hi,
Roberto Flor and me have fixed the bug
"v.digit: Could not set Tcl system encoding"
http://intevation.de/rt/webrt?serial_num=4110Please test. I'll backport it to 6.2.x then.
Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2
but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work.
Maybe my installation...
I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper
32bit.
Maciek
Maciej Sieczka wrote on 02/07/2007 04:51 PM:
Markus Neteler wrote:
Hi,
Roberto Flor and me have fixed the bug
"v.digit: Could not set Tcl system encoding"
http://intevation.de/rt/webrt?serial_num=4110Please test. I'll backport it to 6.2.x then.
Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2
but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work.
Maybe my installation...
I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper
32bit.
So we are happy since most of the encodings now work.
Markus
Markus Neteler wrote:
>> Roberto Flor and me have fixed the bug
>> "v.digit: Could not set Tcl system encoding"
>> http://intevation.de/rt/webrt?serial_num=4110
>>
>> Please test. I'll backport it to 6.2.x then.
>>
>> Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2
>> but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work.
>> Maybe my installation...
>>
>
> I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper
> 32bit.So we are happy since most of the encodings now work.
Not having ISO-8859-1 working is a pretty major issue.
Can you provide more details, preferably including a recipe to
reproduce the issue using either spearfish or a new location?
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote on 02/08/2007 12:41 PM:
Markus Neteler wrote:
Roberto Flor and me have fixed the bug
"v.digit: Could not set Tcl system encoding"
http://intevation.de/rt/webrt?serial_num=4110Please test. I'll backport it to 6.2.x then.
Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2
but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work.
Maybe my installation...
I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper
32bit.
So we are happy since most of the encodings now work.
Not having ISO-8859-1 working is a pretty major issue.
I am still not sure if it is a local problem or a general one or depends on the tcltk version.
Can you provide more details, preferably including a recipe to
reproduce the issue using either spearfish or a new location?
Sure (eg Spearfish):
d.mon x0
v.digit -n newmap
# now go to "Settings" icon, "Table" tab, "Add column", add a column of your choice, "Create table"
# close the "Settings" window
# digitize a line
# enter a value into the attribute popup form
# "submit button" (default is utf-8 which seems to work)
# change the encoding, click "submit button" again and voila' the error appear in the terminal
Markus
Markus Neteler wrote:
>>>> Roberto Flor and me have fixed the bug
>>>> "v.digit: Could not set Tcl system encoding"
>>>> http://intevation.de/rt/webrt?serial_num=4110
>>>>
>>>> Please test. I'll backport it to 6.2.x then.
>>>>
>>>> Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2
>>>> but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work.
>>>> Maybe my installation...
>>>>
>>>>
>>> I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper
>>> 32bit.
>>>
>> So we are happy since most of the encodings now work.
>>
>
> Not having ISO-8859-1 working is a pretty major issue.
>
I am still not sure if it is a local problem or a general one or depends
on the tcltk version.
> Can you provide more details, preferably including a recipe to
> reproduce the issue using either spearfish or a new location?
>
Sure (eg Spearfish):
d.mon x0
v.digit -n newmap
# now go to "Settings" icon, "Table" tab, "Add column", add a column of
your choice, "Create table"
# close the "Settings" window
# digitize a line
# enter a value into the attribute popup form
# "submit button" (default is utf-8 which seems to work)
# change the encoding, click "submit button" again and voila' the error
appear in the terminal
Okay.
I'm pretty sure that the problem is that lib/form/form.c doesn't call
Tcl_Main(), so the library path doesn't get set, so Tcl can't find its
.enc files.
Realistically, if you are trying to use Tcl/Tk and your program
*doesn't* look very much like tkAppInit.c, all bets are off.
Rather than trying to process the data from the form library in C,
form.c should just register the commands then do the rest in Tcl.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote on 02/08/2007 11:38 PM:
Markus Neteler wrote:
Roberto Flor and me have fixed the bug
"v.digit: Could not set Tcl system encoding"
http://intevation.de/rt/webrt?serial_num=4110Please test. I'll backport it to 6.2.x then.
Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2
but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work.
Maybe my installation...
I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper
32bit.
So we are happy since most of the encodings now work.
Not having ISO-8859-1 working is a pretty major issue.
I am still not sure if it is a local problem or a general one or depends on the tcltk version.
Can you provide more details, preferably including a recipe to
reproduce the issue using either spearfish or a new location?
Sure (eg Spearfish):
d.mon x0
v.digit -n newmap
# now go to "Settings" icon, "Table" tab, "Add column", add a column of your choice, "Create table"
# close the "Settings" window
# digitize a line
# enter a value into the attribute popup form
# "submit button" (default is utf-8 which seems to work)
# change the encoding, click "submit button" again and voila' the error appear in the terminal
Okay.I'm pretty sure that the problem is that lib/form/form.c doesn't call
Tcl_Main(), so the library path doesn't get set, so Tcl can't find its
.enc files.Realistically, if you are trying to use Tcl/Tk and your program
*doesn't* look very much like tkAppInit.c, all bets are off.Rather than trying to process the data from the form library in C,
form.c should just register the commands then do the rest in Tcl.
Since I know nothing about tcl, I'll leave that to the experts. AFAIK form.c was
originally written by Radim.
Markus
Markus Neteler wrote:
> I'm pretty sure that the problem is that lib/form/form.c doesn't call
> Tcl_Main(), so the library path doesn't get set, so Tcl can't find its
> .enc files.
>
> Realistically, if you are trying to use Tcl/Tk and your program
> *doesn't* look very much like tkAppInit.c, all bets are off.
>
> Rather than trying to process the data from the form library in C,
> form.c should just register the commands then do the rest in Tcl.Since I know nothing about tcl, I'll leave that to the experts. AFAIK
form.c was
originally written by Radim.
The attached patch appears to work, insofar as v.digit appears to work
as before, minus the encoding errors. OTOH, I know next to nothing
about v.digit (or the vector stuff in general), so it would probably
be a good idea for it to be tested by someone who is familiar with
v.digit.
Essentially, the form utility (lib/form/form.c) has been rewritten as
a typical "extended wish", with the communication with the form
library being performed in Tcl.
--
Glynn Clements <glynn@gclements.plus.com>
form.diff (10.5 KB)
Glynn Clements wrote:
> > I'm pretty sure that the problem is that lib/form/form.c doesn't call
> > Tcl_Main(), so the library path doesn't get set, so Tcl can't find its
> > .enc files.
> >
> > Realistically, if you are trying to use Tcl/Tk and your program
> > *doesn't* look very much like tkAppInit.c, all bets are off.
> >
> > Rather than trying to process the data from the form library in C,
> > form.c should just register the commands then do the rest in Tcl.
>
> Since I know nothing about tcl, I'll leave that to the experts. AFAIK
> form.c was
> originally written by Radim.The attached patch appears to work, insofar as v.digit appears to work
as before, minus the encoding errors. OTOH, I know next to nothing
about v.digit (or the vector stuff in general), so it would probably
be a good idea for it to be tested by someone who is familiar with
v.digit.Essentially, the form utility (lib/form/form.c) has been rewritten as
a typical "extended wish", with the communication with the form
library being performed in Tcl.
As I haven't had any response either way on this, I've committed the
changes.
--
Glynn Clements <glynn@gclements.plus.com>