Skip to content
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

Json format return message for lintserver() #194

Merged
merged 20 commits into from
Mar 7, 2017

Conversation

TeroFrondelius
Copy link
Contributor

@TeroFrondelius TeroFrondelius commented Feb 20, 2017

This pull request is ready.

TODO:

  • server emitter
  • server receiver
  • update documentation
  • update REQUIRE
  • test with linter-julia
  • more testing with linter-julia

See issue #131
Maybe it's ok to list the old issue here to get it closed: #70

@TotalVerb and @davidanthoff your comments / improvement ideas would be appreciated.

Ps. I still haven't learned the git. Now it shows all the commits also for the previous pull request.

@davidanthoff
Copy link

@TeroFrondelius Can you ping me again when this is ready to be reviewed? I don't have much time these days, so would prefer to look at a final version.

@TeroFrondelius
Copy link
Contributor Author

@davidanthoff sure I will ping you again. Now there is only a fundamental question: should I keep as it is, or should I change that all messages are sent as one json. Now: {file: 'none', code: 'E321' ...}, other option: [{file: 'none', code: 'E321' ...}, {file: 'none', code: 'E111' ...}], this second option good side is that it would be already in the format linter is expecting it. I'm just thinking do I gain anything if I have to filter the messages in linter-julia side anyways (like ignoring some error codes).

@davidanthoff
Copy link

I think we would want to go with one JSON that has an array of messages, right?

@TeroFrondelius
Copy link
Contributor Author

@davidanthoff yes this is my second option. Thus you think it's better? I think it should be relatively easy to implement, I just need second opinion, because I haven't decided which one is better.

@davidanthoff
Copy link

Yes, I think that is better, otherwise we need another "protocol" that defines how different JSON messages are combined.

Copy link
Collaborator

@TotalVerb TotalVerb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good contribution! Just a few comments.

src/Lint.jl Outdated
@@ -350,7 +356,54 @@ function lintdir{T<:AbstractString}(dir::T, ctx::LintContext=LintContext())
ctx.messages
end

function readandwritethestream(conn)
function convertmsgtojson(msgs, style)
if style == "LintMessage"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This style is in CamelCase and the others in snake-case; should be made consistent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in the next commit.

src/Lint.jl Outdated
txt = msg.message
file = msg.file
linenumber = msg.line
errorrange = Array[[linenumber, 0], [linenumber, 80]]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't support 0.4 any more so this should be [[linenumber, 0], [linenumber, 80]], i.e. leave out the Array.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See issue #195

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, we can leave this until that is fixed.

src/Lint.jl Outdated
end

function lintserver(port)
function lintserver(port,style)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use default argument; i.e. style="original behavior".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in the next commit.

src/Lint.jl Outdated
@@ -391,6 +449,10 @@ function lintserver(port)
end
end

function lintserver(port)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as above, use default argument instead of this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in the next commit.

@TotalVerb
Copy link
Collaborator

CI is failing on 0.5

test/server.jl Outdated
socket = connect(pipe)
write(socket, json_input * "\n")
json_output = readline(socket)
results_array = JSON.parse(strip(json_output))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't need to strip json, here and elsewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I forgot this one.

src/Lint.jl Outdated
write(conn, "\n")
else
json_data = readline(conn)
dict_data = JSON.parse(json_data)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe you can parse the connection directly; i.e. JSON.parse(conn) instead of JSON.parse(readline(conn)). I recommend that over readline so the client can send newlines in their JSON if they prefer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I really appreciate your effort to review and improve my code.

@TeroFrondelius
Copy link
Contributor Author

I guess CI is failing, because I haven't updated the REQUIRE file to demand JSON dependency. I will add it to next commit.

@coveralls
Copy link

coveralls commented Feb 22, 2017

Coverage Status

Coverage increased (+0.3%) to 86.789% when pulling 39c50f5 on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

@coveralls
Copy link

coveralls commented Feb 22, 2017

Coverage Status

Coverage increased (+0.2%) to 86.68% when pulling a81d069 on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

@coveralls
Copy link

coveralls commented Feb 22, 2017

Coverage Status

Coverage increased (+0.3%) to 86.821% when pulling c5ce694 on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

@coveralls
Copy link

coveralls commented Feb 25, 2017

Coverage Status

Coverage increased (+0.3%) to 86.821% when pulling ddefddb on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

@TeroFrondelius
Copy link
Contributor Author

TeroFrondelius commented Feb 25, 2017

@davidanthoff and @TotalVerb this is ready for the final review.

Few questions:

  1. Is the "vscode" style output ok for now?
  2. Is the documentation clear enough?
  3. Can I build the documentation locally somehow?
  4. Is the git status ok? I tried following, but it didn't help:
git remote add upstream https://github.com/tonyhffong/Lint.jl.git
git checkout master
git fetch upstream
git merge upstream/master
git push

@TeroFrondelius
Copy link
Contributor Author

FYI: here is the linter-julia code version that uses this version: https://github.com/TeroFrondelius/linter-julia/blob/JSON/lib/linter-julia.coffee

@coveralls
Copy link

Coverage Status

