Re: [julia-users] numerical trig question about refining good approximation to sin,cos

[Kristoffer Carlsson]

Use a truncated Taylor series around the point maybe? 

Re: [julia-users] Re: Everything I wrote in version .3 is now 'depreciated'

[Tony Kelman]

No, not really. The compiled code is pretty highly dependent on the runtime 
library, which changes between each version. Some day in the future you 
will probably be able to directly compile Julia code into object files, 
libraries, or executables, but not that's not an easy thing to do right now.


On Friday, October 16, 2015 at 10:48:43 PM UTC-7, Forrest Curo wrote:
>
> There's something I haven't quite understood about the language...
>
> It compiles a function the first time that function is run... So I should 
> be able to save a file from that
>
> that julia should be able to link to...?
>
> Is there a way to run a module in julia 3, freeze the machine code that 
> this generates, and afterwards just let julia 4 use that without 
> re-compiling?
>
> On Fri, Oct 16, 2015 at 10:26 PM, Tony Kelman  > wrote:
>
>> You can continue using 0.3 if you want to use 0.3-developed code without 
>> changes or warnings. Yes, the purpose of Compat is to allow using the new 
>> 0.4 syntax, eliminating deprecation warnings but allowing the code to still 
>> run on 0.3.
>>
>>
>> On Friday, October 16, 2015 at 9:27:59 PM UTC-7, Forrest Curo wrote:
>>>
>>> Um... In other words, I can run my old code using julia 0.3  but if I 
>>> want to add new things in julia 0.4 syntax, Compat will translate it so 
>>> julia 0.3 can run it?
>>>
>>> Nothing to convince julia 0.4 to look up & use an older graphics 
>>> package? (That's really the issue here... The graphics for this were a 
>>> trivial hassle I thought I'd finished, & now I'm needing to excavate & 
>>> reconstruct that in order to use them.)
>>>
>>> On Fri, Oct 16, 2015 at 8:41 PM, Matt Bauman  wrote:
>>>
 On Friday, October 16, 2015 at 11:29:40 PM UTC-4, Forrest Curo wrote:
>
> Okay, this might be a good time to explain that 'Compat' package. 
> Evidently I do have it, because I can't Pkg.add it... How does this work?
>

 See the readme here: https://github.com/JuliaLang/Compat.jl

 The short version is that it allows you to write code using the new 0.4 
 names and syntaxes, while still providing compatibility for 0.3.  For the 
 most part, you're able to update your code to the new 0.4 names and simply 
 saying `using Compat` at the top of your file will make things work on 
 0.3.  There are some syntaxes, however, whose new form is an error on 0.3. 
  
 In those cases, you can use the `@compat` macro.  For example, a function 
 definition like `f(x::Union(Int,Float64)) = 2` would become 
 `f(x::@compat(Union{Int,Float64})) = 2`.

>>>
>>>
>

Re: [julia-users] Re: Everything I wrote in version .3 is now 'depreciated'

[Forrest Curo]

There's something I haven't quite understood about the language...

It compiles a function the first time that function is run... So I should
be able to save a file from that

that julia should be able to link to...?

Is there a way to run a module in julia 3, freeze the machine code that
this generates, and afterwards just let julia 4 use that without
re-compiling?

On Fri, Oct 16, 2015 at 10:26 PM, Tony Kelman  wrote:

> You can continue using 0.3 if you want to use 0.3-developed code without
> changes or warnings. Yes, the purpose of Compat is to allow using the new
> 0.4 syntax, eliminating deprecation warnings but allowing the code to still
> run on 0.3.
>
>
> On Friday, October 16, 2015 at 9:27:59 PM UTC-7, Forrest Curo wrote:
>>
>> Um... In other words, I can run my old code using julia 0.3  but if I
>> want to add new things in julia 0.4 syntax, Compat will translate it so
>> julia 0.3 can run it?
>>
>> Nothing to convince julia 0.4 to look up & use an older graphics package?
>> (That's really the issue here... The graphics for this were a trivial
>> hassle I thought I'd finished, & now I'm needing to excavate & reconstruct
>> that in order to use them.)
>>
>> On Fri, Oct 16, 2015 at 8:41 PM, Matt Bauman  wrote:
>>
>>> On Friday, October 16, 2015 at 11:29:40 PM UTC-4, Forrest Curo wrote:

 Okay, this might be a good time to explain that 'Compat' package.
 Evidently I do have it, because I can't Pkg.add it... How does this work?

>>>
>>> See the readme here: https://github.com/JuliaLang/Compat.jl
>>>
>>> The short version is that it allows you to write code using the new 0.4
>>> names and syntaxes, while still providing compatibility for 0.3.  For the
>>> most part, you're able to update your code to the new 0.4 names and simply
>>> saying `using Compat` at the top of your file will make things work on
>>> 0.3.  There are some syntaxes, however, whose new form is an error on 0.3.
>>> In those cases, you can use the `@compat` macro.  For example, a function
>>> definition like `f(x::Union(Int,Float64)) = 2` would become 
>>> `f(x::@compat(Union{Int,Float64}))
>>> = 2`.
>>>
>>
>>

Re: [julia-users] Re: Everything I wrote in version .3 is now 'depreciated'

[Tony Kelman]

You can continue using 0.3 if you want to use 0.3-developed code without 
changes or warnings. Yes, the purpose of Compat is to allow using the new 
0.4 syntax, eliminating deprecation warnings but allowing the code to still 
run on 0.3.


On Friday, October 16, 2015 at 9:27:59 PM UTC-7, Forrest Curo wrote:
>
> Um... In other words, I can run my old code using julia 0.3  but if I want 
> to add new things in julia 0.4 syntax, Compat will translate it so julia 
> 0.3 can run it?
>
> Nothing to convince julia 0.4 to look up & use an older graphics package? 
> (That's really the issue here... The graphics for this were a trivial 
> hassle I thought I'd finished, & now I'm needing to excavate & reconstruct 
> that in order to use them.)
>
> On Fri, Oct 16, 2015 at 8:41 PM, Matt Bauman  > wrote:
>
>> On Friday, October 16, 2015 at 11:29:40 PM UTC-4, Forrest Curo wrote:
>>>
>>> Okay, this might be a good time to explain that 'Compat' package. 
>>> Evidently I do have it, because I can't Pkg.add it... How does this work?
>>>
>>
>> See the readme here: https://github.com/JuliaLang/Compat.jl
>>
>> The short version is that it allows you to write code using the new 0.4 
>> names and syntaxes, while still providing compatibility for 0.3.  For the 
>> most part, you're able to update your code to the new 0.4 names and simply 
>> saying `using Compat` at the top of your file will make things work on 
>> 0.3.  There are some syntaxes, however, whose new form is an error on 0.3.  
>> In those cases, you can use the `@compat` macro.  For example, a function 
>> definition like `f(x::Union(Int,Float64)) = 2` would become 
>> `f(x::@compat(Union{Int,Float64})) = 2`.
>>
>
>

Re: [julia-users] Re: Everything I wrote in version .3 is now 'depreciated'

[Forrest Curo]

Um... In other words, I can run my old code using julia 0.3  but if I want
to add new things in julia 0.4 syntax, Compat will translate it so julia
0.3 can run it?

Nothing to convince julia 0.4 to look up & use an older graphics package?
(That's really the issue here... The graphics for this were a trivial
hassle I thought I'd finished, & now I'm needing to excavate & reconstruct
that in order to use them.)

On Fri, Oct 16, 2015 at 8:41 PM, Matt Bauman  wrote:

> On Friday, October 16, 2015 at 11:29:40 PM UTC-4, Forrest Curo wrote:
>>
>> Okay, this might be a good time to explain that 'Compat' package.
>> Evidently I do have it, because I can't Pkg.add it... How does this work?
>>
>
> See the readme here: https://github.com/JuliaLang/Compat.jl
>
> The short version is that it allows you to write code using the new 0.4
> names and syntaxes, while still providing compatibility for 0.3.  For the
> most part, you're able to update your code to the new 0.4 names and simply
> saying `using Compat` at the top of your file will make things work on
> 0.3.  There are some syntaxes, however, whose new form is an error on 0.3.
> In those cases, you can use the `@compat` macro.  For example, a function
> definition like `f(x::Union(Int,Float64)) = 2` would become 
> `f(x::@compat(Union{Int,Float64}))
> = 2`.
>

Re: [julia-users] Re: Everything I wrote in version .3 is now 'depreciated'

[Matt Bauman]

On Friday, October 16, 2015 at 11:29:40 PM UTC-4, Forrest Curo wrote:
>
> Okay, this might be a good time to explain that 'Compat' package. 
> Evidently I do have it, because I can't Pkg.add it... How does this work?
>

See the readme here: https://github.com/JuliaLang/Compat.jl

The short version is that it allows you to write code using the new 0.4 
names and syntaxes, while still providing compatibility for 0.3.  For the 
most part, you're able to update your code to the new 0.4 names and simply 
saying `using Compat` at the top of your file will make things work on 0.3. 
 There are some syntaxes, however, whose new form is an error on 0.3.  In 
those cases, you can use the `@compat` macro.  For example, a function 
definition like `f(x::Union(Int,Float64)) = 2` would become 
`f(x::@compat(Union{Int,Float64})) = 2`.

Re: [julia-users] Re: Everything I wrote in version .3 is now 'depreciated'

[Forrest Curo]

Okay, this might be a good time to explain that 'Compat' package. Evidently
I do have it, because I can't Pkg.add it... How does this work?

On Fri, Oct 16, 2015 at 8:09 PM, Patrick Kofod Mogensen <
patrick.mogen...@gmail.com> wrote:

> I think most people simply tag a final v0.3 supported version, and then
> develop for v0.4 from then. Alternatively you can use the Compat package.
>
>
> On Friday, October 16, 2015 at 10:40:10 PM UTC-4, feza wrote:
>>
>> On a related note. What is the recommended procedure for dealing with
>> depreciations? Do we just update all the deprecations and push the changes?
>> This would make the package useless for 0.3 users or is this the
>> recommended procedure.
>>
>> On Friday, October 16, 2015 at 7:39:05 PM UTC-4, Forrest Curo wrote:
>>>
>>> So what's the easiest way -- given a long, long list of warnings -- to
>>> find out what needs to be changed in a program (It runs, after replacing
>>> calls to 'Base.Graphics' with 'Graphics' -- but the tk button that used to
>>> close the window and exit now doesn't (Ah! I need to remember the default I
>>> changed for those buttons to make that button work the way I wanted! (What 
>>> *was
>>> *that?!)))
>>>
>>> and what should now be substituted?
>>>
>>> I mean, I could just follow that list of warnings from the top... but
>>> I'd like to know a reference listing displaced packages & their
>>> replacements.
>>>
>>

[julia-users] Re: Installing package (Cpp). Could not spawn 'make'.

[Tony Kelman]

Why many packages don't support Windows? It's par for the course in 
open-source development, unfortunately. I gave a talk on this at JuliaCon 
in June where I discussed some of the challenges in making things work on 
Windows and how to go about fixing them, 
see https://www.youtube.com/watch?v=mbG-rqDCNqs - if you find packages you 
use that aren't currently testing on Windows but could be, I encourage you 
to submit pull requests adding appveyor.yml files and suggesting the 
authors enable Windows CI testing.

Julia makes it easy to wrap C and Fortran libraries so people do exactly 
that quite often, but building most of those C and Fortran libraries on 
Windows is nontrivial. Witness Anaconda, which exists to make binary 
installation of libraries in the Python ecosystem possible so you don't 
need a compiler on the user's machine at install time. In Julia we tend to 
focus on individual platform-specific tools, like WinRPM.jl for a large 
number of packages on Windows and Homebrew.jl on Mac.


