[julia-users] Error when using Interact (in IJulia)

[Frederico Novaes]

Hi,

I'm getting an error when trying to use Interact from IJulia, on Windows 7 
and julia 0.3.1. 

After typing "using Interact", I get:

Javascript error adding output!
ReferenceError: _ is not defined
See your browser Javascript console for more details.

Any help ?

[julia-users] Re: Function Argument Passing

[Ethan Anderes]

… ignore that spurious end in the code I sent. It was left over from a begin 
end block in the REPL. 

On Friday, September 26, 2014 7:44:02 PM UTC-7, Ethan Anderes wrote:

Stephan:
>
> Just as an addendum to Stefan and John’s comments, the following small 
> change to your code will mutate x:
>
> function f!(x) 
>   x[:]=x+1 
>   y=x+1 
>   end 
>end
>
> Notice, I put a ! at the end of the function name. This is just 
> convention to warn the user that the argument may be mutated. Coming form 
> Matlab, the way I reason about this is that everything behaves the same, as 
> far as local scope for x is concerned. The difference is that in Matlab, 
> the input array is copied and assigned to the local x, whereas in Julia 
> the address of the input array is copied and assigned to the local x. 
> Therefore x = x + 1 says assign x to a new address in memory (which 
> wouldn’t change the global scope x since the function scope is blind to 
> it, just as in Matlab). On the other hand x[:] = x + 1 says “go to where 
> x is addressed and put in the value x + 1”. So, in the Julia way, the 
> global scope x address hasn’t changed, but f! just scooped out the values 
> living in those locations and changed them. I’m probably rambling a bit 
> after a few friday night beers but I hope it helps.
>
> BTW: it is entirely possible that my working understanding is not the 
> right way to explain it. Feel free, and be sure to, correct me if I’m not 
> saying it right.
>
> Cheers!
> Ethan
>
> On Friday, September 26, 2014 1:51:37 PM UTC-7, Stephan Buchert wrote:
>
> From the manual
>> Argument Passing Behavior: ...means that values are not copied when they 
>> are passed to functions. ...Modifications to mutable values (such as 
>> Arrays) made within a function will be visible to the caller. 
>>
>> I get
>> julia> function f(x)
>>x=x+1
>>y=x+1
>>end
>> f (generic function with 1 method)
>>
>> julia> x=[1:5]'
>> 1x5 Array{Int64,2}:
>>  1  2  3  4  5
>>
>> julia> y=f(x)
>> 1x5 Array{Int64,2}:
>>  3  4  5  6  7
>>
>> julia> x
>> 1x5 Array{Int64,2}:
>>  1  2  3  4  5
>>
>> Apparently Array x is copied inside the function, at least in this case, 
>> and this is not visible to the caller (here made indirectly visible). The 
>> manual is confusing for me. And what is the difference between my example 
>> and the double! function from the manuals style guide, which does actually 
>> modify the function argument?
>>
>> ​
>
​

[julia-users] Re: Function Argument Passing

[Ethan Anderes]

Stephan:

Just as an addendum to Stefan and John’s comments, the following small 
change to your code will mutate x:

function f!(x) 
  x[:]=x+1 
  y=x+1 
  end 
   end

Notice, I put a ! at the end of the function name. This is just convention 
to warn the user that the argument may be mutated. Coming form Matlab, the 
way I reason about this is that everything behaves the same, as far as 
local scope for x is concerned. The difference is that in Matlab, the input 
array is copied and assigned to the local x, whereas in Julia the address 
of the input array is copied and assigned to the local x. Therefore x = x + 
1 says assign x to a new address in memory (which wouldn’t change the 
global scope x since the function scope is blind to it, just as in Matlab). 
On the other hand x[:] = x + 1 says “go to where x is addressed and put in 
the value x + 1”. So, in the Julia way, the global scope x address hasn’t 
changed, but f! just scooped out the values living in those locations and 
changed them. I’m probably rambling a bit after a few friday night beers 
but I hope it helps.

BTW: it is entirely possible that my working understanding is not the right 
way to explain it. Feel free, and be sure to, correct me if I’m not saying 
it right.

Cheers!
Ethan

On Friday, September 26, 2014 1:51:37 PM UTC-7, Stephan Buchert wrote:

>From the manual
> Argument Passing Behavior: ...means that values are not copied when they 
> are passed to functions. ...Modifications to mutable values (such as 
> Arrays) made within a function will be visible to the caller. 
>
> I get
> julia> function f(x)
>x=x+1
>y=x+1
>end
> f (generic function with 1 method)
>
> julia> x=[1:5]'
> 1x5 Array{Int64,2}:
>  1  2  3  4  5
>
> julia> y=f(x)
> 1x5 Array{Int64,2}:
>  3  4  5  6  7
>
> julia> x
> 1x5 Array{Int64,2}:
>  1  2  3  4  5
>
> Apparently Array x is copied inside the function, at least in this case, 
> and this is not visible to the caller (here made indirectly visible). The 
> manual is confusing for me. And what is the difference between my example 
> and the double! function from the manuals style guide, which does actually 
> modify the function argument?
>
> ​

Re: [julia-users] Creating geometry plots with Julia

[Jason Merrill]

You should file an issue against Cairo. If you can't get it working in the long 
run, you'll be missing out on some important, widely used infrastructure.

Re: [julia-users] Creating geometry plots with Julia

[Erik Schnetter]

Thanks -- I'll have a look at Compose.

Cairo doesn't build for me; I'm outputting to SVG which works without Cairo.

-erik

On Fri, Sep 26, 2014 at 8:31 PM, Jason Merrill  wrote:
> You might consider Compose, which is the geometry layer that sits below 
> Gadfly.
>
> Or if you really want to get down to nuts and bolts, you could just use Cairo 
> directly.



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

Re: [julia-users] Creating geometry plots with Julia

[Tim Holy]

Using Cairo directly is not crazy. It's not that hard to use, and you get a 
lot of control.

Winston is also a good choice; it's pretty high performance, though neither 
Cairo nor Winston is in OpenGL territory. Winston is not as flexibly as Gadfly, 
but it is more performant.

--Tim

On Friday, September 26, 2014 05:31:00 PM Jason Merrill wrote:
> You might consider Compose, which is the geometry layer that sits below
> Gadfly.
> 
> Or if you really want to get down to nuts and bolts, you could just use
> Cairo directly.

[julia-users] Creating geometry plots with Julia

[Jason Merrill]

You might consider Compose, which is the geometry layer that sits below Gadfly.

Or if you really want to get down to nuts and bolts, you could just use Cairo 
directly.

[julia-users] Creating geometry plots with Julia

[Erik Schnetter]

I want to create plots with Julia. The graphs will consist of many points 
and line segments. Currently, I'm using Gadfly, and I'm creating one layer 
per plot element (point or line). This works, but seems slow.

(1) Should I be using Gadfly differently? Can you point me to an example or 
documentation?
(2) Should I be using Gadfly at all? Gadfly is advertised for statistics, 
which isn't what I'm trying to plot -- I have geometry data.

-erik

Re: [julia-users] Function Argument Passing

[John Myles White]

I also tried to write an additional explanation for this recently in case the 
manual isn't sufficient: 
http://www.johnmyleswhite.com/notebook/2014/09/06/values-vs-bindings-the-map-is-not-the-territory/

 -- John

On Sep 26, 2014, at 2:01 PM, Stefan Karpinski  wrote:

> x is a variable, not a value:
> 
> http://julia.readthedocs.org/en/latest/manual/faq/#i-passed-an-argument-x-to-a-function-modified-it-inside-that-function-but-on-the-outside-the-variable-x-is-still-unchanged-why
> 
> On Fri, Sep 26, 2014 at 4:51 PM, Stephan Buchert  
> wrote:
> From the manual
> Argument Passing Behavior: ...means that values are not copied when they are 
> passed to functions. ...Modifications to mutable values (such as Arrays) made 
> within a function will be visible to the caller. 
> 
> I get
> julia> function f(x)
>x=x+1
>y=x+1
>end
> f (generic function with 1 method)
> 
> julia> x=[1:5]'
> 1x5 Array{Int64,2}:
>  1  2  3  4  5
> 
> julia> y=f(x)
> 1x5 Array{Int64,2}:
>  3  4  5  6  7
> 
> julia> x
> 1x5 Array{Int64,2}:
>  1  2  3  4  5
> 
> Apparently Array x is copied inside the function, at least in this case, and 
> this is not visible to the caller (here made indirectly visible). The manual 
> is confusing for me. And what is the difference between my example and the 
> double! function from the manuals style guide, which does actually modify the 
> function argument?
> 
> 

Re: [julia-users] Function Argument Passing

[Stefan Karpinski]

x is a variable, not a value:

http://julia.readthedocs.org/en/latest/manual/faq/#i-passed-an-argument-x-to-a-function-modified-it-inside-that-function-but-on-the-outside-the-variable-x-is-still-unchanged-why

On Fri, Sep 26, 2014 at 4:51 PM, Stephan Buchert 
wrote:

> From the manual
> Argument Passing Behavior: ...means that values are not copied when they
> are passed to functions. ...Modifications to mutable values (such as
> Arrays) made within a function will be visible to the caller.
>
> I get
> julia> function f(x)
>x=x+1
>y=x+1
>end
> f (generic function with 1 method)
>
> julia> x=[1:5]'
> 1x5 Array{Int64,2}:
>  1  2  3  4  5
>
> julia> y=f(x)
> 1x5 Array{Int64,2}:
>  3  4  5  6  7
>
> julia> x
> 1x5 Array{Int64,2}:
>  1  2  3  4  5
>
> Apparently Array x is copied inside the function, at least in this case,
> and this is not visible to the caller (here made indirectly visible). The
> manual is confusing for me. And what is the difference between my example
> and the double! function from the manuals style guide, which does actually
> modify the function argument?
>
>

[julia-users] Function Argument Passing

[Stephan Buchert]

>From the manual
Argument Passing Behavior: ...means that values are not copied when they 
are passed to functions. ...Modifications to mutable values (such as 
Arrays) made within a function will be visible to the caller. 

I get
julia> function f(x)
   x=x+1
   y=x+1
   end
f (generic function with 1 method)

julia> x=[1:5]'
1x5 Array{Int64,2}:
 1  2  3  4  5

julia> y=f(x)
1x5 Array{Int64,2}:
 3  4  5  6  7

julia> x
1x5 Array{Int64,2}:
 1  2  3  4  5

Apparently Array x is copied inside the function, at least in this case, 
and this is not visible to the caller (here made indirectly visible). The 
manual is confusing for me. And what is the difference between my example 
and the double! function from the manuals style guide, which does actually 
modify the function argument?

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Hans W Borchers]

Thanks. I decided to delete all of the .julia directory.
Looks like I can successfully install and build the optimization packages.

