[GRASS-dev] Tests down to 65% (from 86%)

Hi all,

something happened between r62745 (Saturday) and r62754 (Sunday) because tests are failing. Here are the changes in trunk:

http://trac.osgeo.org/grass/log/grass/trunk?action=stop_on_copy&mode=stop_on_copy&rev=62754&stop_rev=62746&limit=100&verbose=on

MarkusM, I’m not sure what was the actual change but it seems that G_tokenize() is the only related change. From the tests it seems that something in parser is failing.

I’ve also noticed that the documentation on server does not contain generated/standard flags (–), the flags are included when there is a short flag (-). I get the flags on my local machine with recent version. Was this changed somehow lately?

Vaclav

http://grass.osgeo.org/grass71/manuals/r.rgb.html
http://grass.osgeo.org/grass71/manuals/r.blend.html

Hi,

2014-11-17 3:54 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:

I've also noticed that the documentation on server does not contain
generated/standard flags (--), the flags are included when there is a short
flag (-). I get the flags on my local machine with recent version. Was this
changed somehow lately?

in r62756 [1] I added `--ui` flag, but it doesn't seems to be related
(needs more investigation).

Martin

[1] http://trac.osgeo.org/grass/changeset/62756

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa

On Mon, Nov 17, 2014 at 3:54 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

Hi all,

something happened between r62745 (Saturday) and r62754 (Sunday) because
tests are failing. Here are the changes in trunk:

http://trac.osgeo.org/grass/log/grass/trunk?action=stop_on_copy&mode=stop_on_copy&rev=62754&stop_rev=62746&limit=100&verbose=on

MarkusM, I'm not sure what was the actual change but it seems that
G_tokenize() is the only related change. From the tests it seems that
something in parser is failing.

G_tokenize() no longer removes leading spaces (it never removed
trailing spaces), but G_parser() relied on that. G_tokenize()
tokenizes a string, spaces can be removed with G_chop(), G_squeeze(),
or G_strip(). Fixed in r62763,4.

BTW, the test suite does not run with Python 2.6 because import
argparse fails, this module is new in Python 2.7.

Markus M

I've also noticed that the documentation on server does not contain
generated/standard flags (--), the flags are included when there is a short
flag (-). I get the flags on my local machine with recent version. Was this
changed somehow lately?

Vaclav

http://grass.osgeo.org/grass71/manuals/r.rgb.html
http://grass.osgeo.org/grass71/manuals/r.blend.html

On Mon, Nov 17, 2014 at 11:32 AM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

BTW, the test suite does not run with Python 2.6 because import
argparse fails, this module is new in Python 2.7.

but can be installed:

https://pypi.python.org/pypi/argparse

Best regards

Pietro

Hi,

2014-11-17 11:32 GMT+01:00 Markus Metz <markus.metz.giswork@gmail.com>:

G_tokenize() no longer removes leading spaces (it never removed
trailing spaces), but G_parser() relied on that. G_tokenize()
tokenizes a string, spaces can be removed with G_chop(), G_squeeze(),
or G_strip(). Fixed in r62763,4.

hm, the r.rgb still lacks flags in parameters section. Any idea? Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa

About which platform do we talk about because now I’m starting to be concerned more about Python 3 which is appearing more and more as default.

I forgot to mention this in the other thread about gunittest backport, incompatibility with 2.6 is another argument against backport.

···

On Mon, Nov 17, 2014 at 5:32 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

BTW, the test suite does not run with Python 2.6 because import
argparse fails, this module is new in Python 2.7.

I know and I don’t know if 2.6 support is feasible. A lot of unittest functions was added in 2.7, so most of the tests would fail anyway. There is unittest2 package which can be installed separately and used instead of unittest in Python 2.6 but as I was reading about it it does not seem as smooth as I hoped for.

But perhaps installing unittest2 and argparse is worth trying. Few changes will be required in gunittest too, mostly imports I hope.

Vaclav