On Friday, October 16, 2015 at 3:56:44 PM UTC-7, Joel wrote:
>
> Thanks for the information; food for thought.
>
> Out of curiosity, do you know why this is the case, by the way? 
>
> Den fredag 16 oktober 2015 kl. 21:00:12 UTC+1 skrev Tony Kelman:
>>
>> Quite a few Julia packages are written in a way that assumes you're on 
>> Linux or Mac with build tools installed. Not all, and we're gradually 
>> fixing cases where packages can be made more portable. Best thing to do for 
>> now would be to submit a pull request adding a note to the readme that the 
>> package does not currently work on Windows, to save future users a bit of 
>> confusion.
>
>

[julia-users] Re: Everything I wrote in version .3 is now 'depreciated'

[Patrick Kofod Mogensen]

I think most people simply tag a final v0.3 supported version, and then 
develop for v0.4 from then. Alternatively you can use the Compat package.

On Friday, October 16, 2015 at 10:40:10 PM UTC-4, feza wrote:
>
> On a related note. What is the recommended procedure for dealing with 
> depreciations? Do we just update all the deprecations and push the changes? 
> This would make the package useless for 0.3 users or is this the 
> recommended procedure.
>
> On Friday, October 16, 2015 at 7:39:05 PM UTC-4, Forrest Curo wrote:
>>
>> So what's the easiest way -- given a long, long list of warnings -- to 
>> find out what needs to be changed in a program (It runs, after replacing 
>> calls to 'Base.Graphics' with 'Graphics' -- but the tk button that used to 
>> close the window and exit now doesn't (Ah! I need to remember the default I 
>> changed for those buttons to make that button work the way I wanted! (What 
>> *was 
>> *that?!)))
>>
>> and what should now be substituted?
>>
>> I mean, I could just follow that list of warnings from the top... but I'd 
>> like to know a reference listing displaced packages & their replacements. 
>>
>

Re: [julia-users] numerical trig question about refining good approximation to sin,cos

[Jeffrey Sarnoff]

your point about sin^2 + cos^2 is well taken -- 

On Friday, October 16, 2015 at 10:35:39 PM UTC-4, Jeffrey Sarnoff wrote:
>
> I am not using a library, I am writing one.
> I have e.g. for x = 0.5, sinx = sin(x); cosx=cos(x);
> I want sinxx = sin(x + dx), cosxx = cos(x +dx) for dx << x.
> Is there some relationship that allows me to refine sinxx, cosxx 
> simultaneously?
>
> On Friday, October 16, 2015 at 10:23:05 PM UTC-4, Yichao Yu wrote:
>>
>> On Fri, Oct 16, 2015 at 10:14 PM, Jeffrey Sarnoff 
>>  wrote: 
>> > Is there a way to use sin(x)^2 + cos(x)^2 = 1 to refine very close 
>> > approximations to sin(x), cos(x)? 
>> > I am using an extended precision, so I have Float64 approximations for 
>> > sin,cos for 'free'. 
>> > 
>>
>> I would guess any library you use to deal with those higher precision 
>> numbers already handle this internally (e.g. `sin(::BigFloat)`) 
>>
>> Also, I doubt sin^2 + cos^2 = 1 would help since it doesn't explicitly 
>> include x. 
>>
>

[julia-users] Re: Everything I wrote in version .3 is now 'depreciated'

[feza]

On a related note. What is the recommended procedure for dealing with 
depreciations? Do we just update all the deprecations and push the changes? 
This would make the package useless for 0.3 users or is this the 
recommended procedure.

On Friday, October 16, 2015 at 7:39:05 PM UTC-4, Forrest Curo wrote:
>
> So what's the easiest way -- given a long, long list of warnings -- to 
> find out what needs to be changed in a program (It runs, after replacing 
> calls to 'Base.Graphics' with 'Graphics' -- but the tk button that used to 
> close the window and exit now doesn't (Ah! I need to remember the default I 
> changed for those buttons to make that button work the way I wanted! (What 
> *was 
> *that?!)))
>
> and what should now be substituted?
>
> I mean, I could just follow that list of warnings from the top... but I'd 
> like to know a reference listing displaced packages & their replacements. 
>

Re: [julia-users] numerical trig question about refining good approximation to sin,cos

[Jeffrey Sarnoff]

I am not using a library, I am writing one.
I have e.g. for x = 0.5, sinx = sin(x); cosx=cos(x);
I want sinxx = sin(x + dx), cosxx = cos(x +dx) for dx << x.
Is there some relationship that allows me to refine sinxx, cosxx 
simultaneously?

On Friday, October 16, 2015 at 10:23:05 PM UTC-4, Yichao Yu wrote:
>
> On Fri, Oct 16, 2015 at 10:14 PM, Jeffrey Sarnoff 
> > wrote: 
> > Is there a way to use sin(x)^2 + cos(x)^2 = 1 to refine very close 
> > approximations to sin(x), cos(x)? 
> > I am using an extended precision, so I have Float64 approximations for 
> > sin,cos for 'free'. 
> > 
>
> I would guess any library you use to deal with those higher precision 
> numbers already handle this internally (e.g. `sin(::BigFloat)`) 
>
> Also, I doubt sin^2 + cos^2 = 1 would help since it doesn't explicitly 
> include x. 
>

Re: [julia-users] Overload Base.show for a Array of specific type

[Chris Stook]

Thanks!

Re: [julia-users] numerical trig question about refining good approximation to sin,cos

[Yichao Yu]

On Fri, Oct 16, 2015 at 10:14 PM, Jeffrey Sarnoff
 wrote:
> Is there a way to use sin(x)^2 + cos(x)^2 = 1 to refine very close
> approximations to sin(x), cos(x)?
> I am using an extended precision, so I have Float64 approximations for
> sin,cos for 'free'.
>

I would guess any library you use to deal with those higher precision
numbers already handle this internally (e.g. `sin(::BigFloat)`)

Also, I doubt sin^2 + cos^2 = 1 would help since it doesn't explicitly
include x.

[julia-users] numerical trig question about refining good approximation to sin,cos

[Jeffrey Sarnoff]

Is there a way to use sin(x)^2 + cos(x)^2 = 1 to refine very close 
approximations to sin(x), cos(x)?
I am using an extended precision, so I have Float64 approximations for 
sin,cos for 'free'.

Re: [julia-users] Overload Base.show for a Array of specific type

[Yichao Yu]

On Fri, Oct 16, 2015 at 9:08 PM, Chris Stook  wrote:
> Is it possible to overload show for an array of a specific type?  See
> example below.
>
> In [1]:
> type a_type
> b_element :: Int64
> c_element :: Int64
> end
> d_array = [a_type(1,2),a_type(3,4),a_type(5,6)]
>
> Out[1]:
> 3-element Array{a_type,1}:
>  a_type(1,2)
>  a_type(3,4)
>  a_type(5,6)
>
> In [2]:
> function Base.show(io::IO, a::Array{a_type,1})
> println(io,rpad("b_element",10),rpad("c_element",10))
> for e in a
> println(io,rpad(e.b_element,10),rpad(e.c_element,10))
> end
> end
>
> Out[2]:
> show (generic function with 105 methods)
>
> In [3]:
> show(d_array)
> b_element c_element
> 12
> 34
> 56
>
> In [4]:
> d_array
>
> Out[4]:
> 3-element Array{a_type,1}:
>  a_type(1,2)
>  a_type(3,4)
>  a_type(5,6)
>

Quote from 
http://julia.readthedocs.org/en/latest/stdlib/io-network/#Base.writemime

> The display functions ultimately call writemime in order to write an object x 
> as a given mime type to a given I/O stream (usually a memory buffer), if 
> possible.

```
julia> type A
   end

julia> A[]
0-element Array{A,1}

julia> Base.writemime(io::IO, ::MIME"text/plain", a::Vector{A}) =
print(io, "nothing")
writemime (generic function with 26 methods)

julia> A[]
nothing
```

>
>
>
> - Chris

[julia-users] Overload Base.show for a Array of specific type

[Chris Stook]

Is it possible to overload show for an array of a specific type?  See 
example below.

In [1]:
type a_type
b_element :: Int64
c_element :: Int64
end
d_array = [a_type(1,2),a_type(3,4),a_type(5,6)]

Out[1]:
3-element Array{a_type,1}:
 a_type(1,2)
 a_type(3,4)
 a_type(5,6)

In [2]:
function Base.show(io::IO, a::Array{a_type,1})
println(io,rpad("b_element",10),rpad("c_element",10))
for e in a
println(io,rpad(e.b_element,10),rpad(e.c_element,10))
end
end

Out[2]:
show (generic function with 105 methods)

In [3]:
show(d_array)
b_element c_element 
12 
34 
56 

In [4]:
d_array

Out[4]:
3-element Array{a_type,1}:
 a_type(1,2)
 a_type(3,4)
 a_type(5,6)




- Chris

[julia-users] Everything I wrote in version .3 is now 'depreciated'

[Forrest Curo]

So what's the easiest way -- given a long, long list of warnings -- to find 
out what needs to be changed in a program (It runs, after replacing calls 
to 'Base.Graphics' with 'Graphics' -- but the tk button that used to close 
the window and exit now doesn't (Ah! I need to remember the default I 
changed for those buttons to make that button work the way I wanted! (What *was 
*that?!)))

and what should now be substituted?

I mean, I could just follow that list of warnings from the top... but I'd 
like to know a reference listing displaced packages & their replacements. 

Re: [julia-users] communicating with a TcpSocket

[Eric Forgy]

We're using Requests.jl alot these days for testing REST APIs and it's great.

[julia-users] Re: Installing package (Cpp). Could not spawn 'make'.

[Joel]

Thanks for the information; food for thought.

Out of curiosity, do you know why this is the case, by the way? 

Den fredag 16 oktober 2015 kl. 21:00:12 UTC+1 skrev Tony Kelman:
>
> Quite a few Julia packages are written in a way that assumes you're on 
> Linux or Mac with build tools installed. Not all, and we're gradually 
> fixing cases where packages can be made more portable. Best thing to do for 
> now would be to submit a pull request adding a note to the readme that the 
> package does not currently work on Windows, to save future users a bit of 
> confusion.

[julia-users] Re: VAR estimation in Julia

[Michael Wang]

Cool, thank you! I will make good use of these. 

On Friday, October 16, 2015 at 1:00:34 PM UTC-7, Patrick Kofod Mogensen 
wrote:
>
> I'm not aware of any packages in metadata, but you can perhaps get 
> inspiration from 
>
> https://github.com/andreasnoack/Civecm.jl (Cointegrated VAR models)
> https://github.com/tomaskrehlik/VARmodels.jl (VAR models)
>
> Neither are from repositories registered in METADATA.jl, so don't expect 
> too much support. They do not seem to have been updated too recently either 
> (5-7 months).
>
> On Friday, October 16, 2015 at 3:03:41 PM UTC-4, Michael Wang wrote:
>>
>> Hi all,
>>
>> I am trying to estimation a vector autoregressive model, but I did not 
>> find a specific Julia package performing the job. Does anyone know that 
>> there is some package doing this?
>>
>> Thanks!
>>
>

Re: [julia-users] Re: Type array bug?

[Yichao Yu]

On Fri, Oct 16, 2015 at 5:35 PM, Thuener Silva  wrote:
> I'm having this kind of problem in different situations. Another example:
>
> julia> groups_1 = [Array((Int),0) for i=1:K]
> 5-element Array{Array{Int64,1},1}:
>  []
>  []
>  []
>  []
>  []
>
> julia> groups_1[size(groups_1[i],1) .!= 0 for i=1:size(groups_1,1)]
> ERROR: `Array{T,N}` has no method matching
> Array{T,N}(::Array{Array{Int64,1},1}, ::Int64)
>  in anonymous at no file

I don't think this kind of indexing is supported.

>
> The workaround:
> julia> not_empty = [size(groups_1[i],1) .!= 0 for i=1:size(groups_1,1)]
> 5-element Array{Any,1}:
>  false
>  false
>  false
>  false
>  false
>
> julia> not_empty = convert( Array{Bool,1}, not_empty)
> 5-element Array{Bool,1}:
>  false
>  false
>  false
>  false
>  false

