Re: [GRASS-dev] black: Python code formatter (eg PEP8)

[Panagiotis Mavrogiorgos]

Just few more points (not in any particular order):

- If black is used, all open pull requests, branches etc will need to be
rebased. My guess is that it will often be easier to just re-implement
instead of solving the conflicts.
- Unless black is used on releasebranches too, backporting will not be
trivial and/or automated.
- black uses 88 chars as the default line length. For legacy python this is
usually enough, but for newer code using type annotations you often want to
bump that up to 100 or even 120 chars
- black formats functions/methods with a lot of arguments in a specific way
that may not be to everyone's liking. E.g.

def foo(, , , ddd):
> pass


becomes:

def foo(
> ,
> ,
> ,
> ddd,
> ):
> pass


bumping up the line length, somewhat's mitigates this.

- black is an automated tool. Optimal results are usually achieved by
manually adjusting the code and/or writing the code in a way that is
compatible with black (i.e. black will not change it). a typical example -
and there are more - are double list comprehensions (which IMHV should
usually be avoided but that's not really relevant here). E.g:

words = [word.upper() for sentence in paragraph for word in sentence]
>

becomes:

words = [
> word.upper()
> for sentence in paragraph
> for word in sentence
> ]


Re-rewriting this as a nested loop is one less line of code, is more
readable because it doesn't change the flow of execution, is more
expendable and is obviously more familiar to those who don't know python
that well:

words = []
> for sentence in paragraph:
> for word in sentence:
> words.append(word.upper())


For the record, this particular case could be re-written using
itertools.chain

from itertools import chain


> words = [word.upper() for word in chain(*paragraph)]


- black doesn't play too well with inline comments. E.g.

a = [
> "a",
> "b",  # noqa
> "c",
> ]


will be transformed to:

a = ["a", "b", "c"]  # noqa


This means that the noqa comment will be applied to all the arguments
instead of "b" only.

- Probably not a huge issue for GRASS, but black does not preserve
indentation of comments. So E.g this will become:

# class A(object):
> # def __init__(self):
> # self.a = 1
> # self.b = 2


 will become

# class A(object):
> # def __init__(self):
> # self.a = 1
> # self.b = 2


If you want to preserve the indentation you would need to comment out using
this:

# class A(object):
> #def __init__(self):
> #self.a = 1
> #self.b = 2


all the best,
P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] instructions to update my local copy of trunk

[Panagiotis Mavrogiorgos]

>
> I'm completely lost...


Dear Vero,

As others have suggested, you pulled changes from upstream into your local
repo and you now need to push them to your personal fork (i.e. you need to
push then to origin).

git is more powerful than subversion, but this power comes with increased
complexity. You can't use git thinking it is subversion. In order to become
effective you need to understand the new concepts. Learning about them is
obviously not trivial but it is not that hard either. It just takes a
little bit of reading and some practise.

In case you are interested, I have heard good words about this tutorial:
https://learngitbranching.js.org/
Do take note that it has two sections: main and remote. The first one will
teach you about working with your local repo (rebasing etc) and the other
about working with remotes.

> It there a way (magic flag?) to avoid this out-of-sync in the first place?
> E.g., for the cronjobs I do not want to go there weekly and "git push"
> stuff around.
>
> Yes, but we need to know the contents of the cron scripts first.

all the best,
P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] black: Python code formatter (eg PEP8)

[Panagiotis Mavrogiorgos]

Hello all,

The main problem with adopting style checkers so late in a project's life
is that they usually introduce really vast changes. You practically end up
with a huge commit that touches each and every python file. Needless to say
this makes using e.g. git blame much much harder.

If you want to test it out, please try the following from a clean state:

cd lib/python

git status # make sure that no files have any changes in lib/python

black --exclude OBJ ./
> git diff --patience --minimal ./ | wc -l


That's a 75k+ line diff and that's only the "grass" library. The gui should
give something similar.

To restore the repo, just run:

git checkout ./


That being said, I do use black in practically all my new projects, usually
applying it via pre-commit , and it works great,
but I am not sure if it is truly an option for GRASS.

all the best,
P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] How to commit changes in git to a release_branch?

[Panagiotis Mavrogiorgos]

hello Markus

In git, a "remote" is a different repository that you share common history
with. It usually exists on a different server, but it can also live on your
filesystem.

In your case you pushed the commit to your origin which is
"grass-p3/master". You can check that by cd-ing into "grass-p3/master" and
running "git log releasebranch_7_4". You should see the commit there. So if
you want to push that to the main repo, you can do it either from
"grass-p3/master" or you can add the main repo as a remote to
"grass-p2/releasebranch_7_4"

all the best,
P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] github: Please squash commits before merging

[Panagiotis Mavrogiorgos]

Hello all,

I just wanted to mention that we should try to have clean history and good
commit messages. This helps really a lot when you try to understand why
something is implemented the way it is. In this spirit, I think it is a
good idea to try to squash a Pull Request's  commits before merging ,
especially if those are trivial fixes (it needs to be enabled

 though).

For example, PR18 contained 5 commits
 which were merged. The
last 4 were trivial fixes that only add noise to the history. Squashing
those would have resulted in a cleaner history and, among other things,
would have made it easier to use git bisect and git blame.

That being said, I am not arguing that the commits of each and every PR
needs to be squashed before merging. When extensive changes are being made,
it often makes sense to keep them unsquashed (e.g. to make reviewing
easier), but trivial fixes should still be squashed to the main commits.

with kind regards,
Panos

PS. BTW, when a PR only has a single commit, the "merge commit" doesn't
offer anything and it can be avoided by rebasing the feature branch. I
think it would be a good idea to try to do that too. Just to avoid any
misunderstandings, when a PR has multiple commits, the merge commit is more
or less mandatory because if you don't have it, you can't use git revert.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Benchmark the overhead of calling GRASS modules

[Panagiotis Mavrogiorgos]

hello Markus and Vaclav,

thank you for your feedback. My answer is inline.

On Wed, May 1, 2019 at 6:03 PM Markus Metz 
wrote:

> IMHO the overhead of calling GRASS modules is insignificant because it is
> in the range of milliseconds. I am much more concerned whether executing a
> GRASS module takes days or hours or minutes.
>

And the overhead is insignificant (not measurable) compared to actual
> execution time for larger datasets/regions.


I would argue that this depends on what you are doing. For a single GRASS
Session using a really big computational region the overhead is obviously
negligible; I wrote that in the initial post

too. But if you do need to massively parallelize GRASS, then the overhead
of setting up the GRASS Session and/or calling GRASS modules might be
measurable too.

Regardless, the overhead

   - can be noticeable while doing exploratory analysis
   - can be significant while **developing** GRASS (e.g. when running
   tests).

BTW, let us also keep in mind that the majority of the tests should be
using really small maps/computational regions (note: they currently don't,
but that's a different issue) which means that the impact of this overhead
should be larger

On Thu, May 2, 2019 at 4:49 AM Vaclav Petras  wrote:

> Hi Panos and Markus,
>
> I actually touched on this in my master's thesis [1, p. 54-58],
> specifically on the subprocess call overhead (i.e. not import or
> initialization overheads). I compared speed of calling subprocess in Python
> to a Python function call. The reason was that I was calling GRASS modules
> many times for small portions of my computational region, i.e. I was
> changing region always to the area/object of interest within the actual
> (user set) computational region. So, the overall process involved actually
> many subprocess calls depending on the size of data. Unfortunately, I don't
> have there a comparison of how the two cases (functions versus
> subprocesses) would look like in terms of time spend for the whole process.
>

Again I would argue that the answer depends on what you are doing.
Pansharpening a 100 pixel map, has a (comparatively) huge overhead.
Pansharpening a landast tile, not so much. Regardless of that, I think we
can all agree that directly calling a function implementing algorithm Foo
is always going to be faster than calling a script that calls the same
function. Unfortunately, and as you pointed out, perhaps most of the GRASS
functionality is only accessible from the CLI and not through an API.


> And speaking more generally, it seems to me that the functionality-CLI
> coupling issue is what might me be partially fueling Facundo's GSoC
> proposal (Python package for topology tools). There access to functionality
> does not seem direct enough to the user-programmer with overhead of
> subprocess call as well as related I/O cost, whether real or perceived,
> playing a role.
>

I can't speak about Facundo. Nevertheless, whenever I try to work with the
API, I do find it limited and it feels that it still has rough edges (e.g.
#3833  and #3845
 ). It very soon becomes clear
that in order to get work done you need to use the Command Line Interface.
As a programmer, I do find this annoying :P


> Best,
> Vaclav
>
> [1] Petras V. 2013. Building detection from aerial images in GRASS GIS
> environment. Master’s thesis. Czech Technical University in Prague.
> http://geo.fsv.cvut.cz/proj/dp/2013/vaclav-petras-dp-2013.pdf
>

Thank you for the link)

