Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: grass-6.0.cvs_src_snapshot__2005_01_15
d.what.vect in most cases quits displaying "Broken pipe" info.
I have written the proceure in detail. Sorry if I overdosed but had a good intention :).
1. Digitized a new vector line layer consisted of one short line. A database with one integer column was created in the v.digit Settings->Table menu.
2. Closed v.digit. Topology built fine.
3. Displayed on x0.
4. First d.what.vect went fine no matter how brutally I clicked and where.
5. Closed d.what.vect.
6. Started d.what.vect again. First click - no response. Next click - "Broken pipe" and exit.
7. Each folowing d.what.vect behaved the same.
8. Quiting Grass or even the X server didn't help. Rebooting did. But the problem was back after invoking d.what.vect for the second time.
9. Also some zooming and uzooming helped though not always. But again the story began after calling d.what.vect for a second time.
Maciek
-------------------------------------------- Managed by Request Tracker
Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: grass-6.0.cvs_src_snapshot__2005_01_15
d.what.vect in most cases quits displaying "Broken pipe" info.
I have written the proceure in detail. Sorry if I overdosed but had a good intention :).
1. Digitized a new vector line layer consisted of one short line. A database with one integer column was created in the v.digit Settings->Table menu.
2. Closed v.digit. Topology built fine.
3. Displayed on x0.
4. First d.what.vect went fine no matter how brutally I clicked and where.
5. Closed d.what.vect.
6. Started d.what.vect again. First click - no response. Next click - "Broken pipe" and exit.
7. Each folowing d.what.vect behaved the same.
8. Quiting Grass or even the X server didn't help. Rebooting did. But the problem was back after invoking d.what.vect for the second time.
9. Also some zooming and uzooming helped though not always. But again the story began after calling d.what.vect for a second time.
Maciek
-------------------------------------------- Managed by Request Tracker
Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: grass-6.0.cvs_src_snapshot__2005_01_15
d.what.vect in most cases quits displaying "Broken pipe" info.
Radim Blazek <blazek@itc.it> wrote:
The GUI mode does not work on all platforms, you have to use '-x'
flag.
Hamish via RT <grass-bugs@intevation.de> wrote
work-around: use text mode. d.what.vect -x
I have just checked that d.what.vect in GUI mode works MUCH better in
grass57_exp_2004_12_18 built from source (though still fails from time to
time diplaying the same "Broken pipe" info). Also the bug in v.digit http://intevation.de/rt/webrt?serial_num=2926 attacks less often in that
grass57. Maybe this could be a clue how to fix it?
My platform is Mandrake 10.1, Kde 3.2, gcc 3.3.4 (I have tried 3.4.1 but it
fails e.g. with grass54, hdf4), kernel 2.4.27-0.pre2.1mdk (defult 2.6.8
behaves spooky sometimes). Could some of these components be guilty? If I
went back to Mandrake 9.2 could it better? I realize you might not be able
to guess that far, but if you have an idea - please let me know.
This has been broken on all Mac OSX platforms for at least 18 months. It
seems to be variably broken on some Linux platforms. I don't know about
Windows/Cygwin platforms. I'm sure I sound like a broken record, but it
would be nice to get it fixed. So far, apparently no one has been able to
clearly find the source of this bug to fix it. I've seen discussion that
adding a 'sleep' function to someplace might help, but for some reason this
has not be implemented (perhaps it breaks something else?).
Michael
On 1/24/05 9:26 AM, "Maciek Sieczka" <werchowyna@pf.pl> wrote:
Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: grass-6.0.cvs_src_snapshot__2005_01_15
d.what.vect in most cases quits displaying "Broken pipe" info.
Radim Blazek <blazek@itc.it> wrote:
The GUI mode does not work on all platforms, you have to use '-x'
flag.
Hamish via RT <grass-bugs@intevation.de> wrote
work-around: use text mode. d.what.vect -x
I have just checked that d.what.vect in GUI mode works MUCH better in
grass57_exp_2004_12_18 built from source (though still fails from time to
time diplaying the same "Broken pipe" info). Also the bug in v.digit http://intevation.de/rt/webrt?serial_num=2926 attacks less often in that
grass57. Maybe this could be a clue how to fix it?
My platform is Mandrake 10.1, Kde 3.2, gcc 3.3.4 (I have tried 3.4.1 but it
fails e.g. with grass54, hdf4), kernel 2.4.27-0.pre2.1mdk (defult 2.6.8
behaves spooky sometimes). Could some of these components be guilty? If I
went back to Mandrake 9.2 could it better? I realize you might not be able
to guess that far, but if you have an idea - please let me know.
Cheers
Maciek
____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
I've seen discussion that
adding a 'sleep' function to someplace might help, but for some reason this
has not be implemented (perhaps it breaks something else?).
it didn't cause any errors for me. i just wasn't sure if it should be uploaded as i don't know why adding "sleep" solved this bug.
if wanted i commit it to cvs.
I've seen discussion that
adding a 'sleep' function to someplace might help, but for some reason
this
has not be implemented (perhaps it breaks something else?).
it didn't cause any errors for me. i just wasn't sure if it should be
uploaded as i don't know why adding "sleep" solved this bug.
if wanted i commit it to cvs.
Florian
If you hesitate to apply thid patch to CVS would you mind sending it to me so I try it on my system at least? Maybe it will help.
Unless this breaks something, can we apply it so that all systems can use
the form mode?
Michael
On 1/26/05 3:20 AM, "Maciek Sieczka" <werchowyna@pf.pl> wrote:
From: "Florian Goessmann" <florian@wallweg39.de>
On 25.01.2005, at 14:47, Michael Barton wrote:
I've seen discussion that
adding a 'sleep' function to someplace might help, but for some reason
this
has not be implemented (perhaps it breaks something else?).
it didn't cause any errors for me. i just wasn't sure if it should be
uploaded as i don't know why adding "sleep" solved this bug.
if wanted i commit it to cvs.
Florian
If you hesitate to apply thid patch to CVS would you mind sending it to me
so I try it on my system at least? Maybe it will help.
Maciek
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
Unless this breaks something, can we apply it so that all systems can
use the form mode?
when tried in the past this made response time horrible.
I tried the "sleep(1)" patch and it did the trick on Mandrake 10.1. As
expected the response time is 1 second worse for each feature, but only for
the *first* query. Each following query result pops up in a reasonable,
standard pace. Expected too?
Also thanks to this "patch" v.digit became more usable - now the atribute
table pops up automatically when a new feature is digitized and at last it
is possible to edit the atributes table without having to click dozens of
times which was the case so far. Again, each first call is 1 delayed second,
each next on normal pace - until the attribute window is closed.
I don't think it's a good idea to apply it into CVS for good as it is not a
real solution, but on the other hand it would be very practical if Debian,
Mandrake 10 and 10.1 users could be somehow informed that such a dirty
workaround is possible temporarily. How can this be done?
Anyway, does anybody have an idea what the hack that on e.g. Mandrake 9.2
this strange patch is not necessary? And also why does this bug attack less
frequently on Grass57 (exp_2004_12_18) than on Grass60 on my Mdk 10.1?
I have got an idea! main() in lib/form/form.c is using G_* functions and G_gisinit() should be always called before other G_ functions are used.
Could you please try to comment sleep(1) and add G_gisinit("form");
as the first function in main(), i.e. before
G_debug ( 2, "Form: main()" ); ?
Let us know if it helps.
Radim
Maciek Sieczka wrote:
From: "Hamish" <hamish_nospam@yahoo.com>
+ sleep(1);
Unless this breaks something, can we apply it so that all systems can
use the form mode?
when tried in the past this made response time horrible.
I tried the "sleep(1)" patch and it did the trick on Mandrake 10.1. As
expected the response time is 1 second worse for each feature, but only for
the *first* query. Each following query result pops up in a reasonable,
standard pace. Expected too?
Also thanks to this "patch" v.digit became more usable - now the atribute
table pops up automatically when a new feature is digitized and at last it
is possible to edit the atributes table without having to click dozens of
times which was the case so far. Again, each first call is 1 delayed second,
each next on normal pace - until the attribute window is closed.
I don't think it's a good idea to apply it into CVS for good as it is not a
real solution, but on the other hand it would be very practical if Debian,
Mandrake 10 and 10.1 users could be somehow informed that such a dirty
workaround is possible temporarily. How can this be done?
Anyway, does anybody have an idea what the hack that on e.g. Mandrake 9.2
this strange patch is not necessary? And also why does this bug attack less
frequently on Grass57 (exp_2004_12_18) than on Grass60 on my Mdk 10.1?