You don't need the convert, not_empty = Bool[.] should work

>
> julia> groups_1 = groups_1[not_empty]
> 0-element Array{Array{Int64,1},1}
>
> On Friday, October 16, 2015 at 3:58:19 PM UTC-3, Steven G. Johnson wrote:
>>
>>
>>
>> On Friday, October 16, 2015 at 1:55:19 PM UTC-4, Andras Niedermayer wrote:
>>>
>>> You can also use `map`, which is better at type inference:
>>>
>>> julia> M=10
>>> 10
>>>
>>> julia> [[i] for i=1:M]
>>> 10-element Array{Any,1}:
>>
>>
>> As usual, type inference is much better if you don't run it in global
>> scope (that's why your "map" example worked better):
>>
>> julia> f(M) = [[i] for i=1:M]
>>
>> f (generic function with 1 method)
>>
>>
>> julia> f(10)
>>
>> 10-element Array{Array{Int64,1},1}:
>>
>>  [1]
>>
>>  [2]
>>
>>  [3]
>>
>>  [4]
>>
>>  [5]
>>
>>  [6]
>>
>>  [7]
>>
>>  [8]
>>
>>  [9]
>>
>>  [10]

Re: [julia-users] Re: Type array bug?

[Thuener Silva]

*I'm having this kind of problem in different situations. Another example:*

julia> groups_1 = [Array((Int),0) for i=1:K]
5-element Array{Array{Int64,1},1}:
 []
 []
 []
 []
 []

julia> groups_1[size(groups_1[i],1) .!= 0 for i=1:size(groups_1,1)]
ERROR: `Array{T,N}` has no method matching 
Array{T,N}(::Array{Array{Int64,1},1}, ::Int64)
 in anonymous at no file

*The workaround:*
julia> not_empty = [size(groups_1[i],1) .!= 0 for i=1:size(groups_1,1)]
5-element Array{Any,1}:
 false
 false
 false
 false
 false

julia> not_empty = convert( Array{Bool,1}, not_empty)
5-element Array{Bool,1}:
 false
 false
 false
 false
 false

julia> groups_1 = groups_1[not_empty]
0-element Array{Array{Int64,1},1}

On Friday, October 16, 2015 at 3:58:19 PM UTC-3, Steven G. Johnson wrote:
>
>
>
> On Friday, October 16, 2015 at 1:55:19 PM UTC-4, Andras Niedermayer wrote:
>>
>> You can also use `map`, which is better at type inference:
>>
>> julia> M=10
>> 10
>>
>> julia> [[i] for i=1:M]
>> 10-element Array{Any,1}:
>>
>
> As usual, type inference is much better if you don't run it in global 
> scope (that's why your "map" example worked better):
>
> julia> *f(M) = [[i] for i=1:M]*
>
> f (generic function with 1 method)
>
>
> julia> *f(10)*
>
> 10-element Array{Array{Int64,1},1}:
>
>  [1] 
>
>  [2] 
>
>  [3] 
>
>  [4] 
>
>  [5] 
>
>  [6] 
>
>  [7] 
>
>  [8] 
>
>  [9] 
>  [10] 
>
>

Re: [julia-users] Deprecation of require

[David Smith]

Thanks, Tim.  I feel like I'm getting closer, but I tried either and both 
of those and nothing worked.  In every case I get this:

WARNING: Module DCEMRI not defined on process 2
fatal error on 2: ERROR: UndefVarError: DCEMRI not defined
 in deserialize at serialize.jl:500
 in handle_deserialize at serialize.jl:461
 in deserialize at serialize.jl:519
 in handle_deserialize at serialize.jl:461
 in deserialize at serialize.jl:694
 in deserialize_datatype at serialize.jl:647
 in handle_deserialize at serialize.jl:461
 in message_handler_loop at multi.jl:847
 in process_tcp_streams at multi.jl:836
 in anonymous at task.jl:63
Worker 2 terminated.

It doesn't seem to be quite the same problem as #9245, but rather the 
entire module is not able to be found.

On Friday, October 16, 2015 at 3:43:20 PM UTC-5, Tim Holy wrote:
>
> On Friday, October 16, 2015 01:07:49 PM David Smith wrote: 
> > I'm also wondering how to replace 'require' without modifying the 
> > LOAD_PATH.  I can't expect my users to know how to make any path 
> changes. 
>
> You can do this: 
>
> thisdir = splitdir(@__FILE__)[1] 
> if !any(LOAD_PATH .== thisdir) 
> push!(LOAD_PATH, thisdir) 
> end 
>
> Whatever file has this code snippet in it will cause its enclosing folder 
> to be 
> added to the LOAD_PATH. 
>
> You may also be running up against 
> https://github.com/JuliaLang/julia/issues/9245. Better (but more awkward) 
> than 
>
> @everywhere using DCEMRI 
>
> would be 
>
> for p in workers() 
> remotecall_fetch(p, eval, :(using DCEMRI)) 
> end 
>
> On julia 0.3, that has to be 
>remotecall_fetch(p, eval, Expr(:using, :DCEMRI)) 
>
> --Tim 
>
> > 
> > 'using' and 'import' doesn't work for my parallel processes even though 
> I'm 
> > loading a registered package ("DCEMRI").  I get this error. 
> > 
> > WARNING: Module DCEMRI not defined on process 2 
> > fatal error on 2: ERROR: UndefVarError: DCEMRI not defined 
> > 
> > 
> > I have just a small bit of code in a separate file in the DCEMRI package 
> > directory that I need each worker to load.  What is the preferred way to 
> > enable this in 0.4? 
> > 
> > 
> > On Thursday, September 17, 2015 at 7:18:54 AM UTC-5, Christopher Fisher 
> > 
> > wrote: 
> > > I am using .4.0-rc1 and have encountered a similar situation and have 
> > > fairly basic questions about the way .4 loads files. I normally use 
> > > require 
> > > to load a file of functions from my working directory in to Julia on a 
> > > local computer or a cluster of computers. I was hoping someone would 
> be 
> > > willing to answer a few related questions. 
> > > 
> > > First, where can I find the .juliarc.jl file? 
> > > 
> > > Second, is there an easier way to load a .jl file from my working 
> > > directory into Julia onto a local computer or cluster of computers 
> that 
> > > does not require editing the .juliarc.fil file? (Editing this file for 
> > > every project seems a little inconvenient). 
> > > 
> > > Third, will the code loaded from a .jl  always be precompiled in .4? 
> If 
> > > not, how do I choose whether it is precompiled or not? 
> > > 
> > > Thanks in advance (and my apologies for the basic questions;I'm not a 
> > > programmer per se) 
> > > 
> > > Chris 
> > > 
> > > On Friday, July 31, 2015 at 7:30:44 AM UTC-4, Tim Holy wrote: 
> > >> If MyModule.jl is on your LOAD_PATH, 
> > >> 
> > >> @everywhere import MyModule 
> > >> 
> > >> should work. You can add 
> > >> 
> > >> push!(LOAD_PATH,"/my/code/repository") 
> > >> 
> > >> to your .juliarc.jl file. 
> > >> 
> > >> This has been deprecated because of precompilation; it was felt that 
> the 
> > >> string version left it too ambiguous about whether you wanted to load 
> the 
> > >> raw 
> > >> file or the cached version. 
> > >> 
> > >> Best, 
> > >> --Tim 
> > >> 
> > >> On Thursday, July 23, 2015 11:58:58 AM Eduardo Lenz wrote: 
> > >> > Hi 
> > >> > I just downloaded the last nightly build  and I am receiving a new 
> > >> > deprecation message: 
> > >> > 
> > >> > Warning, "require" is deprecated, use "using" or "import" instead. 
> > >> > 
> > >> > My question is: I am using "require" due to the need to 
> automatically 
> > >> > import these functions for all workers in a cluster. As long as I 
> know, 
> > >> 
> > >> to 
> > >> 
> > >> > accomplish this task I have to use "require" and also provide the 
> > >> 
> > >> correct 
> > >> 
> > >> > path of the corresponding .jl files. How can I do this same thing 
> using 
> > >> > "using" or "import" ? I tried to use it as I was using "require" 
> and it 
> > >> 
> > >> is 
> > >> 
> > >> > not working as expected. 
> > >> > 
> > >> > Thanks for your help and sorry for the dumb question. 
>
>

Re: [julia-users] Deprecation of require

[Tim Holy]

On Friday, October 16, 2015 01:07:49 PM David Smith wrote:
> I'm also wondering how to replace 'require' without modifying the
> LOAD_PATH.  I can't expect my users to know how to make any path changes.

You can do this:

thisdir = splitdir(@__FILE__)[1]
if !any(LOAD_PATH .== thisdir)
push!(LOAD_PATH, thisdir)
end

Whatever file has this code snippet in it will cause its enclosing folder to be 
added to the LOAD_PATH.

You may also be running up against 
https://github.com/JuliaLang/julia/issues/9245. Better (but more awkward) than

@everywhere using DCEMRI

would be

for p in workers()
remotecall_fetch(p, eval, :(using DCEMRI))
end

On julia 0.3, that has to be
   remotecall_fetch(p, eval, Expr(:using, :DCEMRI))

--Tim

> 
> 'using' and 'import' doesn't work for my parallel processes even though I'm
> loading a registered package ("DCEMRI").  I get this error.
> 
> WARNING: Module DCEMRI not defined on process 2
> fatal error on 2: ERROR: UndefVarError: DCEMRI not defined
> 
> 
> I have just a small bit of code in a separate file in the DCEMRI package
> directory that I need each worker to load.  What is the preferred way to
> enable this in 0.4?
> 
> 
> On Thursday, September 17, 2015 at 7:18:54 AM UTC-5, Christopher Fisher
> 
> wrote:
> > I am using .4.0-rc1 and have encountered a similar situation and have
> > fairly basic questions about the way .4 loads files. I normally use
> > require
> > to load a file of functions from my working directory in to Julia on a
> > local computer or a cluster of computers. I was hoping someone would be
> > willing to answer a few related questions.
> > 
> > First, where can I find the .juliarc.jl file?
> > 
> > Second, is there an easier way to load a .jl file from my working
> > directory into Julia onto a local computer or cluster of computers that
> > does not require editing the .juliarc.fil file? (Editing this file for
> > every project seems a little inconvenient).
> > 
> > Third, will the code loaded from a .jl  always be precompiled in .4? If
> > not, how do I choose whether it is precompiled or not?
> > 
> > Thanks in advance (and my apologies for the basic questions;I'm not a
> > programmer per se)
> > 
> > Chris
> > 
> > On Friday, July 31, 2015 at 7:30:44 AM UTC-4, Tim Holy wrote:
> >> If MyModule.jl is on your LOAD_PATH,
> >> 
> >> @everywhere import MyModule
> >> 
> >> should work. You can add
> >> 
> >> push!(LOAD_PATH,"/my/code/repository")
> >> 
> >> to your .juliarc.jl file.
> >> 
> >> This has been deprecated because of precompilation; it was felt that the
> >> string version left it too ambiguous about whether you wanted to load the
> >> raw
> >> file or the cached version.
> >> 
> >> Best,
> >> --Tim
> >> 
> >> On Thursday, July 23, 2015 11:58:58 AM Eduardo Lenz wrote:
> >> > Hi
> >> > I just downloaded the last nightly build  and I am receiving a new
> >> > deprecation message:
> >> > 
> >> > Warning, "require" is deprecated, use "using" or "import" instead.
> >> > 
> >> > My question is: I am using "require" due to the need to automatically
> >> > import these functions for all workers in a cluster. As long as I know,
> >> 
> >> to
> >> 
> >> > accomplish this task I have to use "require" and also provide the
> >> 
> >> correct
> >> 
> >> > path of the corresponding .jl files. How can I do this same thing using
> >> > "using" or "import" ? I tried to use it as I was using "require" and it
> >> 
> >> is
> >> 
> >> > not working as expected.
> >> > 
> >> > Thanks for your help and sorry for the dumb question.

Re: [julia-users] Deprecation of require

[David Smith]

Thanks for your reply, but that doesn't work for me.  All of my code is run 
from functions, and when I try 'using' inside a function, I get this:

ERROR: error compiling fitdata: error compiling fitdata: unsupported or 
misplaced expression "using" in function fitdata
 in demo at /home/dss/.julia/v0.4/DCEMRI/src/demo.jl:7
 in demo at /home/dss/.julia/v0.4/DCEMRI/src/demo.jl:2


On Friday, October 16, 2015 at 3:15:25 PM UTC-5, Christopher Fisher wrote:
>
> Hi David-
>
> I've been having similar difficulties. I do not know how to avoid 
> modifying LOAD_PATH, but last code I attached provides a working example: 
> https://groups.google.com/forum/#!searchin/julia-users/christopher$20fisher%7Csort:date/julia-users/jgT47LBBtWk/Caje1PhiAwAJ
>
> My best guess is that you are not doing this after initializing the procs:
>
> using MyModule
>
> @everywhere using MyModule
>
> It seems odd to call using twice but it seems to work. 
>
> Nonetheless, I also would be interested in alternative methods that do not 
> require modifying LOAD_PATH.
>
>
>
> On Friday, October 16, 2015 at 4:07:49 PM UTC-4, David Smith wrote:
>>
>> I'm also wondering how to replace 'require' without modifying the 
>> LOAD_PATH.  I can't expect my users to know how to make any path changes.
>>
>> 'using' and 'import' doesn't work for my parallel processes even though 
>> I'm loading a registered package ("DCEMRI").  I get this error.
>>
>> WARNING: Module DCEMRI not defined on process 2
>> fatal error on 2: ERROR: UndefVarError: DCEMRI not defined
>>
>>
>> I have just a small bit of code in a separate file in the DCEMRI package 
>> directory that I need each worker to load.  What is the preferred way to 
>> enable this in 0.4?
>>
>>
>> On Thursday, September 17, 2015 at 7:18:54 AM UTC-5, Christopher Fisher 
>> wrote:
>>>
>>> I am using .4.0-rc1 and have encountered a similar situation and have 
>>> fairly basic questions about the way .4 loads files. I normally use require 
>>> to load a file of functions from my working directory in to Julia on a 
>>> local computer or a cluster of computers. I was hoping someone would be 
>>> willing to answer a few related questions. 
>>>
>>> First, where can I find the .juliarc.jl file?
>>>
>>> Second, is there an easier way to load a .jl file from my working 
>>> directory into Julia onto a local computer or cluster of computers that 
>>> does not require editing the .juliarc.fil file? (Editing this file for 
>>> every project seems a little inconvenient). 
>>>
>>> Third, will the code loaded from a .jl  always be precompiled in .4? If 
>>> not, how do I choose whether it is precompiled or not?
>>>
>>> Thanks in advance (and my apologies for the basic questions;I'm not a 
>>> programmer per se)
>>>
>>> Chris 
>>>
>>> On Friday, July 31, 2015 at 7:30:44 AM UTC-4, Tim Holy wrote:

 If MyModule.jl is on your LOAD_PATH, 

 @everywhere import MyModule 

 should work. You can add 

 push!(LOAD_PATH,"/my/code/repository") 

 to your .juliarc.jl file. 

 This has been deprecated because of precompilation; it was felt that 
 the 
 string version left it too ambiguous about whether you wanted to load 
 the raw 
 file or the cached version. 

 Best, 
 --Tim 

 On Thursday, July 23, 2015 11:58:58 AM Eduardo Lenz wrote: 
 > Hi 
 > I just downloaded the last nightly build  and I am receiving a new 
 > deprecation message: 
 > 
 > Warning, "require" is deprecated, use "using" or "import" instead. 
 > 
 > My question is: I am using "require" due to the need to automatically 
 > import these functions for all workers in a cluster. As long as I 
 know, to 
 > accomplish this task I have to use "require" and also provide the 
 correct 
 > path of the corresponding .jl files. How can I do this same thing 
 using 
 > "using" or "import" ? I tried to use it as I was using "require" and 
 it is 
 > not working as expected. 
 > 
 > Thanks for your help and sorry for the dumb question. 

[julia-users] Re: Windows: enforce update of ENV["PATH"] after modifying it.

[Tony Kelman]

Modifying ENV only applies for as long as the current julia executable stays 
open, same as on unix. Changing environment variables permanently is doable in 
other ways, but I very strongly recommend against it for any code that you plan 
on having anyone else use.

Re: [julia-users] Deprecation of require

[Christopher Fisher]

Hi David-

I've been having similar difficulties. I do not know how to avoid modifying 
LOAD_PATH, but last code I attached provides a working 
example: 
https://groups.google.com/forum/#!searchin/julia-users/christopher$20fisher%7Csort:date/julia-users/jgT47LBBtWk/Caje1PhiAwAJ

My best guess is that you are not doing this after initializing the procs:

using MyModule

@everywhere using MyModule

It seems odd to call using twice but it seems to work. 

Nonetheless, I also would be interested in alternative methods that do not 
require modifying LOAD_PATH.



On Friday, October 16, 2015 at 4:07:49 PM UTC-4, David Smith wrote:
>
> I'm also wondering how to replace 'require' without modifying the 
> LOAD_PATH.  I can't expect my users to know how to make any path changes.
>
> 'using' and 'import' doesn't work for my parallel processes even though 
> I'm loading a registered package ("DCEMRI").  I get this error.
>
> WARNING: Module DCEMRI not defined on process 2
> fatal error on 2: ERROR: UndefVarError: DCEMRI not defined
>
>
> I have just a small bit of code in a separate file in the DCEMRI package 
> directory that I need each worker to load.  What is the preferred way to 
> enable this in 0.4?
>
>
> On Thursday, September 17, 2015 at 7:18:54 AM UTC-5, Christopher Fisher 
> wrote:
>>
>> I am using .4.0-rc1 and have encountered a similar situation and have 
>> fairly basic questions about the way .4 loads files. I normally use require 
>> to load a file of functions from my working directory in to Julia on a 
>> local computer or a cluster of computers. I was hoping someone would be 
>> willing to answer a few related questions. 
>>
>> First, where can I find the .juliarc.jl file?
>>
>> Second, is there an easier way to load a .jl file from my working 
>> directory into Julia onto a local computer or cluster of computers that 
>> does not require editing the .juliarc.fil file? (Editing this file for 
>> every project seems a little inconvenient). 
>>
>> Third, will the code loaded from a .jl  always be precompiled in .4? If 
>> not, how do I choose whether it is precompiled or not?
>>
>> Thanks in advance (and my apologies for the basic questions;I'm not a 
>> programmer per se)
>>
>> Chris 
>>
>> On Friday, July 31, 2015 at 7:30:44 AM UTC-4, Tim Holy wrote:
>>>
>>> If MyModule.jl is on your LOAD_PATH, 
>>>
>>> @everywhere import MyModule 
>>>
>>> should work. You can add 
>>>
>>> push!(LOAD_PATH,"/my/code/repository") 
>>>
>>> to your .juliarc.jl file. 
>>>
>>> This has been deprecated because of precompilation; it was felt that the 
>>> string version left it too ambiguous about whether you wanted to load 
>>> the raw 
>>> file or the cached version. 
>>>
>>> Best, 
>>> --Tim 
>>>
>>> On Thursday, July 23, 2015 11:58:58 AM Eduardo Lenz wrote: 
>>> > Hi 
>>> > I just downloaded the last nightly build  and I am receiving a new 
>>> > deprecation message: 
>>> > 
>>> > Warning, "require" is deprecated, use "using" or "import" instead. 
>>> > 
>>> > My question is: I am using "require" due to the need to automatically 
>>> > import these functions for all workers in a cluster. As long as I 
>>> know, to 
>>> > accomplish this task I have to use "require" and also provide the 
>>> correct 
>>> > path of the corresponding .jl files. How can I do this same thing 
>>> using 
>>> > "using" or "import" ? I tried to use it as I was using "require" and 
>>> it is 
>>> > not working as expected. 
>>> > 
>>> > Thanks for your help and sorry for the dumb question. 
>>>
>>>

Re: [julia-users] Deprecation of require

[David Smith]

I'm also wondering how to replace 'require' without modifying the 
LOAD_PATH.  I can't expect my users to know how to make any path changes.

'using' and 'import' doesn't work for my parallel processes even though I'm 
loading a registered package ("DCEMRI").  I get this error.

WARNING: Module DCEMRI not defined on process 2
fatal error on 2: ERROR: UndefVarError: DCEMRI not defined


I have just a small bit of code in a separate file in the DCEMRI package 
directory that I need each worker to load.  What is the preferred way to 
enable this in 0.4?


On Thursday, September 17, 2015 at 7:18:54 AM UTC-5, Christopher Fisher 
wrote:
>
> I am using .4.0-rc1 and have encountered a similar situation and have 
> fairly basic questions about the way .4 loads files. I normally use require 
> to load a file of functions from my working directory in to Julia on a 
> local computer or a cluster of computers. I was hoping someone would be 
> willing to answer a few related questions. 
>
> First, where can I find the .juliarc.jl file?
>
> Second, is there an easier way to load a .jl file from my working 
> directory into Julia onto a local computer or cluster of computers that 
> does not require editing the .juliarc.fil file? (Editing this file for 
> every project seems a little inconvenient). 
>
> Third, will the code loaded from a .jl  always be precompiled in .4? If 
> not, how do I choose whether it is precompiled or not?
>
> Thanks in advance (and my apologies for the basic questions;I'm not a 
> programmer per se)
>
> Chris 
>
> On Friday, July 31, 2015 at 7:30:44 AM UTC-4, Tim Holy wrote:
>>
>> If MyModule.jl is on your LOAD_PATH, 
>>
>> @everywhere import MyModule 
>>
>> should work. You can add 
>>
>> push!(LOAD_PATH,"/my/code/repository") 
>>
>> to your .juliarc.jl file. 
>>
>> This has been deprecated because of precompilation; it was felt that the 
>> string version left it too ambiguous about whether you wanted to load the 
>> raw 
>> file or the cached version. 
>>
>> Best, 
>> --Tim 
>>
>> On Thursday, July 23, 2015 11:58:58 AM Eduardo Lenz wrote: 
>> > Hi 
>> > I just downloaded the last nightly build  and I am receiving a new 
>> > deprecation message: 
>> > 
>> > Warning, "require" is deprecated, use "using" or "import" instead. 
>> > 
>> > My question is: I am using "require" due to the need to automatically 
>> > import these functions for all workers in a cluster. As long as I know, 
>> to 
>> > accomplish this task I have to use "require" and also provide the 
>> correct 
>> > path of the corresponding .jl files. How can I do this same thing using 
>> > "using" or "import" ? I tried to use it as I was using "require" and it 
>> is 
>> > not working as expected. 
>> > 
>> > Thanks for your help and sorry for the dumb question. 
>>
>>

[julia-users] Re: VAR estimation in Julia

[Patrick Kofod Mogensen]

I'm not aware of any packages in metadata, but you can perhaps get 
inspiration from 

https://github.com/andreasnoack/Civecm.jl (Cointegrated VAR models)
https://github.com/tomaskrehlik/VARmodels.jl (VAR models)

Neither are from repositories registered in METADATA.jl, so don't expect 
too much support. They do not seem to have been updated too recently either 
(5-7 months).

On Friday, October 16, 2015 at 3:03:41 PM UTC-4, Michael Wang wrote:
>
> Hi all,
>
> I am trying to estimation a vector autoregressive model, but I did not 
> find a specific Julia package performing the job. Does anyone know that 
> there is some package doing this?
>
> Thanks!
>

[julia-users] Installing package (Cpp). Could not spawn 'make'.

[Tony Kelman]

Quite a few Julia packages are written in a way that assumes you're on Linux or 
Mac with build tools installed. Not all, and we're gradually fixing cases where 
packages can be made more portable. Best thing to do for now would be to submit 
a pull request adding a note to the readme that the package does not currently 
work on Windows, to save future users a bit of confusion.

[julia-users] CCALL to intel MKL on MAC ?

[Lionel du Peloux]

Dear all,

I'm struggling with the Julia C-API. I've installed the last version of the 
Intel Composer on my Mac (MKL & C++ compiler).
I thought I could call MKL directly from Julia with the C-API as explained 
in the doc, using MKL Single Dynamic Library 
(SDL) 
model.

I've tried to wrap the asum for double (inspired by the Base.LinAlg.BLAS 
source code) :

function myasum(n::Integer, X::Vector{Float64}, incx::Integer)
  ccall((:cblas_dasum, "/opt/intel/mkl/lib/libmkl_rt"), 
Float64, 
(Ptr{Int64}, Ptr{Float64}, Ptr{Int64}),
&n, X, &incx)
end

X = Float64[1,2,3]
myasum(3,X,1)

It seems the dylib is reached and the "cblas_dasum" is the right name to 
call (otherwidse I get some errors about that).

But now my Julia gets into this error :
Intel MKL FATAL ERROR:
Cannot load libmkl_intel_thread.dylib.

I've tried to add /opt/intel/mkl/lib and /opt/intel/lib directories to my 
PATH, but I still get the same error ...

Do you have any though how I can make it work ??

Thank you for helping,
Lionel

[julia-users] juliaw.exe? Run julia without terminal window popup?

[feza]

How can  I run julia without a terminal window poping up.

Something like where in python you have: pythonw.exe to do this and  also 
javaw.exe for java.

I

[julia-users] VAR estimation in Julia

[Michael Wang]

Hi all,

I am trying to estimation a vector autoregressive model, but I did not find 
a specific Julia package performing the job. Does anyone know that there is 
some package doing this?

Thanks!

Re: [julia-users] Re: Type array bug?

[Steven G. Johnson]

On Friday, October 16, 2015 at 1:55:19 PM UTC-4, Andras Niedermayer wrote:
>
> You can also use `map`, which is better at type inference:
>
> julia> M=10
> 10
>
> julia> [[i] for i=1:M]
> 10-element Array{Any,1}:
>

As usual, type inference is much better if you don't run it in global scope 
(that's why your "map" example worked better):

julia> *f(M) = [[i] for i=1:M]*

f (generic function with 1 method)


julia> *f(10)*

10-element Array{Array{Int64,1},1}:

 [1] 

 [2] 

 [3] 

 [4] 

 [5] 

 [6] 

 [7] 

 [8] 

 [9] 
 [10] 

Re: [julia-users] Does anyone have a fork/branch of Sundials.jl that works on 0.4/0.5?

[Mauro]

The ODE.jl solvers work with 0.4/0.5 (or if not, report and they will be
updated), but presumably you use Sundials.jl because ODE.jl isn't good
enough yet.

Anyway, it's probably best to file a issue with Sundials.jl.  Oh, it's
there already: https://github.com/JuliaLang/Sundials.jl/issues/54

On Fri, 2015-10-16 at 09:28, Simon Frost  wrote:
> Dear All,
>
> Sundials.jl master isn't compatible with 0.4/0.5, I presume due to the
> changes in Ref/Ptr between 0.3 and 0.4. There's quite a few forks and
> branches, which look as though at least in some cases, this has been fixed
> - I care mostly about cvode. Rather than wade through installation and
> testing of a whole bunch of branches, it would be great if someone could
> point me in the right direction of a repo to clone, as I don't know when
> there's going to be a PR.
>
> Best wishes,
> Simon

[julia-users] Show gif in IJulia

[Tom Breloff]

I have an animated gif that I'd like to display in IJulia.  I plan to serve 
it using this method:

function Base.writemime(io::IO, ::MIME"text/html", agif::AnimatedGif)
  write(io, "")
end


This works as expected if the file name is relative and inside the working 
directory, but if it's an absolute path or a path outside the working 
directory it doesn't display.  Is there a way to show the file without 
copying it to the working directory?

[julia-users] Re: [ANN] JuliaIO and FileIO

[MA Laforge]

Hi Simon,

Thanks for the comments.

>In the end, I would rather like to have the hierarchy in the Julia objects 
that get returned by load (e.g. AbstractString <: UTF8String etc)

Hmm... Did not think of this... I guess because an encoding is not 
technically a string, but maybe that does not matter...

>- There are many IO libraries which should get dynamically loaded when the 
format is detected (first argument for registry)

I don't think I really understand this part... I usually like to explicitly 
pick which libraries I want my program to use...  But it looks like FileIO 
auto-loads libraries.  I'm not saying this is necessarily a bad thing... 
I'm just not used to thinking that way.

>- we utilize magic bytes to recognize file formats (second argument for 
registry)

Indeed that part is great!  I just don't need it at the moment - because 
with the code I am writing (right know) I already know the file type.

That said: I *know* I can make use of the magic byte detection in the 
future.  Thanks for that!

>- there are multiple IO libraries for the same formats and we need to 
choose one dynamically.

Maybe that's one of the things I don't get fully... I would expect that if 
you have two PNG reader libraries:

using MyPNGLib
or
using ThisGuysEvenBetterPNGLib


Then, whichever library was "using"d should have registered itself with 
FileIO, and would then be used when the user calls:
img = load(File{format"PNG"}("thisimage.png"))

>>but something seems a little off about how I use/generate objects
>I'm not really sure what you mean by that.

Indeed... I'm not sure either... I'm trying to figure that out:

At the moment, one thing I can think of are issues I expect when building 
an image editor program:

module MyImageEditor #Think of something like GIMP

#This would be a high-level open function that does everything necessary to
#"open" the file to a new canvas:
function open{T<:PixelImageFormat}(file::File{T})
data = FileIO.load(file)
#Create new canvas
#Populate canvas with data
#Show canvas
end

function open{T<:VectorImageFormat}(file::File{T})
#Ask user what resolution they want for the rendered bitmap
data = FileIO.load(file)
#Create new canvas
#Render vector image to canvas
#Populate canvas with data
#Show canvas
end

#For any other file:
function open{T}(file::File{T})
throw("Cannot open this kind of file... not a (recognized) image")
end

#When the user clicks "ok":
function imgopendlg_ok(dlg::ImgOpenDlg)
#I assume FileIO could have an "autodetect" function that tries to
#determine the most likely file type from the extension, then confirm
#everything is ok using magic byes
file = FileIO.autodetect(dlg.filepath)
#Now file is a File object with type information.

try
open(file)
catch e
display_message(e)
end
end

end #module

As far as I can tell: If I were to try to open a large movie instead of a 
pixel image, I expect the following issues:

1) The current implementation of FileIO will try to auto-load the movie 
libraries I don't want to include with my program (because the code to 
register file readers is actually *inside* the FileIO module?? - I think?)