all the best,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] git merge mess on master

[Panagiotis Mavrogiorgos]

>
> On Tue, May 21, 2019 at 11:23 AM Bas Couwenberg  > wrote:
> >* On 2019-05-21 11:22, Markus Neteler wrote:
> *>* > How to revert that? Of course someone had to run into this at some
> *>* > point, so seems I "volunteered" to be the first :((
> *>>* rebase and force push.*
>
>
Vaclav Petras  > wrote:

1) There is probably a smart way to resolve it. Something along the lines
> of what Bas suggested to the situation before but you can also backup diffs
> for all you changes (if any), delete fork and delete your local clone
> and start over.


@all

Please, keep in mind that git push --force is probably the only command
that you should **never** use on main repo.

You are free to force push whatever you want on personal/private
repos/branches. Nevertheless, all commits in the shared repository should
be considered **immutable**. Please don't break this assumption. If there
is need to revert something, use git revert instead.

all the best,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] git: how to avoid bogus merge commits

[Panagiotis Mavrogiorgos]

st 22. 5. 2019 v 21:44 odesílatel Even Rouault
>  > napsal:
> >* git fetch origin  (assuming 'origin' point to OSGeo/grass)
> *>* git rebase origin/master
> *
> or possibly
> git pull --rebase


git pull --rebase can be indeed used to the same effect. You can even add

[pull]

rebase = true

to your .gitconfig.

Nevertheless, IMHV it is still a better idea to use a personal fork + Pull
Requests instead of the main repo. With this workflow, even if you do
something messy you can always sort it out without adding noise to history

I have updated the section
> Keep your local source code up to date
> https://trac.osgeo.org/grass/wiki/HowToGit#Keepyourlocalsourcecodeuptodate


The stash step was wrong. I fixed it. In order to reapply the stash you
need:

git stash apply && git stash pop

This way the stash is being popped if and only if it has been applied
cleanly. If there are conflicts you can reset the repo without losing your
stash (which you might want to apply to a different branch etc).

P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] git: how to switch between branches?

[Panagiotis Mavrogiorgos]

Hello Markus

I don't have real-world experience with this, but I am not sure if changing
branches and
distcleaning/recompiling is the most convenient workflow. I think I would
prefer to have
multiple local repositories with different branches checked out. Thankfully
git makes it
rather easy to have this.  E.g.:

1. You create two root directories. One for Python2 and one for Python3:

mkdir /home/user/git/grass-p{2,3}

2. Create a virtualenv inside grass-p2 and grass-p3. E.g.:

cd /home/user/git/grass-p2
virtualenv -p python2 venv

cd /home/user/git/grass-p2
python3 -m venv venv

3. Clone the remote GRASS repo and name the local repo `dev`. You will only
do this for `grass-p3`:

cd /home/user/git/grass-p3
git clone https://github.com/neteler/grass dev

5. For python 2 and for each release branch you will make a local git
clone. This way
   you won't be wasting disk space. Read more about this
   [here](
https://stackoverflow.com/questions/7187088/git-how-to-create-local-repo-with-symbolic-links-to-the-git-main-repo
).

cd /home/user/git/grass-p2
git clone ../grass-p3/dev dev
git clone ../grass-p3/dev r72
git clone ../grass-p3/dev r74
git clone ../grass-p3/dev r76

6. The dir structure should look like this:

$ tree grass*

grass-p2
├── dev
├── r72
├── r74
├── r76
└── venv
grass-p3
├── dev
└── venv

7. On each release clone you need to checkout the respective branch:

cd /home/user/git/grass-p2/r72 && git checkout releasebranch_7_2
cd /home/user/git/grass-p2/r74 && git checkout releasebranch_7_4
cd /home/user/git/grass-p2/r76 && git checkout releasebranch_7_6

7. Each directory is a full blown git repo. It is only by convention that
7.6 backports
   will happen in `r76` etc.  If you want to directly pull/push from/to
github from the release
   directories, you will probably need to setup remotes. Regardless,
setting up remotes
   etc should only be done once.

8. Obviously, when 7.8 gets released, two more directories will need to be
added (one
   for python2  and one for python 3).

The benefit of this approach is that at least for trivial backports, you
will not need
to recompile everything and, perhaps more importantly, you will not need to
recompile
"master" in order to test a fix in 7.2.

all the best,
Panos

