After installin grass70 from "[http://ppa.launchpad.net/grass/grass-devel/ubuntu](http://ppa.launchpad.net/grass/grass-devel/ubuntu)" on Ubuntu 12.04 64, it fails to ``launch grass. The wxpython gui gives the following error:
Launching GUI in the background, please wait…
GRASS 7.0.svn (utm32n):~ > ERRORE: MAPSET toscana - permesso negato
Traceback (most recent call last):
File “/usr/lib/grass70/etc/gui/wxpython/wxgui.py”, line 143, in
sys.exit(main())
File “/usr/lib/grass70/etc/gui/wxpython/wxgui.py”, line 136, in main
app = GMApp(workspaceFile)
File “/usr/lib/grass70/etc/gui/wxpython/wxgui.py”, line 50, in init
wx.App.init(self, False)
File “/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py”, line 7981, in init
self._BootstrapApp()
File “/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py”, line 7555, in _BootstrapApp
return core.PyApp__BootstrapApp(*args, **kwargs)
File “/usr/lib/grass70/etc/gui/wxpython/wxgui.py”, line 84, in OnInit
workspace = self.workspaceFile)
File “/usr/lib/grass70/etc/gui/wxpython/lmgr/frame.py”, line 109, in init
self._menuTreeBuilder = LayerManagerMenuData()
File “/usr/lib/grass70/etc/gui/wxpython/lmgr/menudata.py”, line 40, in init
MenuTreeModelBuilder.init(self, filename, expandAddons=expandAddons)
File “/usr/lib/grass70/etc/gui/wxpython/core/menutree.py”, line 69, in init
xmlTree = etree.parse(filename)
File “/usr/lib/python2.7/xml/etree/ElementTree.py”, line 1183, in parse
tree.parse(source, parser)
File “/usr/lib/python2.7/xml/etree/ElementTree.py”, line 657, in parse
self._root = parser.close()
File “/usr/lib/python2.7/xml/etree/ElementTree.py”, line 1655, in close
self._raiseerror(v)
File “/usr/lib/python2.7/xml/etree/ElementTree.py”, line 1507, in _raiseerror
raise err
xml.etree.ElementTree.ParseError: no element found: line 1, column 0
After installin grass70 from "[http://ppa.launchpad.net/grass/grass-devel/ubuntu](http://ppa.launchpad.net/grass/grass-devel/ubuntu)" on Ubuntu 12.04 64, it fails to ``launch grass. The wxpython gui gives the following error:
Launching GUI in the background, please wait…
GRASS 7.0.svn (utm32n):~ > ERRORE: MAPSET toscana - permesso negato
Traceback (most recent call last):
File “/usr/lib/grass70/etc/gui/wxpython/wxgui.py”, line 143, in
sys.exit(main())
File “/usr/lib/grass70/etc/gui/wxpython/wxgui.py”, line 136, in main
app = GMApp(workspaceFile)
File “/usr/lib/grass70/etc/gui/wxpython/wxgui.py”, line 50, in init
wx.App.init(self, False)
File “/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py”, line 7981, in init
self._BootstrapApp()
File “/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py”, line 7555, in _BootstrapApp
return core.PyApp__BootstrapApp(*args, **kwargs)
File “/usr/lib/grass70/etc/gui/wxpython/wxgui.py”, line 84, in OnInit
workspace = self.workspaceFile)
File “/usr/lib/grass70/etc/gui/wxpython/lmgr/frame.py”, line 109, in init
self._menuTreeBuilder = LayerManagerMenuData()
File “/usr/lib/grass70/etc/gui/wxpython/lmgr/menudata.py”, line 40, in init
MenuTreeModelBuilder.init(self, filename, expandAddons=expandAddons)
File “/usr/lib/grass70/etc/gui/wxpython/core/menutree.py”, line 69, in init
xmlTree = etree.parse(filename)
File “/usr/lib/python2.7/xml/etree/ElementTree.py”, line 1183, in parse
tree.parse(source, parser)
File “/usr/lib/python2.7/xml/etree/ElementTree.py”, line 657, in parse
self._root = parser.close()
File “/usr/lib/python2.7/xml/etree/ElementTree.py”, line 1655, in close
self._raiseerror(v)
File “/usr/lib/python2.7/xml/etree/ElementTree.py”, line 1507, in _raiseerror
raise err
xml.etree.ElementTree.ParseError: no element found: line 1, column 0
Ahmadou H. DICKO
statistician economist (Ingénieur Statisticien Économiste)
PhD candidate in Climate change economics
Faculty of economics and managment - Cheikh Anta Diop University
West African Science Service Center on Climate Change and Adaptated Land Use (WASCAL)
Center for Development Research (ZEF) - University of Bonn
email : ahmadou.dicko@ucad.edu.sn
twitter : @dickoah
github : github/dickoa
tel : +221 33 827 55 16
portable: +221 77 123 81 69
Ahmadou H. DICKO
statistician economist (Ingénieur Statisticien Économiste)
PhD candidate in Climate change economics
Faculty of economics and managment - Cheikh Anta Diop University
West African Science Service Center on Climate Change and Adaptated Land Use (WASCAL)
Center for Development Research (ZEF) - University of Bonn
email : ahmadou.dicko@ucad.edu.sn
twitter : @dickoah
github : github/dickoa
tel : +221 33 827 55 16
portable: +221 77 123 81 69
I see, generating XML menu files seems to fail. At least on my PC
Generating interface description for all modules...
GISRC=/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70
GISBASE=/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu
PATH="/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts:$PATH"
PYTHONPATH="/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python:$PYTHONPATH"
LD_LIBRARY_PATH="/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib"
LC_ALL=C python tools/build_modules_xml.py >
/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/gui/wxpython/xml/module_items.xml
Traceback (most recent call last):
File "tools/build_modules_xml.py", line 148, in <module>
sys.exit(main())
File "tools/build_modules_xml.py", line 133, in main
header(fh)
File "tools/build_modules_xml.py", line 94, in header
(vInfo['version'].split('.')[0],
KeyError: 'version'
Unfortunately these kind of errors are not reported in error.log
(TODO: should be fixed).
Will have time to check it later unfortunately. Martin
On Tue, Dec 10, 2013 at 12:17 PM, Martin Landa <landa.martin@gmail.com>wrote:
Hi,
2013/12/10 Ahmadou Dicko <dicko.ahmadou@gmail.com>:
> I used to compile it from trunk without problem in ArchLinux but since
this
> morning I have the same error message.
>
> g.version -g
> version=7.0.svn
> date=2013
> revision=58433
> build_date=2013-12-10
>
> Are there any workaround ?
I see, generating XML menu files seems to fail. At least on my PC
Generating interface description for all modules...
/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/gui/wxpython/xml/module_items.xml
Traceback (most recent call last):
File "tools/build_modules_xml.py", line 148, in <module>
sys.exit(main())
File "tools/build_modules_xml.py", line 133, in main
header(fh)
File "tools/build_modules_xml.py", line 94, in header
(vInfo['version'].split('.')[0],
KeyError: 'version'
Unfortunately these kind of errors are not reported in error.log
(TODO: should be fixed).
Will have time to check it later unfortunately. Martin
g.version -r is crashing for me, I just realized it.
Ahmadou H. DICKO
statistician economist (Ingénieur Statisticien Économiste)
PhD candidate in Climate change economics
Faculty of economics and managment - Cheikh Anta Diop University
West African Science Service Center on Climate Change and Adaptated Land Use (WASCAL)
Center for Development Research (ZEF) - University of Bonn
email : ahmadou.dicko@ucad.edu.sn
twitter : @dickoah
github : github/dickoa
tel : +221 33 827 55 16
portable: +221 77 123 81 69
On Tue, Dec 10, 2013 at 6:35 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/12/10 Anna Petrášová <kratochanna@gmail.com>:
Will have time to check it later unfortunately. Martin
g.version -r is crashing for me, I just realized it.
right, I just realized it, it's related to r58417. Quickly fixed in
r58436 (back to the native tokenize soubroutine).
I have fully reverted r58417 because with strtok, "A sequence of two
or more contiguous delimiter characters in the parsed string is
considered to be a single delimiter" (man strtok), whereas the
GRASS routine does not merge delimiters.
2013/12/12 Markus Metz <markus.metz.giswork@gmail.com>:
I have fully reverted r58417 because with strtok, "A sequence of two
or more contiguous delimiter characters in the parsed string is
considered to be a single delimiter" (man strtok), whereas the
GRASS routine does not merge delimiters.
why? It was useful, for example national DEM/DSM in Czech Republic
(sample data [1]) is provided in the format where coordinates are
separated with *two* or more spaces. In other words, with the native
tokenize function `r.in.xyz sep=space` or `r.in.xyz sep=" "`
(double-space as user could expect that it will work) fails bacouse
G_tokenize("x y", " "); returns {'x', '', 'y'} and not {'x', 'y'}.
With strtok-based tokenizing such string works perfectly.
BTW, `separator` parameter can be string with more than one character,
but native tokenize subroutine fails to tokenize such string with
multiple-character delimiter, eg. G_tokenize("firstSElast", "SE");
returns {'first', '', 'last'} and not {'first', 'last'} as someone
could expect.
On Thu, Dec 12, 2013 at 12:10 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/12/12 Markus Metz <markus.metz.giswork@gmail.com>:
I have fully reverted r58417 because with strtok, "A sequence of two
or more contiguous delimiter characters in the parsed string is
considered to be a single delimiter" (man strtok), whereas the
GRASS routine does not merge delimiters.
why? It was useful, for example national DEM/DSM in Czech Republic
(sample data [1]) is provided in the format where coordinates are
separated with *two* or more spaces. In other words, with the native
tokenize function `r.in.xyz sep=space` or `r.in.xyz sep=" "`
(double-space as user could expect that it will work) fails bacouse
G_tokenize("x y", " "); returns {'x', '', 'y'} and not {'x', 'y'}.
With strtok-based tokenizing such string works perfectly.
OTOH, v.in.ascii format=point expects the same number of tokens in each line:
1|1||name
2|2|3|other_name
must always result in 4 tokens. Here, double pipe works as expected
only if delimiters are not merged.
BTW, `separator` parameter can be string with more than one character,
but native tokenize subroutine fails to tokenize such string with
multiple-character delimiter, eg. G_tokenize("firstSElast", "SE");
returns {'first', '', 'last'} and not {'first', 'last'} as someone
could expect.
Someone else would expect that with "SE" as delimiter argument, the
delimiter can be either "S" or "E".
I would leave G_tokenize() as it is because it is used at too many
different places which expect the current behaviour.
It is not uncommon that ASCII input data need a bit of pre-processing
(tr, sed), e.g. when fields have fixed lengths. Alternatively, add an
option (to respective modules, not to G_tokenize()) to expect fixed
length fields defining the field lengths?
2013/12/12 Markus Metz <markus.metz.giswork@gmail.com>:
OTOH, v.in.ascii format=point expects the same number of tokens in each line:
1|1||name
2|2|3|other_name
must always result in 4 tokens. Here, double pipe works as expected
only if delimiters are not merged.
right, we need to have native tokenize() subroutine for such cases. It
was not good idea to replace it directly with tokenize_strtok() even
as a test. Anyway my plan was to introduce a new G_tokenize3() or
G_tokenize_strtok() based on tokenize_strtok(). I believe that such
function would make sense on several places like in `r.in.xyz`.
BTW, `separator` parameter can be string with more than one character,
but native tokenize subroutine fails to tokenize such string with
multiple-character delimiter, eg. G_tokenize("firstSElast", "SE");
returns {'first', '', 'last'} and not {'first', 'last'} as someone
could expect.
Someone else would expect that with "SE" as delimiter argument, the
delimiter can be either "S" or "E".
right, as strtok() behaves.
I would leave G_tokenize() as it is because it is used at too many
different places which expect the current behaviour.
Agreed.
It is not uncommon that ASCII input data need a bit of pre-processing
(tr, sed), e.g. when fields have fixed lengths. Alternatively, add an
right, anyway I think it's still better to handle such issues on
module level. You can hardly ask Windows user to use `tr` or `sed`.
Being user friendly is not so bad idea.
option (to respective modules, not to G_tokenize()) to expect fixed
length fields defining the field lengths?
I still think that G_tokenize_strtok() would make sense to have. Then
`r.in.xyz` or `v.in.ascii` could have special flag which could handle
input files as I described (e.g. columns separated by two spaces).
What do you think?