2) I would have to wait until my program has loaded the movie file before I 
can detect it was a movie file, and *then* I can finally catch it as an 
exception:

function open(file::File) #In MyImageEditor
data = FileIO.load(file)
if !isimage(data)
throw("Cannot open this kind of file... not a (recognized) image")
end
#Create new canvas
#Populate canvas with data
#Show canvas
end

isimage(data::PNGData) = true
isimage(data::BMPData) = true
...
isimage(unknowndata) = false

...Or something similar.

To be fair: I am almost certain the the biggest reason for my unease with 
FileIO is that I have not seen enough examples on how to use the module 
properly.

Can you point me to good example projects/other modules that use FileIO as 
intended?  I am only getting a vague feel for its use by reading the 
included tests.

Otherwise: I guess I will wait until more examples are available - or keep 
trying to play around with FileIO's capabilities when I have time.

Best Regards,

MA

Re: [julia-users] Re: Type array bug?

[Yichao Yu]

On Fri, Oct 16, 2015 at 1:55 PM, Andras Niedermayer
 wrote:
> You can also use `map`, which is better at type inference:

map is not better at type inference. It doesn't use type inference at
all for to determine the return type.

>
> julia> M=10
> 10
>
> julia> [[i] for i=1:M]
> 10-element Array{Any,1}:
>  [1]
>  [2]
>  [3]
>  [4]
>  [5]
>  [6]
>  [7]
>  [8]
>  [9]
>  [10]
>
> julia> map(x->[x],1:M)
> 10-element Array{Array{Int64,1},1}:
>  [1]
>  [2]
>  [3]
>  [4]
>  [5]
>  [6]
>  [7]
>  [8]
>  [9]
>  [10]
>
>
> On Friday, October 16, 2015 at 4:37:26 PM UTC+2, Yichao Yu wrote:
>>
>> On Fri, Oct 16, 2015 at 10:23 AM, Tomas Lycken 
>> wrote:
>> > If you execute this in a function, or in a script file, this won’t
>> > happen.
>> >
>> > The problem when doing it in the REPL is that Julia can’t know what you
>> > will
>> > do with the list variable in the future, so it has to be very defensive
>> > with
>> > type inference, to avoid having to throw nasty type errors later.
>>
>> The issue is related to type inference in global scope but,
>>
>> 1. Putting in a script won't help because it's still in the global scope
>> 2. The issue isn't about future use of list, is't about `M`. Julia
>> have no way to garentee that the type of M is always constant when
>> it's using it (yes, in this case it doesn't change but the compiler
>> cannot know that before running your code)
>> 3. const M = 10 should work
>> 4. putting this in a function should also work
>> 5. There's also discussion about type-inference-free comprehensions.
>>
>> >
>> > // T
>> >
>> > On Friday, October 16, 2015 at 4:19:54 PM UTC+2, Thuener Silva wrote:
>> >>
>> >> I want to create an array of arrays of int64. But sometimes the type
>> >> change to Any, why? It is a bug?
>> >>
>> >> julia> M = 10
>> >> julia> typeof(M)
>> >> Int64
>> >>
>> >> julia> list = [[i] for i=1:M]
>> >> 10-element Array{Any,1}:
>> >>  [1]
>> >>  [2]
>> >>  [3]
>> >>  [4]
>> >>  [5]
>> >>  [6]
>> >>  [7]
>> >>  [8]
>> >>  [9]
>> >>  [10]
>> >>
>> >>  list = [[i] for i=1:10]
>> >> 10-element Array{Array{Int64,1},1}:
>> >>  [1]
>> >>  [2]
>> >>  [3]
>> >>  [4]
>> >>  [5]
>> >>  [6]
>> >>  [7]
>> >>  [8]
>> >>  [9]
>> >>  [10]
>> >>
>> >> Grats,
>> >> Thuener Silva
>> >>
>> >

