Multithreaded parsing error should be warning about csv.jl HOT 7 CLOSED

DKWinners_20230603.csv

sure, here is an example of such a CSV. these are results from sports betting contests. let me know if it helps!

from csv.jl.

cc: @Liozou

from csv.jl.

Thank you for reporting this! Would it be possible for you to share the offending CSV?

I put this as an error precisely to get this kind CSVs reported here. There should indeed be no apparent issue/crash since a fallback was implemented, but it signals a possible mistake in the code and in any case it causes a severe performance drop for CSV parsing (since it falls back to a single thread).
I guess it should be displayed as a warning instead of an error when we can internally check that the cause of this is well-known (i.e. newlines inside quoted fields) and there is nothing more to be done than let the user know of the expected performance loss.

from csv.jl.

The root issue is that starting from line 30 (Gummypecs (2/3)), each line only contains 10 columns instead of 12, i.e. there should be two more commas at the end of each line. But the @error message is quite misleading here I agree, I'll try to fix that.

from csv.jl.

cool! thank you for the quick responses

from csv.jl.

btw this is not fixed for me :)

maybe it is because I set silencewarnings = true, so it is never true that numwarnings[] > 0 ?

from csv.jl.

I think this is just because the latest released version of CSV.jl does not include the bugfix. You can try to ]dev CSV just to check that the bug is indeed fixed. @quinnj would you mind tagging a new patch version?
Otherwise, in the code, both versions of the warnings are under the condition that !ctx.silencewarnings so nothing should appear, unless I'm missing something...

from csv.jl.