The line location code should be fixed now. On Thu, Nov 20, 2014 at 12:50 AM, Tomas Krehlik <tomas.kreh...@gmail.com> wrote:
> I just stumbled upon this post, I have the linter working in sublime for > some time, trying it from time to time. Often it gets wrong lines, etc, but > I guess it is going to improve as well as the time needed to actually do > the lint. (About 10s because julia needs to start up.) Anyway, if anybody > wants to give it a try here is a link > https://gist.github.com/tomaskrehlik/0e8b65d48e2b4f9af85d > > Best, > T. > > On Monday, 15 September 2014 17:36:31 UTC+2, Tomas Lycken wrote: >> >> Jacob, >> >> I recently got my eyes on integrating this with in ST somehow too, so let >> me know if I can help (I'm @tlycken at github). I was thinking that >> integration through SublimeLinter (http://www.sublimelinter.com/ >> en/latest/) might be a good way to do it, but I haven't had time to look >> further into it. >> >> // Tomas >> >> On Monday, September 15, 2014 8:04:07 AM UTC+2, Tony Fong wrote: >>> >>> Jacob, Mike, >>> >>> I just made a 2-line change to help you with that. You can do (block of >>> code as text) + (file/line info) -> Array( LintMessage,1 ) >>> >>> using Lint >>> ctx = LintContext() >>> ctx.file = file >>> ctx.path = path # optional, to direct include() correctly >>> msgs = lintstr( code, ctx, lineoffset ) # lineoffset is how you shift >>> from the relative line of the code to actual >>> >>> On module, however, this is tricky. Some of the Lint code needs to have >>> the whole module code in place to work, such as duplicated export, import >>> using relative path (import .Show). I'd recommend that when you care about >>> those Lint warnings you'd do a lint on the entire module file. I hope it >>> isn't too bad of a restriction that meanwhile you still get most of the >>> "local-level" lint functionality. >>> >>> Tony >>> >>> On Monday, September 15, 2014 6:33:59 AM UTC+7, Mike Innes wrote: >>>> >>>> We can get really nice integration for Lint.jl and Light Table – I've >>>> actually already got some of the GUI parts worked out, so it won't be crazy >>>> difficult to do. >>>> >>>> Quick question: How's Lint.jl's support for modules? For LT it's pretty >>>> essential that the API looks like (block of code as text) + (file/line >>>> info) + (module) => (warnings/errors). Of course, it's fine if I can >>>> wrap Lint.jl's existing functionality to have that, but current AFAICT it >>>> currently only works in terms of whole files. >>>> >>>> On Sunday, 14 September 2014 01:12:49 UTC-4, Viral Shah wrote: >>>>> >>>>> I wonder if these can be integrated into LightTable and IJulia, so >>>>> that they always automatically are running in the background on all code >>>>> one writes. >>>>> >>>>> -viral >>>>> >>>>> On Sunday, September 14, 2014 8:38:09 AM UTC+5:30, Spencer Russell >>>>> wrote: >>>>>> >>>>>> Any comments on how Lint.jl and @astrieanna's also-awesome >>>>>> TypeCheck.jl relate? Are you two working together, or are there different >>>>>> use cases for the two libraries? >>>>>> >>>>>> >>>>>> peace, >>>>>> s >>>>>> >>>>>> On Sat, Sep 13, 2014 at 3:34 PM, Tony Fong <tony.h...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Fellow Julians, >>>>>>> >>>>>>> I think it is time to post an update on Lint.jl >>>>>>> <https://github.com/tonyhffong/Lint.jl>, as it has improved quite a >>>>>>> bit from the initial version I started about 3 months ago. >>>>>>> >>>>>>> Notable new features >>>>>>> >>>>>>> - Local variable type tracking, which enables a range of >>>>>>> features, such as >>>>>>> - Variable type stability warning within a function scope. >>>>>>> - Incompatibility between type assertion and assignment >>>>>>> - Omission of returning the constructed object in a type >>>>>>> constructor >>>>>>> - Check the call signature of a selected set of methods with >>>>>>> collection (push!, append!, etc.) >>>>>>> - More function checks, such as >>>>>>> - repeated arguments >>>>>>> - wrong signatures, e.g. f( x::Array{Number,1} ) >>>>>>> - Mispelled constructor (calls new but the function name >>>>>>> doesn't match the enclosing type) >>>>>>> - Ability to silence lint warning via lintpragma() function, e.g. >>>>>>> - lintpragma( "Ignore unstable type variable [variable name]" >>>>>>> ) >>>>>>> - lintpragma( "Ignore Unused [variable name]" ) >>>>>>> >>>>>>> Also, there is now quite a range of test scripts showing sample >>>>>>> codes with lint problems, so it's easy to grep your own lint warnings in >>>>>>> that folder and see a distilled version of the issue. >>>>>>> >>>>>>> Again, please let me know about gaps and false positives. >>>>>>> >>>>>>> Tony >>>>>>> >>>>>> >>>>>>