Re: [julia-users] Re: Type array bug?

[Andras Niedermayer]

You can also use `map`, which is better at type inference:

julia> M=10
10

julia> [[i] for i=1:M]
10-element Array{Any,1}:
 [1] 
 [2] 
 [3] 
 [4] 
 [5] 
 [6] 
 [7] 
 [8] 
 [9] 
 [10]

julia> map(x->[x],1:M)
10-element Array{Array{Int64,1},1}:
 [1] 
 [2] 
 [3] 
 [4] 
 [5] 
 [6] 
 [7] 
 [8] 
 [9] 
 [10]


On Friday, October 16, 2015 at 4:37:26 PM UTC+2, Yichao Yu wrote:
>
> On Fri, Oct 16, 2015 at 10:23 AM, Tomas Lycken  > wrote: 
> > If you execute this in a function, or in a script file, this won’t 
> happen. 
> > 
> > The problem when doing it in the REPL is that Julia can’t know what you 
> will 
> > do with the list variable in the future, so it has to be very defensive 
> with 
> > type inference, to avoid having to throw nasty type errors later. 
>
> The issue is related to type inference in global scope but, 
>
> 1. Putting in a script won't help because it's still in the global scope 
> 2. The issue isn't about future use of list, is't about `M`. Julia 
> have no way to garentee that the type of M is always constant when 
> it's using it (yes, in this case it doesn't change but the compiler 
> cannot know that before running your code) 
> 3. const M = 10 should work 
> 4. putting this in a function should also work 
> 5. There's also discussion about type-inference-free comprehensions. 
>
> > 
> > // T 
> > 
> > On Friday, October 16, 2015 at 4:19:54 PM UTC+2, Thuener Silva wrote: 
> >> 
> >> I want to create an array of arrays of int64. But sometimes the type 
> >> change to Any, why? It is a bug? 
> >> 
> >> julia> M = 10 
> >> julia> typeof(M) 
> >> Int64 
> >> 
> >> julia> list = [[i] for i=1:M] 
> >> 10-element Array{Any,1}: 
> >>  [1] 
> >>  [2] 
> >>  [3] 
> >>  [4] 
> >>  [5] 
> >>  [6] 
> >>  [7] 
> >>  [8] 
> >>  [9] 
> >>  [10] 
> >> 
> >>  list = [[i] for i=1:10] 
> >> 10-element Array{Array{Int64,1},1}: 
> >>  [1] 
> >>  [2] 
> >>  [3] 
> >>  [4] 
> >>  [5] 
> >>  [6] 
> >>  [7] 
> >>  [8] 
> >>  [9] 
> >>  [10] 
> >> 
> >> Grats, 
> >> Thuener Silva 
> >> 
> > 
>