https://docs.python.org/2/library/unittest.html#assert-methods
https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertRaisesRegexp
https://docs.python.org/2/library/unittest.html#unittest.TestCase.addTypeEqualityFunc
https://docs.python.org/2/library/unittest.html#unittest.TestCase.setUpClass
https://docs.python.org/2/library/unittest.html#unittest.registerResult

https://pypi.python.org/pypi/unittest2
https://pypi.python.org/pypi/argparse

On Mon, Nov 17, 2014 at 2:43 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Mon, Nov 17, 2014 at 5:32 AM, Markus Metz <markus.metz.giswork@gmail.com>
wrote:

BTW, the test suite does not run with Python 2.6 because import
argparse fails, this module is new in Python 2.7.

I know and I don't know if 2.6 support is feasible. A lot of unittest
functions was added in 2.7, so most of the tests would fail anyway. There is
unittest2 package which can be installed separately and used instead of
unittest in Python 2.6 but as I was reading about it it does not seem as
smooth as I hoped for.

But perhaps installing unittest2 and argparse is worth trying. Few changes
will be required in gunittest too, mostly imports I hope.

I will give it a try, argparse and unittest2 are available through the
package manager for my stock Python 2.6 version.

About which platform do we talk about

RHEL 6 and relatives, officially supported until end of 2020.

because now I'm starting to be
concerned more about Python 3 which is appearing more and more as default.

... for cutting (bleeding) edge distros, not yet for enterprise distros.

Markus M

I forgot to mention this in the other thread about gunittest backport,
incompatibility with 2.6 is another argument against backport.

Vaclav

https://docs.python.org/2/library/unittest.html#assert-methods
https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertRaisesRegexp
https://docs.python.org/2/library/unittest.html#unittest.TestCase.addTypeEqualityFunc
https://docs.python.org/2/library/unittest.html#unittest.TestCase.setUpClass
https://docs.python.org/2/library/unittest.html#unittest.registerResult

https://pypi.python.org/pypi/unittest2
https://pypi.python.org/pypi/argparse

On Mon, Nov 17, 2014 at 2:34 PM, Markus Metz <markus.metz.giswork@gmail.com>
wrote:

> But perhaps installing unittest2 and argparse is worth trying. Few
changes
> will be required in gunittest too, mostly imports I hope.

I will give it a try, argparse and unittest2 are available through the
package manager for my stock Python 2.6 version.
>

I will have to change imports to allow unittest2, hopefully today or
tomorrow. It should be simple to write but I will not test it.

> About which platform do we talk about

RHEL 6 and relatives, officially supported until end of 2020.

Good to know, these are important.

On Mon, Nov 17, 2014 at 11:19 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2014-11-17 3:54 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:

I've also noticed that the documentation on server does not contain
generated/standard flags (--), the flags are included when there is a short
flag (-). I get the flags on my local machine with recent version. Was this
changed somehow lately?

in r62756 [1] I added `--ui` flag, but it doesn't seems to be related
(needs more investigation).

I have changed lib/gis/parser_html.c in r62776, now it works for me. A
"Flags" section could not possibly be created if no flags were
defined, and the standard -- flags are never defined with
G_define_flag(). See also G_usage() in lib/gis/parser_help.c

Markus M

Martin

[1] http://trac.osgeo.org/grass/changeset/62756

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa

Hi MarkusM,

2014-11-17 23:01 GMT+01:00 Markus Metz <markus.metz.giswork@gmail.com>:

I have changed lib/gis/parser_html.c in r62776, now it works for me. A
"Flags" section could not possibly be created if no flags were
defined, and the standard -- flags are never defined with
G_define_flag(). See also G_usage() in lib/gis/parser_help.c

I see, thanks for fix. I took liberty to backport this change
(including other changes) to relbr70 in r62784.

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa

Thanks, tests are back to 86%.

http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-11-18-08-00/report_for_nc_spm_08_grass7_nc/testsuites.html