PS1. There are other ways to achieve something like this, e.g.
[`--singlebranch`](https://stackoverflow.com/a/1911126/592289) but I don't
see much
benefit.

PS2. You can optionally use something like [direnv](
https://github.com/direnv/direnv) to
automatically activate the virtualenvs when you cd into the corresponding
directory.
This way there is no confusion WRT which python is active. I use this and
it works
marvellously.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn/trac -> git/github migration plan

[Panagiotis Mavrogiorgos]

On Sun, May 19, 2019 at 6:53 PM Martin Landa  wrote:

> Hi,
>
> ne 19. 5. 2019 v 17:43 odesílatel Markus Metz
> Ideally, you would set up the local repo such that you pull from upstream
> and push to your fork.
>
> This is doable with: https://stackoverflow.com/a/4523625/592289

Nevertheless, occasionally, you might want to pull from your personal fork
too. E.g. when  you want to collaborate on a feature with others. One way
to do this is to agree that the development will happen on a branch on your
own fork. It doesn't matter if you give write access to the other devs or
if they make Pull Requests to your own fork, in the end you will have to
pull those changes to your local repo. And in order to do that you will
have to again edit your remotes.

For the record, in the above example the other devs would have to add your
own personal repository as an additional remote.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn/trac -> git/github migration plan

[Panagiotis Mavrogiorgos]

On Sat, 18 May 2019, 19:11 Markus Neteler,  wrote:.

>
> For fetching the updates, is this enough:
>
> git pull --all
> ?
>

Μmm... sometimes yes, but I wouldn't suggest it.

Git pull is essentially 2 operations in one. It is a git fetch, followed by
a git merge.

The potential problem is with the merge step.

When you have no local changes, git pull works just fine. When you have
local changes though, there might be a conflict with the remote ones. And
if there is a conflict, you need to resolve it.

Resolving the conflicts is not something you can avoid; you will eventually
have to do it, but you should probably not try to do it before you have
reviewed the (remote) changes you just fetched.

This is why I almost always do this in 3 steps:

1. git fetch --all
2. Review the fetched changes. It's often convenient to use a git client
here. gitg, qgit and tig are easy to use and lightweight options.
3. git merge

By injecting step 2 you can both check if there are any conflicts and think
what's the best way to resolve them. Moreover, if there are conflicts, you
can choose to postpone resolving them (resolving conflicts takes time). If
you do git pull you will have to resolve them straight away.

P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn/trac -> git/github migration plan

[Panagiotis Mavrogiorgos]

hello Markus,

I would suggest that:

- even core devs fork the main repo
- "origin" is the personal remote GRASS repository (e.g. in my case
https://github.com/pmav99/grass)
- everyone adds the main GRASS repository as a secondary remote (e.g.
"upstream")

This way:

1. You always push to "origin" and you create a Pull Request from the
Github UI
2. To get updates you always pull from "upstream"
3. You always rebase your code to "upstream/master".
4. You don't need separate instructions for non core-devs.

Just my 2 cents.

P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn/trac -> git/github migration plan

[Panagiotis Mavrogiorgos]

Dear all,

I would argue that even core developers should not be using the main repo
as their
personal one and that, at least most of the time, they should instead be
using the same
procedure as every other contributor.

Branches in git branches are really "cheap" (especially compared to e.g.
SVN).  They do
make it very easy to experiment and the more proficient you become with git
you do tend
to use them more and more.  If every core dev starts pushing their personal
branches on
the main repo, very soon  there will be noise that can effectively become
too much for
UIs to properly display. For example, please visit
[QGIS](https://github.com/qgis/QGIS) and click on the branch selector.
They only have
release branches (like GRASS) and the UI is already at its limit. Imagine
having e.g.
100+ more branches there...

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] pygrass.gis.region.Region + depths property

[Panagiotis Mavrogiorgos]

On Thu, May 9, 2019 at 4:20 PM Panagiotis Mavrogiorgos 
wrote:

> Hello all,
>
> The Region class defines a ["depths" property](
> https://github.com/GRASS-GIS/grass-ci/blob/6451c5aa008d59506f7fb8ce54e0b72eb2188ad2/lib/python/pygrass/gis/region.py#L210-L219)
> which is not being used in e.g. .keys(), __repr__(), __eq__() etc.
> Shouldn't it be added there too?
>
> with kind regards
> Panos
>

In the same topic, shouldn't the property setter (i.e. _set_depths) call
adjust()? In which case, shouldn't adjust() call G_adjust_Cell_head3()
instead of G_adjust_Cell_head()?

Should I open an issue?

P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] pygrass.gis.region.Region + depths property

[Panagiotis Mavrogiorgos]

Hello all,

The Region class defines a ["depths" property](
https://github.com/GRASS-GIS/grass-ci/blob/6451c5aa008d59506f7fb8ce54e0b72eb2188ad2/lib/python/pygrass/gis/region.py#L210-L219)
which is not being used in e.g. .keys(), __repr__(), __eq__() etc.
Shouldn't it be added there too?

with kind regards
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] FYI: Season of the Docs

[Panagiotis Mavrogiorgos]

Hello all,

This year google launched a new project similar to Summer of Code whose
scope is improving documentation. The deadline has passed but it might make
sense to keep it in mind for next year:

https://developers.google.com/season-of-docs/

There is an announcement mailing list, so it might be a good idea for some
core member to subscribe:
https://groups.google.com/forum/#!forum/season-of-docs-announce

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Which is the correct WIND convention for creating a new mapset?

[Panagiotis Mavrogiorgos]

Thank you markus

On Wed, May 8, 2019 at 10:54 PM Markus Metz 
wrote:

> It depends. g.mapset changes the current mapset (and location and
> database). It might also create a new mapset in an existing location, but
> it always switches. If that switch is not desired, GISRC must be adjusted
> to the original GRASS session. G_make_mapset() is a C function and should
> be used by C modules. Of course you could use it with pygrass, but pygrass
> initializes the GRASS C libraries, and you need to take care that
> initializations are properly updated when changing mapsets (and locations).
> Creating a new mapset in an existing location is not difficult: create the
> folder and copy DEFAULT_WIND from PERMANENT to WIND in the new mapset.
> Maybe create a new function create_mapset() in lib/python/script/utils.py?
>

Generally speaking, I think it is important that the API comes first. Once
some functionality has been implemented in a library it can then be exposed
to the end users in multiple ways (e.g. CLI, REST, whatever). Among other
things, by implementing the API first, it is much easier to test the code +
you follow DRY.

This is why I mentioned "G_make_mapset()" which seems to already be
implementing this functionality and which, as you mentioned, is exposed to
Python via pygrass. The idea is that if in the future the process of
creating a mapset becomes more complicated, then we would only have to
update "G_make_mapset()". That being said I am not familiar enough with the
initialization process so I can't really argue if a pure python
implementation is needed or not.

Now to become more specific, as an API user, I think would find it strange
that calling the "create_mapset()" function also changes the current
mapset. I like it when things are explicit + it makes it easier to document
and test. As far as implementing "create_mapset()" in
lib/python/script/utils.py, why not move the relevant functions from
"gui/wxpython/startup/utils.py" and have the GUI code import them from the
"grass" lib?

BTW, those functions do need a few improvements; e.g. rename_mapset()
should fail to rename PERMANENT etc, but let's move them first and we can
do that later.


> >>> I adjusted the wxGUI startup wizard and the tests in trunk r74472,3
> (the tests should use g.mapset -c, not yet implemented)
> >
> >
> > I think that in the nc_spm_full_v2alpha dataset WIND and DEFAULT_WIND
> differ, so 74473 might break any tests that don't explicitly set the region
> themselves (which of course they should). We will see.
>
> IMHO, tests need to set the region themselves, just as users. The current
> region is such a fundamental concept of GRASS (raster processing) that I
> regard it as a mistake if the current region is not explicitly set to
> actual demands.
>

I completely agree that tests that don't set the region themselves should
be fixed.

all the best,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Which is the correct WIND convention for creating a new mapset?

[Panagiotis Mavrogiorgos]

On Tue, May 7, 2019 at 11:03 PM Markus Metz 
wrote:

>
>
> On Tue, May 7, 2019 at 10:20 AM Panagiotis Mavrogiorgos 
> wrote:
> >
> >
> >
> > On Mon, May 6, 2019 at 9:38 PM Markus Metz <
> markus.metz.gisw...@gmail.com> wrote:
> >>
> >>
> >>
> >> On Mon, May 6, 2019 at 6:21 PM Panagiotis Mavrogiorgos <
> pma...@gmail.com> wrote:
> >> >
> >> > Hello all,
> >> >
> >> > I am a bit confused WRT what the expected WIND should be when you
> create a new mapset.
> >>
> >> > [...]
> >>
> >> > Is there an established convention?
> >>
> >> IMHO, new mapsets should use DEFAULT_WIND from PERMANENT.
> >
> >
> > Thank you Markus, that's what I expected, too.
> >
> >>
> >> But the current region of a new mapset is often adjusted, therefore it
> does not really matter if DEFAULT_WIND or WIND is used.
> >
> >
> > I don't disagree, but still, I don't see what's the benefit of not using
> the same convention everywhere. Furthermore, I truly don't understand why 4
> different implementations are needed.
>
> True, g.mapset -c should be used whenever possible.
>

I would argue that it is G_make_mapset() that should be used whenever
possible :)
(which of course, is being used by g.mapset -c, too)

I adjusted the wxGUI startup wizard and the tests in trunk r74472,3 (the
> tests should use g.mapset -c, not yet implemented)
>

I think that in the nc_spm_full_v2alpha dataset WIND and DEFAULT_WIND
differ, so 74473 might break any tests that don't explicitly set the region
themselves (which of course they should). We will see.

P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] fatra reports have not been updated since 2019-03-26

[Panagiotis Mavrogiorgos]

The testsuite reports has not been updated for quite some time now. Can
someone please have a look?

http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Which is the correct WIND convention for creating a new mapset?

[Panagiotis Mavrogiorgos]

On Mon, May 6, 2019 at 9:38 PM Markus Metz 
wrote:

>
>
> On Mon, May 6, 2019 at 6:21 PM Panagiotis Mavrogiorgos 
> wrote:
> >
> > Hello all,
> >
> > I am a bit confused WRT what the expected WIND should be when you create
> a new mapset.
>
> [...]
>
> Is there an established convention?
>
> IMHO, new mapsets should use DEFAULT_WIND from PERMANENT.
>

Thank you Markus, that's what I expected, too.


> But the current region of a new mapset is often adjusted, therefore it
> does not really matter if DEFAULT_WIND or WIND is used.
>

I don't disagree, but still, I don't see what's the benefit of not using
the same convention everywhere. Furthermore, I truly don't understand why 4
different implementations are needed.

with kind regards,
P.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Which is the correct WIND convention for creating a new mapset?

[Panagiotis Mavrogiorgos]

Hello all,

I am a bit confused WRT what the expected WIND should be when you create a
new mapset.

Some functions copy DEFAULT_WIND from PERMANENT. E.g.:

   - lib/gis/make_mapset.c
   


   - pygrass.gis.make_mapset()
   

   - the grass executable
   


While others copy WIND from PERMANENT. E.g.

   - the tests
   

   - gui.wxpython.startup.create_mapset()
   


Is there an established convention?

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Benchmark the overhead of calling GRASS modules

[Panagiotis Mavrogiorgos]

Hello all

You might find it easier to read the following text i
n a gist


## Introduction

I was trying to write a decorator/contextmanager that would temporary
change the
computational region, but while using it I noticed that there was some
overhead the root
of which seemed to be the usage of the GRASS modules. So in order to
quantify this
I wrote a small benchmark that tries to measure the overhead of calling a
GRASS Module.
This is what I found.

## tl;dr

Calling a GRASS module incurs a constant but measurable overhead which, in
certain
cases, e.g. when writing a module that uses a lot of the other modules, can
quickly
add up to a significant quantity.

## Disclaimer

If you try to run the benchmark on your own PC, the actual timings you will
get will
probably be different. The differences might be caused by having:

- a stronger/weaker CPU
- faster/slower hard disk.
- using different Python version
- using different compilation flags

Still, I think that some of the findings are reproducible.

For reference, I used:

- OS: Linux 5.0.9
- CPU: Intel i7 6700HQ
- Disk type: SSD
- Python: 3.7
- `CFLAGS='-O2 -fPIC -march=native -std=gnu99'`

## Demonstration

The easiest way to demonstrate the performance difference between using a
GRASS module
vs using the GRASS API is to run the following snippets.

Both of them do exactly the same thing, i.e. retrieve the current region
settings 10
times in a row.  The performance difference is huge though. On my laptop,
the first one
needs 0.36 seconds while the second one needs just 0.00038 seconds. That's
almost
a 1000x difference...

``` python
import time
import grass.script as gscript

start = time.time()
for i in range(10):
region = gscript.parse_command("g.region", flags="g")
end = time.time()
total = end - start

print("Total time: %s" % total)
```

vs

``` python
import time
from grass.pygrass.gis.region import Region

start = time.time()
for i in range(10):
region = Region()
end = time.time()
total = end - start

print("Total time: %s" % total)
```

## How much is the overhead exactly?

In order to measure the actual overhead of calling a GRASS module, I
created two new
GRASS modules that all they do is parse the command line arguments and
measured how much
time is needed for their execution. The first module is [`r.simple`]() and
is
implemented in Python while the other one is [`r.simple.c`]() and is
implemented in C.
The timings are in msec and the benchmark was executed using Python 3.7

| call method| r.simple | r.simple.c |
||::|:--:|
| pygrass.module.Module  |   85.9   |66.5|
| pygrass.module.Module.shortcut |   85.5   |66.9|
| grass.script.run_command   |   41.3   |30.5|
| subprocess.check_call  |   41.8   |30.3|

As we can see, `gsrcipt.run_command` and `subprocess` give more or less a
identical
results, which is to be expected since `run_command` + friends are just a
thin wrapper
around `subprocess`.  Similarly `shortcuts` has the same overhead as
"vanila"
`pygrass.Module`.  Nevertheless, it is obvious that `pygrass` is roughly 2x
times slower
than `grass.script` (but more about that later).

As far as C vs Python goes, on my computer modules implemented in C seem to
be 25% faster than their
Python counterparts.  Nevertheless, a 40 msec startup time doesn't seem
extraordinary
for a Python script, while 30 msec feels rather large for a CLI application
implemented
in C.

## Where is all that time being spent?

### C Modules

Unfortunately, I am not familiar enough with the GRASS internals to easily
check what is
going on and I didn't have the time to try to profile the code. I suspect
that
`G_gisinit` or something similar is causing the overhead, but someone more
familiar with
the C API should be able to enlighten us.

### Python Modules

In order to gain a better understanding of the overhead we have when
calling python
modules, we also need to measure the following quantities:

1. The time that python needs to spawn a new process
2. The startup time for the python interpreter
3. The time that python needs to `import grass`

These are the results:

| | msec |
|-|::|
| subprocess spawn|  1.2 |
| python 2 startup|  9.0 |
| python 2 + import grass | 24.5 |
| python 3 startup| 18.2 |
| python 3 + import grass | 39.3 |

As we can see:

- the overhead of spawning a new process from within python is more or less
negligible
  (at least compared to the other quantities).
- The overhead of spawning a python 3 interpreter is 2x bigger than Python
2; i.e.  the
  transition to Python 3 will have some performance impact, no matter what.
- The overhead of spawning a python 3 interpreter accounts for roughly 50%
of the total
  overhead 

Re: [GRASS-dev] pygrass.gis.Region API explanations

[Panagiotis Mavrogiorgos]

On Sat, Apr 27, 2019 at 7:13 PM Markus Neteler  wrote:

> Here is some sample code:
>
> https://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library#Using_temporary_region_for_computations
>
> which makes use of script.core.use_temp_region()
>
> https://grass.osgeo.org/grass77/manuals/libpython/script.html#script.core.use_temp_region
>
>
Thank you Markus,

The "problem" is that "use_temp_region()" is calling "g.region" and I would
like to avoid that if possible, since it entails some overhead vs using the
API.

> The following methods seem to be relevant:
>
> Region.set_current()
> Region.set_raster_region()
> Region.write()

As far as I can understand this, the only method that will actually change
the computational region is "write()" am I correct?

Could also someone clarify what is the difference between "working region"
mentioned in "set_current()" and the computational region?

all the best,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] pygrass.gis.Region API explanations