Re: [julia-users] Benchmarking Julia HttpServer

[Jonathan Malmaud]

Ya, it does seem to reproduce. Maybe the first step to investigating is to 
write a super-minimal Julia server that does nothing but listens for TCP 
connections, spawn a task which sends a fixed response on accepted connection, 
and then closes the socket.If that still has this problem, then it might relate 
to a low-level issue with tasks/libuv. 

> On Oct 16, 2015, at 8:52 AM, nikolai.mar...@icloud.com wrote:
> 
> Sure, here it is: https://github.com/JuliaWeb/HttpServer.jl/issues/78
> I hope you can reproduce this behaviour.
> 
> Any ideas how to investigate it?
> 
> On Friday, October 16, 2015 at 4:29:44 PM UTC+3, Jonathan Malmaud wrote:
> Can you file this as an issue on https://github.com/JuliaWeb/HttpServer.jl 
> ? 
> 
> On Friday, October 16, 2015 at 7:31:34 AM UTC-5, nikolai...@icloud.com <> 
> wrote:
> Status update.
> 
> I have updated to Julia 0.4 and added keep-alive support to HttpServer and 
> now ab -k works quite fine.
> However when there is no keep-alive and each request is made in a separate 
> connection, then Julia still hangs around request #16k.
> My first idea of how to profile it was this:
> 
> using HttpServer
> gc_enable(false)
> const Z = "HELLO WORLD"
> c = 0s = open("./prof.txt", "w")
> http = HttpHandler() do req::Request, res::Response
>global cr = Response(Z)c += 1if c == 16000   
> Profile.clear()
>endif c > 16428
>   c = 0   Profile.print(s, C=true, cols=500)   close(s)end
> rend
> server = Server( http )
> @profile run( server, 8000 )
> 
> However the output I got is 19k lines long and I have no idea how to use it. 
> Here's a top of it:
> 3 /private/tmp/julia20151012-99535-1c7kouk/src/builtins.c; jl_egal; line: 
> 3061 /private/tmp/julia20151012-99535-1c7kouk/src/builtins.c; jl_f_isa; 
> line: 3701 /private/tmp/julia20151012-99535-1c7kouk/src/gc.c; 
> jl_gc_alloc_3w; line: 23321 
> /private/tmp/julia20151012-99535-1c7kouk/src/gf.c; jl_apply_generic; line: 
> 17111 /private/tmp/julia20151012-99535-1c7kouk/src/jltypes.c; jl_is_type; 
> line: 691 /private/tmp/julia20151012-99535-1c7kouk/src/jltypes.c; 
> jl_subtype_le; line: 25591683  
> /private/tmp/julia20151012-99535-1c7kouk/src/task.c; jl_apply; line: 2415 
> /private/tmp/julia20151012-99535-1c7kouk/src/task.c; throw_if_exception_set; 
> line: 2301 /usr/lib/system/libsystem_c.dylib; strlen; (unknown line)1 
> /usr/lib/system/libsystem_kernel.dylib; __accept; (unknown line)1 
> /usr/lib/system/libsystem_kernel.dylib; __ioctl; (unknown line)7 
> /usr/lib/system/libsystem_kernel.dylib; close; (unknown line)26463 
> /usr/lib/system/libsystem_kernel.dylib; kevent; (unknown line)4 
> /usr/lib/system/libsystem_kernel.dylib; mach_timebase_info; (unknown line)1   
>   /usr/lib/system/libsystem_kernel.dylib; read; (unknown line)4 
> /usr/lib/system/libsystem_kernel.dylib; shutdown; (unknown line)30
> /usr/lib/system/libsystem_kernel.dylib; write; (unknown line)39
> /usr/lib/system/libsystem_platform.dylib; _platform_bzero$VARIANT$Unknown; 
> (unknown line)2 /usr/lib/system/libsystem_platform.dylib; 
> _platform_memcmp; (unknown line)5 
> /usr/lib/system/libsystem_platform.dylib; _platform_memmove$VARIANT$Unknown; 
> (unknown line)1 /usr/lib/system/libsystem_platform.dylib; 
> _platform_memset$VARIANT$Unknown; (unknown line)2 
> /usr/lib/system/libsystem_platform.dylib; _setjmp; (unknown line)1 /
> ...

Re: [julia-users] Re: Type array bug?

[Yichao Yu]

On Fri, Oct 16, 2015 at 10:23 AM, Tomas Lycken  wrote:
> If you execute this in a function, or in a script file, this won’t happen.
>
> The problem when doing it in the REPL is that Julia can’t know what you will
> do with the list variable in the future, so it has to be very defensive with
> type inference, to avoid having to throw nasty type errors later.

The issue is related to type inference in global scope but,

1. Putting in a script won't help because it's still in the global scope
2. The issue isn't about future use of list, is't about `M`. Julia
have no way to garentee that the type of M is always constant when
it's using it (yes, in this case it doesn't change but the compiler
cannot know that before running your code)
3. const M = 10 should work
4. putting this in a function should also work
5. There's also discussion about type-inference-free comprehensions.

>
> // T
>
> On Friday, October 16, 2015 at 4:19:54 PM UTC+2, Thuener Silva wrote:
>>
>> I want to create an array of arrays of int64. But sometimes the type
>> change to Any, why? It is a bug?
>>
>> julia> M = 10
>> julia> typeof(M)
>> Int64
>>
>> julia> list = [[i] for i=1:M]
>> 10-element Array{Any,1}:
>>  [1]
>>  [2]
>>  [3]
>>  [4]
>>  [5]
>>  [6]
>>  [7]
>>  [8]
>>  [9]
>>  [10]
>>
>>  list = [[i] for i=1:10]
>> 10-element Array{Array{Int64,1},1}:
>>  [1]
>>  [2]
>>  [3]
>>  [4]
>>  [5]
>>  [6]
>>  [7]
>>  [8]
>>  [9]
>>  [10]
>>
>> Grats,
>> Thuener Silva
>>
>

[julia-users] Re: Type array bug?

[Tomas Lycken]

If you execute this in a function, or in a script file, this won’t happen.

The problem when doing it in the REPL is that Julia can’t know what you 
will do with the list variable in the future, so it has to be very 
defensive with type inference, to avoid having to throw nasty type errors 
later.

// T

On Friday, October 16, 2015 at 4:19:54 PM UTC+2, Thuener Silva wrote:

I want to create an array of arrays of int64. But sometimes the type change 
> to Any, why? It is a bug?
>
> julia> M = 10
> julia> typeof(M)
> Int64
>
> julia> list = [[i] for i=1:M]
> 10-element Array{Any,1}:
>  [1] 
>  [2] 
>  [3] 
>  [4] 
>  [5] 
>  [6] 
>  [7] 
>  [8] 
>  [9] 
>  [10]
>
>  list = [[i] for i=1:10]
> 10-element Array{Array{Int64,1},1}:
>  [1] 
>  [2] 
>  [3] 
>  [4] 
>  [5] 
>  [6] 
>  [7] 
>  [8] 
>  [9] 
>  [10]
>
> Grats,
> Thuener Silva
>
> ​

[julia-users] Type array bug?

[Thuener Silva]

I want to create an array of arrays of int64. But sometimes the type change 
to Any, why? It is a bug?

julia> M = 10
julia> typeof(M)
Int64

julia> list = [[i] for i=1:M]
10-element Array{Any,1}:
 [1] 
 [2] 
 [3] 
 [4] 
 [5] 
 [6] 
 [7] 
 [8] 
 [9] 
 [10]

 list = [[i] for i=1:10]
10-element Array{Array{Int64,1},1}:
 [1] 
 [2] 
 [3] 
 [4] 
 [5] 
 [6] 
 [7] 
 [8] 
 [9] 
 [10]

Grats,
Thuener Silva

[julia-users] Re: GraphPlot.jl

[Kristoffer Carlsson]

Cool!

On Friday, October 16, 2015 at 2:57:25 PM UTC+2, Jihui Han wrote:
>
> https://github.com/afternone/GraphPlot.jl
>
>
> 
>
>
> 
>
>
> 
>
>
> 
>
>
> 
>
>

[julia-users] Re: Benchmarking Julia HttpServer

[nikolai . markov]

Sure, here it is: https://github.com/JuliaWeb/HttpServer.jl/issues/78
I hope you can reproduce this behaviour.

Any ideas how to investigate it?

On Friday, October 16, 2015 at 4:29:44 PM UTC+3, Jonathan Malmaud wrote:
>
> Can you file this as an issue on https://github.com/JuliaWeb/HttpServer.jl
> ? 
>
> On Friday, October 16, 2015 at 7:31:34 AM UTC-5, nikolai...@icloud.com 
> wrote:
>>
>> Status update.
>>
>> I have updated to Julia 0.4 and added keep-alive support to HttpServer 
>> and now ab -k works quite fine.
>> However when there is no keep-alive and each request is made in a 
>> separate connection, then Julia still hangs around request #16k.
>> My first idea of how to profile it was this:
>>
>>
>> using HttpServer
>>
>> gc_enable(false)
>>
>> const Z = "HELLO WORLD"
>>
>> c = 0
>>
>> s = open("./prof.txt", "w")
>>
>> http = HttpHandler() do req::Request, res::Response
>>
>>global c
>>
>>r = Response(Z)
>>
>>c += 1
>>
>>if c == 16000
>>
>>   Profile.clear()
>>end
>>
>>if c > 16428
>>   c = 0
>>
>>   Profile.print(s, C=true, cols=500)
>>
>>   close(s)
>>
>>end
>>
>>r
>>
>> end
>>
>> server = Server( http )
>>
>> @profile run( server, 8000 )
>>
>> However the output I got is 19k lines long and I have no idea how to use 
>> it. Here's a top of it:
>>
>> 3 /private/tmp/julia20151012-99535-1c7kouk/src/builtins.c; jl_egal; 
>> line: 306
>>
>> 1 /private/tmp/julia20151012-99535-1c7kouk/src/builtins.c; jl_f_isa; 
>> line: 370
>>
>> 1 /private/tmp/julia20151012-99535-1c7kouk/src/gc.c; jl_gc_alloc_3w; 
>> line: 2332
>>
>> 1 /private/tmp/julia20151012-99535-1c7kouk/src/gf.c; jl_apply_generic
>> ; line: 1711
>>
>> 1 /private/tmp/julia20151012-99535-1c7kouk/src/jltypes.c; jl_is_type; 
>> line: 69
>>
>> 1 /private/tmp/julia20151012-99535-1c7kouk/src/jltypes.c; 
>> jl_subtype_le; line: 2559
>>
>> 1683  /private/tmp/julia20151012-99535-1c7kouk/src/task.c; jl_apply; line
>> : 241
>>
>> 5 /private/tmp/julia20151012-99535-1c7kouk/src/task.c; 
>> throw_if_exception_set; line: 230
>>
>> 1 /usr/lib/system/libsystem_c.dylib; strlen; (unknown line)
>>
>> 1 /usr/lib/system/libsystem_kernel.dylib; __accept; (unknown line)
>>
>> 1 /usr/lib/system/libsystem_kernel.dylib; __ioctl; (unknown line)
>>
>> 7 /usr/lib/system/libsystem_kernel.dylib; close; (unknown line)
>>
>> 26463 /usr/lib/system/libsystem_kernel.dylib; kevent; (unknown line)
>>
>> 4 /usr/lib/system/libsystem_kernel.dylib; mach_timebase_info; (unknown 
>> line)
>>
>> 1 /usr/lib/system/libsystem_kernel.dylib; read; (unknown line)
>>
>> 4 /usr/lib/system/libsystem_kernel.dylib; shutdown; (unknown line)
>>
>> 30/usr/lib/system/libsystem_kernel.dylib; write; (unknown line)
>>
>> 39/usr/lib/system/libsystem_platform.dylib; 
>> _platform_bzero$VARIANT$Unknown; (unknown line)
>>
>> 2 /usr/lib/system/libsystem_platform.dylib; _platform_memcmp; (unknown 
>> line)
>>
>> 5 /usr/lib/system/libsystem_platform.dylib; 
>> _platform_memmove$VARIANT$Unknown; (unknown line)
>>
>> 1 /usr/lib/system/libsystem_platform.dylib; 
>> _platform_memset$VARIANT$Unknown; (unknown line)
>>
>> 2 /usr/lib/system/libsystem_platform.dylib; _setjmp; (unknown line)
>>
>> 1 /
>> ...
>
>

