…by adding the option of a few different compression schemes, including LZ4. I’ve had the ticket open for a week now with no responses. I’d love to get it incorporated into trunk. For more info, see here:
https://trac.osgeo.org/grass/ticket/2750
On Oct 2, 2015 6:49 PM, “Seth Price” <seth@planet.com> wrote:
…by adding the option of a few different compression schemes, including LZ4. I’ve had the ticket open for a week now with no responses. I’d love to get it incorporated into trunk. For more info, see here:
https://trac.osgeo.org/grass/ticket/2750
This is definitely great news!
I saw the ticket but just back from traveling… Need to set up a test installation with our MODIS time series to test it on large data sets.
Thanks for the contribution.
I hope others can test as well, esp. on Mac and Windows.
Markus
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler wrote
On Oct 2, 2015 6:49 PM, "Seth Price" <
seth@
> wrote:
..by adding the option of a few different compression schemes, including
LZ4. I've had the ticket open for a week now with no responses. I'd love
to
get it incorporated into trunk. For more info, see here:This is definitely great news!
I saw the ticket but just back from traveling... Need to set up a test
installation with our MODIS time series to test it on large data sets.Thanks for the contribution.
I hope others can test as well, esp. on Mac and Windows.Markus
_______________________________________________
grass-dev mailing listgrass-dev@.osgeo
_______________________________________________
grass-dev mailing list
grass-dev@.osgeo
what and how to test on windows?
-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/I-ve-tripled-GRASS-s-I-O-speed-tp5227637p5227653.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
On Fri, Oct 2, 2015 at 12:49 PM, Seth Price <seth@planet.com> wrote:
..by adding the option of a few different compression schemes, including
LZ4. I've had the ticket open for a week now with no responses. I'd love to
get it incorporated into trunk. For more info, see here:
https://trac.osgeo.org/grass/ticket/2750
Hi,
thanks for the reminder. This looks really good. Can you provide a test
which would do a trivial operation (like the benchmark in the ticket)
ideally using Python and gunittest [1]? Please, let me know if you don't
know where to start.
Vaclav
[1] https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html
Hi, I’ve spent the last two or three hours trying to get GRASS’ unit tests running. With a fresh source tree, the best I can get is ~9% of the tests passing:
seths-mbp:grass-7.1.svn_src_snapshot_2015_09_19 sprice$ grass71 --text …/nc_spm_08_grass7/PERMANENT/
[…]
GRASS 7.1.svn (nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 > python -m grass.gunittest.main --location /usr/local/grass/nc_spm_08_grass7/ --location-type nc
test_g_list from ./general/g.list failed (1 test failed)
test_g_remove from ./general/g.remove failed (2 tests failed)
test_overwrite from ./general/g.rename failed (3 tests failed)
[…]
test_vto3d from ./vector/v.to.3d failed (1 test failed)
test_vwhat_layers from ./vector/v.what failed (1 test failed)
test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)
Executed 127 test files in 0:00:55.959398.
From them 12 files (9%) were successful and 115 files (91%) failed.
GRASS 7.1.svn (nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
···
I’d really like to work on these unit tests. Any ideas as to where I’m going wrong? I feel like I’ve exhausted the various knowledge bases available online.
Thanks,
Seth
On Fri, Oct 2, 2015 at 11:25 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Fri, Oct 2, 2015 at 12:49 PM, Seth Price <seth@planet.com> wrote:
…by adding the option of a few different compression schemes, including LZ4. I’ve had the ticket open for a week now with no responses. I’d love to get it incorporated into trunk. For more info, see here:
https://trac.osgeo.org/grass/ticket/2750
Hi,
thanks for the reminder. This looks really good. Can you provide a test which would do a trivial operation (like the benchmark in the ticket) ideally using Python and gunittest [1]? Please, let me know if you don’t know where to start.
Vaclav
[1] https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html
On Mon, Oct 5, 2015 at 3:21 PM, Seth Price <seth@planet.com> wrote:
Hi, I've spent the last two or three hours trying to get GRASS' unit tests
running. With a fresh source tree, the best I can get is ~9% of the tests
passing:
Oh, sorry about that, you need to use basic instead of full NC location.
The datasets are unfortunately incompatible and the whole thing is
undocumented because we never made the switch official.
https://grass.osgeo.org/download/sample-data/
But since NC basic will be replaced by standardized sample dataset (which
is partially reason for the confusing situation), use this new dataset
instead.
https://trac.osgeo.org/grass/wiki/SampleDataset (goes here:
http://www4.ncsu.edu/~hmitaso/grasswork/grassbookdat4ed/)
Have you noticed that you can view the errors in an HTML report?
"grass.gunittest.main writes a text summary to standard output and it
creates an HTML report from all tests in all testsuite directories inside
the directory tree. The report is placed in testreport by default. Open
file testreport/index.html in you web browser to inspect it."
seths-mbp:grass-7.1.svn_src_snapshot_2015_09_19 sprice$ grass71 --text
../nc_spm_08_grass7/PERMANENT/
[...]
GRASS 7.1.svn
(nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
python -m grass.gunittest.main --location
/usr/local/grass/nc_spm_08_grass7/ --location-type nctest_g_list from ./general/g.list failed (1 test failed)
test_g_remove from ./general/g.remove failed (2 tests failed)
test_overwrite from ./general/g.rename failed (3 tests failed)
[...]test_vto3d from ./vector/v.to.3d failed (1 test failed)
test_vwhat_layers from ./vector/v.what failed (1 test failed)
test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)
Executed 127 test files in 0:00:55.959398.
From them 12 files (9%) were successful and 115 files (91%) failed.
GRASS 7.1.svn
(nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >I'd really like to work on these unit tests. Any ideas as to where I'm
going wrong? I feel like I've exhausted the various knowledge bases
available online.
Thanks,
SethOn Fri, Oct 2, 2015 at 11:25 AM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:On Fri, Oct 2, 2015 at 12:49 PM, Seth Price <seth@planet.com> wrote:
..by adding the option of a few different compression schemes, including
LZ4. I've had the ticket open for a week now with no responses. I'd love to
get it incorporated into trunk. For more info, see here:
https://trac.osgeo.org/grass/ticket/2750Hi,
thanks for the reminder. This looks really good. Can you provide a test
which would do a trivial operation (like the benchmark in the ticket)
ideally using Python and gunittest [1]? Please, let me know if you don't
know where to start.Vaclav
[1]
https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html
Thanks, I think I’m still getting the same issue. Here is me trying to run tests with both “nc_basic_spm_grass7” and “ncarolina_smp_base0.3.2”:
seths-mbp:grass-7.1.svn_src_snapshot_2015_09_19 sprice$ grass71 --text …/nc_basic_spm_grass7/PERMANENT/
Cleaning up temporary files…
[…]
GRASS 7.1.svn (nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 > python -m grass.gunittest.main --location /usr/local/grass/nc_basic_spm_grass7/ --location-type nc
test_g_list from ./general/g.list failed (1 test failed)
test_g_remove from ./general/g.remove failed (2 tests failed)
test_overwrite from ./general/g.rename failed (3 tests failed)
toolboxes from ./gui/wxpython/core failed
[…]
test_vto3d from ./vector/v.to.3d failed (1 test failed)
test_vwhat_layers from ./vector/v.what failed (1 test failed)
test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)
Executed 127 test files in 0:00:50.862606.
From them 12 files (9%) were successful and 115 files (91%) failed.
GRASS 7.1.svn (nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 > exit
[…]
seths-mbp:grass-7.1.svn_src_snapshot_2015_09_19 sprice$ grass71 --text …/ncarolina_smp_base0.3.2/PERMANENT/
[…]
GRASS 7.1.svn (ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 > python -m grass.gunittest.main --location /usr/local/grass/ncarolina_smp_base0.3.2/ --location-type nc
test_g_list from ./general/g.list failed (1 test failed)
test_g_remove from ./general/g.remove failed (2 tests failed)
test_overwrite from ./general/g.rename failed (3 tests failed)
toolboxes from ./gui/wxpython/core failed
[…]
test_v_net from ./vector/v.net failed (8 tests failed)
test_vto3d from ./vector/v.to.3d failed (1 test failed)
test_vwhat_layers from ./vector/v.what failed (1 test failed)
test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)
Executed 127 test files in 0:00:46.315482.
From them 12 files (9%) were successful and 115 files (91%) failed.
GRASS 7.1.svn (ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
···
On Mon, Oct 5, 2015 at 1:18 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Mon, Oct 5, 2015 at 3:21 PM, Seth Price <seth@planet.com> wrote:
Hi, I’ve spent the last two or three hours trying to get GRASS’ unit tests running. With a fresh source tree, the best I can get is ~9% of the tests passing:
Oh, sorry about that, you need to use basic instead of full NC location. The datasets are unfortunately incompatible and the whole thing is undocumented because we never made the switch official.
https://grass.osgeo.org/download/sample-data/
But since NC basic will be replaced by standardized sample dataset (which is partially reason for the confusing situation), use this new dataset instead.
https://trac.osgeo.org/grass/wiki/SampleDataset (goes here: http://www4.ncsu.edu/~hmitaso/grasswork/grassbookdat4ed/)
Have you noticed that you can view the errors in an HTML report?
“grass.gunittest.main writes a text summary to standard output and it creates an HTML report from all tests in all testsuite directories inside the directory tree. The report is placed in testreport by default. Open file testreport/index.html in you web browser to inspect it.”
seths-mbp:grass-7.1.svn_src_snapshot_2015_09_19 sprice$ grass71 --text …/nc_spm_08_grass7/PERMANENT/
[…]
GRASS 7.1.svn (nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 > python -m grass.gunittest.main --location /usr/local/grass/nc_spm_08_grass7/ --location-type nc
test_g_list from ./general/g.list failed (1 test failed)
test_g_remove from ./general/g.remove failed (2 tests failed)
test_overwrite from ./general/g.rename failed (3 tests failed)
[…]
test_vto3d from ./vector/v.to.3d failed (1 test failed)
test_vwhat_layers from ./vector/v.what failed (1 test failed)
test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)
Executed 127 test files in 0:00:55.959398.
From them 12 files (9%) were successful and 115 files (91%) failed.
GRASS 7.1.svn (nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
I’d really like to work on these unit tests. Any ideas as to where I’m going wrong? I feel like I’ve exhausted the various knowledge bases available online.
Thanks,
Seth
On Fri, Oct 2, 2015 at 11:25 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Fri, Oct 2, 2015 at 12:49 PM, Seth Price <seth@planet.com> wrote:
…by adding the option of a few different compression schemes, including LZ4. I’ve had the ticket open for a week now with no responses. I’d love to get it incorporated into trunk. For more info, see here:
https://trac.osgeo.org/grass/ticket/2750
Hi,
thanks for the reminder. This looks really good. Can you provide a test which would do a trivial operation (like the benchmark in the ticket) ideally using Python and gunittest [1]? Please, let me know if you don’t know where to start.
Vaclav
[1] https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html
On Mon, Oct 5, 2015 at 5:07 PM, Seth Price <seth@planet.com> wrote:
–location /usr/local/grass/nc_basic_spm_grass7/
python -m grass.gunittest.main --location locname --location-type nc
where locname is a name of location in current GRASS GIS data(base) directory (GISDBASE) and nc is a location specified by individual test files (the later is not yet fully implemented, so just put there nc every time).
or:
grass71 --exec python -m grass.gunittest.main --help
…
–location LOCATION Name of location where to perform test
I hope this helps.
Have you found the HTMl output?
Ah, I see now. I have failed tests at 24% & 21% on a recent snapshot now:
GRASS 7.1.svn (ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 > python -m grass.gunittest.main --location ncarolina_smp_base0.3.2 --location-type nc
test_assertions_vect from ./lib/python/gunittest failed (1 test failed)
test_doctests from ./lib/python/pygrass failed (3 tests failed)
[…]
test_v_net from ./vector/v.net failed (4 tests failed)
test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)
Executed 127 test files in 0:24:05.986559.
From them 96 files (76%) were successful and 31 files (24%) failed.
GRASS 7.1.svn (ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
or
GRASS 7.1.svn (nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 > python -m grass.gunittest.main --location nc_basic_spm_grass7 --location-type nc
test_assertions_vect from ./lib/python/gunittest failed (1 test failed)
test_doctests from ./lib/python/pygrass failed (3 tests failed)
[…]
test_raster3d_algebra from ./temporal/t.rast3d.algebra failed (6 tests failed)
test_vector_algebra from ./temporal/t.vect.algebra failed (14 tests failed)
Executed 127 test files in 0:24:47.877746.
From them 100 files (79%) were successful and 27 files (21%) failed.
GRASS 7.1.svn (nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
Is this expected?
···
On Mon, Oct 5, 2015 at 2:13 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Mon, Oct 5, 2015 at 5:07 PM, Seth Price <seth@planet.com> wrote:
–location /usr/local/grass/nc_basic_spm_grass7/
python -m grass.gunittest.main --location locname --location-type nc
where locname is a name of location in current GRASS GIS data(base) directory (GISDBASE) and nc is a location specified by individual test files (the later is not yet fully implemented, so just put there nc every time).
or:
grass71 --exec python -m grass.gunittest.main --help
…
–location LOCATION Name of location where to perform testI hope this helps.
Have you found the HTMl output?
On Mon, Oct 5, 2015 at 6:23 PM, Seth Price <seth@planet.com> wrote:
Ah, I see now. I have failed tests at 24% & 21% on a recent snapshot now:
GRASS 7.1.svn
(ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
> python -m grass.gunittest.main --location ncarolina_smp_base0.3.2
--location-type nctest_assertions_vect from ./lib/python/gunittest failed (1 test failed)
test_doctests from ./lib/python/pygrass failed (3 tests failed)
[...]
test_v_net from ./vector/v.net failed (4 tests failed)
test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)
Executed 127 test files in 0:24:05.986559.
From them 96 files (76%) were successful and 31 files (24%) failed.
GRASS 7.1.svn
(ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
>or
GRASS 7.1.svn
(nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
> python -m grass.gunittest.main --location nc_basic_spm_grass7
--location-type nctest_assertions_vect from ./lib/python/gunittest failed (1 test failed)
test_doctests from ./lib/python/pygrass failed (3 tests failed)
[...]
test_raster3d_algebra from ./temporal/t.rast3d.algebra failed (6 tests
failed)test_vector_algebra from ./temporal/t.vect.algebra failed (14 tests failed)
Executed 127 test files in 0:24:47.877746.
From them 100 files (79%) were successful and 27 files (21%) failed.
GRASS 7.1.svn
(nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
>Is this expected?
This looks quite OK actually. Probably most of the failing tests are
temporal algebra which depends on Python PLY:
https://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html
This should be visible in the HTML reports (the aforementioned
testreport/index.html) which give the actual reasons why the test failed.
This is the result you will get today in best case (on 64bit):
Was this result with or without your changes?
On Mon, Oct 5, 2015 at 2:13 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:On Mon, Oct 5, 2015 at 5:07 PM, Seth Price <seth@planet.com> wrote:
>
> --location /usr/local/grass/nc_basic_spm_grass7/python -m grass.gunittest.main --location locname --location-type nc
where locname is a name of location in current GRASS GIS data(base)
directory (GISDBASE) and nc is a location specified by individual test
files (the later is not yet fully implemented, so just put there nc every
time).or:
grass71 --exec python -m grass.gunittest.main --help
...
--location LOCATION Name of location where to perform testI hope this helps.
Have you found the HTMl output?
The tests are without my changes on 64 bit Mac v10.10.5, Mac Pro with 64 GB of RAM.
./configure --with-freetype --with-freetype-includes=/usr/local/include/freetype2 --with-opengl=aqua --with-libs=/usr/local/lib --enable-64bit --with-sqlite --with-postgres --with-postgres-includes=/usr/local/pgsql/include
···
On Mon, Oct 5, 2015 at 3:34 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Mon, Oct 5, 2015 at 6:23 PM, Seth Price <seth@planet.com> wrote:
Ah, I see now. I have failed tests at 24% & 21% on a recent snapshot now:
GRASS 7.1.svn (ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 > python -m grass.gunittest.main --location ncarolina_smp_base0.3.2 --location-type nc
test_assertions_vect from ./lib/python/gunittest failed (1 test failed)
test_doctests from ./lib/python/pygrass failed (3 tests failed)
[…]
test_v_net from ./vector/v.net failed (4 tests failed)
test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)
Executed 127 test files in 0:24:05.986559.
From them 96 files (76%) were successful and 31 files (24%) failed.
GRASS 7.1.svn (ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
or
GRASS 7.1.svn (nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 > python -m grass.gunittest.main --location nc_basic_spm_grass7 --location-type nc
test_assertions_vect from ./lib/python/gunittest failed (1 test failed)
test_doctests from ./lib/python/pygrass failed (3 tests failed)
[…]
test_raster3d_algebra from ./temporal/t.rast3d.algebra failed (6 tests failed)
test_vector_algebra from ./temporal/t.vect.algebra failed (14 tests failed)
Executed 127 test files in 0:24:47.877746.
From them 100 files (79%) were successful and 27 files (21%) failed.
GRASS 7.1.svn (nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
Is this expected?
This looks quite OK actually. Probably most of the failing tests are temporal algebra which depends on Python PLY:
https://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html
This should be visible in the HTML reports (the aforementioned testreport/index.html) which give the actual reasons why the test failed.
This is the result you will get today in best case (on 64bit):
Was this result with or without your changes?
On Mon, Oct 5, 2015 at 2:13 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Mon, Oct 5, 2015 at 5:07 PM, Seth Price <seth@planet.com> wrote:
–location /usr/local/grass/nc_basic_spm_grass7/
python -m grass.gunittest.main --location locname --location-type nc
where locname is a name of location in current GRASS GIS data(base) directory (GISDBASE) and nc is a location specified by individual test files (the later is not yet fully implemented, so just put there nc every time).
or:
grass71 --exec python -m grass.gunittest.main --help
…
–location LOCATION Name of location where to perform testI hope this helps.
Have you found the HTMl output?
On Mon, Oct 5, 2015 at 6:41 PM, Seth Price <seth@planet.com> wrote:
The tests are without my changes on 64 bit Mac v10.10.5, Mac Pro with 64
GB of RAM.
Good, I hope now you are ready to run tests with your changes as well.
BTW, great that you run tests on Mac!
Sorry for derailing my own thread, but here we go again…
I’m having a hard time reproducing anything with the unit tests. There seems to be some state that exists between unit test runs. I ran it with my updated code, and I got 30% failed. Then I ran the new code with the tests, and I’m getting 30% failed. So I deleted the basic location directory and re-decompressed it. Now I’m getting 31% failed in both directories.
Using these commands, as shown above, resulted in 21% failed. I’m running make && sudo make install when I switch directories. Then I delete & refresh the location files. Then I run the unit tests as python -m grass.gunittest.main --location nc_basic_spm_grass7 --location-type nc. What’s wrong with my test procedure?
···
On Mon, Oct 5, 2015 at 3:57 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Mon, Oct 5, 2015 at 6:41 PM, Seth Price <seth@planet.com> wrote:
The tests are without my changes on 64 bit Mac v10.10.5, Mac Pro with 64 GB of RAM.
Good, I hope now you are ready to run tests with your changes as well.
BTW, great that you run tests on Mac!
On Tue, Oct 6, 2015 at 1:42 AM, Seth Price <seth@planet.com> wrote:
Sorry for derailing my own thread, but here we go again...
I'm having a hard time reproducing anything with the unit tests. There
seems to be some state that exists between unit test runs.
What are the actual errors in the HTML report?
I ran it with my updated code, and I got 30% failed. Then I ran the new
code with the tests, and I'm getting 30% failed. So I deleted the basic
location directory and re-decompressed it. Now I'm getting 31% failed in
both directories.Using these commands, as shown above, resulted in 21% failed. I'm running
`make && sudo make install` when I switch directories. Then I delete &
refresh the location files. Then I run the unit tests as `python -m
grass.gunittest.main --location nc_basic_spm_grass7 --location-type nc`.
What's wrong with my test procedure?
Sorry, I don't understand what is the difference between new code and
updated code. When you get 30, 31 21%? What are the actual commands you are
running?
If you are concerned about reproducibility, use VM or Docker, e.g. with
Ubuntu [1]. In this way, we can see if it is a local or Mac issue or not.
I figured it out. I had to make clean && make && sudo make install to get unit tests working as expected.
I just uploaded a new version of the code that shouldn’t fail any additional unit tests, and I’ve added unit tests to r.compress that test reading/writing the different compression schemes.
~Seth
···
On Tue, Oct 6, 2015 at 5:54 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Tue, Oct 6, 2015 at 1:42 AM, Seth Price <seth@planet.com> wrote:
Sorry for derailing my own thread, but here we go again…
I’m having a hard time reproducing anything with the unit tests. There seems to be some state that exists between unit test runs.
What are the actual errors in the HTML report?
I ran it with my updated code, and I got 30% failed. Then I ran the new code with the tests, and I’m getting 30% failed. So I deleted the basic location directory and re-decompressed it. Now I’m getting 31% failed in both directories.
Using these commands, as shown above, resulted in 21% failed. I’m running
make && sudo make installwhen I switch directories. Then I delete & refresh the location files. Then I run the unit tests aspython -m grass.gunittest.main --location nc_basic_spm_grass7 --location-type nc. What’s wrong with my test procedure?
Sorry, I don’t understand what is the difference between new code and updated code. When you get 30, 31 21%? What are the actual commands you are running?
If you are concerned about reproducibility, use VM or Docker, e.g. with Ubuntu [1]. In this way, we can see if it is a local or Mac issue or not.
On Wed, Oct 7, 2015 at 8:45 PM, Seth Price <seth@planet.com> wrote:
I figured it out. I had to `make clean && make && sudo make install` to
get unit tests working as expected.
Makes sense. I should have suggested that. I was doing make distclean
automatically out of a habit since the change is in the library.
I just uploaded a new version of the code that shouldn't fail any
additional unit tests, and I've added unit tests to r.compress that test
reading/writing the different compression schemes.
Glad to hear that. Replied to the ticket (copy goes to grass-dev):
https://trac.osgeo.org/grass/ticket/2750#comment:6
~Seth
On Tue, Oct 6, 2015 at 5:54 AM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:On Tue, Oct 6, 2015 at 1:42 AM, Seth Price <seth@planet.com> wrote:
Sorry for derailing my own thread, but here we go again...
I'm having a hard time reproducing anything with the unit tests. There
seems to be some state that exists between unit test runs.What are the actual errors in the HTML report?
I ran it with my updated code, and I got 30% failed. Then I ran the new
code with the tests, and I'm getting 30% failed. So I deleted the basic
location directory and re-decompressed it. Now I'm getting 31% failed in
both directories.Using these commands, as shown above, resulted in 21% failed. I'm
running `make && sudo make install` when I switch directories. Then I
delete & refresh the location files. Then I run the unit tests as `python
-m grass.gunittest.main --location nc_basic_spm_grass7 --location-type nc`.
What's wrong with my test procedure?Sorry, I don't understand what is the difference between new code and
updated code. When you get 30, 31 21%? What are the actual commands you are
running?If you are concerned about reproducibility, use VM or Docker, e.g. with
Ubuntu [1]. In this way, we can see if it is a local or Mac issue or not.