[Panagiotis Mavrogiorgos]

Hello all,

I am trying to use the pygrass API to create a contextmanager that set's a
temporary Region, but I am not sure which method I should be using. The
following methods seem to be relevant:

Region.set_current()
Region.set_raster_region()
Region.write()


Could someone further clarify when each one should be used?

all the best,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] Motion: Migrate SVN and trac tickets to github under OSGeo organization

[Panagiotis Mavrogiorgos]

>
> in case you're not aware of it, it turns out that a number of continuous
> integration services, like Travis-CI or AppVeyor, have concurrency limits
> for
> the jobs at the GitHub organization level (ie if using OSGeo/, for all
> repositories under OSGeo/ ). For Travis-CI, OSGeo pays Travis-CI for ~ 11
> concurrent jobs. Primary users are currently GDAL and proj.4. For
> AppVeyor, we
> use the free plan, which is limited to 1 concurrent job, and is sometimes
> the
> reason for pull requests to take a significant time to be completed.


For the record, azure pipelines offers 10 concurrent jobs for Open Source
projects + support for multiple operating systems.
https://azure.microsoft.com/en-us/services/devops/pipelines/

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Update online addons manuals

[Panagiotis Mavrogiorgos]

Hi all,

The urls for the addons manuals indicate that they have not been updated
since 7.4. If possible and if there have been doc updates, it would be nice
if the newer versions were uploaded too.

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Shell scripts for tests

[Panagiotis Mavrogiorgos]

Hello all,

The GRASS testsuite contains several tests that have been written as shell
scripts. If I am not mistaken, those can be identified by the "unknown"
percentages in the testreport (example

).

IMHV this practise is causing several issues:

1. The testrunner seems to be skipping/omitting the majority of the
available tests. More specifically, the testrunner currently runs 27 shell
scripts, while it seems that there are 95+ tests
 written
as shell scripts. I suspect that the testrunner is only matching
"testsuite" directories while skipping directories named "tests",
"test_suite" etc.

1a. There should be uniformity in the naming conventions of test
directories and test files.
1b. Needless to say, we need to make sure that the testrunner runs all the
available tests. I guess that if 1a is taken care off then 1b will have
been resolved too.

2. I only checked a bunch of the shell scripts but I am under the
impression that majority of them (if not all!) are not real tests but just
shell scripts that prove that the code runs while not really asserting that
the code is actually correct. Of course, this is better than nothing, but
it is not good enough.

2a. Ideally and as a mid-term goal these tests should be converted to
proper python tests
2b. In the meantime, and if it is not already being used, we should try to
make sure that the shells scripts are using "strict mode" so that errors do
propagate:
http://redsymbol.net/articles/unofficial-bash-strict-mode/
https://disconnected.systems/blog/another-bash-strict-mode/
2c. Also in the meantime, and in order to make testreports more useful, we
could also add a single python test file next to each shell script which
will contain something similar to this:

subprocess.check_out(shlex.split("bash test_foo.sh"))

This way, we would have reports with proper count of testsuites, failures
etc.