[julia-users] Re: Windows: enforce update of ENV["PATH"] after modifying it.

[bernhard]

No. That does not work for me.
Maybe there is a difference if you change the user path or the system path 
variable...
Or maybe there is some windows setting which handles the caching.
Or maybe you use another windows version. I am on 7 Enterprise.
It is fine though. Log off or reboot will do.

Am Freitag, 16. Oktober 2015 15:35:39 UTC+2 schrieb J Luis:
>
> What???
>
> I do that type of things all the time and never need to sign-out.
> How do you change the PATH variable? If done with the System->... 
> Environment variables box, one have to hit 'Apply' and that's it.
>
> sexta-feira, 16 de Outubro de 2015 às 13:07:24 UTC+1, Tomas Lycken 
> escreveu:
>>
>> Modifying environment variables on Windows usually requires at least a 
>> sign out-sign in again. Can you try that?
>>
>> // T
>>
>> On Friday, October 16, 2015 at 2:06:26 PM UTC+2, bernhard wrote:
>>>
>>> Hi 
>>> can anyone help me with this? When PATH is modified this is not 
>>> immediately reflected in Julia (even after closing and starting Julia 
>>> again). I wonder if this can be done without a reboot.
>>> I am not sure whether this is at all a Julia issue though.
>>>
>>> Bernhard
>>>
>>

[julia-users] Re: Windows: enforce update of ENV["PATH"] after modifying it.

[J Luis]

What???

I do that type of things all the time and never need to sign-out.
How do you change the PATH variable? If done with the System->... 
Environment variables box, one have to hit 'Apply' and that's it.

sexta-feira, 16 de Outubro de 2015 às 13:07:24 UTC+1, Tomas Lycken escreveu:
>
> Modifying environment variables on Windows usually requires at least a 
> sign out-sign in again. Can you try that?
>
> // T
>
> On Friday, October 16, 2015 at 2:06:26 PM UTC+2, bernhard wrote:
>>
>> Hi 
>> can anyone help me with this? When PATH is modified this is not 
>> immediately reflected in Julia (even after closing and starting Julia 
>> again). I wonder if this can be done without a reboot.
>> I am not sure whether this is at all a Julia issue though.
>>
>> Bernhard
>>
>

Re: [julia-users] Re: Julia Docker images

[Jonathan Malmaud]

Thanks André, looking forward to it.

Also wanted to mention that the official Julia Docker image has been 
updated to v0.4, so

docker run -it julia 

will now work for getting anyone with Docker installed into a Julia .4 
prompt, no fuss.

On Thursday, October 15, 2015 at 7:34:34 PM UTC-5, André Lage wrote:
>
> Hi, 
>
> We customized our Docker image from Ubuntu. 
>
> Jonathan, we are using Docker containers to host Julia workers through 
> SSH, you could straightforwardly use our code/Dockerfile to `docker 
> run -it julia` if you want. We are running some tests and we plan to 
> share everything next week. We're excited to get feedback from the 
> community. 
>
> André Lage. 
>
>
> On Wed, Oct 14, 2015 at 2:41 AM, Tony Kelman  > wrote: 
> > I've also been working on a set of containers on docker hub for source 
> builds of dependencies and potential CI uses. Will see if anything 
> interesting comes out of it. Travis lets you use custom docker images as a 
> new beta feature, though there may be a potential issue with UDP tests. 
>

[julia-users] Re: Benchmarking Julia HttpServer

[Jonathan Malmaud]

Can you file this as an issue on https://github.com/JuliaWeb/HttpServer.jl? 

On Friday, October 16, 2015 at 7:31:34 AM UTC-5, nikolai...@icloud.com 
wrote:
>
> Status update.
>
> I have updated to Julia 0.4 and added keep-alive support to HttpServer and 
> now ab -k works quite fine.
> However when there is no keep-alive and each request is made in a separate 
> connection, then Julia still hangs around request #16k.
> My first idea of how to profile it was this:
>
>
> using HttpServer
>
> gc_enable(false)
>
> const Z = "HELLO WORLD"
>
> c = 0
>
> s = open("./prof.txt", "w")
>
> http = HttpHandler() do req::Request, res::Response
>
>global c
>
>r = Response(Z)
>
>c += 1
>
>if c == 16000
>
>   Profile.clear()
>end
>
>if c > 16428
>   c = 0
>
>   Profile.print(s, C=true, cols=500)
>
>   close(s)
>
>end
>
>r
>
> end
>
> server = Server( http )
>
> @profile run( server, 8000 )
>
> However the output I got is 19k lines long and I have no idea how to use 
> it. Here's a top of it:
>
> 3 /private/tmp/julia20151012-99535-1c7kouk/src/builtins.c; jl_egal; 
> line: 306
>
> 1 /private/tmp/julia20151012-99535-1c7kouk/src/builtins.c; jl_f_isa; 
> line: 370
>
> 1 /private/tmp/julia20151012-99535-1c7kouk/src/gc.c; jl_gc_alloc_3w; 
> line: 2332
>
> 1 /private/tmp/julia20151012-99535-1c7kouk/src/gf.c; jl_apply_generic; 
> line: 1711
>
> 1 /private/tmp/julia20151012-99535-1c7kouk/src/jltypes.c; jl_is_type; 
> line: 69
>
> 1 /private/tmp/julia20151012-99535-1c7kouk/src/jltypes.c; 
> jl_subtype_le; line: 2559
>
> 1683  /private/tmp/julia20151012-99535-1c7kouk/src/task.c; jl_apply; line: 
> 241
>
> 5 /private/tmp/julia20151012-99535-1c7kouk/src/task.c; 
> throw_if_exception_set; line: 230
>
> 1 /usr/lib/system/libsystem_c.dylib; strlen; (unknown line)
>
> 1 /usr/lib/system/libsystem_kernel.dylib; __accept; (unknown line)
>
> 1 /usr/lib/system/libsystem_kernel.dylib; __ioctl; (unknown line)
>
> 7 /usr/lib/system/libsystem_kernel.dylib; close; (unknown line)
>
> 26463 /usr/lib/system/libsystem_kernel.dylib; kevent; (unknown line)
>
> 4 /usr/lib/system/libsystem_kernel.dylib; mach_timebase_info; (unknown 
> line)
>
> 1 /usr/lib/system/libsystem_kernel.dylib; read; (unknown line)
>
> 4 /usr/lib/system/libsystem_kernel.dylib; shutdown; (unknown line)
>
> 30/usr/lib/system/libsystem_kernel.dylib; write; (unknown line)
>
> 39/usr/lib/system/libsystem_platform.dylib; 
> _platform_bzero$VARIANT$Unknown; (unknown line)
>
> 2 /usr/lib/system/libsystem_platform.dylib; _platform_memcmp; (unknown 
> line)
>
> 5 /usr/lib/system/libsystem_platform.dylib; 
> _platform_memmove$VARIANT$Unknown; (unknown line)
>
> 1 /usr/lib/system/libsystem_platform.dylib; 
> _platform_memset$VARIANT$Unknown; (unknown line)
>
> 2 /usr/lib/system/libsystem_platform.dylib; _setjmp; (unknown line)
>
> 1 /
> ...

[julia-users] GraphPlot.jl

[Jihui Han]

https://github.com/afternone/GraphPlot.jl

[julia-users] Installing package (Cpp). Could not spawn 'make'.

[Joel]

I am trying to install the package Cpp. However, I get an error when 
building it. I have been trawling different forums but have not managed to 
solve it.

julia> Pkg.add("Cpp")
INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
INFO: Cloning cache of Cpp from git://github.com/timholy/Cpp.jl.git
INFO: Installing Cpp v0.1.0
INFO: Building Cpp

=[ ERROR: Cpp 
]=


LoadError: could not spawn `make`: no such file or directory (ENOENT)
while loading C:\Users\Joel\.julia\v0.4\Cpp\deps\build.jl, in expression 
startin
g on line 1




[ BUILD ERRORS 
]


WARNING: Cpp had build errors.

 - packages with build errors remain installed in C:\Users\Joel\.julia\v0.4
 - build the package(s) and all dependencies with `Pkg.build("Cpp")`
 - build a single package by running its `deps/build.jl` script



Could anyone shed some light? Bear with me, I am new to Julia (background 
in Matlab (for context)).

Thanks in advance!

[julia-users] Re: got v0.4.0, stuck in Pkg.update()

[Jeffrey Sarnoff]

thank you

On Friday, October 16, 2015 at 7:53:59 AM UTC-4, Tony Kelman wrote:
>
> Remove them from the ~/.julia/v0.4/REQUIRE file too

[julia-users] Re: Benchmarking Julia HttpServer

[nikolai . markov]

Status update.

I have updated to Julia 0.4 and added keep-alive support to HttpServer and 
now ab -k works quite fine.
However when there is no keep-alive and each request is made in a separate 
connection, then Julia still hangs around request #16k.
My first idea of how to profile it was this:


using HttpServer

gc_enable(false)

const Z = "HELLO WORLD"

c = 0

s = open("./prof.txt", "w")

http = HttpHandler() do req::Request, res::Response

   global c

   r = Response(Z)

   c += 1

   if c == 16000

  Profile.clear()
   end

   if c > 16428
  c = 0

  Profile.print(s, C=true, cols=500)

  close(s)

   end

   r

end

server = Server( http )

@profile run( server, 8000 )

However the output I got is 19k lines long and I have no idea how to use 
it. Here's a top of it:

3 /private/tmp/julia20151012-99535-1c7kouk/src/builtins.c; jl_egal; line
: 306

1 /private/tmp/julia20151012-99535-1c7kouk/src/builtins.c; jl_f_isa; 
line: 370

1 /private/tmp/julia20151012-99535-1c7kouk/src/gc.c; jl_gc_alloc_3w; 
line: 2332

1 /private/tmp/julia20151012-99535-1c7kouk/src/gf.c; jl_apply_generic; 
line: 1711

1 /private/tmp/julia20151012-99535-1c7kouk/src/jltypes.c; jl_is_type; 
line: 69

