Hi Anna
I just updated GRASS trunk version (GRASS GIS 7.1.svn r68252) to test the data catalogue. However, when opening the data tab in the main GUI, after some waiting, the GUI crashes with:
GRASS_INFO_ERROR(30614,1): Mapset <backup> does not exist
GRASS_INFO_END(30614,1)
python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
There was indeed a reference to a non-existing backup mapset in one of the SEARCH_PATH files, but also after removing that reference, I am getting the same crash with message (below), which makes me wonder where else to look for a reference to an non-existing mapset.
GRASS_INFO_ERROR(32753,1): Mapset <backup> does not exist
GRASS_INFO_END(32753,1)
python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
I tried it again, and got a slightly different message:
GRASS_INFO_ERROR(31864,1): Mapset <backup> does not exist
GRASS_INFO_END(31864,1)
python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Xlib: request 54 length 8 would exceed buffer size.
and yet another time, with the message below, which does not seem terribly helpful, but I am copying anyway.
GRASS_INFO_END(32455,1)
The program 'python' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
(Details: serial 15786 error_code 16 request_code 139 minor_code 4)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
The program 'python' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
(Details: serial 15795 error_code 16 request_code 130 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
On 10-04-16 05:00, Anna Petrášová wrote:
Hi,
I was wondering what is the opinion about the new data catalog (in
trunk), specifically, whether users should be able to modify (copy,
rename, delete) maps from other mapsets and locations than the current
ones. I find it very useful to edit any mapsets, but it goes against
the traditional GRASS approach. I have this (edit anything behavior)
implemented locally, but wanted to know before committing if people
agree with that.
Thanks,
Anna
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user