Re: [julia-users] @code_warntype and for loops

2015-09-24 Thread Mauro
>> This is the lowered and typed abstract syntax tree that you're seeing,
>> so two steps removed from what you've typed already (and another two
>> steps to go to get to machine code).  Thus it gets more verbose.  I
>> guess it would be nice to translate this typed code back to what you
>> wrote but with type annotations and display that.  But that is not
>> possible (yet?).  Have you seen this short and sweet JuliaCon
>> presentation by Jacob:
>>
>>
>> https://www.youtube.com/watch?v=RYZkHudRTvI=PLP8iPy9hna6Sdx4soiGrSefrmOPdUWixM=16
>>
>
> Yes, you worded better than I could: whether it is possible to get a sort
> of breadth first view of the code. From the nice (and too short, thanks for
> the link) presentation, it seems that this is not possible. Is there any
> hope that the "yet?" will become reality? I understand thought that this
> may be a request from somebody unable to read quickly the output of
> code_typed.

If I understand correctly, this issue is requesting this feature
https://github.com/jakebolewski/JuliaParser.jl/issues/22 . By the sounds
of it, it's not going to happen tomorrow but maybe the day after.


Re: [julia-users] @code_warntype and for loops

2015-09-24 Thread Michele Zaffalon


On Thursday, September 24, 2015 at 9:21:47 AM UTC+2, Mauro wrote:
>
> >> This is the lowered and typed abstract syntax tree that you're seeing, 
> >> so two steps removed from what you've typed already (and another two 
> >> steps to go to get to machine code).  Thus it gets more verbose.  I 
> >> guess it would be nice to translate this typed code back to what you 
> >> wrote but with type annotations and display that.  But that is not 
> >> possible (yet?).  Have you seen this short and sweet JuliaCon 
> >> presentation by Jacob: 
> >> 
> >> 
> >> 
> https://www.youtube.com/watch?v=RYZkHudRTvI=PLP8iPy9hna6Sdx4soiGrSefrmOPdUWixM=16
>  
> >> 
> > 
> > Yes, you worded better than I could: whether it is possible to get a 
> sort 
> > of breadth first view of the code. From the nice (and too short, thanks 
> for 
> > the link) presentation, it seems that this is not possible. Is there any 
> > hope that the "yet?" will become reality? I understand thought that this 
> > may be a request from somebody unable to read quickly the output of 
> > code_typed. 
>
> If I understand correctly, this issue is requesting this feature 
> https://github.com/jakebolewski/JuliaParser.jl/issues/22 . By the sounds 
> of it, it's not going to happen tomorrow but maybe the day after. 
>

Just wow. 


Re: [julia-users] @code_warntype and for loops

2015-09-24 Thread Michele Zaffalon


On Wednesday, September 23, 2015 at 11:06:51 AM UTC+2, Mauro wrote:
>
> > Thank you, Kristoffer. I have read the manual and your post about not 
> > getting carried away by the red == bad assumption 
> > <
> https://groups.google.com/forum/#!searchin/julia-users/@code_warntype$20red$20bad/julia-users/g9O9Ik5OAJA/uSGNDyCDEuEJ>.
>  
>
> > Yet, for a for loop, one would not expect so much output. 
>
> This is the lowered and typed abstract syntax tree that you're seeing, 
> so two steps removed from what you've typed already (and another two 
> steps to go to get to machine code).  Thus it gets more verbose.  I 
> guess it would be nice to translate this typed code back to what you 
> wrote but with type annotations and display that.  But that is not 
> possible (yet?).  Have you seen this short and sweet JuliaCon 
> presentation by Jacob: 
>
>
> https://www.youtube.com/watch?v=RYZkHudRTvI=PLP8iPy9hna6Sdx4soiGrSefrmOPdUWixM=16
>  
>

Yes, you worded better than I could: whether it is possible to get a sort 
of breadth first view of the code. From the nice (and too short, thanks for 
the link) presentation, it seems that this is not possible. Is there any 
hope that the "yet?" will become reality? I understand thought that this 
may be a request from somebody unable to read quickly the output of 
code_typed.


Re: [julia-users] @code_warntype and for loops

2015-09-23 Thread Mauro
> Thank you, Kristoffer. I have read the manual and your post about not
> getting carried away by the red == bad assumption
> .
> Yet, for a for loop, one would not expect so much output.

This is the lowered and typed abstract syntax tree that you're seeing,
so two steps removed from what you've typed already (and another two
steps to go to get to machine code).  Thus it gets more verbose.  I
guess it would be nice to translate this typed code back to what you
wrote but with type annotations and display that.  But that is not
possible (yet?).  Have you seen this short and sweet JuliaCon
presentation by Jacob:

https://www.youtube.com/watch?v=RYZkHudRTvI=PLP8iPy9hna6Sdx4soiGrSefrmOPdUWixM=16

>
> On Wed, Sep 23, 2015 at 10:05 AM, Kristoffer Carlsson > wrote:
>
>> It can be a bit difficult to read the output from code_warntype. A good
>> heuristic is to just look at the variables on the top and the final return
>> type. If these are concrete then you are fine. If not, then you can look at
>> the messy code in between to find where the instability occurs.
>>
>> For your examples, everything is OK.


[julia-users] @code_warntype and for loops

2015-09-23 Thread Kristoffer Carlsson
It can be a bit difficult to read the output from code_warntype. A good 
heuristic is to just look at the variables on the top and the final return 
type. If these are concrete then you are fine. If not, then you can look at the 
messy code in between to find where the instability occurs. 

For your examples, everything is OK. 

Re: [julia-users] @code_warntype and for loops

2015-09-23 Thread Michele Zaffalon
Thank you, Kristoffer. I have read the manual and your post about not
getting carried away by the red == bad assumption
.
Yet, for a for loop, one would not expect so much output.

On Wed, Sep 23, 2015 at 10:05 AM, Kristoffer Carlsson  wrote:

> It can be a bit difficult to read the output from code_warntype. A good
> heuristic is to just look at the variables on the top and the final return
> type. If these are concrete then you are fine. If not, then you can look at
> the messy code in between to find where the instability occurs.
>
> For your examples, everything is OK.