1 /private/tmp/julia20151012-99535-1c7kouk/src/jltypes.c; jl_subtype_le; 
line: 2559

1683  /private/tmp/julia20151012-99535-1c7kouk/src/task.c; jl_apply; line: 
241

5 /private/tmp/julia20151012-99535-1c7kouk/src/task.c; 
throw_if_exception_set; line: 230

1 /usr/lib/system/libsystem_c.dylib; strlen; (unknown line)

1 /usr/lib/system/libsystem_kernel.dylib; __accept; (unknown line)

1 /usr/lib/system/libsystem_kernel.dylib; __ioctl; (unknown line)

7 /usr/lib/system/libsystem_kernel.dylib; close; (unknown line)

26463 /usr/lib/system/libsystem_kernel.dylib; kevent; (unknown line)

4 /usr/lib/system/libsystem_kernel.dylib; mach_timebase_info; (unknown 
line)

1 /usr/lib/system/libsystem_kernel.dylib; read; (unknown line)

4 /usr/lib/system/libsystem_kernel.dylib; shutdown; (unknown line)

30/usr/lib/system/libsystem_kernel.dylib; write; (unknown line)

39/usr/lib/system/libsystem_platform.dylib; 
_platform_bzero$VARIANT$Unknown; (unknown line)

2 /usr/lib/system/libsystem_platform.dylib; _platform_memcmp; (unknown 
line)

5 /usr/lib/system/libsystem_platform.dylib; 
_platform_memmove$VARIANT$Unknown; (unknown line)

1 /usr/lib/system/libsystem_platform.dylib; 
_platform_memset$VARIANT$Unknown; (unknown line)

2 /usr/lib/system/libsystem_platform.dylib; _setjmp; (unknown line)

1 /usr/local/Cellar/julia/0.4.0/lib/julia/libjulia.dylib; 
_ZN4llvm12CallSiteBaseINS_8FunctionENS_5ValueENS_4UserENS_11InstructionENS_8CallInstENS_10InvokeInstEPNS_3UseEE3getEPS2_
; (unknown line)

1 /usr/local/Cellar/julia/0.4.0/lib/julia/libjulia.dylib; 
_ZN4llvm12LeakDetector23removeGarbageObjectImplEPKNS_5ValueE; (unknown line)

1 /usr/local/Cellar/julia/0.4.0/lib/julia/libjulia.dylib; 
_ZN4llvm15FoldingSetTraitINS_6MDNodeEE6EqualsERKS1_RKNS_16FoldingSetNodeIDEjRS5_
; (unknown line)

1 /usr/local/Cellar/julia/0.4.0/lib/julia/libjulia.dylib; 
_ZN4llvm21llvm_is_multithreadedEv; (unknown line)

1 /usr/local/Cellar/julia/0.4.0/lib/julia/libjulia.dylib; 
_ZN4llvm23SmallPtrSetIteratorImpl17AdvanceIfNotValidEv; (unknown line)

1 /usr/local/Cellar/julia/0.4.0/lib/julia/libjulia.dylib; 
_ZN4llvm6iplistINS_6SDNodeENS_12ilist_traitsIS1_EEE6removeERNS_14ilist_iteratorIS1_EE
; (unknown line)

2 /usr/local/Cellar/julia/0.4.0/lib/julia/libjulia.dylib; __muloti4; 
(unknown 
line)

1 /usr/local/Cellar/julia/0.4.0/lib/julia/sys.dylib; anonymous; (unknown 
line)

1 /usr/local/Cellar/julia/0.4.0/lib/julia/sys.dylib; getindex; (unknown 
line)

1 /usr/local/Cellar/julia/0.4.0/lib/julia/sys.dylib; hash; (unknown line
)

1 /usr/local/Cellar/julia/0.4.0/lib/julia/sys.dylib; jlcall_getindex_225
; (unknown line)

18/usr/local/bin/julia; main; (unknown line)

1 unknown function (ip: 0x00030d2f0baa)

Any advice on how to find out what is Julia doing when it doesn't respond 
to a request within dozens of seconds (mean response is 1.8ms) is really 
appreciated.



On Wednesday, August 19, 2015 at 1:42:51 PM UTC+3, nikolai...@icloud.com 
wrote:
>
> Hi there!
> I was trying to do some basic benchmark of Julia's HttpServer, however I 
> have some strange behaviour.
> When I ask ab to do 20k requests in a single thread, at around request 
> #16k Julia starts accepting connections quite slowly (around 20s). If I 
> request two threads, then ab fails with timeout on connecting (60s).
> I thought that the problem may be with the GC so I disabled it, but that 
> didn't help.
> I would be grateful for the tips on how to look into this more closely.
>
> (Julia 0.3.10 via brew on os x)
>

[julia-users] Re: Windows: enforce update of ENV["PATH"] after modifying it.

[Tomas Lycken]

Modifying environment variables on Windows usually requires at least a sign 
out-sign in again. Can you try that?

// T

On Friday, October 16, 2015 at 2:06:26 PM UTC+2, bernhard wrote:
>
> Hi 
> can anyone help me with this? When PATH is modified this is not 
> immediately reflected in Julia (even after closing and starting Julia 
> again). I wonder if this can be done without a reboot.
> I am not sure whether this is at all a Julia issue though.
>
> Bernhard
>

[julia-users] Windows: enforce update of ENV["PATH"] after modifying it.

[bernhard]

Hi 
can anyone help me with this? When PATH is modified this is not immediately 
reflected in Julia (even after closing and starting Julia again). I wonder 
if this can be done without a reboot.
I am not sure whether this is at all a Julia issue though.

Bernhard

[julia-users] got v0.4.0, stuck in Pkg.update()

[Tony Kelman]

Remove them from the ~/.julia/v0.4/REQUIRE file too

[julia-users] got v0.4.0, stuck in Pkg.update()

[Jeffrey Sarnoff]

Pkg.update() is complaining about Polynomial and Curl ("can't be installed 
because it has no versions ...")
I physically removed both from .julia/v0.4 and .julia/v0.4/cache, and 
removed whatever else required either.
What should I do to get this clean?  (could not find a good answer 
elsewhere -- though, it must be somewhere)

Re: [julia-users] Re: a pmap question involving Monte Carlo

[Fisher, Christopher]

Hi Jim-

I realized the issue I was having with pmap was related to your issue.
Moreover, your method of using include() will not always work in .4. So I
posted a link with a working that you may find helpful as a future
reference.

 As an alternative to the "super" array, you can actually use multiple
inputs. For example,

output = pmap((x1)->fun(x1,x2),input1,input2)

where input1 and input2 are arrays of arrays: input1 = Any[parms for i =
1:Nprocessors]

If you want to pass data to the function (e.g. to fit a model), you can do
this:

@everywhere MyData
 pmap((x1)->fun(x1,MyData),input1)

rather than duplicate it in an array of arrays.

Or alternatively pass you can pass MyData through a function containing
pmap and @everywhere MyData can be omitted. (I don't understand the scoping
completely, but those two methods appear to work).


Here are two sources for more information. The second source contains an
example of using parallel code that works in .4. One thing that is
counterinutivie is that you have to state: using MyModule followed by
@everywhere using MyModule. The method you have been using does not seem to
work when packages need to be available to multiple processors. For some
reason, there are variable conflicts due to scoping when using that method
in .4

http://stackoverflow.com/questions/24637064/julia-using-pmap-correctly

https://groups.google.com/forum/#!searchin/julia-users/christopher$20fisher%7Csort:date/julia-users/jgT47LBBtWk/Caje1PhiAwAJ

Best regards and happy coding!

Chris


On Sat, Oct 10, 2015 at 9:01 AM, Christopher Fisher 
wrote:

> Creating a "super" array has worked for me in the past. Of course, someone
> with more experience might have a more elegant solution. Good luck!
>
>
> On Saturday, October 10, 2015 at 8:52:38 AM UTC-4, james...@gmail.com
> wrote:
>>
>> Hi Christopher:
>>
>> Thank you for the suggestions.  I think I understand.
>>
>> Is the fix to create a "super" array, super_array, that contains all the
>> inputs PF_outer wants to pass to PF_inner, i.e., output = pmap(PF_Inner,
>> super_array)?
>>
>> I will give your suggestions a go later today or tomorrow and let you
>> know the outcome.
>>
>> Best wishes,
>>
>> Jim
>>
>> On Saturday, October 10, 2015 at 8:38:51 AM UTC-4, Christopher Fisher
>> wrote:
>>>
>>> Another thing to check is how you are mapping your inputs to the
>>> available workers. Just to give you a simple example, suppose you have a
>>> function called MyModel that accepts an array of parameters and each worker
>>> receives the same parameters. The basic steps would be:
>>>
>>> Nworkers = 3
>>>
>>> parms = [.3 2.0 .33]
>>>
>>> #Array of parameter arrays, one for each worker
>>> ParmArray = Any[parms for i = 1:Nworkers]
>>>
>>> output = pmap(MyModel,ParmArray)
>>>
>>> So you would have to adapt your more complex input structure to the
>>> example above.
>>>
>>>
>>> On Wednesday, October 7, 2015 at 7:46:13 PM UTC-4, james...@gmail.com
>>> wrote:

 Hi All:

 Julia is opened for a terminal session using Julia -p 4.

 A program test_SI_AR1.jl is run from the julia command line with the
 return


 exception on exception on exception on 4: exception on 3: 2: 5: ERROR:
 `PF_SI_AR1_inner` has no method matching PF_SI_AR1_inner(::Array{Any,1})
  in anonymous at multi.jl:855
  in run_work_thunk at multi.jl:621
  in anonymous at task.jl:855
 ERROR: `PF_SI_AR1_inner` has no method matching
 PF_SI_AR1_inner(::Array{Any,1})
  in anonymous at multi.jl:855
  in run_work_thunk at multi.jl:621
  in anonymous at task.jl:855
 ERROR: `PF_SI_AR1_inner` has no method matching
 PF_SI_AR1_inner(::Array{Any,1})
  in anonymous at multi.jl:855
  in run_work_thunk at multi.jl:621
  in anonymous at task.jl:855
 ERROR: `PF_SI_AR1_inner` has no method matching
 PF_SI_AR1_inner(::Array{Any,1})
  in anonymous at multi.jl:855
  in run_work_thunk at multi.jl:621
  in anonymous at task.jl:855
 ERROR: `exp` has no method matching exp(::Array{MethodError,1})
  in PF_SI_AR1_outer at
 /home/jim_nason/jmn_work/smith/NS4/jl_code_Summer2015/SI_rho/MH_PF_test/PF_outer_example.jl:123
  in include at ./boot.jl:245
  in include_from_node1 at ./loading.jl:128
  in reload_path at loading.jl:152
  in _require at loading.jl:67
  in require at loading.jl:51
 while loading
 /home/jim_nason/jmn_work/smith/NS4/jl_code_Summer2015/SI_rho/MH_PF_test/test_SI_AR1.jl,
 in expression starting on line 88


 Note that these error statements keep repeating until Julia is forced
 to shut down.

 The code for PF_outer_example.jl is attached.  PF_outer_example.jl
 calls to PF_inner_example.jl, which is also attached.

 This code implements a particle filter Markov chain Monte Carlo
 estimator of a state space model.  The particle filter is run in
 PF_inner_example.jl.

 test_SI_AR1.jl loads parameters and 

[julia-users] Does anyone have a fork/branch of Sundials.jl that works on 0.4/0.5?

[Simon Frost]

Dear All,

Sundials.jl master isn't compatible with 0.4/0.5, I presume due to the 
changes in Ref/Ptr between 0.3 and 0.4. There's quite a few forks and 
branches, which look as though at least in some cases, this has been fixed 
- I care mostly about cvode. Rather than wade through installation and 
testing of a whole bunch of branches, it would be great if someone could 
point me in the right direction of a repo to clone, as I don't know when 
there's going to be a PR.

Best wishes,
Simon