Re: [julia-users] Re: Any 0.5 performance tips?

[Kristoffer Carlsson]

Perhaps you can run, @profile together with ProfileView.jl and compare the two 
julia versions. 

Re: [julia-users] Is there a way to export all functions defined in a module?

[K leo]

Thanks for the reply.

I want to be able to export all symbols of module X from within X.  But 
reexport seems to do something different:

@reexport using X
# all of X's exported symbols available here


On Friday, September 30, 2016 at 9:08:03 AM UTC+8, Erik Schnetter wrote:
>
> Yes; see .
>
> -erik
>
> On Thu, Sep 29, 2016 at 5:35 PM, K leo  
> wrote:
>
>> without retyping all the names.
>>
>
>
>
> -- 
> Erik Schnetter  
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

Re: [julia-users] Re: eval in current scope

[Cedric St-Jean]

Would eval'ing the type inside the macro work? This shows [:x, :y]

macro type_fields(typ)
fields = fieldnames(eval(typ))
@show fields
end

type A
x
y
end

@type_fields A

You can use that to generate the right expansion for that type.

On Thursday, September 29, 2016 at 6:53:01 PM UTC-4, Marius Millea wrote:
>
> I think there's at least once scenario where eval-in-a-macro is not a 
> mistake, mainly when you want to generate some code that depends on 1) some 
> passed in expression and 2) something which can only be known at runtime. 
> Here's my example:
>
> The macro (@self) which I'm writing takes a type name and a function 
> definition, and gives the function a "self" argument of that type and 
> rewrites all occurrences of the type's fields, X, to self.X. Effectively it 
> takes this:
>
> type MyType
> x
> end
>
> @self MyType function inc()
> x += 1
> end
>
> and spits out:
>
> function inc(self::MyType)
> self.x += 1
> end
>
> (if this sounds familiar, its because I've discussed it here before, which 
> spun off this , that I'm 
> currently working on tweaking)
>
>
> To do this my code needs to modify the function expression, but this 
> modification depends on fieldnames(MyType), which can *only* be known at 
> runtime. Hence what I'm doing is, 
>
> macro self(typ,func)
>
> function modify_func(fieldnames)
> # in here I have access to `func` expression *and* 
> `fieldnames(typ)` as evaluated at runtime
> # return modified func expression
> end
>
> quote
> $(esc(:eval))($modify_func(fieldnames($(esc(typ)
> end 
>  
> end
>
> I don't see a cleaner way of doing this, but I'm happy to take 
> suggestions. 
>
> (Btw: my original question was w.r.t. that last "eval', which makes it so 
> that currently this doesn't work on function closures. I'm still processing 
> the several suggestions in this context...)
>
>
> On Tuesday, September 27, 2016 at 5:12:44 PM UTC+2, Steven G. Johnson 
> wrote:
>>
>> On Tuesday, September 27, 2016 at 10:27:59 AM UTC-4, Stefan Karpinski 
>> wrote:
>>>
>>> But note that if you want some piece of f to be "pasted" from the user 
>>> and have access to certain parts of the local state of f, it's probably a 
>>> much better design to let the user pass in a function which f calls, 
>>> passing the function the state that it should have access to:
>>>
>>
>> Right; using "eval" in a function is almost always a mistake, an 
>> indication that you should really be using a higher-order function. 
>> 
>>
>

Re: [julia-users] Re: Any 0.5 performance tips?

[Andrew]

I checked, and my objective function is evaluated exactly as many times 
under 0.4 as it is under 0.5. The number of iterations must be the same.

I also looked at the times more precisely. For one particular function call 
in the code, I have:

0.4 with old code: 6.7s 18.5M allocations
0.4 with 0.5 style code(regular anonymous functions) 11.6s, 141M 
allocations 
0.5: 36.2s, 189M allocations

Surprisingly, 0.4 is still much faster even without the fast anonymous 
functions trick. It doesn't look like 0.5 is generating many more 
allocations than 0.4 on the same code, the time is just a lot slower.

On Thursday, September 29, 2016 at 3:36:46 PM UTC-4, Tim Holy wrote:
>
> No real clue about what's happening, but my immediate thought was that if 
> your algorithm is iterative and uses some kind of threshold to decide 
> convergence, then it seems possible that a change in the accuracy of some 
> computation might lead to it getting "stuck" occasionally due to roundoff 
> error. That's probably more likely to happen because of some kind of 
> worsening rather than some improvement, but either is conceivable.
>
> If that's even a possible explanation, I'd check for unusually-large 
> numbers of iterations and then print some kind of convergence info.
>
> Best,
> --Tim
>
> On Thu, Sep 29, 2016 at 1:21 PM, Andrew  
> wrote:
>
>> In the 0.4 version the above times are pretty consistent. I never observe 
>> any several thousand allocation calls. I wonder if compilation is occurring 
>> repeatedly. 
>>
>> This isn't terribly pressing for me since I'm not currently working on 
>> this project, but if there's an easy fix it would be useful for future work.
>>
>> (sorry I didn't mean to post twice. For some reason hitting spacebar was 
>> interpreted as the post command?)
>>
>>
>> On Thursday, September 29, 2016 at 2:15:35 PM UTC-4, Andrew wrote:
>>>
>>> I've used @code_warntype everywhere I can think to and I've only found 
>>> one Core.box. The @code_warntype looks like this
>>>
>>> Variables:
>>>   #self#::#innerloop#3133{#bellman_obj}
>>>   state::State{IdioState,AggState}
>>>   EVspline::Dierckx.Spline1D
>>>   model::Model{CRRA_Family,AggState}
>>>   policy::PolicyFunctions{Array{Float64,6},Array{Int64,6}}
>>>   OO::NW
>>>   
>>> #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>>
>>> Body:
>>>   begin 
>>>   
>>> #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>>  
>>> = $(Expr(:new, 
>>> ##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj},
>>>  
>>> :(state), :(EVspline), :(model), :(policy), :(OO), 
>>> :((Core.getfield)(#self#,:bellman_obj)::#bellman_obj)))
>>>   SSAValue(0) = 
>>> #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>>   
>>> (Core.setfield!)((Core.getfield)(#self#::#innerloop#3133{#bellman_obj},:obj)::CORE.BOX,:contents,SSAValue(0))::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>>   return SSAValue(0)
>>>   
>>> end::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>>
>>>
>>> I put the CORE.BOX in all caps near the bottom.
>>>
>>> I have no idea if this is actually a problem. The return type is stable. 
>>> Also, this function appears in an outer loop.
>>>
>>> What I noticed putting a @time in places is that in 0.5, occasionally 
>>> calls to my nonlinear equation solver take a really long time, like here:
>>>
>>>   0.069224 seconds (9.62 k allocations: 487.873 KB)
>>>   0.07 seconds (39 allocations: 1.922 KB)
>>>   0.06 seconds (29 allocations: 1.391 KB)
>>>   0.11 seconds (74 allocations: 3.781 KB)
>>>   0.09 seconds (54 allocations: 2.719 KB)
>>>   0.08 seconds (54 allocations: 2.719 KB)
>>>   0.08 seconds (49 allocations: 2.453 KB)
>>>   0.07 seconds (44 allocations: 2.188 KB)
>>>   0.07 seconds (44 allocations: 2.188 KB)
>>>   0.06 seconds (39 allocations: 1.922 KB)
>>>   0.07 seconds (39 allocations: 1.922 KB)
>>>   0.06 seconds (39 allocations: 1.922 KB)
>>>   0.05 seconds (34 allocations: 1.656 KB)
>>>   0.05 seconds (34 allocations: 1.656 KB)
>>>   0.04 seconds (29 allocations: 1.391 KB)
>>>   0.04 seconds (24 allocations: 1.125 KB)
>>>   0.007399 seconds (248 allocations: 15.453 KB)
>>>   0.09 seconds (30 allocations: 1.594 KB)
>>>   0.04 seconds (25 allocations: 1.328 KB)
>>>   0.04 seconds (25 allocations: 1.328 KB)
>>>
>>>   0.10 seconds (70 allocations: 

[julia-users] ANN: CUDAdrv.jl, and CUDA.jl deprecation

[Tim Besard]

Hi all,

CUDAdrv.jl  is Julia wrapper for 
the CUDA driver API -- not to be confused with its counterpart CUDArt.jl 
 which wraps the slightly 
higher-level CUDA runtime API.

The package doesn't feature many high-level or easy-to-use wrappers, but 
focuses on providing the necessary functionality for other packages to 
build upon. For example, CUDArt uses CUDAdrv for launching kernels, while 
CUDAnative (the in-development native programming interface) completely 
relies on CUDAdrv for all GPU interactions.

It features a ccall-like cudacall interface for launching kernels and 
passing values:
using CUDAdrv
using Base.Test

dev = CuDevice(0)
ctx = CuContext(dev)

md = CuModuleFile(joinpath(dirname(@__FILE__), "vadd.ptx"))
vadd = CuFunction(md, "kernel_vadd")

dims = (3,4)
a = round(rand(Float32, dims) * 100)
b = round(rand(Float32, dims) * 100)

d_a = CuArray(a)
d_b = CuArray(b)
d_c = CuArray(Float32, dims)

len = prod(dims)
cudacall(vadd, len, 1, (DevicePtr{Cfloat},DevicePtr{Cfloat},DevicePtr{Cfloat
}), d_a, d_b, d_c)
c = Array(d_c)
@test a+b ≈ c

destroy(ctx)

For documentation, refer to the NVIDIA docs 
. Even though they don't 
fully match what CUDAdrv.jl implements, the package is well tested, and 
redocumenting the entire thing is too much work.

Current master of this package only supports 0.5, but there's a tagged 
version supporting 0.4 (as CUDArt.jl does so as well). It has been tested 
on CUDA 5.0 up to 8.0, but there might always be issues with certain 
versions (as the wrappers aren't auto-generated, and probably will never be 
due to how NVIDIA has implemented cuda.h)

Anybody thinking there's a lot of overlap between CUDArt and CUDAdrv is 
completely right, but it mimics the overlap between CUDA's runtime and 
driver APIs as in some cases we do specifically need one or the other (eg., 
CUDAnative wouldn't work with only the runtime API). There's also some 
legacy at the Julia side: CUDAdrv.jl is based on CUDA.jl, while CUDArt.jl 
has been an independent effort.


In other news, we have recently *deprecated the old CUDA.jl package*. All 
users should now use either CUDArt.jl or CUDAdrv.jl, depending on what 
suits them best. Neither is a drop-in replacement, but the changes should 
be minor. At the very least, users will have to change the kernel launch 
syntax, which should use cudacall as shown above. In the future, we might 
re-use the CUDA.jl package name for the native programming interface 
currently at CUDAnative.jl


Best,
Tim

Re: [julia-users] Is there a way to export all functions defined in a module?

[Erik Schnetter]

Yes; see .

-erik

On Thu, Sep 29, 2016 at 5:35 PM, K leo  wrote:

> without retyping all the names.
>



-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

[julia-users] Julia-i18n logo proposal

[Waldir Pimenta]

Hi all. I made a proposal for the logo for the Julia-i18n organization: 
http://imgh.us/julia-i18n_1.svg

It uses the three most used scripts worldwide, and the characters are 
actually the start of the word “Julia” as written in each of those scripts.

Looking forward to know what you guys think.

--Waldir

Re: [julia-users] Re: eval in current scope

[Marius Millea]

I think there's at least once scenario where eval-in-a-macro is not a 
mistake, mainly when you want to generate some code that depends on 1) some 
passed in expression and 2) something which can only be known at runtime. 
Here's my example:

The macro (@self) which I'm writing takes a type name and a function 
definition, and gives the function a "self" argument of that type and 
rewrites all occurrences of the type's fields, X, to self.X. Effectively it 
takes this:

type MyType
x
end

@self MyType function inc()
x += 1
end

and spits out:

function inc(self::MyType)
self.x += 1
end

(if this sounds familiar, its because I've discussed it here before, which 
spun off this , that I'm 
currently working on tweaking)


To do this my code needs to modify the function expression, but this 
modification depends on fieldnames(MyType), which can *only* be known at 
runtime. Hence what I'm doing is, 

macro self(typ,func)

function modify_func(fieldnames)
# in here I have access to `func` expression *and* 
`fieldnames(typ)` as evaluated at runtime
# return modified func expression
end

quote
$(esc(:eval))($modify_func(fieldnames($(esc(typ)
end 
 
end

I don't see a cleaner way of doing this, but I'm happy to take suggestions. 

(Btw: my original question was w.r.t. that last "eval', which makes it so 
that currently this doesn't work on function closures. I'm still processing 
the several suggestions in this context...)


On Tuesday, September 27, 2016 at 5:12:44 PM UTC+2, Steven G. Johnson wrote:
>
> On Tuesday, September 27, 2016 at 10:27:59 AM UTC-4, Stefan Karpinski 
> wrote:
>>
>> But note that if you want some piece of f to be "pasted" from the user 
>> and have access to certain parts of the local state of f, it's probably a 
>> much better design to let the user pass in a function which f calls, 
>> passing the function the state that it should have access to:
>>
>
> Right; using "eval" in a function is almost always a mistake, an 
> indication that you should really be using a higher-order function. 
> 
>

Re: [julia-users] Re: translating julia

[Ismael Venegas Castelló]

Hello Henri!

Just a question, you are aishenri in GitHub right? Because I answered this 
same question at julia-i18n chat room at Gitter, just want to make sure, I 
don't want to leave any question unanswered.


   - https://gitter.im/JuliaLangEs/julia-i18n?at=57ed5568be5dec755007a21c
   

Cheers
Ismael Venegas Castelló


El jueves, 29 de septiembre de 2016, 2:19:46 (UTC-5), Henri Girard escribió:
>
> Hi Ismael,
>
> I would like to translate "home" first,  but I noticed it's difficult to 
> find all text about it ?
>
> Is there a way to research a precise text ?
>
> I already translated a good part of it but I need to see it so that I can 
> be sûre of that.
>
>
> Best
> Henri
> Le 28/09/2016 à 11:54, henri@gmail.com  a écrit :
>
> I am wondering if one must write the html mark when translating ?
>
> Le 28/09/2016 à 10:26, Ismael Venegas Castelló a écrit :
>
> Hello Henri! 
>
> Currently French is about 0% translated, we are adding to production the 
> languages that at minimum have the home page translated 90 %, but you can 
> see the current progress of all the languages in the staging site here:
>
>
>- http://julialanges.github.io
>
> You can see here a video I did tonight, were I am translating, in order to 
> give a taste of the workflow involved in doing this with Transifex Live.
>
> Please let me know if you have any doubt and I will gladly help you as 
> much as I can and thank you very much for your interest and support to this 
> project.
>
> Cheers,
> Ismael Venegas Castelló
>
> El miércoles, 28 de septiembre de 2016, 2:49:32 (UTC-5), Henri Girard 
> escribió: 
>>
>> I went to french translation startet to translate but can't see it on 
>> julialang.org ? 
>> it's not actualized ?
>> Regards
>>
>
>
>

[julia-users] Is there a way to export all functions defined in a module?

[K leo]

without retyping all the names.

[julia-users] copying package repository for update to 0.5

[Tony Kelman]

A number of packages end up storing absolute paths in generated files. You'll 
likely need to re-run Pkg.build().

[julia-users] copying package repository for update to 0.5

[Milton Huang]

Hi,

I am excited about the new update to Julia to 0.5, but I have a question.  
I have about 1.5 Gib of packages in my .julia/v0.4 package repository.  Are 
there any problems with just copying the whole group over to the v0.5 
folder to make all the packages available instead of Pkg.add-ing them 
individually?  I started with the later just to see if I could clean out 
packages I don't use anymore, but I remember going through lots of Compat 
problems with particular code tweaks I did before...  Comments?

-milton

Re: [julia-users] Re: Problem with julia-0.5 on Gentoo

[Tony Kelman]

Okay, the buildbot that was down was running centos which is failing some 
of the tests due to this very change. We need to come up with a good fix 
for the certificates location lookup issue on non-debian-based 
distributions (https://github.com/JuliaLang/julia/issues/18693) before new 
nightlies will get published.


On Thursday, September 29, 2016 at 12:11:18 PM UTC-7, Tony Kelman wrote:
>
> nighties were a few days behind, I needed to log in and reconnect a few of 
> the buildbots. Check in a few hours if the nightlies are dated with commits 
> from today.

Re: [julia-users] Re: Any 0.5 performance tips?

[Tim Holy]

No real clue about what's happening, but my immediate thought was that if
your algorithm is iterative and uses some kind of threshold to decide
convergence, then it seems possible that a change in the accuracy of some
computation might lead to it getting "stuck" occasionally due to roundoff
error. That's probably more likely to happen because of some kind of
worsening rather than some improvement, but either is conceivable.

If that's even a possible explanation, I'd check for unusually-large
numbers of iterations and then print some kind of convergence info.

Best,
--Tim

On Thu, Sep 29, 2016 at 1:21 PM, Andrew  wrote:

> In the 0.4 version the above times are pretty consistent. I never observe
> any several thousand allocation calls. I wonder if compilation is occurring
> repeatedly.
>
> This isn't terribly pressing for me since I'm not currently working on
> this project, but if there's an easy fix it would be useful for future work.
>
> (sorry I didn't mean to post twice. For some reason hitting spacebar was
> interpreted as the post command?)
>
>
> On Thursday, September 29, 2016 at 2:15:35 PM UTC-4, Andrew wrote:
>>
>> I've used @code_warntype everywhere I can think to and I've only found
>> one Core.box. The @code_warntype looks like this
>>
>> Variables:
>>   #self#::#innerloop#3133{#bellman_obj}
>>   state::State{IdioState,AggState}
>>   EVspline::Dierckx.Spline1D
>>   model::Model{CRRA_Family,AggState}
>>   policy::PolicyFunctions{Array{Float64,6},Array{Int64,6}}
>>   OO::NW
>>   #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1
>> D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,
>> 6},Array{Int64,6}},NW,#bellman_obj}
>>
>> Body:
>>   begin
>>   #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1
>> D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,
>> 6},Array{Int64,6}},NW,#bellman_obj} = $(Expr(:new,
>> ##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model
>> {CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},
>> Array{Int64,6}},NW,#bellman_obj}, :(state), :(EVspline), :(model),
>> :(policy), :(OO), :((Core.getfield)(#self#,:bellman_obj)::#bellman_obj)))
>>   SSAValue(0) = #3130::##3130#3134{State{IdioS
>> tate,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},
>> PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>>   (Core.setfield!)((Core.getfield)(#self#::#innerloop#3133{#
>> bellman_obj},:obj)::CORE.BOX,:contents,SSAValue(0))::##3130#
>> 3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_
>> Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#
>> bellman_obj}
>>   return SSAValue(0)
>>   end::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,
>> Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,
>> 6},Array{Int64,6}},NW,#bellman_obj}
>>
>>
>> I put the CORE.BOX in all caps near the bottom.
>>
>> I have no idea if this is actually a problem. The return type is stable.
>> Also, this function appears in an outer loop.
>>
>> What I noticed putting a @time in places is that in 0.5, occasionally
>> calls to my nonlinear equation solver take a really long time, like here:
>>
>>   0.069224 seconds (9.62 k allocations: 487.873 KB)
>>   0.07 seconds (39 allocations: 1.922 KB)
>>   0.06 seconds (29 allocations: 1.391 KB)
>>   0.11 seconds (74 allocations: 3.781 KB)
>>   0.09 seconds (54 allocations: 2.719 KB)
>>   0.08 seconds (54 allocations: 2.719 KB)
>>   0.08 seconds (49 allocations: 2.453 KB)
>>   0.07 seconds (44 allocations: 2.188 KB)
>>   0.07 seconds (44 allocations: 2.188 KB)
>>   0.06 seconds (39 allocations: 1.922 KB)
>>   0.07 seconds (39 allocations: 1.922 KB)
>>   0.06 seconds (39 allocations: 1.922 KB)
>>   0.05 seconds (34 allocations: 1.656 KB)
>>   0.05 seconds (34 allocations: 1.656 KB)
>>   0.04 seconds (29 allocations: 1.391 KB)
>>   0.04 seconds (24 allocations: 1.125 KB)
>>   0.007399 seconds (248 allocations: 15.453 KB)
>>   0.09 seconds (30 allocations: 1.594 KB)
>>   0.04 seconds (25 allocations: 1.328 KB)
>>   0.04 seconds (25 allocations: 1.328 KB)
>>
>>   0.10 seconds (70 allocations: 3.719 KB)
>>   0.072703 seconds (41.74 k allocations: 1.615 MB)
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thursday, September 29, 2016 at 1:37:18 AM UTC-4, Kristoffer Carlsson
>> wrote:
>>>
>>> Look for Core.Box in @code_warntype. See https://github.com/JuliaLang/j
>>> ulia/issues/15276
>>
>>

Re: [julia-users] Re: Problem with julia-0.5 on Gentoo

[Tony Kelman]

nighties were a few days behind, I needed to log in and reconnect a few of the 
buildbots. Check in a few hours if the nightlies are dated with commits from 
today.

[julia-users] Re: Any 0.5 performance tips?

[Andrew]

In the 0.4 version the above times are pretty consistent. I never observe 
any several thousand allocation calls. I wonder if compilation is occurring 
repeatedly. 

This isn't terribly pressing for me since I'm not currently working on this 
project, but if there's an easy fix it would be useful for future work.

(sorry I didn't mean to post twice. For some reason hitting spacebar was 
interpreted as the post command?)

On Thursday, September 29, 2016 at 2:15:35 PM UTC-4, Andrew wrote:
>
> I've used @code_warntype everywhere I can think to and I've only found one 
> Core.box. The @code_warntype looks like this
>
> Variables:
>   #self#::#innerloop#3133{#bellman_obj}
>   state::State{IdioState,AggState}
>   EVspline::Dierckx.Spline1D
>   model::Model{CRRA_Family,AggState}
>   policy::PolicyFunctions{Array{Float64,6},Array{Int64,6}}
>   OO::NW
>   
> #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>
> Body:
>   begin 
>   
> #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>  
> = $(Expr(:new, 
> ##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj},
>  
> :(state), :(EVspline), :(model), :(policy), :(OO), 
> :((Core.getfield)(#self#,:bellman_obj)::#bellman_obj)))
>   SSAValue(0) = 
> #3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>   
> (Core.setfield!)((Core.getfield)(#self#::#innerloop#3133{#bellman_obj},:obj)::CORE.BOX,:contents,SSAValue(0))::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>   return SSAValue(0)
>   
> end::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
>
>
> I put the CORE.BOX in all caps near the bottom.
>
> I have no idea if this is actually a problem. The return type is stable. 
> Also, this function appears in an outer loop.
>
> What I noticed putting a @time in places is that in 0.5, occasionally 
> calls to my nonlinear equation solver take a really long time, like here:
>
>   0.069224 seconds (9.62 k allocations: 487.873 KB)
>   0.07 seconds (39 allocations: 1.922 KB)
>   0.06 seconds (29 allocations: 1.391 KB)
>   0.11 seconds (74 allocations: 3.781 KB)
>   0.09 seconds (54 allocations: 2.719 KB)
>   0.08 seconds (54 allocations: 2.719 KB)
>   0.08 seconds (49 allocations: 2.453 KB)
>   0.07 seconds (44 allocations: 2.188 KB)
>   0.07 seconds (44 allocations: 2.188 KB)
>   0.06 seconds (39 allocations: 1.922 KB)
>   0.07 seconds (39 allocations: 1.922 KB)
>   0.06 seconds (39 allocations: 1.922 KB)
>   0.05 seconds (34 allocations: 1.656 KB)
>   0.05 seconds (34 allocations: 1.656 KB)
>   0.04 seconds (29 allocations: 1.391 KB)
>   0.04 seconds (24 allocations: 1.125 KB)
>   0.007399 seconds (248 allocations: 15.453 KB)
>   0.09 seconds (30 allocations: 1.594 KB)
>   0.04 seconds (25 allocations: 1.328 KB)
>   0.04 seconds (25 allocations: 1.328 KB)
>
>   0.10 seconds (70 allocations: 3.719 KB)
>   0.072703 seconds (41.74 k allocations: 1.615 MB)
>
>
>
>
>
>
>
>
> On Thursday, September 29, 2016 at 1:37:18 AM UTC-4, Kristoffer Carlsson 
> wrote:
>>
>> Look for Core.Box in @code_warntype. See 
>> https://github.com/JuliaLang/julia/issues/15276
>
>

[julia-users] Re: Any 0.5 performance tips?

[Andrew]

I've used @code_warntype everywhere I can think to and I've only found one 
Core.box. The @code_warntype looks like this

Variables:
  #self#::#innerloop#3133{#bellman_obj}
  state::State{IdioState,AggState}
  EVspline::Dierckx.Spline1D
  model::Model{CRRA_Family,AggState}
  policy::PolicyFunctions{Array{Float64,6},Array{Int64,6}}
  OO::NW
  
#3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}

Body:
  begin 
  
#3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
 
= $(Expr(:new, 
##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj},
 
:(state), :(EVspline), :(model), :(policy), :(OO), 
:((Core.getfield)(#self#,:bellman_obj)::#bellman_obj)))
  SSAValue(0) = 
#3130::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
  
(Core.setfield!)((Core.getfield)(#self#::#innerloop#3133{#bellman_obj},:obj)::CORE.BOX,:contents,SSAValue(0))::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}
  return SSAValue(0)
  
end::##3130#3134{State{IdioState,AggState},Dierckx.Spline1D,Model{CRRA_Family,AggState},PolicyFunctions{Array{Float64,6},Array{Int64,6}},NW,#bellman_obj}


I put the CORE.BOX in all caps near the bottom.

I have no idea if this is actually a problem. The return type is stable. 
Also, this function appears in an outer loop.

What I noticed putting a @time in places is that in 0.5, occasionally calls 
to my nonlinear equation solver take a really long time, like here:

  0.069224 seconds (9.62 k allocations: 487.873 KB)
  0.07 seconds (39 allocations: 1.922 KB)
  0.06 seconds (29 allocations: 1.391 KB)
  0.11 seconds (74 allocations: 3.781 KB)
  0.09 seconds (54 allocations: 2.719 KB)
  0.08 seconds (54 allocations: 2.719 KB)
  0.08 seconds (49 allocations: 2.453 KB)
  0.07 seconds (44 allocations: 2.188 KB)
  0.07 seconds (44 allocations: 2.188 KB)
  0.06 seconds (39 allocations: 1.922 KB)
  0.07 seconds (39 allocations: 1.922 KB)
  0.06 seconds (39 allocations: 1.922 KB)
  0.05 seconds (34 allocations: 1.656 KB)
  0.05 seconds (34 allocations: 1.656 KB)
  0.04 seconds (29 allocations: 1.391 KB)
  0.04 seconds (24 allocations: 1.125 KB)
  0.007399 seconds (248 allocations: 15.453 KB)
  0.09 seconds (30 allocations: 1.594 KB)
  0.04 seconds (25 allocations: 1.328 KB)
  0.04 seconds (25 allocations: 1.328 KB)

  0.10 seconds (70 allocations: 3.719 KB)
  0.072703 seconds (41.74 k allocations: 1.615 MB)








On Thursday, September 29, 2016 at 1:37:18 AM UTC-4, Kristoffer Carlsson 
wrote:
>
> Look for Core.Box in @code_warntype. See 
> https://github.com/JuliaLang/julia/issues/15276

Re: [julia-users] Re: Problem with julia-0.5 on Gentoo

['Bill Hart' via julia-users]

Do you mean the current nightly, or one to come? The current nightly seems
to have the same issue.

Also, we have ssl installed, so this doesn't seem to be a workaround.

Bill.

On 29 September 2016 at 17:52, Bill Hart 
wrote:

> Thanks!
>
> On 29 September 2016 at 17:49, Tony Kelman  wrote:
>
>> Should be fixed on nightly and hopefully in a future 0.5.x point release.
>> In the meantime try installing openssl and/or krb5?
>>
>>
>>
>> On Thursday, September 29, 2016 at 6:20:19 AM UTC-7, Bill Hart wrote:
>>>
>>> We are having problems running the Generic 64 bit x86 Linux binary on
>>> Gentoo. It appears to be looking for some Kerberos library. Is there
>>> something we need to install?
>>>
>>> The German message below just says, "Cannot open the shared-object-file:
>>> file or directory not found"
>>>
>>> fatal: error thrown and no exception handler available.
>>> Base.InitError(mod=:LibGit2, error=ErrorException("could not load
>>> library "libgit2"
>>> libgssapi_krb5.so.2: Kann die Shared-Object-Datei nicht öffnen: Datei
>>> oder Verzeichnis nicht gefunden"))
>>> rec_backtrace at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/stackwalk.c:84
>>> record_backtrace at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/task.c:232
>>> jl_throw at /home/centos/buildbot/slave/package_tarball64/build/src/task
>>> .c:550
>>> jl_errorf at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/builtins.c:78
>>> jl_dlerror at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/dlload.c:69 [inlined]
>>> jl_load_dynamic_library_ at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/dlload.c:209
>>> jl_get_library at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/runtime_ccall.cpp:152
>>> jl_load_and_lookup at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/runtime_ccall.cpp:163
>>> unknown function (ip: 0x7f6334fe9346)
>>> __init__ at ./libgit2/libgit2.jl:538
>>> unknown function (ip: 0x7f6334fe9b58)
>>> jl_call_method_internal at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/julia_internal.h:189 [inlined]
>>> jl_apply_generic at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/gf.c:1942
>>> jl_apply at 
>>> /home/centos/buildbot/slave/package_tarball64/build/src/julia.h:1392
>>> [inlined]
>>> jl_module_run_initializer at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/toplevel.c:83
>>> _julia_init at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/init.c:742
>>> julia_init at /home/centos/buildbot/slave/pa
>>> ckage_tarball64/build/src/task.c:283
>>> main at /home/centos/buildbot/slave/package_tarball64/build/ui/repl.
>>> c:231
>>> __libc_start_main at /lib64/libc.so.6 (unknown line)
>>> unknown function (ip: 0x4013fc)
>>>
>>> Bill.
>>>
>>
>

Re: [julia-users] Re: Problem with julia-0.5 on Gentoo

['Bill Hart' via julia-users]

Thanks!

On 29 September 2016 at 17:49, Tony Kelman  wrote:

> Should be fixed on nightly and hopefully in a future 0.5.x point release.
> In the meantime try installing openssl and/or krb5?
>
>
>
> On Thursday, September 29, 2016 at 6:20:19 AM UTC-7, Bill Hart wrote:
>>
>> We are having problems running the Generic 64 bit x86 Linux binary on
>> Gentoo. It appears to be looking for some Kerberos library. Is there
>> something we need to install?
>>
>> The German message below just says, "Cannot open the shared-object-file:
>> file or directory not found"
>>
>> fatal: error thrown and no exception handler available.
>> Base.InitError(mod=:LibGit2, error=ErrorException("could not load library
>> "libgit2"
>> libgssapi_krb5.so.2: Kann die Shared-Object-Datei nicht öffnen: Datei
>> oder Verzeichnis nicht gefunden"))
>> rec_backtrace at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/stackwalk.c:84
>> record_backtrace at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/task.c:232
>> jl_throw at /home/centos/buildbot/slave/package_tarball64/build/src/task
>> .c:550
>> jl_errorf at /home/centos/buildbot/slave/package_tarball64/build/src/buil
>> tins.c:78
>> jl_dlerror at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/dlload.c:69 [inlined]
>> jl_load_dynamic_library_ at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/dlload.c:209
>> jl_get_library at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/runtime_ccall.cpp:152
>> jl_load_and_lookup at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/runtime_ccall.cpp:163
>> unknown function (ip: 0x7f6334fe9346)
>> __init__ at ./libgit2/libgit2.jl:538
>> unknown function (ip: 0x7f6334fe9b58)
>> jl_call_method_internal at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/julia_internal.h:189 [inlined]
>> jl_apply_generic at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/gf.c:1942
>> jl_apply at 
>> /home/centos/buildbot/slave/package_tarball64/build/src/julia.h:1392
>> [inlined]
>> jl_module_run_initializer at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/toplevel.c:83
>> _julia_init at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/init.c:742
>> julia_init at /home/centos/buildbot/slave/pa
>> ckage_tarball64/build/src/task.c:283
>> main at /home/centos/buildbot/slave/package_tarball64/build/ui/repl.c:231
>> __libc_start_main at /lib64/libc.so.6 (unknown line)
>> unknown function (ip: 0x4013fc)
>>
>> Bill.
>>
>

[julia-users] Re: Problem with julia-0.5 on Gentoo

[Tony Kelman]

Should be fixed on nightly and hopefully in a future 0.5.x point release. 
In the meantime try installing openssl and/or krb5?


On Thursday, September 29, 2016 at 6:20:19 AM UTC-7, Bill Hart wrote:
>
> We are having problems running the Generic 64 bit x86 Linux binary on 
> Gentoo. It appears to be looking for some Kerberos library. Is there 
> something we need to install?
>
> The German message below just says, "Cannot open the shared-object-file: 
> file or directory not found"
>
> fatal: error thrown and no exception handler available.
> Base.InitError(mod=:LibGit2, error=ErrorException("could not load library 
> "libgit2"
> libgssapi_krb5.so.2: Kann die Shared-Object-Datei nicht öffnen: Datei oder 
> Verzeichnis nicht gefunden"))
> rec_backtrace at 
> /home/centos/buildbot/slave/package_tarball64/build/src/stackwalk.c:84
> record_backtrace at 
> /home/centos/buildbot/slave/package_tarball64/build/src/task.c:232
> jl_throw at 
> /home/centos/buildbot/slave/package_tarball64/build/src/task.c:550
> jl_errorf at 
> /home/centos/buildbot/slave/package_tarball64/build/src/builtins.c:78
> jl_dlerror at 
> /home/centos/buildbot/slave/package_tarball64/build/src/dlload.c:69 
> [inlined]
> jl_load_dynamic_library_ at 
> /home/centos/buildbot/slave/package_tarball64/build/src/dlload.c:209
> jl_get_library at 
> /home/centos/buildbot/slave/package_tarball64/build/src/runtime_ccall.cpp:152
> jl_load_and_lookup at 
> /home/centos/buildbot/slave/package_tarball64/build/src/runtime_ccall.cpp:163
> unknown function (ip: 0x7f6334fe9346)
> __init__ at ./libgit2/libgit2.jl:538
> unknown function (ip: 0x7f6334fe9b58)
> jl_call_method_internal at 
> /home/centos/buildbot/slave/package_tarball64/build/src/julia_internal.h:189 
> [inlined]
> jl_apply_generic at 
> /home/centos/buildbot/slave/package_tarball64/build/src/gf.c:1942
> jl_apply at 
> /home/centos/buildbot/slave/package_tarball64/build/src/julia.h:1392 
> [inlined]
> jl_module_run_initializer at 
> /home/centos/buildbot/slave/package_tarball64/build/src/toplevel.c:83
> _julia_init at 
> /home/centos/buildbot/slave/package_tarball64/build/src/init.c:742
> julia_init at 
> /home/centos/buildbot/slave/package_tarball64/build/src/task.c:283
> main at /home/centos/buildbot/slave/package_tarball64/build/ui/repl.c:231
> __libc_start_main at /lib64/libc.so.6 (unknown line)
> unknown function (ip: 0x4013fc)
>
> Bill.
>

[julia-users] Re: Overload what to fix "Julia Client - Internal Error" with subtype of AbstractArray?

[Chris Stook]

That fixed it.

Thank you!

[julia-users] Re: Overload what to fix "Julia Client - Internal Error" with subtype of AbstractArray?

[randmstring]

That error happens because your subtyping isn't entirely correct:

IsModifiedArray{Float64, 1} <: AbstractArray{Float64, 1} == false

with your definition. If you do 

abstract SpecialArray{T,S} <: AbstractArray{T,S}
type IsModifiedArray{T,S} <: SpecialArray{T,S}
  values :: Array{T,S}
  ismodified :: Bool
end

you won't get that error. 

If you want to pretty print results in Juno that won't be enough: Have a 
look here .

Am Donnerstag, 29. September 2016 14:44:52 UTC+2 schrieb Chris Stook:
>
>
> I have defined a simple subtype of AbstractArray which keeps track if an 
> array has been modified by the user.  Base.show, Base.showcompact, and 
> Base.display are overloaded.  This works in the REPL, but with Atom I 
> receive the following error.
>
> Julia Client - Internal Error
>
> MethodError: no method matching 
> print_matrix(::IOContext{Base.AbstractIOBuffer{Array{UInt8,1}}}, 
> ::LTspice.IsModifiedArray{Float64,1}, ::String, ::String, ::String)
> Closest candidates are:
>   print_matrix(::IO, 
> !Matched::Union{AbstractArray{T,1},AbstractArray{T,2}}, ::AbstractString, 
> ::AbstractString, ::AbstractString) at show.jl:1379
>   print_matrix(::IO, 
> !Matched::Union{AbstractArray{T,1},AbstractArray{T,2}}, ::AbstractString, 
> ::AbstractString, ::AbstractString, !Matched::AbstractString) at 
> show.jl:1379
>   print_matrix(::IO, 
> !Matched::Union{AbstractArray{T,1},AbstractArray{T,2}}, ::AbstractString, 
> ::AbstractString, ::AbstractString, !Matched::AbstractString, 
> !Matched::AbstractString) at show.jl:1379
>   ...
>  in #showarray#330(::Bool, ::Function, 
> ::IOContext{Base.AbstractIOBuffer{Array{UInt8,1}}}, 
> ::LTspice.IsModifiedArray{Float64,1}, ::Bool) at .\show.jl:1618
>  in verbose_show(::Base.AbstractIOBuffer{Array{UInt8,1}}, 
> ::MIME{Symbol("text/plain")}, ::LTspice.IsModifiedArray{Float64,1}) at 
> .\multimedia.jl:50
>  in #sprint#304(::Void, ::Function, ::Int64, ::Function, 
> ::MIME{Symbol("text/plain")}, ::Vararg{Any,N}) at .\strings\io.jl:37
>  in Type at C:\Users\Chris\.julia\v0.5\Juno\src\types.jl:48 [inlined]
>  in Type at C:\Users\Chris\.julia\v0.5\Juno\src\types.jl:49 [inlined]
>  in render(::Juno.Editor, ::LTspice.IsModifiedArray{Float64,1}) at 
> C:\Users\Chris\.julia\v0.5\Juno\src\types.jl:12
>  in (::Atom.##81#84)(::Dict{String,Any}) at 
> C:\Users\Chris\.julia\v0.5\Atom\src\eval.jl:64
>  in handlemsg(::Dict{String,Any}, ::Dict{String,Any}, 
> ::Vararg{Dict{String,Any},N}) at 
> C:\Users\Chris\.julia\v0.5\Atom\src\comm.jl:148
>  in (::Atom.##7#10)() at .\event.jl:68
>
>
> What do I need to overload to fix this?
>
> Code below:
>
> abstract SpecialArray <: AbstractArray
>
> Base.size(a::SpecialArray) = size(a.values)
> Base.linearindexing{T<:SpecialArray}(::Type{T}) = Base.LinearFast()
> Base.getindex(a::SpecialArray, i::Int) = a.values[i]
> Base.ndims(a::SpecialArray) = ndims(a.values)
> Base.show(io::IO, a::SpecialArray) = show(io,a.values)
> Base.showcompact(io::IO, a::SpecialArray) = showcompact(io,a.values)
> Base.display(a::SpecialArray) = display(a.values)
> """
> Same as Array, but tracks is user has modified values.
> """
> type IsModifiedArray{T,S} <: SpecialArray
>   values :: Array{T,S}
>   ismodified :: Bool
> end
>
> function Base.setindex!(a::IsModifiedArray, v, i::Int)
>   a.ismodified = true
>   a.values[i] = v
> end
>
> a =  IsModifiedArray{Float64,1}([1.0,2.0,3.0],false) # error here
>
>

[julia-users] Problem with julia-0.5 on Gentoo

[Lutfullah Tomak]

https://github.com/JuliaLang/julia/pull/18658

[julia-users] Problem with julia-0.5 on Gentoo

['Bill Hart' via julia-users]

We are having problems running the Generic 64 bit x86 Linux binary on 
Gentoo. It appears to be looking for some Kerberos library. Is there 
something we need to install?

The German message below just says, "Cannot open the shared-object-file: 
file or directory not found"

fatal: error thrown and no exception handler available.
Base.InitError(mod=:LibGit2, error=ErrorException("could not load library 
"libgit2"
libgssapi_krb5.so.2: Kann die Shared-Object-Datei nicht öffnen: Datei oder 
Verzeichnis nicht gefunden"))
rec_backtrace at 
/home/centos/buildbot/slave/package_tarball64/build/src/stackwalk.c:84
record_backtrace at 
/home/centos/buildbot/slave/package_tarball64/build/src/task.c:232
jl_throw at 
/home/centos/buildbot/slave/package_tarball64/build/src/task.c:550
jl_errorf at 
/home/centos/buildbot/slave/package_tarball64/build/src/builtins.c:78
jl_dlerror at 
/home/centos/buildbot/slave/package_tarball64/build/src/dlload.c:69 
[inlined]
jl_load_dynamic_library_ at 
/home/centos/buildbot/slave/package_tarball64/build/src/dlload.c:209
jl_get_library at 
/home/centos/buildbot/slave/package_tarball64/build/src/runtime_ccall.cpp:152
jl_load_and_lookup at 
/home/centos/buildbot/slave/package_tarball64/build/src/runtime_ccall.cpp:163
unknown function (ip: 0x7f6334fe9346)
__init__ at ./libgit2/libgit2.jl:538
unknown function (ip: 0x7f6334fe9b58)
jl_call_method_internal at 
/home/centos/buildbot/slave/package_tarball64/build/src/julia_internal.h:189 
[inlined]
jl_apply_generic at 
/home/centos/buildbot/slave/package_tarball64/build/src/gf.c:1942
jl_apply at 
/home/centos/buildbot/slave/package_tarball64/build/src/julia.h:1392 
[inlined]
jl_module_run_initializer at 
/home/centos/buildbot/slave/package_tarball64/build/src/toplevel.c:83
_julia_init at 
/home/centos/buildbot/slave/package_tarball64/build/src/init.c:742
julia_init at 
/home/centos/buildbot/slave/package_tarball64/build/src/task.c:283
main at /home/centos/buildbot/slave/package_tarball64/build/ui/repl.c:231
__libc_start_main at /lib64/libc.so.6 (unknown line)
unknown function (ip: 0x4013fc)

Bill.

Re: [julia-users] Re: cfunction result garbage collected

[Christian Rorvik]

That's very helpful, thanks very much!

On Wednesday, September 28, 2016 at 10:33:04 PM UTC+1, Yichao Yu wrote:
>
> On Wed, Sep 28, 2016 at 5:16 PM, Christian Rorvik 
>  wrote: 
> > Thanks! I'll try this tomorrow. So similar to what you've done here? 
> > 
> https://github.com/yuyichao/FunctionWrappers.jl/blob/master/src/FunctionWrappers.jl#L40
>  
>
> Correct. Also https://github.com/JuliaPy/PyCall.jl/pull/267 
>
> > 
> > I can't remember if I actually called that explicitly, but I believe 
> what I 
> > ended up with was similar to here: 
> > http://julialang.org/blog/2013/05/callback, where they use 
> > unsafe_pointer_to_objref to recover the function object. 
>
> unsafe_pointer_to_objref is ok. It's unsafe in the sense that you 
> almost guarantee a segfault if it is not used correctly. 
> pointer_from_objref is less unsafe in that you might not get a 
> segfault if the GC is nice to you today. 
>
> Ref https://github.com/JuliaLang/julia/issues/15857 for why 
> pointer_from_objref is bad if you call it on arbitrary object (mostly 
> immutables). Essentially the compiler is free to give you garbage if 
> you call it on immutables or the pointer you get back might not be the 
> pointer that you stored somewhere else since the pointer value is 
> supposed to be insignificant, only the content is, for immutables. 
>
> > 
> > On Wednesday, September 28, 2016 at 10:06:51 PM UTC+1, Yichao Yu wrote: 
> >> 
> >> On Wed, Sep 28, 2016 at 5:00 PM, Christian Rorvik 
> >>  wrote: 
> >> > I don't have the code at hand right now (it's at work), but what I 
> was 
> >> > doing 
> >> > was something like 
> >> > 
> >> > type Wrapper{Arg} 
> >> > cfun::Ptr{Void} 
> >> > cobj::Ptr{Void} 
> >> > obj 
> >> > 
> >> > function Wrapper{T}(f::T) 
> >> > return new(cfunction(call_wrapper, Void, (Ref{T}, Arg)), 
> >> > pointer_from_objref(f), f) 
> >> > end 
> >> > end 
> >> 
> >> This is wrong, You shouldn't ever call `pointer_from_objref` for 
> >> unknown object. The right way to handl this is 
> >> 
> >> type Wrapper{Arg} 
> >> cfun::Ptr{Void} 
> >> cobj::Ptr{Void} 
> >> obj 
> >> function Wrapper{T}(f::T) 
> >> to_root = Base.cconvert(Ref{T}, f) 
> >> ptr = Base.unsafe_convert(Ref{T}, to_root) 
> >> return new(cfunction(call_wrapper, Void, (Ref{T}, Arg)), 
> >> Ptr{Void}(ptr), to_root) 
> >> end 
> >> end 
> >> 
> >> 
> >> > 
> >> > Where call_wrapper would invoke the closure. I had to change 
> >> > call_wrapper to 
> >> > receive the closure as Ptr{T} and call unsafe_pointer_to_objref and 
> then 
> >> > call it. 
> >> > 
> >> > 
> >> > On Wednesday, September 28, 2016 at 9:50:47 PM UTC+1, Yichao Yu 
> wrote: 
> >> >> 
> >> >> On Wed, Sep 28, 2016 at 4:36 PM, Christian Rorvik 
> >> >>  wrote: 
> >> >> > GC of code turned out to be a red herring. After isolating the 
> >> >> > instance 
> >> >> > of a 
> >> >> > call that was crashing, and getting right up to it, GDB was kind 
> >> >> > enough 
> >> >> > to 
> >> >> > get its knickers in a twist and segfault itself every time I 
> stepped 
> >> >> > instruction by instruction to find the precise point of failure 
> >> >> > (backtrace 
> >> >> > after segfault looked pretty meaningless). 
> >> >> > 
> >> >> > What it tunred out to be a was a Ref vs Ptr problem, where in 
> Julia I 
> >> >> > have a 
> >> >> > callback wrapper that receives a pointer to the closure. I was 
> taking 
> >> >> > this 
> >> >> > as Ref{T} and invoking it with a pointer from the C code. This 
> worked 
> >> >> > all 
> >> >> > fine and dandy, but somehow caused the object to be collected (I'm 
> >> >> > guessing). I can see how what I did was wrong, but I can't see how 
> it 
> >> >> > would 
> >> >> > lead to something being collected when there still exists roots 
> >> >> > pointing 
> >> >> > to 
> >> >> > it. If anything I would possibly expect a leak. Nonetheless, bit 
> of a 
> >> >> > wild 
> >> >> > goose chase. 
> >> >> 
> >> >> It's unclear what exactly you mean but just to be clear 
> `cfunction(f, 
> >> >> Ret, Tuple{Ref{Int}})` expect a pointer to a julia boxed `Int` that 
> is 
> >> >> rooted somewhere during the execution of the julia callback 
> function. 
> >> >> It is illegal to pass it a bare C `intptr_t*` (that doesn't point to 
> >> >> julia memory of a boxed Int) and it is illegal to generates it with 
> >> >> `ccall(..., (Ptr{Int},), )`. 
> >> >> 
> >> >> > 
> >> >> > 
> >> >> > On Wednesday, September 28, 2016 at 5:22:49 PM UTC+1, Christian 
> >> >> > Rorvik 
> >> >> > wrote: 
> >> >> >> 
> >> >> >> I'm not yet a 100% sure what is happening in my application, but 
> I'm 
> >> >> >> embedding Julia and using cfunction() to generate C-callable 
> >> >> >> functions 
> >> >> >> that 
> >> >> >> at a later time invoke the registered julia code. I use a fairly 
> >> >> >> standard 
> >> >> >> pattern I think, of passing a pointer to a 

[julia-users] Overload what to fix "Julia Client - Internal Error" with subtype of AbstractArray?

[Chris Stook]

I have defined a simple subtype of AbstractArray which keeps track if an 
array has been modified by the user.  Base.show, Base.showcompact, and 
Base.display are overloaded.  This works in the REPL, but with Atom I 
receive the following error.

Julia Client - Internal Error

MethodError: no method matching 
print_matrix(::IOContext{Base.AbstractIOBuffer{Array{UInt8,1}}}, 
::LTspice.IsModifiedArray{Float64,1}, ::String, ::String, ::String)
Closest candidates are:
  print_matrix(::IO, 
!Matched::Union{AbstractArray{T,1},AbstractArray{T,2}}, ::AbstractString, 
::AbstractString, ::AbstractString) at show.jl:1379
  print_matrix(::IO, 
!Matched::Union{AbstractArray{T,1},AbstractArray{T,2}}, ::AbstractString, 
::AbstractString, ::AbstractString, !Matched::AbstractString) at 
show.jl:1379
  print_matrix(::IO, 
!Matched::Union{AbstractArray{T,1},AbstractArray{T,2}}, ::AbstractString, 
::AbstractString, ::AbstractString, !Matched::AbstractString, 
!Matched::AbstractString) at show.jl:1379
  ...
 in #showarray#330(::Bool, ::Function, 
::IOContext{Base.AbstractIOBuffer{Array{UInt8,1}}}, 
::LTspice.IsModifiedArray{Float64,1}, ::Bool) at .\show.jl:1618
 in verbose_show(::Base.AbstractIOBuffer{Array{UInt8,1}}, 
::MIME{Symbol("text/plain")}, ::LTspice.IsModifiedArray{Float64,1}) at 
.\multimedia.jl:50
 in #sprint#304(::Void, ::Function, ::Int64, ::Function, 
::MIME{Symbol("text/plain")}, ::Vararg{Any,N}) at .\strings\io.jl:37
 in Type at C:\Users\Chris\.julia\v0.5\Juno\src\types.jl:48 [inlined]
 in Type at C:\Users\Chris\.julia\v0.5\Juno\src\types.jl:49 [inlined]
 in render(::Juno.Editor, ::LTspice.IsModifiedArray{Float64,1}) at 
C:\Users\Chris\.julia\v0.5\Juno\src\types.jl:12
 in (::Atom.##81#84)(::Dict{String,Any}) at 
C:\Users\Chris\.julia\v0.5\Atom\src\eval.jl:64
 in handlemsg(::Dict{String,Any}, ::Dict{String,Any}, 
::Vararg{Dict{String,Any},N}) at 
C:\Users\Chris\.julia\v0.5\Atom\src\comm.jl:148
 in (::Atom.##7#10)() at .\event.jl:68


What do I need to overload to fix this?

Code below:

abstract SpecialArray <: AbstractArray

Base.size(a::SpecialArray) = size(a.values)
Base.linearindexing{T<:SpecialArray}(::Type{T}) = Base.LinearFast()
Base.getindex(a::SpecialArray, i::Int) = a.values[i]
Base.ndims(a::SpecialArray) = ndims(a.values)
Base.show(io::IO, a::SpecialArray) = show(io,a.values)
Base.showcompact(io::IO, a::SpecialArray) = showcompact(io,a.values)
Base.display(a::SpecialArray) = display(a.values)
"""
Same as Array, but tracks is user has modified values.
"""
type IsModifiedArray{T,S} <: SpecialArray
  values :: Array{T,S}
  ismodified :: Bool
end

function Base.setindex!(a::IsModifiedArray, v, i::Int)
  a.ismodified = true
  a.values[i] = v
end

a =  IsModifiedArray{Float64,1}([1.0,2.0,3.0],false) # error here

Re: [julia-users] Re: Why does Julia 0.5 keep complaining about method re-definitions?

[Daniel Carrera]

Hi everyone,

I created a new issue asking the Julia developers to please restore the
earlier behaviour. I would be immensely grateful if you could write on this
issue and let the Julia developers know that I am not the only person who
would be happier without the sea of warnings.

https://github.com/JuliaLang/julia/issues/18725

Cheers,
Daniel.



On 28 September 2016 at 15:15, J Luis  wrote:

>
> This a very heavy install.  It's fetching tons of things that I have not
>> used.  Not sure what they are, but seems like trashing my system.
>>
>
> Yes, unfortunately Conda is an unbearably big dependency (over 1.xxx Gb)
> that sneaks in via un-suspicious packages. A dependency this big should
> never install without a strict user consent. Docs explain how to avoid it
> but don't find the explanation clear. I had to declare this
>
> ENV["JUPYTER"]="C:/programs/WinPython-3.5.2.2_64/python-3.
> 5.2.amd64/Scripts/jupyter"
>
> to really prevent a Conda installation
>
>
>>
>> On Wednesday, September 28, 2016 at 4:30:32 AM UTC+8, Cedric St-Jean
>> wrote:
>>>
>>> Yeah, it's because of IJulia, sorry about that. I need it to support
>>> autoreloading. I could split the package in two, but it's small enough
>>> already that it doesn't feel like the right call.
>>>
>>> One day we'll get conditional imports...
>>>
>>> On Tue, Sep 27, 2016 at 4:14 PM, Daniel Carrera 
>>> wrote:
>>>
 Thanks! You are a savior!

 Here is something odd: when I installed it with Pkg.clone(...) my Julia
 decided that it also had to update Conda and install Jupyter. Is this some
 weird quirk of my setup. I notice that you import IJulia, so I guess that
 has something to do with it. It's not a big deal; I just thought it was
 weird to see the package manager installing stuff like Qt, fontconfig, SSL,
 and libxml just to clobber include().

 But other than that, it works fabulously. Thank you so much!

 Cheers,
 Daniel.



 On 27 September 2016 at 21:45, Cedric St-Jean 
 wrote:

> I wrote a work-around earlier today:
>
> Pkg.clone("git://github.com/cstjean/ClobberingReload.jl.git")
>
> using ClobberingReload: sinclude # silent include
> sinclude("foo.jl")   # no redefinition warnings
>
>
> It's fresh off the press, so please file an issue if you encounter a
> problem. It calls `include` under the hood; there's no magic involved. I
> just intercept STDERR and remove the redefinition warnings.
>
> On Tuesday, September 27, 2016 at 3:13:00 PM UTC-4, Andrew wrote:
>>
>> It seems like a lot of people are complaining about this. Is there
>> some way to suppress method overwritten warnings for an include()
>> statement? Perhaps a keyword like include("foo.jl", quietly = true)?
>>
>> On Tuesday, September 27, 2016 at 1:56:27 PM UTC-4, Daniel Carrera
>> wrote:
>>>
>>> Hello,
>>>
>>> I'm not sure when I upgraded, but I am using Julia 0.5 and now it
>>> complains every time I redefine a method, which is basically all the 
>>> time.
>>> When I'm developing ideas I usually have a file with a script that I 
>>> modify
>>> and reload all the time:
>>>
>>> julia> include("foo.jl");
>>>
>>> ... see the results, edit file ...
>>>
>>> julia> include("foo.jl");
>>>
>>> ... see the results, edit file ...
>>> julia> include("foo.jl");
>>>
>>> ... see the results, edit file ...
>>>
>>>
>>> And so on. This is what I do most of the time. But now every time I
>>> `include("foo.jl")` I get warnings for every method that has been 
>>> redefined
>>> (which is all of them):
>>>
>>> julia> include("foo.jl");
>>>
>>> WARNING: Method definition (::Type{Main.Line})(Float64, Float64) in
>>> module Main at /home/daniel/Data/Science/Thesis/SI.jl:4 overwritten
>>> at /home/daniel/Data/Science/Thesis/SI.jl:4.
>>> WARNING: Method definition (::Type{Main.Line})(Any, Any) in module
>>> Main at /home/daniel/Data/Science/Thesis/SI.jl:4 overwritten at
>>> /home/daniel/Data/Science/Thesis/SI.jl:4.
>>> WARNING: Method definition new_line(Any, Any, Any) in module Main at
>>> /home/daniel/Data/Science/Thesis/SI.jl:8 overwritten at
>>> /home/daniel/Data/Science/Thesis/SI.jl:8.
>>>
>>>
>>> Is there a way that this can be fixed? How can I recover Julia's
>>> earlier behaviour? This is very irritating, and I don't think it makes
>>> sense for a functional language like Julia. If I wrote a method as a
>>> variable assignment (e.g. "foo = x -> 2*x") Julia wouldn't complain.
>>>
>>>
>>> Thanks for the help,
>>> Daniel.
>>>
>>

>>>

[julia-users] Re: Broken PyPlot... need to revert to a previous version asap.

[Andreas Lobinger]

Hello colleague,

On Thursday, September 29, 2016 at 9:36:43 AM UTC+2, Ferran Mazzanti wrote:
>
> Nobody is using PyPlot under OSX, please?
>

your description of the error/failure is quite broad. Please file an issue 
to the package and provide details.

I'm not a OSX user (and also not pyplot), but recently it looked like the 
main problems (of packages of this style) are in the area of interactions 
between OSX and the python packaging/distribution mechanism(s) (Conda, 
Ananconda, brew etc.).

So actually the situation is different at every computer, because it 
contains the history of all (re-)configurations.


 

Re: [julia-users] Error printing for too many ouputs

[Mauro]

On Thu, 2016-09-29 at 10:09, DNF  wrote:
> I recently spent an unreasonable amount of time figuring out what my error was
> in a function analogous to the following:
> too_many_outputs() = rand(100, 100), zeros(100, 100)
> a, b, c = too_many_outputs()
> The output from this is, on 0.5.0, several screenfuls of red numerical data,
> and an error message I simply did not understand
> -- BoundsError - Stacktrace (most recent call last)
> [1] — indexed_next(::Tuple{Array{Float64,2},Array{Float64,2}}, ::Int64, ::
> Int64) at tuple.jl:33
>
> BoundsError: attempt to access (
>
> [0.301287 0.256923 0.722508 0.408858 0.319346 0.179616 0.960471 0.789095
> 0.910412 0.265434 0.718849 0.937929 0.0367298 0.205515 0.883508 0.712387
> 0.267544 0.301452 0.359053 0.640887 0.144168 0.288608 0.890876 0.812196
> 0.764392 0.729052 0.74899 0.189467 0.251815 0.368224 0.194331 0.477015 
> 0.164543
> 0.719979 0.469798 0.575245 0.193929 0.921848 0.640391 0.0087104 0.329382
> 0.357261 0.237266 0.0663893 0.864157 0.619164 0.260045 0.774574 0.470039
> 0.571927 0.0538007 0.015361 0.121495 0.99733 0.672622 0.770356 0.0467123
> 0.597193 0.741415 0.809322 0.289837 0.919511 0.186844 0.233542 0.664298
> 0.0701865 0.166444 0.32414 0.425086 0.347678 0.442404 0.367277 0.493046
> 0.942807 0.210841 0.00490626 0.784097 .
>
> My code actually had four return arrays each with 1 million elements, that 
> were
> printed in full.
>
>
> Questions:
>
> 0. Is there already an issue for this (there always seems to be, but I cannot
> find one)

Yep, I've ran into this too.  Here's the issue, add another thumbs up.

https://github.com/JuliaLang/julia/issues/14734


> 1. Can the printing of the output tuple contents be compact like in normal
> array display?
>
> 2. Can the error message be more informative, e.g. "Too many output 
> arguments"?

Presumably yes.

[julia-users] Error printing for too many ouputs

[DNF]

I recently spent an unreasonable amount of time figuring out what my error 
was in a function analogous to the following:
too_many_outputs() = rand(100, 100), zeros(100, 100)
a, b, c = too_many_outputs()
The output from this is, on 0.5.0, several screenfuls of red numerical 
data, and an error message I simply did not understand
-- BoundsError - Stacktrace (most recent call last)
 [1] — indexed_next(::Tuple{Array{Float64,2},Array{Float64,2}}, ::Int64, ::
Int64) at tuple.jl:33

BoundsError: attempt to access ( 

[0.301287 0.256923 0.722508 0.408858 0.319346 0.179616 0.960471 0.789095 
0.910412 0.265434 0.718849 0.937929 0.0367298 0.205515 0.883508 0.712387 
0.267544 0.301452 0.359053 0.640887 0.144168 0.288608 0.890876 0.812196 
0.764392 0.729052 0.74899 0.189467 0.251815 0.368224 0.194331 0.477015 
0.164543 0.719979 0.469798 0.575245 0.193929 0.921848 0.640391 0.0087104 
0.329382 0.357261 0.237266 0.0663893 0.864157 0.619164 0.260045 0.774574 
0.470039 0.571927 0.0538007 0.015361 0.121495 0.99733 0.672622 0.770356 
0.0467123 0.597193 0.741415 0.809322 0.289837 0.919511 0.186844 0.233542 
0.664298 0.0701865 0.166444 0.32414 0.425086 0.347678 0.442404 0.367277 
0.493046 0.942807 0.210841 0.00490626 0.784097 .

My code actually had four return arrays each with 1 million elements, that 
were printed in full.


Questions:

0. Is there already an issue for this (there always seems to be, but I 
cannot find one)

1. Can the printing of the output tuple contents be compact like in normal 
array display?

2. Can the error message be more informative, e.g. "Too many output 
arguments"?

Re: [julia-users] Re: Broken PyPlot... need to revert to a previous version asap.

[Mauro]

Have you tried the latest master?

Pkg.checkout("PyPlot", "master")

Otherwise revert to an older version and try that.  I think from within
Julia you'd have to edit the REQUIRE file (or is there an easier way?).
Probably ~/.julia/v0.5/REQUIRE or ~/.julia/v0.4/REQUIRE, modify the line
with PyPlot. For example:

PyPlot 2.1.0 2.2.0

to get version 2.1.0 installed.  To actually install it run
Pkg.resolve() at the julia prompt.  Other packages may be downgraded
too.  Also, you may run into problems with required version from other
packages.

Alternatively, and less safe, cd into ~/.julia/v0.5/PyPlot and there run
in the shell

$ git checkout v2.2.0

Then check whether PyPlot works again.

I hope this helps.

On Thu, 2016-09-29 at 09:36, Ferran Mazzanti  wrote:
> Nobody is using PyPlot under OSX, please?
> Best,
> Ferran.
>
> On Wednesday, September 28, 2016 at 10:35:58 AM UTC+2, Ferran Mazzanti
> wrote:
>>
>> Hi,
>>
>> it seems that PyPlot is still broken in 0.5.0 and OSX, at least
>> Mavericks... Anybody else has faced this problem? If yes, how can I solve
>> it? If not, what versions of PyCall/PyPlot are you using? The ones I was
>> told to use here still work, but spit quite a lot of warnings etc... and it
>> is not clean.
>>
>> Thanks a lot,
>>
>> Ferran.
>>
>> On Thursday, August 18, 2016 at 10:47:27 AM UTC+2, Ferran Mazzanti wrote:
>>>
>>> Dear all,
>>>
>>> looks like lots of messing around with versions had rendered PyPlot
>>> unusable in 0.4.6 under OSX (at least).
>>> Now I need to do some work that requires its use so I need to have it up
>>> and working. Could anybody please let me know
>>> if it is possible to revert to a previous working version, and how this
>>> is done? I know it used to work with 0.4.6 as I had it
>>> installed, but once I did an update and things stopped working since then.
>>>
>>> Thanks for your help,
>>>
>>> Ferran.
>>>
>>

[julia-users] Re: Broken PyPlot... need to revert to a previous version asap.

[Ferran Mazzanti]

Nobody is using PyPlot under OSX, please?
Best,
Ferran.

On Wednesday, September 28, 2016 at 10:35:58 AM UTC+2, Ferran Mazzanti 
wrote:
>
> Hi,
>
> it seems that PyPlot is still broken in 0.5.0 and OSX, at least 
> Mavericks... Anybody else has faced this problem? If yes, how can I solve 
> it? If not, what versions of PyCall/PyPlot are you using? The ones I was 
> told to use here still work, but spit quite a lot of warnings etc... and it 
> is not clean.
>
> Thanks a lot,
>
> Ferran.
>
> On Thursday, August 18, 2016 at 10:47:27 AM UTC+2, Ferran Mazzanti wrote:
>>
>> Dear all,
>>
>> looks like lots of messing around with versions had rendered PyPlot 
>> unusable in 0.4.6 under OSX (at least).
>> Now I need to do some work that requires its use so I need to have it up 
>> and working. Could anybody please let me know
>> if it is possible to revert to a previous working version, and how this 
>> is done? I know it used to work with 0.4.6 as I had it
>> installed, but once I did an update and things stopped working since then.
>>
>> Thanks for your help,
>>
>> Ferran.
>>
>

Re: [julia-users] Re: translating julia

[henri.gir...@gmail.com]

Hi Ismael,

I would like to translate "home" first,  but I noticed it's difficult to 
find all text about it ?


Is there a way to research a precise text ?

I already translated a good part of it but I need to see it so that I 
can be sûre of that.



Best
Henri
Le 28/09/2016 à 11:54, henri.gir...@gmail.com a écrit :


I am wondering if one must write the html mark when translating ?


Le 28/09/2016 à 10:26, Ismael Venegas Castelló a écrit :

Hello Henri!

Currently French is about 0% translated, we are adding to production 
the languages that at minimum have the home page translated 90 %, but 
you can see the current progress of all the languages in the staging 
site here:


  * http://julialanges.github.io

You can see here a video I did tonight, were I am translating, in 
order to give a taste of the workflow involved in doing this with 
Transifex Live.


Please let me know if you have any doubt and I will gladly help you 
as much as I can and thank you very much for your interest and 
support to this project.


Cheers,
Ismael Venegas Castelló

El miércoles, 28 de septiembre de 2016, 2:49:32 (UTC-5), Henri Girard 
escribió:


I went to french translation startet to translate but can't see
it on julialang.org  ?
it's not actualized ?
Regards