3. Finally, IMHV there should also be an official policy/requirement, that
new code/modules cannot be accepted unless they have proper and
comprehensive tests written in python.

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Translations and command description/options

[Panagiotis Mavrogiorgos]

On Tue, Mar 12, 2019 at 11:51 AM Nikos Alexandris 
wrote:

> * Panagiotis Mavrogiorgos  [2019-03-12 02:39:01 +0200]:
>
> ..
>
> >I don't have GRASS installed. I always run it from bin.x86_64-pc-linux-gnu
> >too.
>
> Pano,
>
> I know you do, but just to verify again:
> you do `make distclean` before each fresh compilation, right?
>

I occasionally do, but not before each compilation. But you were right.
This fixed this. I expected that changes in "./configure" would somehow
propagate, but I was obviously wrong.
Thank you
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Translations and command description/options

[Panagiotis Mavrogiorgos]

On Mon, Mar 11, 2019 at 10:05 PM Markus Neteler  wrote:

> Hi,
>
> On Mon, Mar 11, 2019 at 6:49 PM Panagiotis Mavrogiorgos
>  wrote:
> >
> > Not sure if there is any relation but just in case it proves useful:
> >
> > I configure grass with:
> >
> > ./configure \
> > --with-nls \
> > ...
> >
> >
> > At the end of the configuration step I get the following output:
> >
> >   NetCDF support: no
> >   NLS support:yes
> >   ODBC support:   no
>
> Can you please double check what's in config.log related to NLS?
>

Thank you Markus,

There is only a single line mentioning NLS:

*configure:12419: checking whether to use NLS*


I also attach the log file, in case it helps in debugging this.


> Funny idea:
>   which grass77
>
> Please check for conflicting installations, or files not belonging to
> the user used to compile GRASS GIS (anecdote: in the past I got
> trapped because I commonly do not run "make install" but run it from
> bin.x86_64-pc-linux-gnu/grass77 and then I one day used "make install"
> and immediately forgot the day after that it was executed from
> /usr/local/...).
>
>
I don't have GRASS installed. I always run it from bin.x86_64-pc-linux-gnu
too.

What I do find most frustrating is that translations do work for the
"text-based splash screen" (which is printed by `lib/init/grass.py`) and
the GUI but not for the scripts directory:
https://asciinema.org/a/233110

with kind regards,
Panos


config.log
Description: Binary data


config.status.x86_64-pc-linux-gnu
Description: Binary data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Translations and command description/options

[Panagiotis Mavrogiorgos]

Not sure if there is any relation but just in case it proves useful:

I configure grass with:

./configure \
--with-nls \
...


At the end of the configuration step I get the following output:

  NetCDF support: no
  NLS support:yes
  ODBC support:   no


Nevertheless, g.version -b seems to think otherwise:

g.version -b
GRASS 7.7.svn (2019)


 ./configure  --host=x86_64-linux-gnu --build=x86_64-linux-gnu
--target=x86_64-linux-gnu --prefix=/usr/lib --sysconfdir=/etc
--sharedstatedir=/var --enable-shared --enable-largefile=yes --with-x
--with-wxwidgets=/usr/bin/wx-config --without-blas --without-bzlib
--with-cxx --with-cairo --with-fftw --with-gdal --without-lapack
--without-liblas --without-mysql --without-netcdf *--without-nls*
--without-odbc
--with-opengl --without-openmp --with-png --without-pthread
--without-readline --with-regex --with-sqlite --with-tiff --disable-w11
--without-zstd --with-freetype
--with-freetype-includes=/usr/include/freetype2/ --without-geos ' '
--without-opencl --without-postgres --without-pdal
--with-proj-share=/usr/share/proj
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Translations and command description/options

[Panagiotis Mavrogiorgos]

On Sat, Mar 9, 2019 at 4:53 PM Markus Neteler  wrote:

> Did you try to set this within the GRASS session?
>
> export LANG=fr_FR.UTF-8
> export LANGUAGE=fr_FR.UTF-8
> export LC_MESSAGES=fr_FR.UTF-8
>

Thank you Markus,

Yes I did try that and it doesn't help.

Maybe zshell still needs some extras in grass py?
>

zsh is certainly not well supported by GRASS (e.g. #3740
). The lack of support is
probably due to using "default_startup()" in "lib/init/grass.py"


2235if sh in ['csh', 'tcsh']:
2236shell_process = csh_startup(mapset_settings.full_mapset,
2237mapset_settings.location,
2238mapset_settings.mapset,
2239grass_env_file)
2240elif sh in ['bash', 'msh', 'cygwin']:
2241shell_process = bash_startup(mapset_settings.full_mapset,
2242 mapset_settings.location,
2243 grass_env_file)
2244else:
2245shell_process = default_startup(mapset_settings.full_mapset,
2246mapset_settings.location)


Nevertheless, the issue we are discussing here is not related to zsh. Even
with bash, the translations do not work

https://asciinema.org/a/232727
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Translations and command description/options

[Panagiotis Mavrogiorgos]

If anyone has any other ideas, I would be happy to hear them out. here
 is
what has been tried so far.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Compilation/Distribution of *.pyc files

[Panagiotis Mavrogiorgos]

In continuation of the previous message.

If the compilation of *.py files is indeed important, then copying the *.py
files into dist and issuing

python -m compileall ./dist.x86_64-pc-linux-gnu
>

is going to be orders of magnitudes faster (a single process that compiles
all the files vs creating a new process per *.py file). This is going to be
even faster if only a bunch of *.py files need to be compiled.

Just for comparison on my laptop (using Python 3):

- I need ~5 secs to run make on lib/python
- I need ~8 secs to run make on gui/wxpython
- while I only need ~1 sec to compile all the *.py files using compileall:

$ find ./dist.x86_64-pc-linux-gnu -name '*.pyc' -delete
> $ python -m compileall ./dist.x86_64-pc-linux-gnu
> [...]
>
python -m compileall ./dist.x86_64-pc-linux-gnu  1.10s user 0.11s system
> 99% cpu 1.214 total
>

Re-running compileall is nearly instantaneous:

python -mcompileall ./  0.07s user 0.03s system 99% cpu 0.101 total
>

So, unless someone can clarify why the compilation step is necessary, I
would suggest removing it.
If it is indeed needed, then I would suggest modifying the Makefile rules
to use compileall instead of plain compile

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Translations and command description/options

[Panagiotis Mavrogiorgos]

On Wed, Mar 6, 2019 at 10:53 PM Markus Neteler  wrote:

