Link to the error does not work

[bmaschio]

@fmontesi

linter works fine and it highlights the correct error

yet when i double click on the link

it does not open the correct file but instead it opens a new empty file atom application directory

I think this is due to the fact that the path is expressed in relative terms

[fmontesi]

Can you reproduce this in other OSs? It works fine in my MacOS laptop.

On Wed, Apr 27, 2016 at 9:19 AM, Balint Maschio notifications@github.com wrote:

@fmontesi https://github.com/fmontesi

linter works fine and it highlights the correct error

[image: image] https://cloud.githubusercontent.com/assets/12083716/14844588/a9c0d514-0c58-11e6-9c90-260ca1767a2b.png

yet when i double click on the link

it does not open the correct file but instead it opens a new empty file atom application directory

[image: image] https://cloud.githubusercontent.com/assets/12083716/14844635/06386582-0c59-11e6-8f38-3f4b5a4dd1b4.png

I think this is due to the fact that the path is expressed in relative terms

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/fmontesi/linter-jolie/issues/5

[bmaschio]

No unfortunately

yet I add a log to the code

and it seems to have the correct file

I think it maybe a problem at level of Issue reporting
I also noticed that on the original file is not highlighted like in the case of any other language

tnks

[bmaschio]

on the linter own tool the error are reported in this way

  transform = ({level, message, rule, lineNumber, context, column}) ->
    message = "#{message}. #{context}" if context
    message = "#{message}. (#{rule})";

    # Calculate range to make the error whole line
    # without the indentation at begining of line
    indentLevel = TextEditor.indentationForBufferRow(lineNumber - 1)

    startCol = (TextEditor.getTabLength() * indentLevel)
    endCol = TextBuffer.lineLengthForRow(lineNumber - 1)

    range = [[lineNumber - 1, startCol], [lineNumber - 1, endCol]]

    return {
      type: if level is 'error' then 'Error' else 'Warning'
      text: message
      filePath: filePath
      range: range
    }

[fmontesi]

Not sure what's the difference, helpers.exec should be doing the same thing (but I haven't checked).

On Wed, Apr 27, 2016 at 2:40 PM, Balint Maschio notifications@github.com wrote:

on the linter own tool the error are reported in this way

transform = ({level, message, rule, lineNumber, context, column}) -> message = "#{message}. #{context}" if context message = "#{message}. (#{rule})";

# Calculate range to make the error whole line
# without the indentation at begining of line
indentLevel = TextEditor.indentationForBufferRow(lineNumber - 1)

startCol = (TextEditor.getTabLength() * indentLevel)
endCol = TextBuffer.lineLengthForRow(lineNumber - 1)

range = [[lineNumber - 1, startCol], [lineNumber - 1, endCol]]

return {
  type: if level is 'error' then 'Error' else 'Warning'
  text: message
  filePath: filePath
  range: range
}

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/fmontesi/linter-jolie/issues/5#issuecomment-215069333

[bmaschio]

@fmontesi

I think I may have found out the reason why it does not not work i thinkis a question of the regular expression used to parse the message I was wandering why also it is present / on the start of the file path could be somenthing to to with linux Caused by: jolie.lang.parse.ParserException: /C:/Users/maschio/Documents/GitHub/MongoDBConnector/JolieTest/main_insert_test.ol:48: error: expected }. Found toke n type UNDEF, token content undef

thanks

Balint

[fmontesi]

It's because the filename is basically converted to a URL in Jolie. (Think file://C:/Users/...etc...) That's because some resources that are included may not be in the local filesystem, so we need a uniform representation (offered by URLs).

Maybe there's some Javascript API around that can convert it back to what we need in Atom?

[bmaschio]

there is not File under windows jolie.InterpreterException: jolie.lang.parse.ParserException: /C:/Progetti/SVN_D EV/PortaleManutenzioneAndroid/MaintanceService/file:/Progetti/SVN_DEV/PortaleMan utenzioneAndroid/MaintanceService/./public/interfaces/maintanaceServiceInterface .iol:146: error: invalid type: AddMainLineResponse. Found token type COMMA

