Re: [julia-users] Lint.jl status update

[Tim Holy]

Wow, this is really impressive. I'm going to have to take a close look again.

What do you mean below about "wrong signatures"? That signature looks correct 
to me, albeit not very useful and probably not what the programmer intended.

--Tim

On Saturday, September 13, 2014 12:34:44 PM Tony Fong wrote:
> Fellow Julians,
> 
> I think it is time to post an update on 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

Re: [julia-users] Lint.jl status update

[Tony Fong]

I think a container type with a non-leaf eltype won't match anything. The 
right way to declare such a function should be instead

function f{T<:Number}( x::Array{T,1} )
...
end


On Sunday, September 14, 2014 5:09:39 AM UTC+7, Tim Holy wrote:
>
> Wow, this is really impressive. I'm going to have to take a close look 
> again. 
>
> What do you mean below about "wrong signatures"? That signature looks 
> correct 
> to me, albeit not very useful and probably not what the programmer 
> intended. 
>
> --Tim 
>
> On Saturday, September 13, 2014 12:34:44 PM Tony Fong wrote: 
> > Fellow Julians, 
> > 
> > I think it is time to post an update on 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 
>
>

Re: [julia-users] Lint.jl status update

[Keno Fischer]

It's callable, but probably not what you want:

julia> f(A::Vector{Number}) = println(A)
f (generic function with 1 method)

julia> f(Number[1.0; 1])
Number[1.0,1]

On Sat, Sep 13, 2014 at 9:51 PM, Tony Fong  wrote:
> I think a container type with a non-leaf eltype won't match anything. The
> right way to declare such a function should be instead
>
> function f{T<:Number}( x::Array{T,1} )
> ...
> end
>
>
> On Sunday, September 14, 2014 5:09:39 AM UTC+7, Tim Holy wrote:
>>
>> Wow, this is really impressive. I'm going to have to take a close look
>> again.
>>
>> What do you mean below about "wrong signatures"? That signature looks
>> correct
>> to me, albeit not very useful and probably not what the programmer
>> intended.
>>
>> --Tim
>>
>> On Saturday, September 13, 2014 12:34:44 PM Tony Fong wrote:
>> > Fellow Julians,
>> >
>> > I think it is time to post an update on 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
>>
>

Re: [julia-users] Lint.jl status update

[Tony Fong]

Right, the correct way to say this should be Array{Number,1} in a function 
signature would not match an input of Array{Int,1} etc. so in your example 
if I do
julia> f( [1,2] )
ERROR: `f` has no method matching f(::Array{Int64,1})

Anyway, Lint catches that.

On Sunday, September 14, 2014 8:55:02 AM UTC+7, Keno Fischer wrote:
>
> It's callable, but probably not what you want: 
>
> julia> f(A::Vector{Number}) = println(A) 
> f (generic function with 1 method) 
>
> julia> f(Number[1.0; 1]) 
> Number[1.0,1] 
>
> On Sat, Sep 13, 2014 at 9:51 PM, Tony Fong  > wrote: 
> > I think a container type with a non-leaf eltype won't match anything. 
> The 
> > right way to declare such a function should be instead 
> > 
> > function f{T<:Number}( x::Array{T,1} ) 
> > ... 
> > end 
> > 
> > 
> > On Sunday, September 14, 2014 5:09:39 AM UTC+7, Tim Holy wrote: 
> >> 
> >> Wow, this is really impressive. I'm going to have to take a close look 
> >> again. 
> >> 
> >> What do you mean below about "wrong signatures"? That signature looks 
> >> correct 
> >> to me, albeit not very useful and probably not what the programmer 
> >> intended. 
> >> 
> >> --Tim 
> >> 
> >> On Saturday, September 13, 2014 12:34:44 PM Tony Fong wrote: 
> >> > Fellow Julians, 
> >> > 
> >> > I think it is time to post an update on 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 
> >> 
> > 
>

Re: [julia-users] Lint.jl status update

[Spencer Russell]

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  wrote:

> Fellow Julians,
>
> I think it is time to post an update on 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
>

Re: [julia-users] Lint.jl status update

[Viral Shah]

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  wrote:
>
>> Fellow Julians,
>>
>> I think it is time to post an update on 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
>>
>
>

Re: [julia-users] Lint.jl status update

[Tony Fong]

That's a good question. They can be used together, obviously. I can easily 
speak for Lint. The key trade-off made in Lint is that it does not strive 
for very in-depth type analysis. The focus is finding dodgy AST, where it 
is located in the source file, and with a bit of explanation around issues. 
The analyses are done recursively in a very small neighborhood around each 
node in the AST, although the locality issue has improved somewhat with the 
new type-tracking ability. The "type guessing and tracking" could leverage 
Typecheck.jl, only possible since about last week (with the new features), 
and it's a very exciting prospect.

Lint already provides functionality to return an array of lint messages 
(from a file, a code snippet, or a module), so it could be used in IDE 
integration I suppose.

Tony

On Sunday, September 14, 2014 10:08:09 AM UTC+7, 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  > wrote:
>
>> Fellow Julians,
>>
>> I think it is time to post an update on 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
>>
>
>

Re: [julia-users] Lint.jl status update

[Adam Smith]

This looks awesome. Regarding the Array parameter issue (which I'm really 
glad to see in the linter; this issue really tripped me up when learning 
Julia), if https://github.com/JuliaLang/julia/issues/6984 ever finds a 
resolution, it would be great to suggest that new syntax in the lint 
message. Then if the linter becomes common-place, beginners that have never 
heard of type variance will have a path to understanding.

