These are chat archives for coala/coala-bears
@jayvdb Regarding https://github.com/coala/coala-bears/pull/2316/files/4aad1ae6216cddef5d61644c114543842abd3f75#diff-f5c369821ed5f2660ab333edc21ed4c7 I did something terribly wrong in haste. Perhaps setting should be something like
include_filters: typed_list(str) = None,
if not include_filters: args += ('--filter=' + ','.join(include_filters),)
+. I think we talked about that when you first created your PR. that still hasnt been resolved.
bad_file_mixes_case. The invalid files I am using for my issues are working fine.
why do you think it doesn’t make sense, and doesn’t align with coala’s concepts?
It would be a special case in our core to handle a new kind of parallelization with special support to internally pass results. The idea is to be very generic with that to allow any level of parallelization. And when we would introduce job queues for each file, what if we don't need that only for files, but other data structures/resources as well? This becomes so super special now that at least I don't see a concise concept where someone would say "yes, I understand why and what it does" when reading the code.
Is there a concept of priority now? The bears could run in any order, considering the dependencies.
No, so only dependencies control execution order currently (and the executor).
I don’t see a problem. Why wouldn’t it work the same way as now as if
--jobsis set to 1?
I'm getting confused. I thought if you want to avoid conflicts by applying multiple bears that have to work on a single file one by one. So that is a problem. Currently we already parallelize on a per-file basis (if possible), but bears emit results/patches independently from their results so they can be executed in parallel, even when working on a single file.
coala/baseimage (just tested)