On Friday, September 26, 2014 7:49:24 PM UTC+2, Joey Huchette wrote:
>
> I followed your advice and, unintendedly being transferred to 0.4, managed 
>> to 
>> move back to 0.3.1 -- at the price that some packages (like Cbc) don't 
>> build 
>> anymore at the moment. Still I think it is unfortunate to keep interested 
>> and 
>> adventurous users away from a development version.
>>
>
> Please do open an issue (https://github.com/JuliaOpt/Cbc.jl/issues/new) 
> if you have build troubles, especially on the latest official release!
>

Re: [julia-users] Performance improvements double digest problem

[Stefan Karpinski]

On Fri, Sep 26, 2014 at 1:53 PM, Paul Lange  wrote:

>
> I was also unable to run the profiler since it keeps crashing julia (julia
> 0.3.1, Mac).
>

Profiler crashes are no good. I've not encountered that before on a Mac.
Filing an issue would be appreciated.

[julia-users] Re: Performance improvements double digest problem

[Daniel Jones]

Hi Paul,

Have you looked at the performance chapter in the manual? Some of that 
could help: http://julia.readthedocs.org/en/latest/manual/performance-tips/

There are few things you can do to speed this up:

Declare your globals with 'const'. Use sort! instead of sort to avoid 
allocating a new array. 

Lastly, vector operations like what you do in the Energy function allocate 
intermediate arrays which can slow things down. You can automatically 
"devectorize" this with the Devoctorize package, which lets you rewrite 
your Energy function like

function Energy(original, current)
  @devec ans = sum((original - current).^2 ./ original);
  return ans
end

That gives a nearly 4x speed up when combined with the other two changes I 
mentioned.

P.S. You don't need semicolons at the end of lines in Julia. We usually 
only use them if we need to put two statements on the same line.


On Friday, September 26, 2014 10:53:56 AM UTC-7, Paul Lange wrote:
>
> Hey,
>
> I'm currently working on the double digest problem [1] for a homework. I 
> first wrote the program in Matlab, but that became to slow for larger data 
> sets. So I switched to julia in hope of some
> speedup. Indeed by naively converting I get roughly a 5x increase: 
> 0.734531s in Matlab for 10k iterations.
> @time in julia returns the following after some runs: elapsed time: 
> 0.159896259 seconds (27817864 bytes allocated, 20.24% gc time)
>
> However I hope I can squeeze out some more performance and hope you can 
> give me some hints where to look at. The 20 Mbyte allocations seems quite a 
> lot, however I create a small new vector in the Neighbor function every 
> iteration. I was also unable to run the profiler since it keeps crashing 
> julia (julia 0.3.1, Mac).
>
>
> Code can be found here: 
> https://gist.github.com/palango/04599a4d553068189d96
>
> Some words about it:
> We've got two enzymes A and B that can cut DNA. When A is applied to some 
> DNA some fragments are created and their length can be measured. The sorted 
> lengths are stored in a and the same applies for b.
> If the same DNA gets first digested by A and then by B we get more 
> fragements. Their length is stored in c.
> The problem is now to find the correct order of fragments in a and b so 
> that we get the same fragments as in c.
> The program implements a simulated annealing approach. confa and confb 
> store the permutation auf a and b, which are used to calculate the c of the 
> current permutations.
>
> Thanks in advance,
> Paul
>
> [1] https://en.wikipedia.org/wiki/Restriction_map
>

[julia-users] Performance improvements double digest problem

[Paul Lange]

Hey,

I'm currently working on the double digest problem [1] for a homework. I 
first wrote the program in Matlab, but that became to slow for larger data 
sets. So I switched to julia in hope of some
speedup. Indeed by naively converting I get roughly a 5x increase: 
0.734531s in Matlab for 10k iterations.
@time in julia returns the following after some runs: elapsed time: 
0.159896259 seconds (27817864 bytes allocated, 20.24% gc time)

However I hope I can squeeze out some more performance and hope you can 
give me some hints where to look at. The 20 Mbyte allocations seems quite a 
lot, however I create a small new vector in the Neighbor function every 
iteration. I was also unable to run the profiler since it keeps crashing 
julia (julia 0.3.1, Mac).


Code can be found here: https://gist.github.com/palango/04599a4d553068189d96

Some words about it:
We've got two enzymes A and B that can cut DNA. When A is applied to some 
DNA some fragments are created and their length can be measured. The sorted 
lengths are stored in a and the same applies for b.
If the same DNA gets first digested by A and then by B we get more 
fragements. Their length is stored in c.
The problem is now to find the correct order of fragments in a and b so 
that we get the same fragments as in c.
The program implements a simulated annealing approach. confa and confb 
store the permutation auf a and b, which are used to calculate the c of the 
current permutations.

Thanks in advance,
Paul

[1] https://en.wikipedia.org/wiki/Restriction_map

Re: [julia-users] least squares algorithm

[Davide Lasagna]

Thanks Tim

Davide

On Thursday, September 25, 2014 2:35:43 PM UTC+1, Tim Holy wrote:
>
> Just FYI: you can easily find out the answer for yourself like this, 
>
> julia> A = rand(5,4) 
> 5x4 Array{Float64,2}: 
>  0.248302   0.330028  0.893083  0.390297 
>  0.0306052  0.298042  0.343798  0.569406 
>  0.935467   0.384105  0.972919  0.716717 
>  0.455494   0.351314  0.443435  0.848758 
>  0.752286   0.827971  0.590855  0.582407 
>
> julia> b = rand(5) 
> 5-element Array{Float64,1}: 
>  0.0326256 
>  0.546855 
>  0.425118 
>  0.0974509 
>  0.535496 
>
> julia> @which A\b 
> \(A::Union(DenseArray{T,2},SubArray{T,2,A<:DenseArray{T,N},I<: 
> (Union(Int64,Range{Int64})...,)}),B::Union(SubArray{T,1,A<:DenseArray{T,N},I<:
>  
>
> (Union(Int64,Range{Int64})...,)},DenseArray{T,2},SubArray{T,2,A<:DenseArray{T,N},I<:
>  
>
> (Union(Int64,Range{Int64})...,)},DenseArray{T,1})) at linalg/dense.jl:409 
>
> julia> edit("linalg/dense.jl", 409) 
>
> and then look at the function definition. 
>
> --Tim 
>
> On Thursday, September 25, 2014 06:12:39 AM Davide Lasagna wrote: 
> > Thank you Andreas. 
> > 
> > Sooner or later one needs to have a precise idea of what is going on 
> behing 
> > the scenes. Having a reference to the relevant lapack function is fine. 
> > 
> > Davide 
>
>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Joey Huchette]

>
> I followed your advice and, unintendedly being transferred to 0.4, managed 
> to 
> move back to 0.3.1 -- at the price that some packages (like Cbc) don't 
> build 
> anymore at the moment. Still I think it is unfortunate to keep interested 
> and 
> adventurous users away from a development version.
>

Please do open an issue (https://github.com/JuliaOpt/Cbc.jl/issues/new) if 
you have build troubles, especially on the latest official release!

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Jiahao Chen]

> I am sorry you felt uneasy when reading my post. I am sometimes a bit
ironic,
but please consider that irony is a friendly and sympathetic way to look at
things. A pity you couldn't laugh about the comparison with Perl. (I never
use smileys.)

It is very hard to infer tone from writing, and especially email. Usually,
it is better to be clear than to be clever.

> About the names I feel stricter. I don't like terms like 'Nullable' or
'NullableArrays' (for 'DataArrays'?), terms than seem to fit better for a
systems programming language than for a technical computing environment.
I will get used to them, no problem.

This particular naming issue was discussed at great length in #8152
 and the decision to go ahead
was made in the context of considerable debate. I would recommend taking
part in such discussions of interest, rather than falling victim to
consensus.

Thanks,

Jiahao Chen
Staff Research Scientist
MIT Computer Science and Artificial Intelligence Laboratory

On Fri, Sep 26, 2014 at 12:22 PM, Hans W Borchers 
wrote:

> Dear John,
>
> I am sorry you felt uneasy when reading my post. I am sometimes a bit
> ironic,
> but please consider that irony is a friendly and sympathetic way to look
> at
> things. A pity you couldn't laugh about the comparison with Perl. (I never
> use smileys.)
>
> I followed your advice and, unintendedly being transferred to 0.4, managed
> to
> move back to 0.3.1 -- at the price that some packages (like Cbc) don't
> build
> anymore at the moment. Still I think it is unfortunate to keep interested
> and
> adventurous users away from a development version.
>
> About the names I feel stricter. I don't like terms like 'Nullable' or
> 'NullableArrays' (for 'DataArrays'?), terms than seem to fit better for a
> systems programming language than for a technical computing environment.
> I will get used to them, no problem.
>
>
> On Friday, September 26, 2014 4:12:39 PM UTC+2, John Myles White wrote:
>>
>> Hans,
>>
>> The tone of your e-mail is a little odd in my opinion. It seems to imply
>> distrust and even possibly anger for a project that would be substantially
>> better served by participating actively in the issue discussions that Tim
>> Holy discussed. I don't think anyone who's following 0.4's progress would
>> ever believe that 0.4 is not on track.
>>
>>  -- John
>>
>>
>>

Re: [julia-users] Re: Why lufact() is faster than my code?

[Andreas Noack]

I'd like to add that in many cases it is not necessary to call the methods
in the BLAS module to get the benefit form BLAS3. You can use the A_mul_B!
family of functions in base/linalg/matmul. That is more generic and the
approach I prefer.

What I meant about BLAS 3 is that you would like to structure your code
such it performs matrix-matrix multiplications instead of matrix-vector
multiplications. That will give you the speed. You can see an example of
such julia code below for the Cholesky which is easy to block

https://github.com/andreasnoack/LinearAlgebra.jl/blob/master/src/cholesky.jl

Med venlig hilsen

Andreas Noack

2014-09-26 12:55 GMT-04:00 Douglas Bates :

> On Friday, September 26, 2014 2:50:51 AM UTC-5, Staro Pickle wrote:
>>
>> Thank you all.
>>
>> On Friday, September 26, 2014 2:50:56 AM UTC+8, Jason Riedy wrote:
>>>
>>>
>>> Others have given some reasons...  If you want to see contortions
>>> that were (perhaps still are) necessary to be competitive, see:
>>>   https://groups.google.com/forum/#!msg/julia-users/
>>> DJRxApmpJmU/NqepNaX5ARIJ
>>>
>>
>> This article is expert but as you say, they are not clear and straight.
>> Is it possible to call BLAS-3 an easy way?
>>
>
> There are two ways to access BLAS subroutines from within Julia but
> neither is considered "easy".  The first is direct calls to functions in
> the BLAS and LAPACK namespaces.  The fact that these names are not exported
> means that they are not intended for general use.  However, sometimes it is
> useful to access them directly.  To find the available functions use
>
> julia> whos(BLAS)
> BLAS  Module
> asum  Function
> axpy! Function
> dot   Function
> dotc  Function
> dotu  Function
> gbmv  Function
> gbmv! Function
> gemm  Function
> gemm! Function
> ger!  Function
> her!  Function
> her2k Function
> her2k!Function
> herk  Function
> herk! Function
> iamax Function
> nrm2  Function
> sbmv  Function
> sbmv! Function
> scal  Function
> scal! Function
> symm  Function
> symm! Function
> symv  Function
> symv! Function
> syr!  Function
> syr2k Function
> syr2k!Function
> syrk  Function
> syrk! Function
>
>
> If you know the BLAS names you will see that these names are the same with
> the storage type indicator removed.  So instead of the BLAS names cgemm,
> dgemm, sgemm and zgemm there is a single gemm function.  The difference
> between the functions whose names end in ! and those whose names don't is
> that the name ending in ! is the mutating version of the function.  It
> overwrites one of its arguments with the result.  The name without the !
> copies that argument before calling the mutating version.
>
> The functions are called as, e.g.
> julia> A = ones(5,5)
> 5x5 Array{Float64,2}:
>  1.0  1.0  1.0  1.0  1.0
>  1.0  1.0  1.0  1.0  1.0
>  1.0  1.0  1.0  1.0  1.0
>  1.0  1.0  1.0  1.0  1.0
>  1.0  1.0  1.0  1.0  1.0
>
> julia> B = ones(5,2)
> 5x2 Array{Float64,2}:
>  1.0  1.0
>  1.0  1.0
>  1.0  1.0
>  1.0  1.0
>  1.0  1.0
>
> julia> BLAS.gemm('N','N',1.0,A,B)
> 5x2 Array{Float64,2}:
>  5.0  5.0
>  5.0  5.0
>  5.0  5.0
>  5.0  5.0
>  5.0  5.0
>
> julia> C = Array(Float64,(5,2))
> 5x2 Array{Float64,2}:
>  0.0  0.0
>  0.0  0.0
>  0.0  0.0
>  0.0  0.0
>  0.0  0.0
>
> julia> BLAS.gemm!('N','N',2.0,A,B,0.0,C)
> 5x2 Array{Float64,2}:
>  10.0  10.0
>  10.0  10.0
>  10.0  10.0
>  10.0  10.0
>  10.0  10.0
>
> julia> C
> 5x2 Array{Float64,2}:
>  10.0  10.0
>  10.0  10.0
>  10.0  10.0
>  10.0  10.0
>  10.0  10.0
>
>
> You can determine the calling sequence from a call like
> methods(gemm!)
> but the result isn't the most readable you will ever see.  You may be
> better off reading the source code in src/linalg/blas.jl
>
> In that file you will see that these functions just marshal argument
> values for the Fortran calling conventions then call ccall to call the BLAS
> or LAPACK subroutine.  That's the other way of calling BLAS or LAPACK
> directly, although it should not be necessary to drop down to that level of
> code.
>
>
>>
>>> However, if your matrices always have this form, I would highly
>>> recommend solving a few by hand to notice the pattern.
>>>
>>
>> Good observation and sense! Yes, I know that can be calculated by hand. I
>> use this matrix in a case related to sparse matrix.
>>
>> 

[julia-users] Re: Why lufact() is faster than my code?

[Douglas Bates]

On Friday, September 26, 2014 2:50:51 AM UTC-5, Staro Pickle wrote:
>
> Thank you all.
>
> On Friday, September 26, 2014 2:50:56 AM UTC+8, Jason Riedy wrote:
>>
>>
>> Others have given some reasons...  If you want to see contortions 
>> that were (perhaps still are) necessary to be competitive, see: 
>>   
>> https://groups.google.com/forum/#!msg/julia-users/DJRxApmpJmU/NqepNaX5ARIJ 
>>
>
> This article is expert but as you say, they are not clear and straight. Is 
> it possible to call BLAS-3 an easy way?
>

There are two ways to access BLAS subroutines from within Julia but neither 
is considered "easy".  The first is direct calls to functions in the BLAS 
and LAPACK namespaces.  The fact that these names are not exported means 
that they are not intended for general use.  However, sometimes it is 
useful to access them directly.  To find the available functions use

julia> whos(BLAS)
BLAS  Module
asum  Function
axpy! Function
dot   Function
dotc  Function
dotu  Function
gbmv  Function
gbmv! Function
gemm  Function
gemm! Function
ger!  Function
her!  Function
her2k Function
her2k!Function
herk  Function
herk! Function
iamax Function
nrm2  Function
sbmv  Function
sbmv! Function
scal  Function
scal! Function
symm  Function
symm! Function
symv  Function
symv! Function
syr!  Function
syr2k Function
syr2k!Function
syrk  Function
syrk! Function


If you know the BLAS names you will see that these names are the same with 
the storage type indicator removed.  So instead of the BLAS names cgemm, 
dgemm, sgemm and zgemm there is a single gemm function.  The difference 
between the functions whose names end in ! and those whose names don't is 
that the name ending in ! is the mutating version of the function.  It 
overwrites one of its arguments with the result.  The name without the ! 
copies that argument before calling the mutating version.

The functions are called as, e.g.
julia> A = ones(5,5)
5x5 Array{Float64,2}:
 1.0  1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0  1.0
 1.0  1.0  1.0  1.0  1.0

julia> B = ones(5,2)
5x2 Array{Float64,2}:
 1.0  1.0
 1.0  1.0
 1.0  1.0
 1.0  1.0
 1.0  1.0

julia> BLAS.gemm('N','N',1.0,A,B)
5x2 Array{Float64,2}:
 5.0  5.0
 5.0  5.0
 5.0  5.0
 5.0  5.0
 5.0  5.0

julia> C = Array(Float64,(5,2))
5x2 Array{Float64,2}:
 0.0  0.0
 0.0  0.0
 0.0  0.0
 0.0  0.0
 0.0  0.0

julia> BLAS.gemm!('N','N',2.0,A,B,0.0,C)
5x2 Array{Float64,2}:
 10.0  10.0
 10.0  10.0
 10.0  10.0
 10.0  10.0
 10.0  10.0