Coverage increased (+0.3%) to 86.821% when pulling 343f842 on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage increased (+0.3%) to 86.821% when pulling 343f842 on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

@TeroFrondelius TeroFrondelius mentioned this pull request Feb 26, 2017
@TeroFrondelius
Copy link
Contributor Author

I now have a problem with linter-julia json parsing. I need to study what changed.

@coveralls
Copy link

coveralls commented Feb 27, 2017

Coverage Status

Coverage increased (+0.3%) to 86.821% when pulling 0222c9d on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

Copy link
Collaborator

@TotalVerb TotalVerb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code LGTM now. I just have a few remaining comments about the documentation, which is overall great.

docs/features.md Outdated
The new protocol for the server is JSON in both input and output:
```json
"{
\"file\":\"path_to_the_file\",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a Julia string that happens to contain JSON, not JSON. We should not have the \" and the surrounding "" in the README.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fixed.

docs/features.md Outdated
\"show_code\":true
}"
```
Only the two first `'file'` and `'code_str'` are mandatory fields. For the output
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be "file" and "code_str"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fixed.

docs/features.md Outdated
```
Only the two first `'file'` and `'code_str'` are mandatory fields. For the output
there are four different protocols from which the `"lint-message"` is preferred,
because it is the direct match of `LintMessage` and this way will be always up
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't say it is preferred, because the LintMessage format, while up to date, is subject to change.

docs/features.md Outdated
julia> conn = connect(pipe_lm)
Base.PipeEndpoint(open, 0 bytes waiting)

julia> write(conn, json_input1)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using JSON.print(conn, Dict(...)) in this example would be better.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason this didn't work:

julia> conn = connect(pipe_lm)
Base.PipeEndpoint(open, 0 bytes waiting)

julia> JSON.print(conn, json_input1)
connection ended with error MethodError(getindex,("{\"file\":\"none\",\"code_str\":\"something\"}","file"))

julia> conn = connect(pipe_lm)
Base.PipeEndpoint(open, 0 bytes waiting)

julia> write(conn, json_input1)
38

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the noise. I found my mistake. I will push another commit.

@TeroFrondelius
Copy link
Contributor Author

@TotalVerb thanks, once again, your valuable comments. I will make the changes. If you wouldn't mind taking another look (or even testing) where is my bug. I had this already working with linter-julia, but then I introduced a bug somewhere, which I haven't been able to find. It can be trivial because there are not so many changes between the working commits and non working.

This is the comparison to working version and current, changes in Lint.jl:
TeroFrondelius/Lint.jl@1ccc0e9...TeroFrondelius:JSON

and in linter-julia: AtomLinter/linter-julia@db8daf9...JSON

@TeroFrondelius
Copy link
Contributor Author

I think I found my bug: TeroFrondelius/Lint.jl@a81d069...TeroFrondelius:ddefddb

if haskey(dict_data,"show_code")
    if !dict_data["show_code"]
        msgtext = "$evar: $txt"
    end
else
    msgtext = "$code $evar: $txt"
end

The bug is the case when "show_code" = true

@coveralls
Copy link

coveralls commented Mar 4, 2017

Coverage Status

Coverage increased (+0.3%) to 86.778% when pulling 91dd2f0 on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

@coveralls
Copy link

coveralls commented Mar 4, 2017

Coverage Status

Coverage increased (+0.3%) to 86.778% when pulling 175ab5c on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

@coveralls
Copy link

coveralls commented Mar 5, 2017

Coverage Status

Coverage increased (+0.3%) to 86.828% when pulling f814b29 on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

@coveralls
Copy link

coveralls commented Mar 5, 2017

Coverage Status

Coverage increased (+0.3%) to 86.828% when pulling b4593be on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

@TeroFrondelius
Copy link
Contributor Author

@tonyhffong or @Michael-Klassen, I think this is ready for merge. @TotalVerb thanks for your help, please comment if there is still something to do.

@coveralls
Copy link

coveralls commented Mar 5, 2017

Coverage Status

Coverage increased (+0.3%) to 86.828% when pulling 78dfe6c on TeroFrondelius:JSON into f1db4f0 on tonyhffong:master.

Copy link
Collaborator

@TotalVerb TotalVerb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. @tonyhffong @Michael-Klassen This LGTM.

@TotalVerb
Copy link
Collaborator

@TeroFrondelius The merging of #179 has resulted in some merge conflicts; could you resolve those?

@TeroFrondelius
Copy link
Contributor Author

Yes, I will try.

@TeroFrondelius
Copy link
Contributor Author

BTW I changed in REQUIRE: julia 0.5

@TotalVerb
Copy link
Collaborator

For some reason, Travis did not run. Could you try closing and reopening this PR to restart the CI?

@coveralls
Copy link

coveralls commented Mar 7, 2017

Coverage Status

Coverage increased (+0.4%) to 88.912% when pulling 38ccf65 on TeroFrondelius:JSON into 564469e on tonyhffong:master.

@Michael-Klassen Michael-Klassen merged commit 1dfcfd4 into tonyhffong:master Mar 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Lint Server
5 participants