[GRASS-dev] I've tripled GRASS's I/O speed

[Seth Price]

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 at gmail.com> wrote:

>
> On Tue, Oct 6, 2015 at 1:42 AM, Seth Price <seth at 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.
>
> [1] https://github.com/wenzeslaus/grass-gis-docker
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151007/d2a1ead6/attachment.html>