julia> C
5x2 Array{Float64,2}:
 10.0  10.0
 10.0  10.0
 10.0  10.0
 10.0  10.0
 10.0  10.0


You can determine the calling sequence from a call like
methods(gemm!)
but the result isn't the most readable you will ever see.  You may be 
better off reading the source code in src/linalg/blas.jl

In that file you will see that these functions just marshal argument values 
for the Fortran calling conventions then call ccall to call the BLAS or 
LAPACK subroutine.  That's the other way of calling BLAS or LAPACK 
directly, although it should not be necessary to drop down to that level of 
code.

 
>
>> However, if your matrices always have this form, I would highly 
>> recommend solving a few by hand to notice the pattern. 
>>
>
> Good observation and sense! Yes, I know that can be calculated by hand. I 
> use this matrix in a case related to sparse matrix. 
>
> By the way, the citation above is not displayed grey as usual. I made a 
> few try but didn't see how. Should that text be chosen grey? 
>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Hans W Borchers]

Dear John,

I am sorry you felt uneasy when reading my post. I am sometimes a bit 
ironic, 
but please consider that irony is a friendly and sympathetic way to look at 
things. A pity you couldn't laugh about the comparison with Perl. (I never 
use smileys.)

I followed your advice and, unintendedly being transferred to 0.4, managed 
to 
move back to 0.3.1 -- at the price that some packages (like Cbc) don't 
build 
anymore at the moment. Still I think it is unfortunate to keep interested 
and 
adventurous users away from a development version.

About the names I feel stricter. I don't like terms like 'Nullable' or 
'NullableArrays' (for 'DataArrays'?), terms than seem to fit better for a 
systems programming language than for a technical computing environment. 
I will get used to them, no problem.


On Friday, September 26, 2014 4:12:39 PM UTC+2, John Myles White wrote:
>
> Hans,
>
> The tone of your e-mail is a little odd in my opinion. It seems to imply 
> distrust and even possibly anger for a project that would be substantially 
> better served by participating actively in the issue discussions that Tim 
> Holy discussed. I don't think anyone who's following 0.4's progress would 
> ever believe that 0.4 is not on track. 
>
>  -- John
>
>
>

[julia-users] HTTPClient.HTTPC giving curl_easy_duphandle at /usr/lib64/libcurl.so (unknown line) in OEL 6

[sagar ram]

Hi,

I am running julia v0.3 on OEL 6u8

while running the below program i am getting signal (4): Illegal 
instruction Error

Can you please let us know what went wrong. Same program works fine in 
Windows. :(

 sample.jl
using HTTPClient.HTTPC
using JSON
using Base.Test


RB = 
"http://10.10.41.246/solr/PhysicalDeviceInfo/select?q=bTWSID:BTWSID711255948&wt=json";
println("URL : $RB")

r=HTTPC.get(RB)
println("Test 1 passed, http_code : " * string(r.http_code))


julia sample.jl
hellp-
URL : 
http://10.101.41.246/solr/PhysicalDeviceInfo/select?q=bTWSID:BTWSID711255948&wt=json

signal (4): Illegal instruction
curl_easy_duphandle at /usr/lib64/libcurl.so (unknown line)
unknown function (ip: -1667694976)
Illegal instruction

Re: [julia-users] Re: pycall to use sklearn

[Cedric St-Jean]

I use it without pycall on Julia 0.3:

@pyimport sklearn.linear_model as lm
XX = reshape([1:10],(10,1))
lm.LinearRegression()[:fit](XX, linspace(0,200,10))[:predict]([3])

Cédric

On Friday, September 26, 2014 12:07:02 AM UTC-4, Arshak Navruzyan wrote:
>
> Didn't seem to work either
>
> PyError (PyObject_Call) 
> AttributeError("'float' object has no attribute 'shape'",)
>   File "/Users/arshakn/anaconda/lib/python2.7/site-packages/sklearn/hmm.py", 
> line 419, in fit
> self._init(obs, self.init_params)
>   File "/Users/arshakn/anaconda/lib/python2.7/site-packages/sklearn/hmm.py", 
> line 756, in _init
> self.n_features = obs[0].shape[1]
>
> while loading In[295], in expression starting on line 3
>
>  in pyerr_check at /Users/arshakn/.julia/v0.3/PyCall/src/exception.jl:58
>  in pycall at /Users/arshakn/.julia/v0.3/PyCall/src/PyCall.jl:85
>
>
>
> On Thu, Sep 25, 2014 at 8:37 PM, Steven G. Johnson  > wrote:
>
>>
>>
>> On Thursday, September 25, 2014 11:10:22 PM UTC-4, Arshak Navruzyan wrote:
>>>
>>> Jake,
>>>
>>> Thanks for the suggestion.  When I do that, I get back (anonymous 
>>> function). What I would like to get back is the actual model (with the new 
>>> parameters) to be able to do things like this
>>>
>>
>> If you want the return value to be the raw PyObject, do
>>
>>  pycall(hmmodel["fit"], PyObject, df[:abc])
>>
>> (This will no longer be necessary in Julia 0.4 once function-calling is 
>> overloadable.)
>>
>
>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Adam R. Smith]

Yep that was it, thanks! Sorry to sidetrack the conversation.

 a d a m

On September 26, 2014 at 11:23:21 AM, Jameson Nash (vtjn...@gmail.com) wrote:

https://github.com/Rory-Finnegan/Playground.jl ?

On Fri, Sep 26, 2014 at 11:17 AM, Adam R. Smith  wrote:
Steve: that’s a useful setup!

Somebody was also making a Julia equivalent for python’s virtualenv, but I 
can’t remember the name so I can’t find it now. Using aliases like yours, you 
could associate a particular project with a particular julia version with a 
virtualenv. I wish I could remember the name.

 a d a m

On September 26, 2014 at 11:12:22 AM, Steve Kelly (kd2...@gmail.com) wrote:

This is how I set up my environment to stay involved:

julia -> master
julia3 -> release-0.3
julia4on3-> use 0.4 packages on julia3 (this is helpful since I like to develop 
in the v0.4 directory)
julia-multi -> run something with 0.4 packages on julia and julia3 (I normally 
only use this with 'julia-multi ./test/runtests.jl')

I've put the scripts I use for the last two on Github: 
https://github.com/sjkelly/julia_scripts

These four commands give me the satisfaction of seeing stuff break, and also 
providing comfort when there are deadlines to meet :P.


On Fri, Sep 26, 2014 at 10:49 AM, Stefan Karpinski  
wrote:
It's a bit odd for there to be simultaneous complaints about 0.4 being unstable 
(ie under rapid development) and not going anywhere. It's been, what, 13 years 
since the plans to release Perl 6 were announced? Seems a bit early to worry 
about that kind of problem a couple of months after the last significant 
release of Julia. If 0.4 isn't out by 2020 we can start to worry.


On Sep 26, 2014, at 10:12 AM, John Myles White  wrote:

Hans,

The tone of your e-mail is a little odd in my opinion. It seems to imply 
distrust and even possibly anger for a project that would be substantially 
better served by participating actively in the issue discussions that Tim Holy 
discussed. I don't think anyone who's following 0.4's progress would ever 
believe that 0.4 is not on track. 

 -- John

On Sep 26, 2014, at 3:30 AM, Hans W Borchers  wrote:

Ivar,

thanks for this clarification; I was really under the impression that -- like
for Perl and other projects -- I might never ever again hear from a Julia 0.4
version.

A question I asked got buried in another thread and never answered, so I'd like
to repeat it here:

  Will the NEWS.md file immediately document the (disruptive or non-disruptive)
  changes? That would be very helpful, even if the change is withdrawn later on.
  Also, every NEWS entry could include a date to make it easier to follow the
  development.

By the way, I am a bit worried about some of the names that seem to come up in a
next version of Julia. For example, 'Nullable' or 'NullableArray' sound strange
for me in a technical computing environment.


On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote:
I think this is a too strong statement. There are definitely happening a lot on 
the master (0.4-dev) branch, but it should be quite usable even without reading 
the majority of Github issues. The more users we have, the earlier concerns is 
raised, and the earlier we can fix them and prepare for the final release. You 
should definitely avoid master on any project with a deadline tough.

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Jameson Nash]

https://github.com/Rory-Finnegan/Playground.jl ?

On Fri, Sep 26, 2014 at 11:17 AM, Adam R. Smith  wrote:

> Steve: that’s a useful setup!
>
> Somebody was also making a Julia equivalent for python’s virtualenv, but I
> can’t remember the name so I can’t find it now. Using aliases like yours,
> you could associate a particular project with a particular julia version
> with a virtualenv. I wish I could remember the name.
>
>  a d a m
>
> On September 26, 2014 at 11:12:22 AM, Steve Kelly (kd2...@gmail.com)
> wrote:
>
>  This is how I set up my environment to stay involved:
>
> julia -> master
> julia3 -> release-0.3
> julia4on3-> use 0.4 packages on julia3 (this is helpful since I like to
> develop in the v0.4 directory)
> julia-multi -> run something with 0.4 packages on julia and julia3 (I
> normally only use this with 'julia-multi ./test/runtests.jl')
>
> I've put the scripts I use for the last two on Github:
> https://github.com/sjkelly/julia_scripts
>
> These four commands give me the satisfaction of seeing stuff break, and
> also providing comfort when there are deadlines to meet :P.
>
>
> On Fri, Sep 26, 2014 at 10:49 AM, Stefan Karpinski <
> stefan.karpin...@gmail.com> wrote:
>
>>  It's a bit odd for there to be simultaneous complaints about 0.4 being
>> unstable (ie under rapid development) and not going anywhere. It's been,
>> what, 13 years since the plans to release Perl 6 were announced? Seems a
>> bit early to worry about that kind of problem a couple of months after the
>> last significant release of Julia. If 0.4 isn't out by 2020 we can start to
>> worry.
>>
>>
>> On Sep 26, 2014, at 10:12 AM, John Myles White 
>> wrote:
>>
>>  Hans,
>>
>> The tone of your e-mail is a little odd in my opinion. It seems to imply
>> distrust and even possibly anger for a project that would be substantially
>> better served by participating actively in the issue discussions that Tim
>> Holy discussed. I don't think anyone who's following 0.4's progress would
>> ever believe that 0.4 is not on track.
>>
>>  -- John
>>
>>  On Sep 26, 2014, at 3:30 AM, Hans W Borchers 
>> wrote:
>>
>>  Ivar,
>>
>> thanks for this clarification; I was really under the impression that --
>> like
>> for Perl and other projects -- I might never ever again hear from a Julia
>> 0.4
>> version.
>>
>> A question I asked got buried in another thread and never answered, so
>> I'd like
>> to repeat it here:
>>
>>   Will the NEWS.md file immediately document the (disruptive or
>> non-disruptive)
>>   changes? That would be very helpful, even if the change is withdrawn
>> later on.
>>   Also, every NEWS entry could include a date to make it easier to follow
>> the
>>   development.
>>
>> By the way, I am a bit worried about some of the names that seem to come
>> up in a
>> next version of Julia. For example, 'Nullable' or 'NullableArray' sound
>> strange
>> for me in a technical computing environment.
>>
>>
>> On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote:
>>>
>>> I think this is a too strong statement. There are definitely happening a
>>> lot on the master (0.4-dev) branch, but it should be quite usable even
>>> without reading the majority of Github issues. The more users we have, the
>>> earlier concerns is raised, and the earlier we can fix them and prepare for
>>> the final release. You should definitely avoid master on any project with a
>>> deadline tough.
>>>
>>>
>>>
>>
>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Adam R. Smith]

Steve: that’s a useful setup!

Somebody was also making a Julia equivalent for python’s virtualenv, but I 
can’t remember the name so I can’t find it now. Using aliases like yours, you 
could associate a particular project with a particular julia version with a 
virtualenv. I wish I could remember the name.

 a d a m

On September 26, 2014 at 11:12:22 AM, Steve Kelly (kd2...@gmail.com) wrote:

This is how I set up my environment to stay involved:

julia -> master
julia3 -> release-0.3
julia4on3-> use 0.4 packages on julia3 (this is helpful since I like to develop 
in the v0.4 directory)
julia-multi -> run something with 0.4 packages on julia and julia3 (I normally 
only use this with 'julia-multi ./test/runtests.jl')

I've put the scripts I use for the last two on Github: 
https://github.com/sjkelly/julia_scripts

These four commands give me the satisfaction of seeing stuff break, and also 
providing comfort when there are deadlines to meet :P.


On Fri, Sep 26, 2014 at 10:49 AM, Stefan Karpinski  
wrote:
It's a bit odd for there to be simultaneous complaints about 0.4 being unstable 
(ie under rapid development) and not going anywhere. It's been, what, 13 years 
since the plans to release Perl 6 were announced? Seems a bit early to worry 
about that kind of problem a couple of months after the last significant 
release of Julia. If 0.4 isn't out by 2020 we can start to worry.


On Sep 26, 2014, at 10:12 AM, John Myles White  wrote:

Hans,

The tone of your e-mail is a little odd in my opinion. It seems to imply 
distrust and even possibly anger for a project that would be substantially 
better served by participating actively in the issue discussions that Tim Holy 
discussed. I don't think anyone who's following 0.4's progress would ever 
believe that 0.4 is not on track. 

 -- John

On Sep 26, 2014, at 3:30 AM, Hans W Borchers  wrote:

Ivar,

thanks for this clarification; I was really under the impression that -- like
for Perl and other projects -- I might never ever again hear from a Julia 0.4
version.

A question I asked got buried in another thread and never answered, so I'd like
to repeat it here:

  Will the NEWS.md file immediately document the (disruptive or non-disruptive)
  changes? That would be very helpful, even if the change is withdrawn later on.
  Also, every NEWS entry could include a date to make it easier to follow the
  development.

