-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve split lines with lines #2864
Conversation
why is the test failing again? |
Why spaming everybody by closing and opening new pullrequest? And losing the discussion history by the way ... |
Sorry for that, Matthias already pointed it out to me. |
OK, sorry to blame you again :-) |
Seems the CRS in your reference files and the one produced by running the test on travis don't match. https://travis-ci.org/qgis/QGIS/jobs/113374867#L1294
Plus there are some indentation problems. Best to setup a pre-commit hook to avoid that in the future: |
Hi Matthias, |
In the python file, have a look at the Details link as soon as the test finished for details. But I would really recommend setting up the pre-commit git hook as explained in the link above, it will save you a lot of time. |
When I (manually) run |
Can you do now:
It should bring print a warning that there are indentation problems and correct them for you. If you re-add the file and commit, it should be all fixed and good. |
Better follow the tip on the dash page. The symbolic link is wrong in that forked branch. |
I already tried with autopep (that what you mean, Jürgen?) as proposed there, which resulted in the whole Python file being marked as changed when doing |
Thanks for pointing out @jef-n |
Maybe two empty lines are not allowed? |
ok, seems like the indentation error is fixed now (two consecutive empty lines) |
There is still a mismatch in the CRS |
Yes I have seen that in the test result but why? The CRS is declared in the gfs file and all features carry the CRS information, too. So the question is, why does |
This seems to be related to the .gfs file which is present in your expected data but none of the others. Was this .gfs file produced by processing or a leftover from your save-as approach? It looks as if processing would not create this file and this leads to results end up without a properly specified CRS. I'm still investigating if this is a processing, QGIS or test infrastructure issue. |
Yeah, you are right, looks like a left over (by file date). I will remove and recreate all files in expected and try them as a new commit, ok? |
Yep, that would be good. Can you also limit the coordinate comparison precision (the results I get here are slightly less precise)
|
done both, see what the test result will be |
seems that the test crashes because of the proposed coordinate precision limitation(?) |
why that? to me it looks like it's still the same CRS issue... Interesting enough a very similar commit fixed things |
because the red cross marks this particular commit but checking the test result shows you are right
How can I improve my PR? |
Not sure, I'll check |
So it seems it's failing for a good reason this time. I have improved debug output for the tests, I'll push this soon. Meanwhile you can already work on fixing the algorithm. Problem description is here: https://travis-ci.org/qgis/QGIS/jobs/115020339#L1316-L1320 |
Hihi, that's the code you proposed the other day :-) |
I get an exception when I run it on QGIS desktop and when I run the tests locally In the build folder :
Just push your changes to this branch, the next results should include the backtrace |
ah, maybe it's because I use QGIS 2.14.0 |
0a5ae6c
to
4980ab7
Compare
Manually merged Thanks a lot for your patience |
any hint why the tests threw errors? |
|
hmm, I deleted the blank line and thought this fixed it, you mean the backslash that you deleted in d6fca7e ? Why is it not allowed?
how can I create them with the test? Any link that explains what one has to do? |
No idea, autopep8 deleted it here and is happy now
https://github.com/qgis/QGIS/blob/master/python/plugins/processing/tests/README.md |
the README says
That's what I did and it is is different from
I do not want to blame you (or anybody else) but as it is now I am reluctant to write more tests (and so are others as the processing tests thread in the dev ML shows). Or would you neverthelesss encourage me to write tests and produce pull requests (with probaly fainling tests) so you can debug? |
The readme also says
didn't you create the output somewhere else and then re-save it or copy it to this location?
As I also said on the thread in the ML: absolutely! I am glad you opened this pull request. As a result I spent quite a bit of time in improving the test infrastructure and now there's better debug output if a test fails. |
No (if I recall correctly) at least in the end I clicked the three-dots button and directly saved the result to testdata/expected as gml
ok, so I will probably add some more tests (at least for the other algorithm I provided)
So how do I proceed with this PR? Shall I delete the branch or leave it as it is? |
Strange, because here it does not create a .gfs file in this case but it does create a .xsd file - not sure if that's actually better but at least it's what succeeds on travis.
👍
The PR is merged and closed, so feel free to delete your branch. |
OK, will see what the next test does |
ok, next PR is ont its way |
No description provided.