> On Wed, Mar 6, 2019 at 9:48 PM Panagiotis Mavrogiorgos 
> wrote:
> > On Wed, Mar 6, 2019 at 10:26 PM Markus Neteler 
> wrote:
> >>
> >> On Wed, Mar 6, 2019 at 8:20 PM Panagiotis Mavrogiorgos <
> pma...@gmail.com> wrote:
> >> >
> >> > hello everyone
> >> >
> >> > After activating the french locale and running GRASS GIS with
> >> >
> >> >> LANG=fr_FR.UTF-8 LANGUAGE=fr_FR.UTF-8 LC_MESSAGES=fr_FR.UTF-8
> bin.x86_64-pc-linux-gnu/grass77
> >>
> >> AFAIK you need to export the variables:
> >>
> >> # the content of my helper script:
> >> [mneteler@oboe ~ ]$ cat ~/bin/fr.sh
> >>  export LANG=fr_FR.UTF-8
> >>  export LANGUAGE=fr_FR.UTF-8
> >>  export LC_MESSAGES=fr_FR.UTF-8
> >>
> >> # sourcing it into the current terminal session
> >> [mneteler@oboe ~ ]$ . ~/bin/fr.sh
> >>
> >> [mneteler@oboe ~ ]$ grass77 ~/grassdata/nc_spm_08_grass7/user1
> >>   __  ___   _____
> >>  / / __ \/   | / ___/ ___/   / /  _/ ___/
> >> / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
> >>/ /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
> >>\/_/ |_/_/  |_///   \/___///
> >>
> >> Bienvenue dans le SIG GRASS 7.7.svn (r74163)
> >> Page d'accueil du SIG GRASS :https://grass.osgeo.org
> >> Cette version fonctionne avec :  Bash Shell (/bin/bash)
> >> L'aide est disponible par la commande :  g.manual -i
> >> Voir les termes de la licence avec : g.version -c
> >> Voir les termes de la licence avec : g.version -x
> >> Démarrer l'interface graphique avec :   g.gui wxpython
> >> Lors prêt pour la fermeture entrer :exit
> >>
> >> GRASS 7.7.svn (nc_spm_08_grass7):~ > r3.cross.rast --help
> >> Créer une section de coupe 2D depuis une carte raster 3D et une carte
> d'altitude 2D
> >>
> >> Utilisation :
> >>  r3.cross.rast [-m] input=string elevation=string output=string
> >>[--overwrite] [--help] [--verbose] [--quiet] [--ui]
> >>
> >> Options :
> >>   -m   Utiliser le masque raster 3D (s'il existe) surnla carte en entrée
>
>
> --> what is your shell?
>
>
I use zsh. I just tried this with bash but I still don't get the
translations, so we can probably rule this out.


> GRASS 7.7.svn (nc_spm_08_grass7):~ > set | grep fr
> LANG=fr_FR
> LANGUAGE=fr_FR
> LC_ADDRESS=fr_FR.UTF-8
> LC_COLLATE=fr_FR.UTF-8
> LC_CTYPE=fr_FR.UTF-8
> LC_IDENTIFICATION=fr_FR.UTF-8
> LC_MEASUREMENT=fr_FR.UTF-8
> LC_MESSAGES=fr_FR.UTF-8
> LC_MONETARY=fr_FR.UTF-8
> LC_NAME=fr_FR.UTF-8
> LC_PAPER=fr_FR.UTF-8
> LC_TELEPHONE=fr_FR.UTF-8
> LC_TIME=fr_FR.UTF-8
>
> .. do you have the same?
>
>
Yes I believe so. Here is mine:

$ set | grep fr

LANG=fr_FR
> LANGUAGE=fr_FR
> LC_ADDRESS=fr_FR.UTF-8
> LC_COLLATE=fr_FR.UTF-8
> LC_CTYPE=fr_FR.UTF-8
> LC_IDENTIFICATION=fr_FR.UTF-8
> LC_MEASUREMENT=fr_FR.UTF-8
> LC_MESSAGES=fr_FR.UTF-8
> LC_MONETARY=fr_FR.UTF-8
> LC_NAME=fr_FR.UTF-8
> LC_PAPER=fr_FR.UTF-8
> LC_TELEPHONE=fr_FR.UTF-8
> LC_TIME=fr_FR.UTF-8
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Translations and command description/options

[Panagiotis Mavrogiorgos]

On Wed, Mar 6, 2019 at 10:26 PM Markus Neteler  wrote:

> On Wed, Mar 6, 2019 at 8:20 PM Panagiotis Mavrogiorgos 
> wrote:
> >
> > hello everyone
> >
> > After activating the french locale and running GRASS GIS with
> >
> >> LANG=fr_FR.UTF-8 LANGUAGE=fr_FR.UTF-8 LC_MESSAGES=fr_FR.UTF-8
> bin.x86_64-pc-linux-gnu/grass77
>
> AFAIK you need to export the variables:
>
> # the content of my helper script:
> [mneteler@oboe ~ ]$ cat ~/bin/fr.sh
>  export LANG=fr_FR.UTF-8
>  export LANGUAGE=fr_FR.UTF-8
>  export LC_MESSAGES=fr_FR.UTF-8
>
> # sourcing it into the current terminal session
> [mneteler@oboe ~ ]$ . ~/bin/fr.sh
>
> [mneteler@oboe ~ ]$ grass77 ~/grassdata/nc_spm_08_grass7/user1
>   __  ___   _____
>  / / __ \/   | / ___/ ___/   / /  _/ ___/
> / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
>/ /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
>\/_/ |_/_/  |_///   \/___///
>
> Bienvenue dans le SIG GRASS 7.7.svn (r74163)
> Page d'accueil du SIG GRASS :https://grass.osgeo.org
> Cette version fonctionne avec :  Bash Shell (/bin/bash)
> L'aide est disponible par la commande :  g.manual -i
> Voir les termes de la licence avec : g.version -c
> Voir les termes de la licence avec : g.version -x
> Démarrer l'interface graphique avec :   g.gui wxpython
> Lors prêt pour la fermeture entrer :exit
>
> GRASS 7.7.svn (nc_spm_08_grass7):~ > r3.cross.rast --help
> Créer une section de coupe 2D depuis une carte raster 3D et une carte
> d'altitude 2D
>
> Utilisation :
>  r3.cross.rast [-m] input=string elevation=string output=string
>[--overwrite] [--help] [--verbose] [--quiet] [--ui]
>
> Options :
>   -m   Utiliser le masque raster 3D (s'il existe) surnla carte en entrée
>
> Paramètres :
>   input   Carte raste 3D d'entrée pour la section de coupe
>   elevation   Carte 2D d'altitudes pour créer la carte de section de coupe
>  output   Carte raster 2D en sortie de la section de coupe
>
> Looks ok to me...
>
> Markus
>

Thank you Markus

That's also what I was expecting to see, because the strings are wrapped
with _() and they should be translated, but that's not what I observe...
Here is what happens on my PC:
https://asciinema.org/a/MWCHVRe70tpYJpFVYTMccNKdo
At 0.11 you can clearly see that command description is not translated.

So does anyone has any ideas?

Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Test coverage

[Panagiotis Mavrogiorgos]

On Wed, Mar 6, 2019 at 10:28 PM Markus Neteler  wrote:

> On Wed, Mar 6, 2019 at 2:34 AM Panagiotis Mavrogiorgos 
> wrote:
> >
> > Q: Is it possible to run coverage with the GRASS testsuite?
>
> Do you mean something like this?
>
> http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html
>
> If not, your question isn't yet clear (to me).
>
> Best
> Markus
>

No, I mean using e.g. this tool <https://coverage.readthedocs.io/en/v4.5.x/>
to get a report like this
<https://nedbatchelder.com/files/sample_coverage_html/index.html>. I.e. a
report of which lines of code are actually covered by tests and which are
not.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Translations and command description/options

[Panagiotis Mavrogiorgos]

hello everyone

After activating the french locale and running GRASS GIS with

LANG=fr_FR.UTF-8 LANGUAGE=fr_FR.UTF-8 LC_MESSAGES=fr_FR.UTF-8
> bin.x86_64-pc-linux-gnu/grass77


both the GUI and the TUI are translated. E.g.

  __  ___   _____
>  / / __ \/   | / ___/ ___/   / /  _/ ___/
> / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
>/ /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
>\/_/ |_/_/  |_///   \/___///
> Bienvenue dans le SIG GRASS 7.7.svn (exported)
> Page d'accueil du SIG GRASS :https://grass.osgeo.org
> Cette version fonctionne avec :  Z Shell (/usr/bin/zsh)
> L'aide est disponible par la commande :  g.manual -i
> Voir les termes de la licence avec : g.version -c
> Voir les termes de la licence avec : g.version -x
> Si requis, redémarrer l'interface graphique avec :g.gui wxpython
> Lors prêt pour la fermeture entrer : exit




Nevertheless, the command descriptions and options are not. E.g.:

r3.cross.rast --help
> Creates cross section 2D raster map from 3D raster map based on 2D
> elevation map
> Usage:
>  r3.cross.rast [-m] input=string elevation=string output=string
>[--overwrite] [--help] [--verbose] [--quiet] [--ui]
> Flags:
>   -m   Use 3D raster mask (if exists) with input map
> Parameters:
>   input   Input 3D raster map for cross section
>   elevation   2D elevation map used to create the cross section map
>  output   Resulting cross section 2D raster map




The question is: Are command description supposed to be translated too or
not? I mean, is everything working as expected or is there something wrong
in my setup?

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Test coverage

[Panagiotis Mavrogiorgos]

Q: Is it possible to run coverage with the GRASS testsuite?

with kind regards
Panagiotis
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Compilation/Distribution of *.pyc files

[Panagiotis Mavrogiorgos]

>
> $ cat include/Make/Python.make


> PY_SOURCES := $(wildcard *.py)
> %.pyc: %.py
> $(PYTHON) -t -m py_compile $<


The make command explicitly compiles the *.py files to *.pyc and copies
them to the dist directory. I haven't tested the packaging code but I guess
that they might get included in the packages too.

Just for the record, on linux x64 + Python 3:

du -ch ./dist.x86_64-pc-linux-gnu | tail -n1

93M ./


$ find ./dist.x86_64-pc-linux-gnu -name *.pyc -exec du -ch {} + | tail -n1

6.6M total



$ find ./dist.x86_64-pc-linux-gnu -name *.py -exec du -ch {} + | tail -n1

9.7M total


Is there a reason why this is happening? AFAIK distributing just the *.py
files is usually enough since *.pyc files get created on first import (if
the user has write permissions; for more info here
)

The other downside, and the real reason I looked into this, is that on my
laptop I need ~5 secs to run make on lib/python (on Python 3; Python 2 is
faster). Not too big, but big enough for an interpreted language like
Python. And smaller compilation times help you get into and stay in the flow

 :P

PS. Not a real biggie, but I am just curious.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Editing issue descriptions

[Panagiotis Mavrogiorgos]

On Wed, Mar 6, 2019 at 12:17 AM Markus Neteler  wrote:

> > Google suggests that TICKET_EDIT_DESCRIPTION needs to be granted in
> order to be have the permission to edit.
>
> I see
>
> --> pmav99 has been granted the permission TICKET_EDIT_DESCRIPTION.
>
> Please try again. Probably you need to logout/login for that.
>

Yes, I can edit now.
Thank you

Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Editing issue descriptions

[Panagiotis Mavrogiorgos]

>
> On the right side of each comment I see an "edit" button (you need to
> have used "login").
> Do you see that?
>

I am afraid that I don't see it:
https://screenshots.firefox.com/A73gnNzs8SKEKeKE/trac.osgeo.org

Google suggests  that TICKET_EDIT_DESCRIPTION
needs to be granted in order to be have the permission to edit.


>
> If not I can edit for you.
>
> No need for that, I just wanted to edit a couple of typos.
But I think it would be useful if this was fixed for everyone.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Editing issue descriptions

[Panagiotis Mavrogiorgos]

On Tue, Mar 5, 2019 at 9:26 PM Martin Landa  wrote:

> Hi,
>
> út 5. 3. 2019 v 18:30 odesílatel Panagiotis Mavrogiorgos
>  napsal:
> > Does trac allow editing the description of an issue?
>
> yes, go to 'Modify ticket'. Ma
>
> Thank you Martin,

I am afraid I don't really see how I can change the text though
https://screenshots.firefox.com/HdwZ50o0QKbDCKpC/trac.osgeo.org

Do you perhaps have an admin account? it might be a permissions issue.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Editing issue descriptions

[Panagiotis Mavrogiorgos]

Does trac allow editing the description of an issue?

with kind regards
Panagiotis
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [Anouncement] Ansible role for installing GRASS GIS with Python 2/3

[Panagiotis Mavrogiorgos]

# Anouncement

Hello everyone,

I am happy to announce the creation of an "Ansible role" that can be used to
compile GRASS GIS on Ubuntu 18.04, using either of Python 2 or Python 3.

## Concerns of getting started

IMHV, one of the factors that prevent people from getting involved with the
development, of a rather complex project, like GRASS GIS, is the difficulty to
get started.  The procedure usually involves:

- reading various wiki pages, sometimes even outdated ones
- identifying software dependencies
- often trial-and-error attempts to successfully compile GRASS GIS

Casual power-users with the potential to bring-in positive contributions,
might be overwhelmed by this.  Furthermore, this procedure has to be repeated
by each and everyone willing to get involved.

## Kickstarting a development environment

A user's level of expertise shouldn't matter in getting involved.  With this in
mind, the goal is to create a _single-command_, easy to use, automated tool.
This tool will kickstart a GRASS GIS development environment within minutes.

## About Ansible

Ansible is one of the tools used by devops for automating IT tasks.  These
tasks can be actions like:

- install this package
- create this user
- rename this file
- start this service
- run this command
- etc

Ansible covers pretty much anything you can do with a computer.  In layman
terms, an "ansible role" is nothing more than a list of tasks to be executed.

## Ansible role to compile GRASS GIS

With the execution of a single command, this role will:

- install dependencies required for compiling and running GRASS GIS
- checkout the source code
- create a virtualenv and install all python dependencies
- compile GRASS GIS

The only requirements are an Ubuntu 18.04 installation and internet connection.

## Your support

Would you have some spare time and a VM available, I would be happy if you give
it a try. Even more, if you let me know what you think about it.

I am by no means a GRASS GIS expert, and I certainly have tested only a small
part of GRASS GIS' functionality.  Thus, there will be things not working as
expected. Some dependency might be missing or the documentation might not be
clear enough.

The code is hosted on github and you can find instructions how to use the role
on the README file.  No ansible knowledge is required and if you can't follow
the instructions on the first time you read them, then this is a bug!

Let me know :)

## A note about security

Dislaimer: Downloading and executing an ansible role entails all the dangers of
executing a random script from the internet. So all the usual warnings are in
order. Best to try this on a throwaway VM

Thank you and looking forward to hear from you

Panagiotis
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Python 3 minimum version

[Panagiotis Mavrogiorgos]

Hello everyone,

Quick question, which Python 3 version is the minimum one targeted for the
next GRASS Releases?

with kind regards
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS gui modes

[Panagiotis Mavrogiorgos]

On Mon, Feb 4, 2019 at 12:23 PM Martin Landa  wrote:

> Hi,
>
> po 4. 2. 2019 v 11:11 odesílatel Panagiotis Mavrogiorgos
>  napsal:
> > Question: are there any other GUI modes apart from "wxpython"?
>
> no, only wxPython, see `g.gui --help`
>
> ```
>  ui   User interface
>   options: wxpython,text,gtext
> ```
>
> Martin
>
> Thank you Martin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS gui modes

[Panagiotis Mavrogiorgos]

Question: are there any other GUI modes apart from "wxpython"?

Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Question for set_gui_path()

[Panagiotis Mavrogiorgos]

I am trying to wrap my head around grass initialization, which
unfortunately is not that easy, so bear with me if I ask something stupid.

In grass/script/setup.py there is a function called set_gui_path():

def set_gui_path():
"""Insert wxPython GRASS path to sys.path."""
gui_path = os.path.join(os.environ['GISBASE'], 'gui', 'wxpython')
if gui_path and gui_path not in sys.path:
sys.path.insert(0, gui_path)

As you can see it has a very specific side-effect, i.e. it adds
GISBASE/gui/wxpython to sys.path.

This function was introduced in 67310
 and is being called in a
bunch of gui/wxpython modules:

gui/wxpython/photo2image/g.gui.photo2image.py
gui/wxpython/image2target/g.gui.image2target.py
gui/wxpython/gmodeler/g.gui.gmodeler.py
gui/wxpython/timeline/g.gui.timeline.py
gui/wxpython/rlisetup/g.gui.rlisetup.py
gui/wxpython/vdigit/g.gui.vdigit.py
gui/wxpython/animation/g.gui.animation.py
gui/wxpython/startup/locdownload.py
gui/wxpython/mapswipe/g.gui.mapswipe.py
gui/wxpython/dbmgr/g.gui.dbmgr.py
gui/wxpython/gcp/g.gui.gcp.py
gui/wxpython/psmap/g.gui.psmap.py
gui/wxpython/mapdisp/main.py
gui/wxpython/mapdisp/test_mapdisp.py
gui/wxpython/iclass/g.gui.iclass.py
gui/wxpython/gui_core/pyedit.py
gui/wxpython/gui_core/goutput.py
gui/wxpython/gui_core/ghelp.py
gui/wxpython/gui_core/forms.py
gui/wxpython/gui_core/treeview.py
gui/wxpython/gui_core/simplelmgr.py
gui/wxpython/datacatalog/g.gui.datacatalog.py
gui/wxpython/modules/mapsets_picker.py
gui/wxpython/tplot/g.gui.tplot.py

Nevertheless, if we start the GUI, and check sys.path in the embedded
python console,
we see that GISBASE/gui/wxpython has been already added to the path;
probably due to one of those calls:

>>> import sys
>>> sys.path
['/home/pmav99/Prog/svn/grass_svn/dist.x86_64-pc-linux-gnu/gui/wxpython',
 '/home/pmav99/Prog/svn/grass_svn/dist.x86_64-pc-linux-gnu/etc/python',
 '/usr/lib/python37.zip',
 '/usr/lib/python3.7',
 '/usr/lib/python3.7/lib-dynload',
 '/home/pmav99/Prog/svn/grass_svn/venv3/lib/python3.7/site-packages',
 '/home/pmav99/Prog/svn/grass_svn/dist.x86_64-pc-linux-gnu/etc/r.in.wms'
]

So if GISBASE/gui/wxpython is needed to be in sys.path for the GUI to work
correctly, what is the problem with adding it once when the GUI starts and
be done with it?

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Testsuite: script for easier use of test framework

[Panagiotis Mavrogiorgos]

Since the testsuite script and its configuration file are committed, I
think it would be a good idea to also change the (hardcoded) default value
of GRASSSRC from:

# source code directory as full path:
> GRASSSRC="$HOME/software/grass77"


To something like:

GRASSSRC="$(cd ../../; pwd)"
> GRASSSRC="$(realpath ../../)"


So that you don't need to necessarily edit them in order to run them
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS addons dependencies

[Panagiotis Mavrogiorgos]

On Thu, Feb 4, 2016 at 11:53 PM, Martin Landa <landa.mar...@gmail.com>
 wrote:

> Hi,
>
> 2016-02-04 22:28 GMT+01:00 Panagiotis Mavrogiorgos <pma...@gmail.com>:
> > So my question is whether there is a way to define addon dependencies,
> and
> > if there is not, what would be a sensible way to support something like
> > this.
>
> currently it's not possible. Please fill the ticket. Martin


Here is the ticket: https://trac.osgeo.org/grass/ticket/2895#ticket
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS addons dependencies

[Panagiotis Mavrogiorgos]

Hi everybody,

Some addons depend on other addons. E.g. r.lfp depends on r.stream.distance.

If you try to use it while r.stream.distance is not installed, you get the
following traceback which is not particularly helpful; especially so if you
are not familiar with Python.

Traceback (most recent call last):
>   File "/home/grassuser/.grass7/addons/scripts/r.lfp", line 111, in
> 
> sys.exit(main())
>   File "/home/grassuser/.grass7/addons/scripts/r.lfp", line 43, in main
> calculate_lfp(input, output, coords)
>   File "/home/grassuser/.grass7/addons/scripts/r.lfp", line 67, in
> calculate_lfp
> distance=flds)
>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 392, in
> run_command
> ps = start_command(*args, **kwargs)
>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 361, in
> start_command
> return Popen(args, **popts)
>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 64, in
> __init__
> subprocess.Popen.__init__(self, args, **kwargs)
>   File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> errread, errwrite)
>   File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory


So my question is whether there is a way to define addon dependencies, and
if there is not, what would be a sensible way to support something like
this.

best regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Max Memory usage limit

[Panagiotis Mavrogiorgos]

On Tue, Jan 12, 2016 at 10:20 AM, Markus Neteler <nete...@osgeo.org> wrote:

> On Mon, Jan 11, 2016 at 8:04 PM, Panagiotis Mavrogiorgos
> <pma...@gmail.com> wrote:
> > Hi all,
> >
> > Just out of curiosity, why is there an upper limit to the memory we can
> use
> > on operations like r.in.gdal?
>
> The question is too generic, so I'll refer to r.in.gdal only:
> To my knowledge there is a GDAL imposed CACHE limit
>
>
> https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.in.gdal/main.c#L271
>
> 271/* default GDAL memory cache size appears to be only 40 MiB,
> slowing down r.in.gdal */
> 272if (parm.memory->answer && *parm.memory->answer) {
> 273   /* TODO: GDALGetCacheMax() overflows at 2GiB, implement
> use of GDALSetCacheMax64() */
> 274   GDALSetCacheMax(atol(parm.memory->answer) * 1024 * 1024);
>
> but concerning the data you can import I am not aware of any limit.
>
> Maybe this page is of interest to you:
> https://grasswiki.osgeo.org/wiki/Large_raster_data_processing
>
> What is exactly your problem you encountered?


Thank you Marcus,

That was really helpful. I don't have a particular problem. I just found
strange that the limit was so low on x64 architectures.

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Max Memory usage limit

[Panagiotis Mavrogiorgos]

Hi all,

Just out of curiosity, why is there an upper limit to the memory we can use
on operations like r.in.gdal?

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] grouping most important parameters in a 'main' tab