What if we put the check output into a nice tageted format such XML or into a structured output like JSON? I know is a silly idea

[fmontesi]

How would that help? It would still contain that path written like that, no? The problem seems to be that path string. :-\

[bmaschio]

I suppose in my silly mind it would help making it a bit more readable but yes I agree it would not solve the problem: Why do you think the ParserExpeption has a behavior in linux jolie.InterpreterException: jolie.lang.parse.ParserException: /home/italianasoftware/microservices/testGenerici/testOSCommand.ol:15: error: and one in windows jolie.InterpreterException: jolie.lang.parse.ParserException: /C:/Progetti/Dropb ox/testGenerici/testOSCommand.ol:15: error: expected }

I think i may have found where the problem is in the commandLineParser method GetOLStreamResult where the souce is defined as

result.source = f.toURI().getSchemeSpecificPart();

I did not want do dismantle the code so i did a simple code

        File f = new File ("TestForUri.java").getAbsoluteFile();
        System.out.println(f.getAbsolutePath());
        System.out.println(f.toURI());
        System.out.println(f.toURI().getSchemeSpecificPart());

with the following result

C:\Users\maschio\Documents\NetBeansProjects\TestForUri\TestForUri.java
file:/C:/Users/maschio/Documents/NetBeansProjects/TestForUri/TestForUri.java
/C:/Users/maschio/Documents/NetBeansProjects/TestForUri/TestForUri.java

I am not sure this helps

[fmontesi]

Maybe Atom would understand it better if we passed file: too at the beginning?

Try adding

issue.filePath = "file:" + issue.filePath

Right before the final return return issue in https://github.com/fmontesi/linter-jolie/blob/master/lib/main.coffee

[fmontesi]

If that's the case, then we could change Jolie to give the full URI instead of just the scheme-specific part.

[bmaschio]

Shell I then modify jolie GetOLStreamResult?

[fmontesi]

Depends on what the Atom patch reveals. Have you tried applying the line of code I mentioned in my comment? (issue.filePath = ...)

[bmaschio]

After some serious swearing I have arrived to a script ( coffee script more like heroine script ) that looks like this

helpers = require 'atom-linter'
{ BufferedProcess } = require 'atom'

executablePath = "jolie"
pattern = ".+:\\s*(?<file>[^:]+):\\s*(?<line>\\d+):\\s*(?<type>error|warning)\\s*:(?<message>.+)"

module.exports =
  config: {}

 activate: ->
    require( "atom-package-deps" ).install( "linter-jolie" );

  provideLinter : ->
      parse =  (jolieCheckOuput, textEditor) ->
            return helpers.parse( jolieCheckOuput.stderr, pattern ,{ filePath: textEditor.getPath() } )
                .map ( issue ) ->          
                    [ [ lineStart, colStart ], [ lineEnd, colEnd ] ] = issue.range
                    issue.range = helpers.rangeFromLineNumber textEditor, lineStart, colStart
                    issue.filePath = textEditor.getPath()
                    return issue
      provider =
        grammarScopes: ['source.jolie']
        scope: 'file'
        lintOnFly: true    
        lint: (editor) =>
            filePath = editor.getPath()
            return helpers.exec( executablePath, [ "--check", editor.getPath() ], { stream: "both" } ).then ( data )-> 
                    parse data , editor

that seems to work

then when i click on the link i get the proper file opened and joy more joy i get also

what do you think

[fmontesi]

You're taking the file path from the editor. I suspect that this doesn't work for (errors that come from) included files that you have not currently opened in the editor. Does it?

[bmaschio]

No I had the entire project opened is something to do on how it formats the Path in linux format

[bmaschio]