By the way, I am a bit worried about some of the names that seem to come up in a
next version of Julia. For example, 'Nullable' or 'NullableArray' sound strange
for me in a technical computing environment.


On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote:
I think this is a too strong statement. There are definitely happening a lot on 
the master (0.4-dev) branch, but it should be quite usable even without reading 
the majority of Github issues. The more users we have, the earlier concerns is 
raised, and the earlier we can fix them and prepare for the final release. You 
should definitely avoid master on any project with a deadline tough.

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[John Myles White]

I also keep separate installations of julia: I have both julia-0.3 and 
julia-0.4 installations in separate directories, with the julia symlink only 
referring to julia-0.3

 -- John

On Sep 26, 2014, at 8:12 AM, Steve Kelly  wrote:

> This is how I set up my environment to stay involved:
> 
> julia -> master
> julia3 -> release-0.3
> julia4on3-> use 0.4 packages on julia3 (this is helpful since I like to 
> develop in the v0.4 directory)
> julia-multi -> run something with 0.4 packages on julia and julia3 (I 
> normally only use this with 'julia-multi ./test/runtests.jl')
> 
> I've put the scripts I use for the last two on Github: 
> https://github.com/sjkelly/julia_scripts
> 
> These four commands give me the satisfaction of seeing stuff break, and also 
> providing comfort when there are deadlines to meet :P. 
> 
> 
> On Fri, Sep 26, 2014 at 10:49 AM, Stefan Karpinski 
>  wrote:
> It's a bit odd for there to be simultaneous complaints about 0.4 being 
> unstable (ie under rapid development) and not going anywhere. It's been, 
> what, 13 years since the plans to release Perl 6 were announced? Seems a bit 
> early to worry about that kind of problem a couple of months after the last 
> significant release of Julia. If 0.4 isn't out by 2020 we can start to worry.
> 
> 
> On Sep 26, 2014, at 10:12 AM, John Myles White  
> wrote:
> 
>> Hans,
>> 
>> The tone of your e-mail is a little odd in my opinion. It seems to imply 
>> distrust and even possibly anger for a project that would be substantially 
>> better served by participating actively in the issue discussions that Tim 
>> Holy discussed. I don't think anyone who's following 0.4's progress would 
>> ever believe that 0.4 is not on track. 
>> 
>>  -- John
>> 
>> On Sep 26, 2014, at 3:30 AM, Hans W Borchers  wrote:
>> 
>>> Ivar,
>>> 
>>> thanks for this clarification; I was really under the impression that -- 
>>> like 
>>> for Perl and other projects -- I might never ever again hear from a Julia 
>>> 0.4 
>>> version.
>>> 
>>> A question I asked got buried in another thread and never answered, so I'd 
>>> like 
>>> to repeat it here:
>>> 
>>>   Will the NEWS.md file immediately document the (disruptive or 
>>> non-disruptive)
>>>   changes? That would be very helpful, even if the change is withdrawn 
>>> later on.
>>>   Also, every NEWS entry could include a date to make it easier to follow 
>>> the
>>>   development.
>>> 
>>> By the way, I am a bit worried about some of the names that seem to come up 
>>> in a 
>>> next version of Julia. For example, 'Nullable' or 'NullableArray' sound 
>>> strange 
>>> for me in a technical computing environment.
>>> 
>>> 
>>> On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote:
>>> I think this is a too strong statement. There are definitely happening a 
>>> lot on the master (0.4-dev) branch, but it should be quite usable even 
>>> without reading the majority of Github issues. The more users we have, the 
>>> earlier concerns is raised, and the earlier we can fix them and prepare for 
>>> the final release. You should definitely avoid master on any project with a 
>>> deadline tough.
>>> 
>>> 
>> 
> 

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Steve Kelly]

This is how I set up my environment to stay involved:

julia -> master
julia3 -> release-0.3
julia4on3-> use 0.4 packages on julia3 (this is helpful since I like to
develop in the v0.4 directory)
julia-multi -> run something with 0.4 packages on julia and julia3 (I
normally only use this with 'julia-multi ./test/runtests.jl')

I've put the scripts I use for the last two on Github:
https://github.com/sjkelly/julia_scripts

These four commands give me the satisfaction of seeing stuff break, and
also providing comfort when there are deadlines to meet :P.


On Fri, Sep 26, 2014 at 10:49 AM, Stefan Karpinski <
stefan.karpin...@gmail.com> wrote:

> It's a bit odd for there to be simultaneous complaints about 0.4 being
> unstable (ie under rapid development) and not going anywhere. It's been,
> what, 13 years since the plans to release Perl 6 were announced? Seems a
> bit early to worry about that kind of problem a couple of months after the
> last significant release of Julia. If 0.4 isn't out by 2020 we can start to
> worry.
>
>
> On Sep 26, 2014, at 10:12 AM, John Myles White 
> wrote:
>
> Hans,
>
> The tone of your e-mail is a little odd in my opinion. It seems to imply
> distrust and even possibly anger for a project that would be substantially
> better served by participating actively in the issue discussions that Tim
> Holy discussed. I don't think anyone who's following 0.4's progress would
> ever believe that 0.4 is not on track.
>
>  -- John
>
> On Sep 26, 2014, at 3:30 AM, Hans W Borchers  wrote:
>
> Ivar,
>
> thanks for this clarification; I was really under the impression that --
> like
> for Perl and other projects -- I might never ever again hear from a Julia
> 0.4
> version.
>
> A question I asked got buried in another thread and never answered, so I'd
> like
> to repeat it here:
>
>   Will the NEWS.md file immediately document the (disruptive or
> non-disruptive)
>   changes? That would be very helpful, even if the change is withdrawn
> later on.
>   Also, every NEWS entry could include a date to make it easier to follow
> the
>   development.
>
> By the way, I am a bit worried about some of the names that seem to come
> up in a
> next version of Julia. For example, 'Nullable' or 'NullableArray' sound
> strange
> for me in a technical computing environment.
>
>
> On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote:
>>
>> I think this is a too strong statement. There are definitely happening a
>> lot on the master (0.4-dev) branch, but it should be quite usable even
>> without reading the majority of Github issues. The more users we have, the
>> earlier concerns is raised, and the earlier we can fix them and prepare for
>> the final release. You should definitely avoid master on any project with a
>> deadline tough.
>>
>>
>>
>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Stefan Karpinski]

It's a bit odd for there to be simultaneous complaints about 0.4 being unstable 
(ie under rapid development) and not going anywhere. It's been, what, 13 years 
since the plans to release Perl 6 were announced? Seems a bit early to worry 
about that kind of problem a couple of months after the last significant 
release of Julia. If 0.4 isn't out by 2020 we can start to worry.


> On Sep 26, 2014, at 10:12 AM, John Myles White  
> wrote:
> 
> Hans,
> 
> The tone of your e-mail is a little odd in my opinion. It seems to imply 
> distrust and even possibly anger for a project that would be substantially 
> better served by participating actively in the issue discussions that Tim 
> Holy discussed. I don't think anyone who's following 0.4's progress would 
> ever believe that 0.4 is not on track. 
> 
>  -- John
> 
>> On Sep 26, 2014, at 3:30 AM, Hans W Borchers  wrote:
>> 
>> Ivar,
>> 
>> thanks for this clarification; I was really under the impression that -- 
>> like 
>> for Perl and other projects -- I might never ever again hear from a Julia 
>> 0.4 
>> version.
>> 
>> A question I asked got buried in another thread and never answered, so I'd 
>> like 
>> to repeat it here:
>> 
>>   Will the NEWS.md file immediately document the (disruptive or 
>> non-disruptive)
>>   changes? That would be very helpful, even if the change is withdrawn later 
>> on.
>>   Also, every NEWS entry could include a date to make it easier to follow the
>>   development.
>> 
>> By the way, I am a bit worried about some of the names that seem to come up 
>> in a 
>> next version of Julia. For example, 'Nullable' or 'NullableArray' sound 
>> strange 
>> for me in a technical computing environment.
>> 
>> 
>>> On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote:
>>> I think this is a too strong statement. There are definitely happening a 
>>> lot on the master (0.4-dev) branch, but it should be quite usable even 
>>> without reading the majority of Github issues. The more users we have, the 
>>> earlier concerns is raised, and the earlier we can fix them and prepare for 
>>> the final release. You should definitely avoid master on any project with a 
>>> deadline tough.
> 

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Tim Holy]

Although I believe Jiahao is looking for someone to step up and take charge of 
a "this week in Julia" publication. Hans, since you want this information 
yourself, you've just made yourself the perfect candidate.

As that pulse link that Adam forwarded shows, there is a _lot_ of material to 
cover just in the last week, much of it pretty darn revolutionary. So I'm sure 
you'll be very busy writing it all up :-).

--Tim

On Friday, September 26, 2014 07:24:42 AM Adam Smith wrote:
> Hans, like John said in the OP, v0.4 is really unstable right now. I would
> not expect them to publish updates to NEWS.md for new things that could get
> reverted a few days later. If you want to monitor updates, Github provides
> some really nice tools, like the Pulse
> page: https://github.com/JuliaLang/julia/pulse/weekly
> 
> There are a number of ways to monitor something in flux like v0.4 without
> requiring manual updates to a changelog.
> 
> On Friday, September 26, 2014 6:30:48 AM UTC-4, Hans W Borchers wrote:
> > Ivar,
> > 
> > thanks for this clarification; I was really under the impression that --
> > like
> > for Perl and other projects -- I might never ever again hear from a Julia
> > 0.4
> > version.
> > 
> > A question I asked got buried in another thread and never answered, so I'd
> > like
> > 
> > to repeat it here:
> >   Will the NEWS.md file immediately document the (disruptive or
> > 
> > non-disruptive)
> > 
> >   changes? That would be very helpful, even if the change is withdrawn
> > 
> > later on.
> > 
> >   Also, every NEWS entry could include a date to make it easier to follow
> > 
> > the
> > 
> >   development.
> > 
> > By the way, I am a bit worried about some of the names that seem to come
> > up in a
> > next version of Julia. For example, 'Nullable' or 'NullableArray' sound
> > strange
> > for me in a technical computing environment.
> > 
> > On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote:
> >> I think this is a too strong statement. There are definitely happening a
> >> lot on the master (0.4-dev) branch, but it should be quite usable even
> >> without reading the majority of Github issues. The more users we have,
> >> the
> >> earlier concerns is raised, and the earlier we can fix them and prepare
> >> for
> >> the final release. You should definitely avoid master on any project with
> >> a
> >> deadline tough.

[julia-users] Re: Calling Julia from .NET

[Stefan Babinec]

Hi Guido.

Can you please point me to C# example ? 

I would appreciate your help.

Thanks.

On Friday, September 26, 2014 11:55:55 AM UTC+2, Guido De Bouver wrote:
>
> dear Julia users,
>
> I would need to call Julia from VB .NET. I have seen it is possible to do 
> so from C#, but is it possible to call from VB .NET ? If so, any examples 
> available ?
> Thanks for this great product
>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Adam Smith]

Hans, like John said in the OP, v0.4 is really unstable right now. I would 
not expect them to publish updates to NEWS.md for new things that could get 
reverted a few days later. If you want to monitor updates, Github provides 
some really nice tools, like the Pulse 
page: https://github.com/JuliaLang/julia/pulse/weekly

There are a number of ways to monitor something in flux like v0.4 without 
requiring manual updates to a changelog.

On Friday, September 26, 2014 6:30:48 AM UTC-4, Hans W Borchers wrote:
>
> Ivar,
>
> thanks for this clarification; I was really under the impression that -- 
> like 
> for Perl and other projects -- I might never ever again hear from a Julia 
> 0.4 
> version.
>
> A question I asked got buried in another thread and never answered, so I'd 
> like 
> to repeat it here:
>
>   Will the NEWS.md file immediately document the (disruptive or 
> non-disruptive)
>   changes? That would be very helpful, even if the change is withdrawn 
> later on.
>   Also, every NEWS entry could include a date to make it easier to follow 
> the
>   development.
>
> By the way, I am a bit worried about some of the names that seem to come 
> up in a 
> next version of Julia. For example, 'Nullable' or 'NullableArray' sound 
> strange 
> for me in a technical computing environment.
>
>
> On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote:
>>
>> I think this is a too strong statement. There are definitely happening a 
>> lot on the master (0.4-dev) branch, but it should be quite usable even 
>> without reading the majority of Github issues. The more users we have, the 
>> earlier concerns is raised, and the earlier we can fix them and prepare for 
>> the final release. You should definitely avoid master on any project with a 
>> deadline tough.
>>
>>
>>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[John Myles White]

Hans,

The tone of your e-mail is a little odd in my opinion. It seems to imply 
distrust and even possibly anger for a project that would be substantially 
better served by participating actively in the issue discussions that Tim Holy 
discussed. I don't think anyone who's following 0.4's progress would ever 
believe that 0.4 is not on track. 

 -- John

On Sep 26, 2014, at 3:30 AM, Hans W Borchers  wrote:

> Ivar,
> 
> thanks for this clarification; I was really under the impression that -- like 
> for Perl and other projects -- I might never ever again hear from a Julia 0.4 
> version.
> 
> A question I asked got buried in another thread and never answered, so I'd 
> like 
> to repeat it here:
> 
>   Will the NEWS.md file immediately document the (disruptive or 
> non-disruptive)
>   changes? That would be very helpful, even if the change is withdrawn later 
> on.
>   Also, every NEWS entry could include a date to make it easier to follow the
>   development.
> 
> By the way, I am a bit worried about some of the names that seem to come up 
> in a 
> next version of Julia. For example, 'Nullable' or 'NullableArray' sound 
> strange 
> for me in a technical computing environment.
> 
> 
> On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote:
> I think this is a too strong statement. There are definitely happening a lot 
> on the master (0.4-dev) branch, but it should be quite usable even without 
> reading the majority of Github issues. The more users we have, the earlier 
> concerns is raised, and the earlier we can fix them and prepare for the final 
> release. You should definitely avoid master on any project with a deadline 
> tough.
> 
> 

Re: [julia-users] Re: Current state of 3rd party APIs in Julia?

[Adam Smith]

Re: Google APIs, Google's python clients are pretty complete and 
up-to-date, so I'd suspect that you could get pretty far with those and 
Julia's PyCall to get up & running in the short term.

On Wednesday, September 24, 2014 10:53:05 AM UTC-4, Stefan Karpinski wrote:
>
> Julia Ferraioli wrote a blog post on running Julia on the Google Compute 
> Engine earlier in 2014:
>
>
> http://www.blog.juliaferraioli.com/2014/02/julia-on-google-compute-engine-parallel.html
>
> I'm not sure how up-to-date it is, but it may be helpful.
>
> On Wed, Sep 24, 2014 at 3:10 AM, Viral Shah 
> > wrote:
>
>> The EC2 API is pretty complete in Amit Murthy's AWS.jl, but it needs to 
>> be updated, and takes a long time to compile.
>>
>> I don't know of Google APIs. We do want to have stable and well-tested 
>> packages for some widely used AWS APIs to start with. 
>>
>> -viral
>>
>>
>> On Monday, September 22, 2014 5:24:21 AM UTC+5:30, Randy Zwitch wrote:
>>>
>>> Julia and Postgres works fine using the ODBC.jl package; I know there is 
>>> also a Postgres-specific package in the works. I've used the AWS.jl package 
>>> to download from S3, but haven't used it enough to say it "just works".
>>>
>>> I'm not aware of Google package APIs.
>>>
>>> On Sunday, September 21, 2014 4:25:15 PM UTC-4, Ed wrote:

 Please?

 On Friday, September 19, 2014 11:37:21 AM UTC-6, Ed wrote:
>
> Hello, I was wondering if anybody knows what's the current state of 
> the connectors between Julia and postgres, Amazon S3, and Google Storage 
> and Google BigQuery? Do they "just work", or are they buggy, or 
> completely 
> unusable/not built yet?
>

>

[julia-users] Re: a good IDE for Julia ? (Julia Studio does not work with Julia v 0.3.0)

[Adam Smith]

I'd give somebody's left arm to code in Julia in a Jetbrains IDE, but I 
think writing a plugin requires Java and the full IntelliJ IDEA IDE (which 
is much more expensive than the one I use), so it's not something I can get 
started.

I'm pretty happy with the VIM support for now. Once Julia has a great 
debugger I think commercial IDE integration will be more important.

On Friday, September 26, 2014 5:00:09 AM UTC-4, Ján Dolinský wrote:
>
> Hello,
>
> I cloned the master branch of Julia Studio and compiled it. I am however 
> getting this error when running ./JuliaStudio :
> libExtensionSystem.so.1: cannot open shared object file: No such file or 
> directory
>
> however when running using ./julia-studio.sh it runs but fails to open a 
> console with the following errors:
> Error: Failed to start Julia.
> Expected location: /usr/local/Julia_Studio/julia
>
> I am little bit lost here but exploring the Julia Studio menu I assume 
> that it doe not provide debugging capability (I had an impression that it 
> does).
>
> Thanks,
> Jan
>
>
> Dňa piatok, 19. septembra 2014 11:57:47 UTC+2 Uwe Fechner napísal(-a):
>>
>> I think that this branch is already merged into the master branch:
>> https://github.com/forio/julia-studio/tree/julia-0.3-compatibility
>>
>> On Friday, September 19, 2014 11:54:41 AM UTC+2, Uwe Fechner wrote:
>>>
>>> If you compile Julia Studio from source it should work with Julia 0.3. 
>>> See:
>>> https://github.com/forio/julia-studio/issues/241
>>>
>>> Regards:
>>>
>>> Uwe
>>>
>>> On Friday, September 19, 2014 10:58:26 AM UTC+2, Ján Dolinský wrote:

 Hello guys,

 After upgrading to Julia 0.3.0 Julia Studio stopped working (I changed 
 the symbolic links in Julia Studio directory but nevertheless ...). Can 
 somebody suggest any workaround ? Is it true that Julia Studio will not 
 support newer versions of Julia ?
 What are you guys using now ? 

 Thanks a lot,
 Jan 

>>>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Tim Holy]

Hans, a great way to keep up with what's going on with the development of 0.4 
is to visit the GitHub page
https://github.com/JuliaLang/julia
and click the "Watch" button. But be prepared for a lot of emails.

--Tim

On Friday, September 26, 2014 06:26:36 AM Ivar Nesje wrote:
> Hans: I think the reason you did not get an answer is that your question is
> more a request than a question. NEWS.md is a great resource we try to keep
> updated when we make significant changes to Julia. Unfortunately it's easy
> to forget to update it, so it is often forgotten. I'm not sure we should
> add dates, because often the NEWS.md notice is written a long time before
> the PR is merged. You can look at the commit history
>  if you want.
> 
> Isaiah: Yes, Packages is a really important point for using 0.3.X. I had
> that on my mind while writing my comment, but somehow I missed it.
> 
> kl. 15:01:44 UTC+2 fredag 26. september 2014 skrev Isaiah følgende:
> > Master should be usable, but many packages won't be. Given the limited
> > bandwidth of package maintainers, and the scope of pending changes,
> > supporting both 0.3 and 0.4-dev is probably not realistic for many
> > packages.
> > On Sep 26, 2014 3:19 AM, "Ivar Nesje" >
> > 
> > wrote:
> >> I think this is a too strong statement. There are definitely happening a
> >> lot on the master (0.4-dev) branch, but it should be quite usable even
> >> without reading the majority of Github issues. The more users we have,
> >> the
> >> earlier concerns is raised, and the earlier we can fix them and prepare
> >> for
> >> the final release. You should definitely avoid master on any project with
> >> a
> >> deadline tough.
> >> 
> >> For people compiling julia from source, it would be a great service to
> >> the community to use `release-0.3` instead of the explicit version tags.
> >> All changes to release-0.3 is first tested on master before they are
> >> backported if they don
> >> 
> >> kl. 06:15:11 UTC+2 fredag 26. september 2014 skrev Steve Kelly følgende:
> >>> Case and point: https://github.com/JuliaLang/julia/commit/
> >>> 2ef8d31b6b05ed0a8934c7a13f6490939a30b24b
> >>> 
> >>> :)
> >>> 
> >>> On Thu, Sep 25, 2014 at 11:46 PM, Isaiah Norton 
> >>> 
> >>> wrote:
>  Checking out the release branch is fine; the 0.3.1 tag is on that
>  branch.
>  
>  On Thu, Sep 25, 2014 at 11:12 PM, John Myles White <
>  
>  johnmyl...@gmail.com> wrote:
> > I think it's more correct to check out tags since there seems to be
> > work being done progressively on that branch to keep up with
> > backports.
> > 
> > Not totally sure, though.
> > 
> >  -- John
> > 
> > On Sep 25, 2014, at 7:58 PM, David P. Sanders 
> > wrote:
> > 
> > 
> > 
> > El jueves, 25 de septiembre de 2014 19:59:41 UTC-5, John Myles White
> > 
> > escribió:
> >> I just wanted to suggest that almost everyone on this mailing list
> >> should be using Julia 0.3, not Julia 0.4. Julia 0.4 changes
> >> dramatically
> >> from day to day and is probably not safe for most use cases.
> >> 
> >> I'd suggest the following criterion: "are you reading the comment
> >> threads for the majority of issues being filed on the Julia GitHub
> >> repo?"
> >> If the answer is no, you probably should use Julia 0.3.
> > 
> > Thanks for the nice, clear statement, John!
> > 
> > Currently I have been using
> > 
> > git checkout release-0.3
> > 
> > and compiling from there.
> > 
> > Is this the "correct" thing to do?  I notice there is now a v0.3.1
> > tag.
> > 
> > David.
> > 
> >>  -- John

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Ivar Nesje]

Hans: I think the reason you did not get an answer is that your question is 
more a request than a question. NEWS.md is a great resource we try to keep 
updated when we make significant changes to Julia. Unfortunately it's easy 
to forget to update it, so it is often forgotten. I'm not sure we should 
add dates, because often the NEWS.md notice is written a long time before 
the PR is merged. You can look at the commit history 
 if you want.

Isaiah: Yes, Packages is a really important point for using 0.3.X. I had 
that on my mind while writing my comment, but somehow I missed it.

kl. 15:01:44 UTC+2 fredag 26. september 2014 skrev Isaiah følgende:
>
> Master should be usable, but many packages won't be. Given the limited 
> bandwidth of package maintainers, and the scope of pending changes, 
> supporting both 0.3 and 0.4-dev is probably not realistic for many 
> packages. 
> On Sep 26, 2014 3:19 AM, "Ivar Nesje" > 
> wrote:
>
>> I think this is a too strong statement. There are definitely happening a 
>> lot on the master (0.4-dev) branch, but it should be quite usable even 
>> without reading the majority of Github issues. The more users we have, the 
>> earlier concerns is raised, and the earlier we can fix them and prepare for 
>> the final release. You should definitely avoid master on any project with a 
>> deadline tough.
>>
>> For people compiling julia from source, it would be a great service to 
>> the community to use `release-0.3` instead of the explicit version tags. 
>> All changes to release-0.3 is first tested on master before they are 
>> backported if they don
>>
>> kl. 06:15:11 UTC+2 fredag 26. september 2014 skrev Steve Kelly følgende:
>>>
>>> Case and point: https://github.com/JuliaLang/julia/commit/
>>> 2ef8d31b6b05ed0a8934c7a13f6490939a30b24b
>>>
>>> :)
>>>
>>> On Thu, Sep 25, 2014 at 11:46 PM, Isaiah Norton  
>>> wrote:
>>>
 Checking out the release branch is fine; the 0.3.1 tag is on that 
 branch.

 On Thu, Sep 25, 2014 at 11:12 PM, John Myles White <
 johnmyl...@gmail.com> wrote:

> I think it's more correct to check out tags since there seems to be 
> work being done progressively on that branch to keep up with backports.
>
> Not totally sure, though.
>
>  -- John
>
> On Sep 25, 2014, at 7:58 PM, David P. Sanders  
> wrote:
>
>
>
> El jueves, 25 de septiembre de 2014 19:59:41 UTC-5, John Myles White 
> escribió:
>>
>> I just wanted to suggest that almost everyone on this mailing list 
>> should be using Julia 0.3, not Julia 0.4. Julia 0.4 changes dramatically 
>> from day to day and is probably not safe for most use cases. 
>>
>> I'd suggest the following criterion: "are you reading the comment 
>> threads for the majority of issues being filed on the Julia GitHub 
>> repo?" 
>> If the answer is no, you probably should use Julia 0.3. 
>>
>
> Thanks for the nice, clear statement, John!
>
> Currently I have been using
>
> git checkout release-0.3
>
> and compiling from there.
>
> Is this the "correct" thing to do?  I notice there is now a v0.3.1 tag.
>  
> David.
>
>>
>>  -- John 
>>
>>
>

>>> 

Re: [julia-users] Calling Julia from .NET

[Isaiah Norton]

I am not aware of any VB examples, but if you have c# examples to start
from then the same native invocation should be possible from VB.
On Sep 26, 2014 5:56 AM, "Guido De Bouver" 
wrote:

> dear Julia users,
>
> I would need to call Julia from VB .NET. I have seen it is possible to do
> so from C#, but is it possible to call from VB .NET ? If so, any examples
> available ?
> Thanks for this great product
>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Isaiah Norton]

Master should be usable, but many packages won't be. Given the limited
bandwidth of package maintainers, and the scope of pending changes,
supporting both 0.3 and 0.4-dev is probably not realistic for many
packages.
On Sep 26, 2014 3:19 AM, "Ivar Nesje"  wrote:

> I think this is a too strong statement. There are definitely happening a
> lot on the master (0.4-dev) branch, but it should be quite usable even
> without reading the majority of Github issues. The more users we have, the
> earlier concerns is raised, and the earlier we can fix them and prepare for
> the final release. You should definitely avoid master on any project with a
> deadline tough.
>
> For people compiling julia from source, it would be a great service to the
> community to use `release-0.3` instead of the explicit version tags. All
> changes to release-0.3 is first tested on master before they are backported
> if they don
>
> kl. 06:15:11 UTC+2 fredag 26. september 2014 skrev Steve Kelly følgende:
>>
>> Case and point: https://github.com/JuliaLang/julia/commit/
>> 2ef8d31b6b05ed0a8934c7a13f6490939a30b24b
>>
>> :)
>>
>> On Thu, Sep 25, 2014 at 11:46 PM, Isaiah Norton 
>> wrote:
>>
>>> Checking out the release branch is fine; the 0.3.1 tag is on that branch.
>>>
>>> On Thu, Sep 25, 2014 at 11:12 PM, John Myles White >> > wrote:
>>>
 I think it's more correct to check out tags since there seems to be
 work being done progressively on that branch to keep up with backports.

 Not totally sure, though.

  -- John

 On Sep 25, 2014, at 7:58 PM, David P. Sanders 
 wrote:



 El jueves, 25 de septiembre de 2014 19:59:41 UTC-5, John Myles White
 escribió:
>
> I just wanted to suggest that almost everyone on this mailing list
> should be using Julia 0.3, not Julia 0.4. Julia 0.4 changes dramatically
> from day to day and is probably not safe for most use cases.
>
> I'd suggest the following criterion: "are you reading the comment
> threads for the majority of issues being filed on the Julia GitHub repo?"
> If the answer is no, you probably should use Julia 0.3.
>

 Thanks for the nice, clear statement, John!

 Currently I have been using

 git checkout release-0.3

 and compiling from there.

 Is this the "correct" thing to do?  I notice there is now a v0.3.1 tag.

 David.

>
>  -- John
>
>

>>>
>>

Re: [julia-users] Upgrading/building Images problem

[Adrian Cuthbertson]

It seems I clobbered imagemagick somehow. It was missing from
Homebrew.list(). I've reinstalled that with Homebrew.add("imagemagick"),
then Pkg.build("Images") works ok. All seems ok now.

Thanks for your help Tim!

On Fri, Sep 26, 2014 at 11:28 AM, Tim Holy  wrote:

> Why doesn't it have the path to the ImageMagick libs? Let alone the
> __init__
> function, which is what is triggering the error. Here's an example of what
> it
> should approximately look like:
> https://github.com/timholy/Images.jl/issues/188#issuecomment-56418102
> A "complete" deps.jl will also have the ImageMagick library version.
>
> You might want to check Pkg.status() and see if you have an old copy of
> BinDeps or something. Also, check your Images/build.jl against the version
> at
> https://github.com/timholy/Images.jl/blob/master/deps/build.jl
>
> --Tim
>
> On Friday, September 26, 2014 10:08:55 AM Adrian Cuthbertson wrote:
> > Hi Tim,
> >
> > deps.jl...
> >
> > macro checked_lib(libname, path)
> > (dlopen_e(path) == C_NULL) && error("Unable to load \n\n$libname
> > ($path)\n\nPlease re-run Pkg.build(package), and restart Julia.")
> > quote const $(esc(libname)) = $path end
> > end
> >
> > and yes, I'm on OSX 10.8.5
> >
> > Thanks, Adrian.
> >
> > On Fri, Sep 26, 2014 at 9:19 AM, Tim Holy  wrote:
> > > What does /Users/adrian/.julia/Images/deps/deps.jl look like?
> > >
> > > By "Darwin" does this mean OSX, or are you running something else on
> that
> > > machine?
> > >
> > > --Tim
> > >
> > > On Friday, September 26, 2014 08:43:10 AM Adrian Cuthbertson wrote:
> > > > I had upgraded to 0.4 and then decided to revert to 0.3, with:
> > > > git checkout release-0.3
> > > > make cleanall
> > > > make
> > > >
> > > > I then did a Pkg.update(), but the Images update failed.
> > > > Pkg.build("Images") also.
> > > > Here's the info...
> > > >
> > > > julia> BinDeps.debug("Images")
> > > > INFO: Reading build script...
> > > > ERROR: __init__ not defined
> > > >
> > > >  in include at ./boot.jl:245
> > > >  in include_from_node1 at ./loading.jl:128
> > > >  in debug_context at /Users/adrian/.julia/BinDeps/src/debug.jl:54
> > > >  in debug at /Users/adrian/.julia/BinDeps/src/debug.jl:59
> > > >  in debug at /Users/adrian/.julia/BinDeps/src/debug.jl:65
> > > >
> > > > while loading /Users/adrian/.julia/Images/deps/build.jl, in
> expression
> > > > starting on line 77
> > > >
> > > > julia> versioninfo()
> > > > Julia Version 0.3.2-pre+23
> > > > Commit db57e41* (2014-09-25 20:26 UTC)
> > > >
> > > > Platform Info:
> > > >   System: Darwin (x86_64-apple-darwin12.5.0)
> > > >   CPU: Intel(R) Core(TM)2 Duo CPU T7700  @ 2.40GHz
> > > >   WORD_SIZE: 64
> > > >   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Core2)
> > > >   LAPACK: libopenblas
> > > >   LIBM: libopenlibm
> > > >   LLVM: libLLVM-3.3
> > > >
> > > > Any help appreciated,
> > > > Adrian.
>
>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Hans W Borchers]

Ivar,

thanks for this clarification; I was really under the impression that -- 
like 
for Perl and other projects -- I might never ever again hear from a Julia 
0.4 
version.

A question I asked got buried in another thread and never answered, so I'd 
like 
to repeat it here:

  Will the NEWS.md file immediately document the (disruptive or 
non-disruptive)
  changes? That would be very helpful, even if the change is withdrawn 
later on.
  Also, every NEWS entry could include a date to make it easier to follow 
the
  development.

By the way, I am a bit worried about some of the names that seem to come up 
in a 
next version of Julia. For example, 'Nullable' or 'NullableArray' sound 
strange 
for me in a technical computing environment.


On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote:
>
> I think this is a too strong statement. There are definitely happening a 
> lot on the master (0.4-dev) branch, but it should be quite usable even 
> without reading the majority of Github issues. The more users we have, the 
> earlier concerns is raised, and the earlier we can fix them and prepare for 
> the final release. You should definitely avoid master on any project with a 
> deadline tough.
>
>
>

[julia-users] Calling Julia from .NET

[Guido De Bouver]

dear Julia users,

I would need to call Julia from VB .NET. I have seen it is possible to do 
so from C#, but is it possible to call from VB .NET ? If so, any examples 
available ?
Thanks for this great product

Re: [julia-users] Upgrading/building Images problem

[Tim Holy]

Why doesn't it have the path to the ImageMagick libs? Let alone the __init__ 
function, which is what is triggering the error. Here's an example of what it 
should approximately look like:
https://github.com/timholy/Images.jl/issues/188#issuecomment-56418102
A "complete" deps.jl will also have the ImageMagick library version.

You might want to check Pkg.status() and see if you have an old copy of 
BinDeps or something. Also, check your Images/build.jl against the version at
https://github.com/timholy/Images.jl/blob/master/deps/build.jl

--Tim

On Friday, September 26, 2014 10:08:55 AM Adrian Cuthbertson wrote:
> Hi Tim,
> 
> deps.jl...
> 
> macro checked_lib(libname, path)
> (dlopen_e(path) == C_NULL) && error("Unable to load \n\n$libname
> ($path)\n\nPlease re-run Pkg.build(package), and restart Julia.")
> quote const $(esc(libname)) = $path end
> end
> 
> and yes, I'm on OSX 10.8.5
> 
> Thanks, Adrian.
> 
> On Fri, Sep 26, 2014 at 9:19 AM, Tim Holy  wrote:
> > What does /Users/adrian/.julia/Images/deps/deps.jl look like?
> > 
> > By "Darwin" does this mean OSX, or are you running something else on that
> > machine?
> > 
> > --Tim
> > 
> > On Friday, September 26, 2014 08:43:10 AM Adrian Cuthbertson wrote:
> > > I had upgraded to 0.4 and then decided to revert to 0.3, with:
> > > git checkout release-0.3
> > > make cleanall
> > > make
> > > 
> > > I then did a Pkg.update(), but the Images update failed.
> > > Pkg.build("Images") also.
> > > Here's the info...
> > > 
> > > julia> BinDeps.debug("Images")
> > > INFO: Reading build script...
> > > ERROR: __init__ not defined
> > > 
> > >  in include at ./boot.jl:245
> > >  in include_from_node1 at ./loading.jl:128
> > >  in debug_context at /Users/adrian/.julia/BinDeps/src/debug.jl:54
> > >  in debug at /Users/adrian/.julia/BinDeps/src/debug.jl:59
> > >  in debug at /Users/adrian/.julia/BinDeps/src/debug.jl:65
> > > 
> > > while loading /Users/adrian/.julia/Images/deps/build.jl, in expression
> > > starting on line 77
> > > 
> > > julia> versioninfo()
> > > Julia Version 0.3.2-pre+23
> > > Commit db57e41* (2014-09-25 20:26 UTC)
> > > 
> > > Platform Info:
> > >   System: Darwin (x86_64-apple-darwin12.5.0)
> > >   CPU: Intel(R) Core(TM)2 Duo CPU T7700  @ 2.40GHz
> > >   WORD_SIZE: 64
> > >   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Core2)
> > >   LAPACK: libopenblas
> > >   LIBM: libopenlibm
> > >   LLVM: libLLVM-3.3
> > > 
> > > Any help appreciated,
> > > Adrian.

[julia-users] Re: a good IDE for Julia ? (Julia Studio does not work with Julia v 0.3.0)

[Ján Dolinský]

Hello,

I cloned the master branch of Julia Studio and compiled it. I am however 
getting this error when running ./JuliaStudio :
libExtensionSystem.so.1: cannot open shared object file: No such file or 
directory

however when running using ./julia-studio.sh it runs but fails to open a 
console with the following errors:
Error: Failed to start Julia.
Expected location: /usr/local/Julia_Studio/julia

I am little bit lost here but exploring the Julia Studio menu I assume that 
it doe not provide debugging capability (I had an impression that it does).

Thanks,
Jan


Dňa piatok, 19. septembra 2014 11:57:47 UTC+2 Uwe Fechner napísal(-a):
>
> I think that this branch is already merged into the master branch:
> https://github.com/forio/julia-studio/tree/julia-0.3-compatibility
>
> On Friday, September 19, 2014 11:54:41 AM UTC+2, Uwe Fechner wrote:
>>
>> If you compile Julia Studio from source it should work with Julia 0.3. 
>> See:
>> https://github.com/forio/julia-studio/issues/241
>>
>> Regards:
>>
>> Uwe
>>
>> On Friday, September 19, 2014 10:58:26 AM UTC+2, Ján Dolinský wrote:
>>>
>>> Hello guys,
>>>
>>> After upgrading to Julia 0.3.0 Julia Studio stopped working (I changed 
>>> the symbolic links in Julia Studio directory but nevertheless ...). Can 
>>> somebody suggest any workaround ? Is it true that Julia Studio will not 
>>> support newer versions of Julia ?
>>> What are you guys using now ? 
>>>
>>> Thanks a lot,
>>> Jan 
>>>
>>

[julia-users] Re: problem with HttpServer

[sagar ram]

Thanks Keith,

After digging more into this i found issue is with Requests.jl which is 
making a GET call (get("
http://10.101.41.246/solr/PhysicalDeviceInfo/select?q="*keyVal*"&wt=json";).data)
 
to remote host on load giving this ERROR.
I need to dig more in closing the remote HTTP connection.

Please let us know anything i can do something like request.close.

On Thursday, 25 September 2014 21:28:53 UTC+1, Keith Campbell wrote:
>
> https://github.com/JuliaWeb/HttpServer.jl/blob/master/test/runtests.jl
>
> contains an example that may be helpful.  See lines 27-37.
>
>

Re: [julia-users] Matlab bench in Julia

[Ján Dolinský]

Adding the Julia Dependencies repo then updating and upgrading the system 
did not change anything. "versioninfo()" gives me the same output. Shall I 
purge Julia and re-install it again ?

Thanks,
Jan 

Dňa piatok, 26. septembra 2014 10:19:33 UTC+2 Ján Dolinský napísal(-a):
>
> Actually after more careful look, I found in Julia dependencies repo 
> "openblas 0.2.10.1-juliadeps1~trusty" but I thought this repo is not needed 
> because the description of the repo says it is meant for Ubuntu up to 13.04 
> but apparently there are two packages for trusty in there ... 
>
> Dňa piatok, 26. septembra 2014 10:14:10 UTC+2 Ján Dolinský napísal(-a):
>>
>> Hello,
>>
>> I am using the repo you mentioned. I upgraded to latest version and I get 
>> the following:
>> versioninfo()
>> Julia Version 0.3.1
>> Commit c03f413 (2014-09-21 21:30 UTC)
>> Platform Info:
>>   System: Linux (x86_64-linux-gnu)
>>   CPU: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
>>   WORD_SIZE: 64
>>   BLAS: libblas.so.3
>>   LAPACK: liblapack.so.3
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.3
>>
>> I did not included Julia Dependencies repo because it is meant for Ubuntu 
>> up to 13.04.
>>
>> I both repos however OpenBLAS is available only for Raring, Quantal and 
>> Precise not for Trusty Tahr ... so I assume Julia 0.3.1~trusty1 is using 
>> original Ubuntu repo for linear algebra libraries and thus users of Trusty 
>> Tahr ends up without OpenBLAS.
>>
>> Best Regards,
>> Jan
>>
>> Dňa štvrtok, 25. septembra 2014 16:57:48 UTC+2 Andreas Noack napísal(-a):
>>>
>>> It appears that you are not using a fast BLAS. The BLAS and LAPACK 
>>> entries in versioninfo() should say libopenblas instead of libblas and 
>>> liblapack. You should use 
>>>
>>> https://launchpad.net/~staticfloat/+archive/ubuntu/juliareleases
>>>
>>> as your repo for julia. That should give you Julia with fast linear 
>>> algebra.
>>>
>>> Med venlig hilsen
>>>
>>> Andreas Noack
>>>
>>> 2014-09-25 10:36 GMT-04:00 Ján Dolinský :
>>>
 Hello,

 Yes, Andreas point makes sense. Sometimes you may not want threaded 
 linear algebra routines. 

 My current installation reports this:
 versioninfo()
 Julia Version 0.3.0
 Commit 7681878 (2014-08-20 20:43 UTC)
 Platform Info:
   System: Linux (x86_64-linux-gnu)
   CPU: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
   WORD_SIZE: 64
   BLAS: libblas.so.3
   LAPACK: liblapack.so.3
   LIBM: libopenlibm
   LLVM: libLLVM-3.3

 Am I using the right library ? How do I plug-in the OpenBLAS ? I am 
 under Ubuntu 14.4.01.

 Thanks,
 Jan

 Dňa štvrtok, 25. septembra 2014 14:47:12 UTC+2 Andreas Noack 
 napísal(-a):
>
> OpenBLAS uses threads by default, but Milan reported that Fedora's 
> maintainer had them disabled. Hence, unless you are using Fedora, you 
> should have threaded OpenBLAS.
>
> What is the best setup for fast linear algebra operations ?
>
>
> That question doesn't have a single answer. Often when people want to 
> show performance of linear algebra libraries they run a single routine on 
> a 
> big matrix. In that case you'll often benefit from many threads. However, 
> in many applications you solve smaller problems many times. In this case, 
> many threads can actually be a problem and you could be better off with 
> turning off OpenBLAS threading. So it depends on your problem.
>
> Med venlig hilsen
>
> Andreas Noack
>
> 2014-09-25 5:52 GMT-04:00 Ján Dolinský:
>
>> Hello,
>>
>> How do I make Julia to use threaded version of OpenBLAS ? Do I have 
>> to compile using some special option or there is a config file ?
>> What is the best setup for fast linear algebra operations ?
>>
>> Best Regards,
>> Jan
>>
>> Dňa nedeľa, 21. septembra 2014 9:50:52 UTC+2 Stephan Buchert 
>> napísal(-a):
>>
>>> Wow, I have now LU a little bit faster on the latest julia Fedora 
>>> package than on my locally compiled julia:
>>>
>>> julia> versioninfo()
>>> Julia Version 0.3.0
>>> Platform Info:
>>>   System: Linux (x86_64-redhat-linux)
>>>   CPU: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
>>>   LAPACK: libopenblasp.so.0
>>>   LIBM: libopenlibm
>>>   LLVM: libLLVM-3.3
>>>
>>> julia> include("code/julia/bench.jl")
>>> LU decomposition, elapsed time: 0.07222901 seconds, was 0.123 
>>> seconds with my julia
>>> FFT , elapsed time: 0.248571629 seconds
>>>
>>> Thanks for making and  improving the Fedora package
>>>
>>
>
>>>

Re: [julia-users] Matlab bench in Julia

[Ján Dolinský]

Actually after more careful look, I found in Julia dependencies repo 
"openblas 0.2.10.1-juliadeps1~trusty" but I thought this repo is not needed 
because the description of the repo says it is meant for Ubuntu up to 13.04 
but apparently there are two packages for trusty in there ... 

Dňa piatok, 26. septembra 2014 10:14:10 UTC+2 Ján Dolinský napísal(-a):
>
> Hello,
>
> I am using the repo you mentioned. I upgraded to latest version and I get 
> the following:
> versioninfo()
> Julia Version 0.3.1
> Commit c03f413 (2014-09-21 21:30 UTC)
> Platform Info:
>   System: Linux (x86_64-linux-gnu)
>   CPU: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
>   WORD_SIZE: 64
>   BLAS: libblas.so.3
>   LAPACK: liblapack.so.3
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> I did not included Julia Dependencies repo because it is meant for Ubuntu 
> up to 13.04.
>
> I both repos however OpenBLAS is available only for Raring, Quantal and 
> Precise not for Trusty Tahr ... so I assume Julia 0.3.1~trusty1 is using 
> original Ubuntu repo for linear algebra libraries and thus users of Trusty 
> Tahr ends up without OpenBLAS.
>
> Best Regards,
> Jan
>
> Dňa štvrtok, 25. septembra 2014 16:57:48 UTC+2 Andreas Noack napísal(-a):
>>
>> It appears that you are not using a fast BLAS. The BLAS and LAPACK 
>> entries in versioninfo() should say libopenblas instead of libblas and 
>> liblapack. You should use 
>>
>> https://launchpad.net/~staticfloat/+archive/ubuntu/juliareleases
>>
>> as your repo for julia. That should give you Julia with fast linear 
>> algebra.
>>
>> Med venlig hilsen
>>
>> Andreas Noack
>>
>> 2014-09-25 10:36 GMT-04:00 Ján Dolinský :
>>
>>> Hello,
>>>
>>> Yes, Andreas point makes sense. Sometimes you may not want threaded 
>>> linear algebra routines. 
>>>
>>> My current installation reports this:
>>> versioninfo()
>>> Julia Version 0.3.0
>>> Commit 7681878 (2014-08-20 20:43 UTC)
>>> Platform Info:
>>>   System: Linux (x86_64-linux-gnu)
>>>   CPU: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libblas.so.3
>>>   LAPACK: liblapack.so.3
>>>   LIBM: libopenlibm
>>>   LLVM: libLLVM-3.3
>>>
>>> Am I using the right library ? How do I plug-in the OpenBLAS ? I am 
>>> under Ubuntu 14.4.01.
>>>
>>> Thanks,
>>> Jan
>>>
>>> Dňa štvrtok, 25. septembra 2014 14:47:12 UTC+2 Andreas Noack napísal(-a):

 OpenBLAS uses threads by default, but Milan reported that Fedora's 
 maintainer had them disabled. Hence, unless you are using Fedora, you 
 should have threaded OpenBLAS.

 What is the best setup for fast linear algebra operations ?


 That question doesn't have a single answer. Often when people want to 
 show performance of linear algebra libraries they run a single routine on 
 a 
 big matrix. In that case you'll often benefit from many threads. However, 
 in many applications you solve smaller problems many times. In this case, 
 many threads can actually be a problem and you could be better off with 
 turning off OpenBLAS threading. So it depends on your problem.

 Med venlig hilsen

 Andreas Noack

 2014-09-25 5:52 GMT-04:00 Ján Dolinský:

> Hello,
>
> How do I make Julia to use threaded version of OpenBLAS ? Do I have to 
> compile using some special option or there is a config file ?
> What is the best setup for fast linear algebra operations ?
>
> Best Regards,
> Jan
>
> Dňa nedeľa, 21. septembra 2014 9:50:52 UTC+2 Stephan Buchert 
> napísal(-a):
>
>> Wow, I have now LU a little bit faster on the latest julia Fedora 
>> package than on my locally compiled julia:
>>
>> julia> versioninfo()
>> Julia Version 0.3.0
>> Platform Info:
>>   System: Linux (x86_64-redhat-linux)
>>   CPU: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
>>   LAPACK: libopenblasp.so.0
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.3
>>
>> julia> include("code/julia/bench.jl")
>> LU decomposition, elapsed time: 0.07222901 seconds, was 0.123 seconds 
>> with my julia
>> FFT , elapsed time: 0.248571629 seconds
>>
>> Thanks for making and  improving the Fedora package
>>
>

>>

Re: [julia-users] Matlab bench in Julia

[Ján Dolinský]

Hello,

I am using the repo you mentioned. I upgraded to latest version and I get 
the following:
versioninfo()
Julia Version 0.3.1
Commit c03f413 (2014-09-21 21:30 UTC)
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
  WORD_SIZE: 64
  BLAS: libblas.so.3
  LAPACK: liblapack.so.3
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

I did not included Julia Dependencies repo because it is meant for Ubuntu 
up to 13.04.

I both repos however OpenBLAS is available only for Raring, Quantal and 
Precise not for Trusty Tahr ... so I assume Julia 0.3.1~trusty1 is using 
original Ubuntu repo for linear algebra libraries and thus users of Trusty 
Tahr ends up without OpenBLAS.

Best Regards,
Jan

Dňa štvrtok, 25. septembra 2014 16:57:48 UTC+2 Andreas Noack napísal(-a):
>
> It appears that you are not using a fast BLAS. The BLAS and LAPACK entries 
> in versioninfo() should say libopenblas instead of libblas and liblapack. 
> You should use 
>
> https://launchpad.net/~staticfloat/+archive/ubuntu/juliareleases
>
> as your repo for julia. That should give you Julia with fast linear 
> algebra.
>
> Med venlig hilsen
>
> Andreas Noack
>
> 2014-09-25 10:36 GMT-04:00 Ján Dolinský  >:
>
>> Hello,
>>
>> Yes, Andreas point makes sense. Sometimes you may not want threaded 
>> linear algebra routines. 
>>
>> My current installation reports this:
>> versioninfo()
>> Julia Version 0.3.0
>> Commit 7681878 (2014-08-20 20:43 UTC)
>> Platform Info:
>>   System: Linux (x86_64-linux-gnu)
>>   CPU: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
>>   WORD_SIZE: 64
>>   BLAS: libblas.so.3
>>   LAPACK: liblapack.so.3
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.3
>>
>> Am I using the right library ? How do I plug-in the OpenBLAS ? I am under 
>> Ubuntu 14.4.01.
>>
>> Thanks,
>> Jan
>>
>> Dňa štvrtok, 25. septembra 2014 14:47:12 UTC+2 Andreas Noack napísal(-a):
>>>
>>> OpenBLAS uses threads by default, but Milan reported that Fedora's 
>>> maintainer had them disabled. Hence, unless you are using Fedora, you 
>>> should have threaded OpenBLAS.
>>>
>>> What is the best setup for fast linear algebra operations ?
>>>
>>>
>>> That question doesn't have a single answer. Often when people want to 
>>> show performance of linear algebra libraries they run a single routine on a 
>>> big matrix. In that case you'll often benefit from many threads. However, 
>>> in many applications you solve smaller problems many times. In this case, 
>>> many threads can actually be a problem and you could be better off with 
>>> turning off OpenBLAS threading. So it depends on your problem.
>>>
>>> Med venlig hilsen
>>>
>>> Andreas Noack
>>>
>>> 2014-09-25 5:52 GMT-04:00 Ján Dolinský:
>>>
 Hello,

 How do I make Julia to use threaded version of OpenBLAS ? Do I have to 
 compile using some special option or there is a config file ?
 What is the best setup for fast linear algebra operations ?

 Best Regards,
 Jan

 Dňa nedeľa, 21. septembra 2014 9:50:52 UTC+2 Stephan Buchert 
 napísal(-a):

> Wow, I have now LU a little bit faster on the latest julia Fedora 
> package than on my locally compiled julia:
>
> julia> versioninfo()
> Julia Version 0.3.0
> Platform Info:
>   System: Linux (x86_64-redhat-linux)
>   CPU: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblasp.so.0
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> julia> include("code/julia/bench.jl")
> LU decomposition, elapsed time: 0.07222901 seconds, was 0.123 seconds 
> with my julia
> FFT , elapsed time: 0.248571629 seconds
>
> Thanks for making and  improving the Fedora package
>

>>>
>

[julia-users] Julia 0.3.1 error when installing IJulia

[Daniel Høegh]

My versioninfo is:

julia> versioninfo()
Julia Version 0.3.1
Commit c03f413* (2014-09-21 21:30 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

[julia-users] Julia 0.3.1 error when installing IJulia

[Daniel Høegh]

I have updated Julia to 0.3.1 to get rid of the error regarding profiling. When 
I tried to install IJulia
I encountered an error see the log. I think it is an error in BinDeps but I am 
not sure, can anybody help me?
```
julia> Pkg.add("IJulia")
INFO: Cloning cache of BinDeps from git://github.com/JuliaLang/BinDeps.jl.git
INFO: Cloning cache of HTTPClient from git://github.com/JuliaWeb/HTTPClient.jl.g
it
INFO: Cloning cache of IJulia from git://github.com/JuliaLang/IJulia.jl.git
INFO: Cloning cache of JSON from git://github.com/JuliaLang/JSON.jl.git
INFO: Cloning cache of LibCURL from git://github.com/JuliaWeb/LibCURL.jl.git
INFO: Cloning cache of LibExpat from git://github.com/amitmurthy/LibExpat.jl.git

INFO: Cloning cache of Nettle from git://github.com/staticfloat/Nettle.jl.git
INFO: Cloning cache of REPLCompletions from git://github.com/Keno/REPLCompletion
s.jl.git
INFO: Cloning cache of SHA from git://github.com/staticfloat/SHA.jl.git
INFO: Cloning cache of URIParser from git://github.com/JuliaWeb/URIParser.jl.git

INFO: Cloning cache of URLParse from git://github.com/tanmaykm/URLParse.jl.git
INFO: Cloning cache of WinRPM from git://github.com/JuliaLang/WinRPM.jl.git
INFO: Cloning cache of ZMQ from git://github.com/JuliaLang/ZMQ.jl.git
INFO: Cloning cache of Zlib from git://github.com/dcjones/Zlib.jl.git
INFO: Installing BinDeps v0.3.5
INFO: Installing HTTPClient v0.1.4
INFO: Installing IJulia v0.1.15
INFO: Installing JSON v0.3.8
INFO: Installing LibCURL v0.1.4
INFO: Installing LibExpat v0.0.4
INFO: Installing Nettle v0.1.6
INFO: Installing REPLCompletions v0.0.3
INFO: Installing SHA v0.0.3
INFO: Installing URIParser v0.0.3
INFO: Installing URLParse v0.0.0
INFO: Installing WinRPM v0.1.2
INFO: Installing ZMQ v0.1.13
INFO: Installing Zlib v0.1.7
INFO: Building WinRPM
WARNING: The URLParse.jl package has been deprecated in favour of JuliaWeb/URIPa
rser.jl
https://github.com/JuliaWeb/URIParser.jl
As of Julia 0.4 this package will no longer be installable
through `Pkg.add`. Please convert your code accordingly.
WARNING: skipping repodata/repomd.xml, not in cache -- call WinRPM.update() to d
ownload
WARNING: skipping repodata/repomd.xml, not in cache -- call WinRPM.update() to d
ownload
INFO: Downloading http://download.opensuse.org/repositories/windows:/mingw:/win3
2/openSUSE_13.1//repodata/repomd.xml
INFO: Downloading http://download.opensuse.org/repositories/windows:/mingw:/win3
2/openSUSE_13.1//repodata/ad33f4a5b71009783361067934a560478eeda01c17d4887aad6e91
de3777a0c0-primary.xml.gz
WARNING: encounted invalid data while parsing repomd
===[ ERROR: WinRPM ]


"ErrorException(\"Error parsing document : 0\"), not well-formed (invalid token)
, 1, 1, 1"
while loading C:\Users\Hoegh\.julia\v0.3\WinRPM\deps\build.jl, in expression sta
rting on line 2



INFO: Building LibCURL
INFO: Updating WinRPM package list
INFO: Downloading http://download.opensuse.org/repositories/windows:/mingw:/win3
2/openSUSE_13.1//repodata/repomd.xml
WARNING: encounted invalid data while parsing repomd
===[ ERROR: LibCURL ]===


"ErrorException(\"Error parsing document : 0\"), not well-formed (invalid token)
, 1, 1, 1"
while loading C:\Users\Hoegh\.julia\v0.3\LibCURL\deps\build.jl, in expression st
arting on line 14



INFO: Building Nettle
INFO: Updating WinRPM package list
INFO: Downloading http://download.opensuse.org/repositories/windows:/mingw:/win3
2/openSUSE_13.1//repodata/repomd.xml
WARNING: encounted invalid data while parsing repomd
===[ ERROR: Nettle ]


"ErrorException(\"Error parsing document : 0\"), not well-formed (invalid token)
, 1, 1, 1"
while loading C:\Users\Hoegh\.julia\v0.3\Nettle\deps\build.jl, in expression sta
rting on line 38



INFO: Building ZMQ
INFO: Attempting to Create directory C:\Users\Hoegh\.julia\v0.3\ZMQ\deps\downloa
ds
INFO: Downloading file http://s3.amazonaws.com/julialang/bin/winnt/extras/libzmq
-3.3-x64.zip
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  100k  100  100k0 0   153k  0 --:--:-- --:--:-- --:--:--  153k
INFO: Done downloading file http://s3.amazonaws.com/julialang/bin/winnt/extras/l
ibzmq-3.3-x64.zip
INFO: Attempting to Create directory C:\Users\Hoegh\.julia\v0.3\ZMQ
INFO: Directory C:\Users\Hoegh\.julia\v0.3\ZMQ already created
INFO: Attempting to Create directory C:\Users\Hoegh\.julia\v0.3\ZMQ\deps\usr

7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18

Processing archive: C:\Users\Hoegh\.julia\v0.3\ZMQ\deps\downloads\libzmq-3.3-x64

Re: [julia-users] Upgrading/building Images problem

[Adrian Cuthbertson]

Hi Tim,

deps.jl...

macro checked_lib(libname, path)
(dlopen_e(path) == C_NULL) && error("Unable to load \n\n$libname
($path)\n\nPlease re-run Pkg.build(package), and restart Julia.")
quote const $(esc(libname)) = $path end
end

and yes, I'm on OSX 10.8.5

Thanks, Adrian.



On Fri, Sep 26, 2014 at 9:19 AM, Tim Holy  wrote:

> What does /Users/adrian/.julia/Images/deps/deps.jl look like?
>
> By "Darwin" does this mean OSX, or are you running something else on that
> machine?
>
> --Tim
>
> On Friday, September 26, 2014 08:43:10 AM Adrian Cuthbertson wrote:
> > I had upgraded to 0.4 and then decided to revert to 0.3, with:
> > git checkout release-0.3
> > make cleanall
> > make
> >
> > I then did a Pkg.update(), but the Images update failed.
> > Pkg.build("Images") also.
> > Here's the info...
> >
> > julia> BinDeps.debug("Images")
> > INFO: Reading build script...
> > ERROR: __init__ not defined
> >  in include at ./boot.jl:245
> >  in include_from_node1 at ./loading.jl:128
> >  in debug_context at /Users/adrian/.julia/BinDeps/src/debug.jl:54
> >  in debug at /Users/adrian/.julia/BinDeps/src/debug.jl:59
> >  in debug at /Users/adrian/.julia/BinDeps/src/debug.jl:65
> > while loading /Users/adrian/.julia/Images/deps/build.jl, in expression
> > starting on line 77
> >
> > julia> versioninfo()
> > Julia Version 0.3.2-pre+23
> > Commit db57e41* (2014-09-25 20:26 UTC)
> > Platform Info:
> >   System: Darwin (x86_64-apple-darwin12.5.0)
> >   CPU: Intel(R) Core(TM)2 Duo CPU T7700  @ 2.40GHz
> >   WORD_SIZE: 64
> >   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Core2)
> >   LAPACK: libopenblas
> >   LIBM: libopenlibm
> >   LLVM: libLLVM-3.3
> >
> > Any help appreciated,
> > Adrian.
>
>

[julia-users] IJulia Interrupt key restart kernel

[xiongjieyi]

In IJulia, when I press the Interrupt button to Ctrl-C the running script, 
it always pop up a window with:
"The kernel appears to have died. It will restart automatically."
and the kernel is rebooted totally. How to just send a Ctrl-C in IJulia 
rather than reboot the kernel?

[julia-users] Re: Why lufact() is faster than my code?

[Staro Pickle]

Thank you all.

On Friday, September 26, 2014 2:50:56 AM UTC+8, Jason Riedy wrote:
>
>
> Others have given some reasons...  If you want to see contortions 
> that were (perhaps still are) necessary to be competitive, see: 
>   
> https://groups.google.com/forum/#!msg/julia-users/DJRxApmpJmU/NqepNaX5ARIJ 
>

This article is expert but as you say, they are not clear and straight. Is 
it possible to call BLAS-3 an easy way?  
 

> However, if your matrices always have this form, I would highly 
> recommend solving a few by hand to notice the pattern. 
>

Good observation and sense! Yes, I know that can be calculated by hand. I 
use this matrix in a case related to sparse matrix. 

By the way, the citation above is not displayed grey as usual. I made a few 
try but didn't see how. Should that text be chosen grey? 

[julia-users] Re: Why lufact() is faster than my code?

[Staro Pickle]

>
> How to make comment? 

 > Is that what you want or not? 

 > interesting...


OK. 

[julia-users] Re: Why lufact() is faster than my code?

[Staro Pickle]

Thank you all.

On Friday, September 26, 2014 2:50:56 AM UTC+8, Jason Riedy wrote:
>
>
> Others have given some reasons...  If you want to see contortions 
> that were (perhaps still are) necessary to be competitive, see: 
>   
> https://groups.google.com/forum/#!msg/julia-users/DJRxApmpJmU/NqepNaX5ARIJ 
>
 
 This article is expert but as you say, they are not clear and straight. Is 
it possible to call BLAS-3 an easy way?  

 

> However, if your matrices always have this form, I would highly 
> recommend solving a few by hand to notice the pattern. 


Good observation and sense! Yes, I know that can be calculated by hand. I 
use this matrix in a case related to sparse matrix.

[julia-users] Re: Why lufact() is faster than my code?

[Staro Pickle]

Thank you all.


On Friday, September 26, 2014 2:50:56 AM UTC+8, Jason Riedy wrote:
>
>
> Others have given some reasons...  If you want to see contortions 
> that were (perhaps still are) necessary to be competitive, see: 
>   
> https://groups.google.com/forum/#!msg/julia-users/DJRxApmpJmU/NqepNaX5ARIJ 
>

This article is expert but as you say, they are not clear and straight. Is 
it possible to call BLAS-3 an easy way?  
 

> However, if your matrices always have this form, I would highly 
> recommend solving a few by hand to notice the pattern. 


 Good observation and sense! Yes, I know that can be calculated by hand. I 
use this matrix in a case related to sparse matrix.

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Ivar Nesje]

Sorry (somehow I sendt the previous mail by accident while writing it)

My point was that `release-0.3` does not (intentionally) break backwards 
compatibility, and if it breaks anything it would be really great to get a 
bug report before we tag a new 0.3.X release. The more testers/users we 
have, the better. We are also very careful about what we accept on 
release-0.3, so it is unlikely that anything major breaks. The tagged 
releases is mostly a signal to people that we have worked on fixes and that 
it is time to upgrade.

Regards
Ivar

kl. 09:19:37 UTC+2 fredag 26. september 2014 skrev Ivar Nesje følgende:
>
> I think this is a too strong statement. There are definitely happening a 
> lot on the master (0.4-dev) branch, but it should be quite usable even 
> without reading the majority of Github issues. The more users we have, the 
> earlier concerns is raised, and the earlier we can fix them and prepare for 
> the final release. You should definitely avoid master on any project with a 
> deadline tough.
>
> For people compiling julia from source, it would be a great service to the 
> community to use `release-0.3` instead of the explicit version tags. All 
> changes to release-0.3 is first tested on master before they are backported 
> if they don
>
> kl. 06:15:11 UTC+2 fredag 26. september 2014 skrev Steve Kelly følgende:
>>
>> Case and point: 
>> https://github.com/JuliaLang/julia/commit/2ef8d31b6b05ed0a8934c7a13f6490939a30b24b
>>
>> :)
>>
>> On Thu, Sep 25, 2014 at 11:46 PM, Isaiah Norton  
>> wrote:
>>
>>> Checking out the release branch is fine; the 0.3.1 tag is on that branch.
>>>
>>> On Thu, Sep 25, 2014 at 11:12 PM, John Myles White >> > wrote:
>>>
 I think it's more correct to check out tags since there seems to be 
 work being done progressively on that branch to keep up with backports.

 Not totally sure, though.

  -- John

 On Sep 25, 2014, at 7:58 PM, David P. Sanders  
 wrote:



 El jueves, 25 de septiembre de 2014 19:59:41 UTC-5, John Myles White 
 escribió:
>
> I just wanted to suggest that almost everyone on this mailing list 
> should be using Julia 0.3, not Julia 0.4. Julia 0.4 changes dramatically 
> from day to day and is probably not safe for most use cases. 
>
> I'd suggest the following criterion: "are you reading the comment 
> threads for the majority of issues being filed on the Julia GitHub repo?" 
> If the answer is no, you probably should use Julia 0.3. 
>

 Thanks for the nice, clear statement, John!

 Currently I have been using

 git checkout release-0.3

 and compiling from there.

 Is this the "correct" thing to do?  I notice there is now a v0.3.1 tag.
  
 David.

>
>  -- John 
>
>

>>>
>>

Re: [julia-users] Re: PSA: Choosing between Julia 0.3 vs Julia 0.4

[Ivar Nesje]

I think this is a too strong statement. There are definitely happening a 
lot on the master (0.4-dev) branch, but it should be quite usable even 
without reading the majority of Github issues. The more users we have, the 
earlier concerns is raised, and the earlier we can fix them and prepare for 
the final release. You should definitely avoid master on any project with a 
deadline tough.

For people compiling julia from source, it would be a great service to the 
community to use `release-0.3` instead of the explicit version tags. All 
changes to release-0.3 is first tested on master before they are backported 
if they don

kl. 06:15:11 UTC+2 fredag 26. september 2014 skrev Steve Kelly følgende:
>
> Case and point: 
> https://github.com/JuliaLang/julia/commit/2ef8d31b6b05ed0a8934c7a13f6490939a30b24b
>
> :)
>
> On Thu, Sep 25, 2014 at 11:46 PM, Isaiah Norton  > wrote:
>
>> Checking out the release branch is fine; the 0.3.1 tag is on that branch.
>>
>> On Thu, Sep 25, 2014 at 11:12 PM, John Myles White > > wrote:
>>
>>> I think it's more correct to check out tags since there seems to be work 
>>> being done progressively on that branch to keep up with backports.
>>>
>>> Not totally sure, though.
>>>
>>>  -- John
>>>
>>> On Sep 25, 2014, at 7:58 PM, David P. Sanders >> > wrote:
>>>
>>>
>>>
>>> El jueves, 25 de septiembre de 2014 19:59:41 UTC-5, John Myles White 
>>> escribió:

 I just wanted to suggest that almost everyone on this mailing list 
 should be using Julia 0.3, not Julia 0.4. Julia 0.4 changes dramatically 
 from day to day and is probably not safe for most use cases. 

 I'd suggest the following criterion: "are you reading the comment 
 threads for the majority of issues being filed on the Julia GitHub repo?" 
 If the answer is no, you probably should use Julia 0.3. 

>>>
>>> Thanks for the nice, clear statement, John!
>>>
>>> Currently I have been using
>>>
>>> git checkout release-0.3
>>>
>>> and compiling from there.
>>>
>>> Is this the "correct" thing to do?  I notice there is now a v0.3.1 tag.
>>>  
>>> David.
>>>

  -- John 


>>>
>>
>

Re: [julia-users] Upgrading/building Images problem

[Tim Holy]

What does /Users/adrian/.julia/Images/deps/deps.jl look like?

By "Darwin" does this mean OSX, or are you running something else on that 
machine?

--Tim

On Friday, September 26, 2014 08:43:10 AM Adrian Cuthbertson wrote:
> I had upgraded to 0.4 and then decided to revert to 0.3, with:
> git checkout release-0.3
> make cleanall
> make
> 
> I then did a Pkg.update(), but the Images update failed.
> Pkg.build("Images") also.
> Here's the info...
> 
> julia> BinDeps.debug("Images")
> INFO: Reading build script...
> ERROR: __init__ not defined
>  in include at ./boot.jl:245
>  in include_from_node1 at ./loading.jl:128
>  in debug_context at /Users/adrian/.julia/BinDeps/src/debug.jl:54
>  in debug at /Users/adrian/.julia/BinDeps/src/debug.jl:59
>  in debug at /Users/adrian/.julia/BinDeps/src/debug.jl:65
> while loading /Users/adrian/.julia/Images/deps/build.jl, in expression
> starting on line 77
> 
> julia> versioninfo()
> Julia Version 0.3.2-pre+23
> Commit db57e41* (2014-09-25 20:26 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin12.5.0)
>   CPU: Intel(R) Core(TM)2 Duo CPU T7700  @ 2.40GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Core2)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
> 
> Any help appreciated,
> Adrian.