On Sunday, September 14, 2014 1:38:50 AM UTC-4, Tony Fong wrote:
>
> That's a good question. They can be used together, obviously. I can easily 
> speak for Lint. The key trade-off made in Lint is that it does not strive 
> for very in-depth type analysis. The focus is finding dodgy AST, where it 
> is located in the source file, and with a bit of explanation around issues. 
> The analyses are done recursively in a very small neighborhood around each 
> node in the AST, although the locality issue has improved somewhat with the 
> new type-tracking ability. The "type guessing and tracking" could leverage 
> Typecheck.jl, only possible since about last week (with the new features), 
> and it's a very exciting prospect.
>
> Lint already provides functionality to return an array of lint messages 
> (from a file, a code snippet, or a module), so it could be used in IDE 
> integration I suppose.
>
> Tony
>
> On Sunday, September 14, 2014 10:08:09 AM UTC+7, 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  wrote:
>>
>>> Fellow Julians,
>>>
>>> I think it is time to post an update on 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
>>>
>>
>>

Re: [julia-users] Lint.jl status update

[Jacob Quinn]

I've definitely been meaning to work on integrating this with
Sublime-IJulia. Hopefully in the next week or so.

-Jacb

On Sun, Sep 14, 2014 at 10:19 AM, Adam Smith 
wrote:

> This looks awesome. Regarding the Array parameter issue (which I'm really
> glad to see in the linter; this issue really tripped me up when learning
> Julia), if https://github.com/JuliaLang/julia/issues/6984 ever finds a
> resolution, it would be great to suggest that new syntax in the lint
> message. Then if the linter becomes common-place, beginners that have never
> heard of type variance will have a path to understanding.
>
>
> On Sunday, September 14, 2014 1:38:50 AM UTC-4, Tony Fong wrote:
>>
>> That's a good question. They can be used together, obviously. I can
>> easily speak for Lint. The key trade-off made in Lint is that it does not
>> strive for very in-depth type analysis. The focus is finding dodgy AST,
>> where it is located in the source file, and with a bit of explanation
>> around issues. The analyses are done recursively in a very small
>> neighborhood around each node in the AST, although the locality issue has
>> improved somewhat with the new type-tracking ability. The "type guessing
>> and tracking" could leverage Typecheck.jl, only possible since about last
>> week (with the new features), and it's a very exciting prospect.
>>
>> Lint already provides functionality to return an array of lint messages
>> (from a file, a code snippet, or a module), so it could be used in IDE
>> integration I suppose.
>>
>> Tony
>>
>> On Sunday, September 14, 2014 10:08:09 AM UTC+7, 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  wrote:
>>>
 Fellow Julians,

 I think it is time to post an update on 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

>>>
>>>

Re: [julia-users] Lint.jl status update

[Mike Innes]

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 > > wrote:
>>
>>> Fellow Julians,
>>>
>>> I think it is time to post an update on 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
>>>
>>
>>

Re: [julia-users] Lint.jl status update

[Tony Fong]

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  wrote:
>>>
 Fellow Julians,

 I think it is time to post an update on 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

>>>
>>>

Re: [julia-users] Lint.jl status update

[Tomas Lycken]

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  wrote:

> Fellow Julians,
>
> I think it is time to post an update on 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
>

Re: [julia-users] Lint.jl status update

[Patrick O'Leary]

On Sunday, September 14, 2014 12:12:49 AM UTC-5, 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.
>

For Emacs users, I threw together a Flycheck extension for Lint.jl:

https://gist.github.com/pao/e65029bf88650e592929

Note that if the `julia` executable is not on your path, you need to 
customize--*not* setq--the variable `flycheck-julia-lint-executable`; if 
you try to use setq it just goes buffer-local. I have no idea why Flycheck 
is designed that way.

Re: [julia-users] Lint.jl status update

[Tony Fong]

This is so cool.

On Thursday, September 18, 2014 11:43:38 AM UTC+7, Patrick O'Leary wrote:
>
> On Sunday, September 14, 2014 12:12:49 AM UTC-5, 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.
>>
>
> For Emacs users, I threw together a Flycheck extension for Lint.jl:
>
> https://gist.github.com/pao/e65029bf88650e592929
>
> Note that if the `julia` executable is not on your path, you need to 
> customize--*not* setq--the variable `flycheck-julia-lint-executable`; if 
> you try to use setq it just goes buffer-local. I have no idea why Flycheck 
> is designed that way.
>

Re: [julia-users] Lint.jl status update

[Patrick O'Leary]

It was shockingly easy once I figured out how to get the bleepin regex to 
work. And how to use rx syntax.

On Thursday, September 18, 2014 12:29:46 AM UTC-5, Tony Fong wrote:
>
> This is so cool.
>
> On Thursday, September 18, 2014 11:43:38 AM UTC+7, Patrick O'Leary wrote:
>>
>> On Sunday, September 14, 2014 12:12:49 AM UTC-5, 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.
>>>
>>
>> For Emacs users, I threw together a Flycheck extension for Lint.jl:
>>
>> https://gist.github.com/pao/e65029bf88650e592929
>>
>> Note that if the `julia` executable is not on your path, you need to 
>> customize--*not* setq--the variable `flycheck-julia-lint-executable`; if 
>> you try to use setq it just goes buffer-local. I have no idea why Flycheck 
>> is designed that way.
>>
>

Re: [julia-users] Lint.jl status update

[Tomas Krehlik]

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  
> wrote:
>
>> Fellow Julians,
>>
>> I think it is time to post an update on 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
>>
>
>

Re: [julia-users] Lint.jl status update

[Tony Fong]

The line location code should be fixed now.

On Thu, Nov 20, 2014 at 12:50 AM, Tomas Krehlik 
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 
>> wrote:
>>
>>> Fellow Julians,
>>>
>>> I think it is time to post an update on 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
>>>
>>
>>