[Panagiotis Mavrogiorgos]

On Thu, Dec 24, 2015 at 6:56 PM,  wrote:

> Send grass-dev mailing list submissions to
> grass-dev@lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> or, via email, send a message with subject or body 'help' to
> grass-dev-requ...@lists.osgeo.org
>
> You can reach the person managing the list at
> grass-dev-ow...@lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-dev digest..."
>
> Today's Topics:
>
>1. Re: grouping most important parameters in a 'main' tab
>   (Vaclav Petras)
>2. r.category: wrong separator in examples (Helmut Kudrnovsky)
>3. Re: [GRASS GIS] #2819: v.db.renamecolumn mysql error (GRASS GIS)
>4. Re: [GRASS GIS] #2745: i.cluster: report file has wrong
>   linebreaks on Windows (GRASS GIS)
>5. Re: [GRASS GIS] #2775: Hangs when closing db drivers (GRASS GIS)
>6. Re: [GRASS GIS] #2775: Hangs when closing db drivers (GRASS GIS)
>7. Re: [GRASS GIS] #2775: Hangs when closing db drivers (GRASS GIS)
>8. Re: [GRASS GIS] #2759: v.rast.stats and mySQL (GRASS GIS)
>
>
> -- Forwarded message --
> From: Vaclav Petras 
> To: Moritz Lennert , "Blumentrath, Stefan" <
> stefan.blumentr...@nina.no>
> Cc: Paulo van Breugel , grass-dev <
> grass-dev@lists.osgeo.org>
> Date: Wed, 23 Dec 2015 15:53:52 -0500
> Subject: Re: [GRASS-dev] grouping most important parameters in a 'main' tab
>
> On Wed, Dec 23, 2015 at 7:15 AM, Paulo van Breugel  > wrote:
>
>> On Wed, Dec 23, 2015 at 12:19 PM, Moritz Lennert <
>> mlenn...@club.worldonline.be> wrote:
>>
>>>
>>> In a response to #2632 [1], I changed v.db.select in trunk (r67337) in
>>> order to reorder parameters in the module GUI and group what I consider the
>>> most important parameters in a 'Main' tab.
>>>
>>> I know there has been much discussion about parameter grouping in the
>>> GUI before and I don't want to impose my choices here. So, I'm more than
>>> happy to revert if necessary.
>>>
>>> The main idea is to ease the use of module GUIs without giving up their
>>> complete power. In other words, simplify, without dumming down. If, for a
>>> module, there are some parameters that seem the most obvious ones to
>>> change, then why not regroup them in a 'Main' tab, while leaving the other,
>>> more specialised ones, in separate tabs ?
>>>
>>
>> I am all in favour of this. Easier for the casual user and it means less
>> clicks for probably most user-cases. I guess it will not always be easy to
>> determine what are the most important / common parameters, but for this
>> module I think you got them all right under the main tab.
>>
>
wrt to the name of the tab, instead of "main", "common" might be more
accurate.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] d.mon using PIL tostring() (not used anymore), tobytes() to be used

[Panagiotis Mavrogiorgos]

I have opened https://trac.osgeo.org/grass/ticket/2815

@Anna, the calls to "fromstring()" need to also be replaced.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Ubuntu ppa for stable GRASS version

[Panagiotis Mavrogiorgos]

copying a message from https://trac.osgeo.org/grass/ticket/2809

Replying to [comment:5 martinl]:
> Replying to [comment:4 pmav99]:
>
> you are right. grass-stable is now obsolete, I will maintain stable
package on ubuntugis-unstable (I will upload 7.0.2 ASAP).

Sorry to nag, but any updates? The `ubuntugis-unstable` ppa still does not
have `7.0.2`.

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev