Cache: inconsistent result in different runs based on the same coafile.

[gaocegege]

Hi, I have tried to run coala with the .coafile in https://github.com/gaocegege/Processing.R

[Default]
files = src/**/*.java, examples/**/*.rpde

max_line_length = 80

[Java]
bears = CheckstyleBear
indent_size = 4

[R]
bears = FormatRBear
files = examples/**/*.rpde

Then I got an error caused by checkstyle:

[DEBUG][20:22:24] The bear CheckstyleBear raised an exception. If you are the author of this bear, please make sure to catch all exceptions. If not and this error annoys you, you might want to get in contact with the author of this bear.

Traceback information is provided below:

Traceback (most recent call last):
  File "/home/ist/venvs/profiler/lib/python3.5/site-packages/coalib/bears/Bear.py", line 234, in execute
    result = self.run_bear_from_section(args, kwargs)
  File "/home/ist/venvs/profiler/lib/python3.5/site-packages/coalib/bears/Bear.py", line 227, in run_bear_from_section
    return self.run(*args, **kwargs)
  File "/home/ist/venvs/profiler/lib/python3.5/site-packages/coalib/bearlib/abstractions/Linter.py", line 540, in run
    **create_arguments_kwargs)
  File "/home/ist/venvs/profiler/lib/python3.5/site-packages/bears/java/CheckstyleBear.py", line 81, in create_arguments
    checkstyle_configs, use_spaces, indent_size)
  File "/home/ist/venvs/profiler/lib/python3.5/site-packages/bears/java/CheckstyleBear.py", line 21, in check_invalid_configuration
    raise ValueError('Google checkstyle config does not support '
ValueError: Google checkstyle config does not support use_spaces=False or indent_size != 2

I am not sure if it is a feature or a bug. But I think it is common to use 4 spaces in Java code. If coala could support the config painlessly, it will be better :)

[gaocegege]

And I found a weird thing:

coala will return a warning message the first time I run it. And after that, the warning message don't appear again.

[Makman2]

Hm maybe caching suppresses the output then? Not sure...

[gaocegege]

Maybe

FYI, coala -V returns the error trace every time.

[SanketDG]

I tested this on latest master and can't replicate this.

Are you on master?

[SanketDG]

Sorry, I didn't see your .coafile was commented out.

I think for your first issue, relevant info is #898

Maybe you can use a different checkstyle config other than google?

No idea about the second weird behaviour.

[SanketDG]

I dug deeper into the second bug and it seems like the filename queue is being taken as empty on the second run.

Definitely a bug imo^^

[SanketDG]

uh okay they are features :3

caching suppresses the output yes, but the log message that informs this needs to be a higher log level imo i.e. info

cc @adtac

[adtac]

This is a known issue (there's a github issue somewhere). Bears that fail to run are not run again next time. Caching doesn't suppress the output; the bear doesn't even run even though it should. It's a bug in caching :3

[Makman2]

Feel free to close this bug as duplicate once the other one is found 👍

[jeremydouglass]

I'm a newcomer, but these might be related:

1. a type of coala-bears issue requiring bears to forbid linting incorrect indents, e.g. Google Java requires "2" so "4" throws an error. CheckstyleBear: Add invalid configuration check #917 "CheckstyleBear: Add invalid configuration check"

   Closes CheckstyleBear should error when use_spaces is False or indent_size is not 2 #898 ensuring that if the checkstyle_config is google, then use_spaces has to be true and indent_size is 2.

2. special handling of large error dumps generated by things like the above: WriteGoodLintBear violated one-based offset convention #2573 "Allow failing/skipping Linter bears based on arguments"

   this is about general settings ... for example for linters that only support 2 spaces tabwidth^^ (like some of your issues have required from some bears :D)

[Makman2]

I think it's this one: coala/coala#3950
But it's marked as can't reproduce. Seems like it's reproducible again^^

[meetmangukiya]

@adtac couldn't reproduce, nor was I able to. I had experienced it a few times but didn't report right away

[gaocegege]

re @SanketDG I am not in master, I install the coala from pip. But I could have a try on master soon.

[gaocegege]

Detail

Environment

OS

$ # Ubuntu 16.04
$ uname -a
Linux ist 4.4.0-77-generic #98-Ubuntu SMP Wed Apr 26 08:34:02 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

python

This is a clean environment created via virtualenv -p python3 :

Python 3.5.2

coala

coala is installed from pip:

coala (0.10.0)
coala-bears (0.10.1)

HOWTO reproduce the bug

0. Checkout processing-r/Processing.R@13148dc and uncomment the Java section
1. Run coala. If you could not get the warning message for the first time, change the content in .coafile, for example, add a new line at the end, then you could get it.
2. Run the command again.

[gaocegege]

Log

https://pastebin.com/2W3R8Tvh

EDIT by Makman2:
Moved code snippet into a link so it doesn't blast discussion.

[Makman2]

@gaocegege please retry from latest master (using --pre when installing via pip or install from repo master), so we can see if we have merged some fix meanwhile.

[gaocegege]

@Makman2

Successfully installed coala-0.12.0.dev20170517235947 coala-bears-0.12.0.dev20170518184442 dependency-management-0.4.0 pydocstyle-2.0.0 restructuredtext-lint-1.0.1 unidiff-0.5.3 yamllint-1.6.1

Is it in the master?

Log

https://pastebin.com/Zz2b5vWu

[Makman2]

--pre always contains the latest master :)
Hm but it reappears it seems... Could you flush the cache and try it again?

[gaocegege]

Flushing the cache works, since I reproduce the bug when I run coala twice without the change of coafile.

If the coafile changes, coala will report those warning messages again :)

FYI, it seems that coala -V works well every time.

[DEBUG][22:28:23] Platform Linux -- Python 3.5.2, coalib 0.12.0.dev20170517235947
[DEBUG][22:28:23] Since the configuration settings have changed since the last run, the cache will be flushed and rebuilt.
[DEBUG][22:28:23] The file cache was successfully flushed.

[Makman2]

Alright, @adtac caching is yours ;)
Though I thought that this was fixed :/