@fmontesi Shell we talk over skype or handout about this would be nice to have it working for the italian meeting what you think?

[fmontesi]

Absolutely! (Sent you an e-mail.)

On Thu, Nov 10, 2016 at 7:16 PM, Balint Maschio notifications@github.com wrote:

@fmontesi https://github.com/fmontesi Shell we talk over skype or handout about this would be nice to have it working for the italian meeting what you think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fmontesi/linter-jolie/issues/5#issuecomment-259765493, or mute the thread https://github.com/notifications/unsubscribe-auth/AB-xybwodbXPohL4THBtmiVQ8AOE-Aw4ks5q81-EgaJpZM4IQqnK .

[bmaschio]

what mail did you sent it ro i can not find it Thank B

[fmontesi]

Your address at Monrif.

Cheers, Fabrizio

On Fri, Nov 11, 2016 at 10:06 AM, Balint Maschio notifications@github.com wrote:

what mail did you sent it ro i can not find it Thank B

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fmontesi/linter-jolie/issues/5#issuecomment-259913119, or mute the thread https://github.com/notifications/unsubscribe-auth/AB-xyWrwIe-ymPWQwGfg0sYc9FRC5JmRks5q9DAYgaJpZM4IQqnK .

[fmontesi]

Looks like our problem lies in URIParsingContext, in method sourceName. I'm attempting a fix using Paths from the standard library. Will commit soon.

[fmontesi]

Pushed. Can you try? You need to update both Jolie from git and linter-jolie in Atom.

[bmaschio]

@fmontesi Jolie check works fine

but we still have the same problem

it does kill the C:\

[fmontesi]

It's the regular expression in linter-jolie, checking..

[bmaschio]

@fmontesi

the probably the problem in the [^:] this kind of is a problem under windows can we not add some token like <C:\pippo\pluto\paperino.ol> in the output of the url

[fmontesi]

Hi Balint, try now! Update again both linter-jolie and jolie.

[bmaschio]

@fmontesi

with the source file it fantastically well

but with the include files is missing the correct path when using jolie --check filename.ol

C:\Progetti\SVN_DEV\RilevazioneTimbrature\AccountManager\leonardo>jolie --check leonardo.ol jolie.lang.parse.ParserException: \Progetti\SVN_DEV\RilevazioneTimbrature\Accoun tManager\leonardo.\public\interfaces\HttpTimbratureInterface.iol:13: error: exp ected type name. Found token type RCURLY at jolie.lang.parse.AbstractParser.throwException(AbstractParser.java:24 1) at jolie.lang.parse.AbstractParser.assertIdentifier(AbstractParser.java: 210) at jolie.lang.parse.AbstractParser.eatIdentifier(AbstractParser.java:196 ) at jolie.lang.parse.OLParser.parseSubTypes(OLParser.java:303) at jolie.lang.parse.OLParser.parseType(OLParser.java:274) at jolie.lang.parse.OLParser.parseTypes(OLParser.java:245) at jolie.lang.parse.OLParser._parse(OLParser.java:209) at jolie.lang.parse.OLParser.parseInclude(OLParser.java:702) at jolie.lang.parse.OLParser._parse(OLParser.java:202) at jolie.lang.parse.OLParser.parse(OLParser.java:183) at jolie.Interpreter.buildOOIT(Interpreter.java:1220) at jolie.Interpreter.init(Interpreter.java:1033) at jolie.Interpreter.run(Interpreter.java:1108) at jolie.Jolie.main(Jolie.java:60)

thanks

Balint

[fmontesi]

Looks like a problem in libjolie, I'll check it tomorrow.

[fmontesi]

I've attempted a fix, but I can't test it on Windows. Please update libjolie and try again.

[bmaschio]

@fmontesi

It works fantastically well great job

It was tested on window 7 professional iwill try it on windows 10 tonight for issue #4 i think you can close this issue

Thanks B

[fmontesi]

Great! :+1: