Re: [julia-users] Re: ApproxFun First Order PDE Question

[idontgetoutmuch]

I tried

Pkg.checkout("ApproxFun")

using ApproxFun

d = domain(Fun(identity,[0.0,1.0]))
f = Fun(x->exp(-x^2),d)
D = Derivative(d)
L = 2.0D⊗I+I⊗D
u = [ldirichlet(d)⊗I,L]\[f]

but I get the following error

julia> u = [ldirichlet(d)⊗I,L]\[f]

ERROR: MethodError: `cont_reduce_dofs!` has no method matching 
cont_reduce_dofs!(::ApproxFun.OperatorSchur{Float64,Float64}, 
::ApproxFun.SavedBandedOperator{Float64,ApproxFun.ConstantTimesOperator{Float64,ApproxFun.Derivative{ApproxFun.Ultraspherical{0},Int64,Float64},Float64}},
 
::ApproxFun.SavedBandedOperator{Float64,ApproxFun.TimesOperator{Float64}}, 
::Array{Any,1}, 
::ApproxFun.ProductFun{ApproxFun.Ultraspherical{1},ApproxFun.Ultraspherical{1},ApproxFun.TensorSpace{ApproxFun.Ultraspherical{1},ApproxFun.Ultraspherical{1},Float64,ApproxFun.Domain{T<:Number}},Float64})
Closest candidates are:
  
cont_reduce_dofs!{T<:ApproxFun.Fun{S<:ApproxFun.FunctionSpace{T,D},T<:Number}}(::ApproxFun.OperatorSchur{BT<:Number,MT<:Number},
 
::ApproxFun.Operator{T}, ::ApproxFun.Operator{T}, 
!Matched::Array{T<:ApproxFun.Fun{S<:ApproxFun.FunctionSpace{T,D},T<:Number},1}, 
::ApproxFun.ProductFun{S<:ApproxFun.FunctionSpace{T,D},V<:ApproxFun.FunctionSpace{T,D},SS<:ApproxFun.AbstractProductSpace{S,V,T,D},T})
  
cont_reduce_dofs!{T<:ApproxFun.Fun{S<:ApproxFun.FunctionSpace{T,D},T<:Number}}(::ApproxFun.OperatorSchur{BT<:Number,MT<:Number},
 
::ApproxFun.Operator{T}, ::ApproxFun.Operator{T}, 
!Matched::Array{T<:ApproxFun.Fun{S<:ApproxFun.FunctionSpace{T,D},T<:Number},1}, 
!Matched::Array{T,N})
  
cont_reduce_dofs!{T<:ApproxFun.Fun{S<:ApproxFun.FunctionSpace{T,D},T<:Number},NT<:Number}(!Matched::AbstractArray{NT<:Number,N},
 
::ApproxFun.Operator{T}, 
!Matched::Array{T<:ApproxFun.Fun{S<:ApproxFun.FunctionSpace{T,D},T<:Number},1}, 
!Matched::ApproxFun.Fun{S<:ApproxFun.FunctionSpace{T,D},T<:Number})
  ...
 in cont_constrained_lyap at 
/Users/dom/.julia/v0.4/ApproxFun/src/PDE/cont_lyap.jl:300
 in cont_constrained_lyap at 
/Users/dom/.julia/v0.4/ApproxFun/src/PDE/cont_lyap.jl:295
 in pdesolve at /Users/dom/.julia/v0.4/ApproxFun/src/PDE/pdesolve.jl:146
 in pdesolve at /Users/dom/.julia/v0.4/ApproxFun/src/PDE/pdesolve.jl:145
 in pdesolve at /Users/dom/.julia/v0.4/ApproxFun/src/PDE/pdesolve.jl:120
 in \ at /Users/dom/.julia/v0.4/ApproxFun/src/PDE/pdesolve.jl:157

Re: [julia-users] Can't make something out of nothing

[Dominique Orban]

Ah! Lowercase "n"! Thanks!

On Thursday, April 16, 2015 at 6:33:17 PM UTC-4, Scott T wrote:
>
> julia> type Something
>s::Void
>end
>
>
> julia> Something(nothing)
> Something(nothing)
>
>
>
> On Thursday, 16 April 2015 23:23:52 UTC+1, Dominique Orban wrote:
>>
>> Which way should I change my example then? It seems all combinations of 
>> Void/Nothing and Void()/Nothing() give me the same MethodError.
>>
>> On Thursday, April 16, 2015 at 4:14:21 PM UTC-4, Jameson wrote:
>>>
>>> Nothing was renamed to Void, to better reflect its place in C-interop. 
>>> It's instance is still named `nothing`.
>>>
>>> On Thu, Apr 16, 2015 at 4:03 PM Dominique Orban  
>>> wrote:
>>>
 In 0.3, I used to be able to make something out of nothing:

 julia> VERSION
 v"0.3.6"

 julia> type Something
s :: Nothing
end

 julia> Something(Nothing())
 Something(nothing)

 but no longer in 0.4:

 julia> VERSION
 v"0.4.0-dev+4294"

 julia> type Something
s :: Nothing
end

 julia> Something(Nothing())
 ERROR: MethodError: `convert` has no method matching convert(::Type{
 Void})
 This may have arisen from a call to the constructor Void(...),
 since type constructors fall back to convert methods.
 Closest candidates are:
   convert{T}(::Type{T}, ::T)
  in call at base.jl:38


 How do I achieve the same effect?

 Thanks.

>>>

Re: [julia-users] Can't make something out of nothing

[Scott T]

julia> type Something
   s::Void
   end


julia> Something(nothing)
Something(nothing)



On Thursday, 16 April 2015 23:23:52 UTC+1, Dominique Orban wrote:
>
> Which way should I change my example then? It seems all combinations of 
> Void/Nothing and Void()/Nothing() give me the same MethodError.
>
> On Thursday, April 16, 2015 at 4:14:21 PM UTC-4, Jameson wrote:
>>
>> Nothing was renamed to Void, to better reflect its place in C-interop. 
>> It's instance is still named `nothing`.
>>
>> On Thu, Apr 16, 2015 at 4:03 PM Dominique Orban  
>> wrote:
>>
>>> In 0.3, I used to be able to make something out of nothing:
>>>
>>> julia> VERSION
>>> v"0.3.6"
>>>
>>> julia> type Something
>>>s :: Nothing
>>>end
>>>
>>> julia> Something(Nothing())
>>> Something(nothing)
>>>
>>> but no longer in 0.4:
>>>
>>> julia> VERSION
>>> v"0.4.0-dev+4294"
>>>
>>> julia> type Something
>>>s :: Nothing
>>>end
>>>
>>> julia> Something(Nothing())
>>> ERROR: MethodError: `convert` has no method matching convert(::Type{Void
>>> })
>>> This may have arisen from a call to the constructor Void(...),
>>> since type constructors fall back to convert methods.
>>> Closest candidates are:
>>>   convert{T}(::Type{T}, ::T)
>>>  in call at base.jl:38
>>>
>>>
>>> How do I achieve the same effect?
>>>
>>> Thanks.
>>>
>>

[julia-users] Re: Julia and Spark

[Andrei Zh]

Julia bindings for Spark would provide much more than just RDD, they will 
give us access to multiple big data components for streaming, machine 
learning, SQL capabilities and much more. 

On Friday, April 17, 2015 at 12:54:32 AM UTC+3, wil...@gmail.com wrote:
>
> However, I wonder, how hard it would be to implement RDD in Julia? It 
> looks straight forward from a RDD paper 
>  how to 
> implement it. It is a robust abstraction that can be used in any parallel 
> computation.
>
> On Thursday, April 16, 2015 at 3:32:32 AM UTC-4, Steven Sagaert wrote:
>>
>> yes that's a solid approach. For my personal julia - java integrations I 
>> also run the JVM in a separate process.
>>
>> On Wednesday, April 15, 2015 at 9:30:28 PM UTC+2, wil...@gmail.com wrote:
>>>
>>> 1) simply wrap the Spark java API via JavaCall. This is the low level 
 approach. BTW I've experimented with javaCall and found it was unstable & 
 also lacking functionality (e.g. there's no way to shutdown the jvm or 
 create a pool of JVM analogous to DB connections) so that might need some 
 work before trying the Spark integration.

>>>
>>> Using JavaCall is not an option, especially when JVM became 
>>> close-sourced, see https://github.com/aviks/JavaCall.jl/issues/7.
>>>
>>> Python bindings are done through Py4J, which is RPC to JVM. If you look 
>>> at the sparkR , it is 
>>> done in a same way. sparkR uses a RPC interface to communicate with a 
>>> Netty-based Spark JVM backend that translates R calls into JVM calls, keeps 
>>> SparkContext on a JVM side, and ships serialized data to/from R.
>>>
>>> So it is just a matter of writing Julia RPC to JVM and wrapping 
>>> necessary Spark methods in a Julia friendly way. 
>>>
>>

Re: [julia-users] Can't make something out of nothing

[Dominique Orban]

Which way should I change my example then? It seems all combinations of 
Void/Nothing and Void()/Nothing() give me the same MethodError.

On Thursday, April 16, 2015 at 4:14:21 PM UTC-4, Jameson wrote:
>
> Nothing was renamed to Void, to better reflect its place in C-interop. 
> It's instance is still named `nothing`.
>
> On Thu, Apr 16, 2015 at 4:03 PM Dominique Orban  > wrote:
>
>> In 0.3, I used to be able to make something out of nothing:
>>
>> julia> VERSION
>> v"0.3.6"
>>
>> julia> type Something
>>s :: Nothing
>>end
>>
>> julia> Something(Nothing())
>> Something(nothing)
>>
>> but no longer in 0.4:
>>
>> julia> VERSION
>> v"0.4.0-dev+4294"
>>
>> julia> type Something
>>s :: Nothing
>>end
>>
>> julia> Something(Nothing())
>> ERROR: MethodError: `convert` has no method matching convert(::Type{Void
>> })
>> This may have arisen from a call to the constructor Void(...),
>> since type constructors fall back to convert methods.
>> Closest candidates are:
>>   convert{T}(::Type{T}, ::T)
>>  in call at base.jl:38
>>
>>
>> How do I achieve the same effect?
>>
>> Thanks.
>>
>

[julia-users] Re: Julia and Spark

[wildart]

However, I wonder, how hard it would be to implement RDD in Julia? It looks 
straight forward from a RDD paper 
 how to 
implement it. It is a robust abstraction that can be used in any parallel 
computation.

On Thursday, April 16, 2015 at 3:32:32 AM UTC-4, Steven Sagaert wrote:
>
> yes that's a solid approach. For my personal julia - java integrations I 
> also run the JVM in a separate process.
>
> On Wednesday, April 15, 2015 at 9:30:28 PM UTC+2, wil...@gmail.com wrote:
>>
>> 1) simply wrap the Spark java API via JavaCall. This is the low level 
>>> approach. BTW I've experimented with javaCall and found it was unstable & 
>>> also lacking functionality (e.g. there's no way to shutdown the jvm or 
>>> create a pool of JVM analogous to DB connections) so that might need some 
>>> work before trying the Spark integration.
>>>
>>
>> Using JavaCall is not an option, especially when JVM became 
>> close-sourced, see https://github.com/aviks/JavaCall.jl/issues/7.
>>
>> Python bindings are done through Py4J, which is RPC to JVM. If you look 
>> at the sparkR , it is 
>> done in a same way. sparkR uses a RPC interface to communicate with a 
>> Netty-based Spark JVM backend that translates R calls into JVM calls, keeps 
>> SparkContext on a JVM side, and ships serialized data to/from R.
>>
>> So it is just a matter of writing Julia RPC to JVM and wrapping necessary 
>> Spark methods in a Julia friendly way. 
>>
>

Re: [julia-users] Can't make something out of nothing

[Jameson Nash]

Nothing was renamed to Void, to better reflect its place in C-interop. It's
instance is still named `nothing`.

On Thu, Apr 16, 2015 at 4:03 PM Dominique Orban 
wrote:

> In 0.3, I used to be able to make something out of nothing:
>
> julia> VERSION
> v"0.3.6"
>
> julia> type Something
>s :: Nothing
>end
>
> julia> Something(Nothing())
> Something(nothing)
>
> but no longer in 0.4:
>
> julia> VERSION
> v"0.4.0-dev+4294"
>
> julia> type Something
>s :: Nothing
>end
>
> julia> Something(Nothing())
> ERROR: MethodError: `convert` has no method matching convert(::Type{Void})
> This may have arisen from a call to the constructor Void(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   convert{T}(::Type{T}, ::T)
>  in call at base.jl:38
>
>
> How do I achieve the same effect?
>
> Thanks.
>

[julia-users] Can't make something out of nothing

[Dominique Orban]

In 0.3, I used to be able to make something out of nothing:

julia> VERSION
v"0.3.6"

julia> type Something
   s :: Nothing
   end

julia> Something(Nothing())
Something(nothing)

but no longer in 0.4:

julia> VERSION
v"0.4.0-dev+4294"

julia> type Something
   s :: Nothing
   end

julia> Something(Nothing())
ERROR: MethodError: `convert` has no method matching convert(::Type{Void})
This may have arisen from a call to the constructor Void(...),
since type constructors fall back to convert methods.
Closest candidates are:
  convert{T}(::Type{T}, ::T)
 in call at base.jl:38


How do I achieve the same effect?

Thanks.

Re: [julia-users] DataFrames IO error

[Stefan Karpinski]

Probably most effective to open an issue on the DataFrames package.

On Thu, Apr 16, 2015 at 1:10 PM, Arshak Navruzyan  wrote:

> Trying to read 30GB file into a DataFrame on a machine with 60GB of RAM. I
> get the following error
>
> MemoryError()
> while loading In[12], in expression starting on line 1
>
>  in readtable at /home/ubuntu/.julia/v0.3/DataFrames/src/dataframe/io.jl:833
>  in readtable at /home/ubuntu/.julia/v0.3/DataFrames/src/dataframe/io.jl:893
>
>
> noticed in the code, it's allocating doing this:
>
> nbytes = 2 * filesize(pathname)
>
> Is this really necessary?
>

[julia-users] DataFrames IO error

[Arshak Navruzyan]

Trying to read 30GB file into a DataFrame on a machine with 60GB of RAM. I
get the following error

MemoryError()
while loading In[12], in expression starting on line 1

 in readtable at /home/ubuntu/.julia/v0.3/DataFrames/src/dataframe/io.jl:833
 in readtable at /home/ubuntu/.julia/v0.3/DataFrames/src/dataframe/io.jl:893


noticed in the code, it's allocating doing this:

nbytes = 2 * filesize(pathname)

Is this really necessary?

Re: [julia-users] Non-GPL Julia?

[Tony Kelman]

Yes, Pardiso certainly has Cholesky. Also general symmetric indefinite 
Bunch-Kaufman with inertia output, which makes it quite useful for 
non-convex optimization applications. Not sure about sparse QR in Pardiso 
or some other component of MKL but it might be in there somewhere.


On Thursday, April 16, 2015 at 9:53:50 AM UTC-7, Viral Shah wrote:
>
> Can Pardiso do cholesky as well as LU? I think QR is probably still 
> missing in MKL. 
>
> -viral 
>
>
>
> > On 16-Apr-2015, at 10:10 pm, Tony Kelman > 
> wrote: 
> > 
> > MKL contains Pardiso and a number of other sparse routines that can be 
> quite useful and could be good alternatives to SuiteSparse (as well as 
> providing some additional functionality that SuiteSparse does not have), 
> but would of course need to have Julia bindings written for them. The API 
> documentation for MKL is quite comprehensive so I don't expect this would 
> be all that challenging, but work still needs to be done on the sparse 
> linear algebra functionality in base to make things more flexible so you 
> could easily swap out different backend solver libraries. The situation is 
> a bit more complicated than with swapping out different dense Blas/Lapack 
> implementations where the API's are standardized. 
> > 
> > 
> > On Thursday, April 16, 2015 at 9:32:01 AM UTC-7, Viral Shah wrote: 
> > The useful parts of SuiteSparse are all GPL. So, for a GPL-free build, 
> it is straightforward to completely avoid using SuiteSparse. 
> > 
> > One of the things I want is to have a version of Julia built with Intel 
> compilers and linked to MKL. Julia can already use Intel's BLAS, LAPACK, 
> LIBM, and FFT routines. There is also a VML package for vector math 
> functions. The only big missing piece is sparse solvers - but perhaps that 
> is ok for people, who can use Intel's sparse solvers or MUMPS or something 
> else. 
> > 
> > -viral 
> > 
> > On Thursday, April 16, 2015 at 7:51:38 PM UTC+5:30, Isaiah wrote: 
> > I recently annotated the license list to give myself (and others) a 
> quick-look grasp of the license situation: 
> > 
> > 
> https://github.com/JuliaLang/julia/commit/d2ee85d1135fd801f1230530f39f05369f6384df
>  
> > 
> > I agree with Tony that in the short-term, distributing a GPL-free binary 
> ourselves is not a priority, but pull requests to make the situation 
> clearer or to make a GPL-free build simpler would be fine. For example, 
> there could be a NO_GPL Makefile variable, and a macro on the Julia side to 
> annotate and selectively exclude GPL stuff from the system image (FFTW and 
> Rmath should be, respectively, easy and very easy to exclude, however I'm 
> not sure how deeply entangled the SuiteSparse stuff is). 
> > 
> > 
> > 
> > On Thu, Apr 16, 2015 at 10:04 AM, Tony Kelman  wrote: 
> > It's certainly a long-term goal. 0.4 is far enough behind-schedule 
> already that it's very unlikely to happen by then. Like most things in open 
> source, it's limited by available labor. People who want to see it happen 
> will need to help out if they want it to happen faster. For this particular 
> issue of GPL dependencies, the most useful places to contribute would be 
> helping set up BinDeps for the forked Rmath-julia library so it does not 
> need to be built by base and Distributions.jl can still work well and be 
> easy to install, and asking on the "New DFT API" pull request whether there 
> are specific areas where Steven Johnson needs help - likely answers are 
> benchmarking, conflict resolution to rebase to master, and setting up FFTW 
> as a package with automatic BinDeps etc. 
> > 
> > Removing things from Base has proven difficult to do smoothly, and while 
> it will be necessary to slim down the mandatory runtime dependencies for 
> embedding, static compilation, and less-restrictive licensing use cases, a 
> lot of work still needs to be done to figure out how to manage code 
> migrations in the least disruptive manner possible. I don't think this is 
> the primary concern of any core Julia developers or contributors at the 
> moment (in fact several people have said they would strongly prefer to not 
> remove any other code from Base until after 0.4.0 is released, and I agree 
> with that), but help and contributions are always welcome. 
> > 
> > 
> > On Wednesday, April 15, 2015 at 6:51:44 AM UTC-7, Sebastian Good wrote: 
> > Is producing a non-GPL Julia build still on the radar? It might be a 
> nice goal for the 0.4 release, even if we have to build it ourselves (e.g. 
> against MKL, etc.) 
> > 
> > On Monday, April 21, 2014 at 5:00:47 PM UTC-4, Steven G. Johnson wrote: 
> > 
> > 
> > On Monday, April 21, 2014 4:40:38 PM UTC-4, Tobias Knopp wrote: 
> > Yes this is awesome work you have done there. Do you plan to implement 
> the real-data FFT, DCT and DST in pure Julia also? Then one could really 
> think about moving FFTW into a package. Hopefully its author is ok with 
> that ;-) 
> > 
> > I plan to implement real-data FFTs, and move FFTW int

Re: [julia-users] Non-GPL Julia?

[Viral Shah]

Can Pardiso do cholesky as well as LU? I think QR is probably still missing in 
MKL.

-viral



> On 16-Apr-2015, at 10:10 pm, Tony Kelman  wrote:
> 
> MKL contains Pardiso and a number of other sparse routines that can be quite 
> useful and could be good alternatives to SuiteSparse (as well as providing 
> some additional functionality that SuiteSparse does not have), but would of 
> course need to have Julia bindings written for them. The API documentation 
> for MKL is quite comprehensive so I don't expect this would be all that 
> challenging, but work still needs to be done on the sparse linear algebra 
> functionality in base to make things more flexible so you could easily swap 
> out different backend solver libraries. The situation is a bit more 
> complicated than with swapping out different dense Blas/Lapack 
> implementations where the API's are standardized.
> 
> 
> On Thursday, April 16, 2015 at 9:32:01 AM UTC-7, Viral Shah wrote:
> The useful parts of SuiteSparse are all GPL. So, for a GPL-free build, it is 
> straightforward to completely avoid using SuiteSparse.
> 
> One of the things I want is to have a version of Julia built with Intel 
> compilers and linked to MKL. Julia can already use Intel's BLAS, LAPACK, 
> LIBM, and FFT routines. There is also a VML package for vector math 
> functions. The only big missing piece is sparse solvers - but perhaps that is 
> ok for people, who can use Intel's sparse solvers or MUMPS or something else.
> 
> -viral
> 
> On Thursday, April 16, 2015 at 7:51:38 PM UTC+5:30, Isaiah wrote:
> I recently annotated the license list to give myself (and others) a 
> quick-look grasp of the license situation:
> 
> https://github.com/JuliaLang/julia/commit/d2ee85d1135fd801f1230530f39f05369f6384df
> 
> I agree with Tony that in the short-term, distributing a GPL-free binary 
> ourselves is not a priority, but pull requests to make the situation clearer 
> or to make a GPL-free build simpler would be fine. For example, there could 
> be a NO_GPL Makefile variable, and a macro on the Julia side to annotate and 
> selectively exclude GPL stuff from the system image (FFTW and Rmath should 
> be, respectively, easy and very easy to exclude, however I'm not sure how 
> deeply entangled the SuiteSparse stuff is).
> 
> 
> 
> On Thu, Apr 16, 2015 at 10:04 AM, Tony Kelman  wrote:
> It's certainly a long-term goal. 0.4 is far enough behind-schedule already 
> that it's very unlikely to happen by then. Like most things in open source, 
> it's limited by available labor. People who want to see it happen will need 
> to help out if they want it to happen faster. For this particular issue of 
> GPL dependencies, the most useful places to contribute would be helping set 
> up BinDeps for the forked Rmath-julia library so it does not need to be built 
> by base and Distributions.jl can still work well and be easy to install, and 
> asking on the "New DFT API" pull request whether there are specific areas 
> where Steven Johnson needs help - likely answers are benchmarking, conflict 
> resolution to rebase to master, and setting up FFTW as a package with 
> automatic BinDeps etc.
> 
> Removing things from Base has proven difficult to do smoothly, and while it 
> will be necessary to slim down the mandatory runtime dependencies for 
> embedding, static compilation, and less-restrictive licensing use cases, a 
> lot of work still needs to be done to figure out how to manage code 
> migrations in the least disruptive manner possible. I don't think this is the 
> primary concern of any core Julia developers or contributors at the moment 
> (in fact several people have said they would strongly prefer to not remove 
> any other code from Base until after 0.4.0 is released, and I agree with 
> that), but help and contributions are always welcome.
> 
> 
> On Wednesday, April 15, 2015 at 6:51:44 AM UTC-7, Sebastian Good wrote:
> Is producing a non-GPL Julia build still on the radar? It might be a nice 
> goal for the 0.4 release, even if we have to build it ourselves (e.g. against 
> MKL, etc.)
> 
> On Monday, April 21, 2014 at 5:00:47 PM UTC-4, Steven G. Johnson wrote:
> 
> 
> On Monday, April 21, 2014 4:40:38 PM UTC-4, Tobias Knopp wrote:
> Yes this is awesome work you have done there. Do you plan to implement the 
> real-data FFT, DCT and DST in pure Julia also? Then one could really think 
> about moving FFTW into a package. Hopefully its author is ok with that ;-) 
> 
> I plan to implement real-data FFTs, and move FFTW into a package.
> 
> Pure-Julia DCT and DST are not in my immediate plans (they are a PITA to do 
> right because there are 16 types, of which 8 are common); my feeling is that 
> the need for these is uncommon enough that it's not terrible to have these in 
> a package instead of in Base.(Hadamard transforms and MDCTs are also 
> currently in packages.)
> 

[julia-users] Re: Need help parallelizing this benchmark

[Viral Shah]

Multi-threading in Julia is still some ways away. Basic thread safety 
should be in place soon after 0.4.

-viral

On Thursday, April 16, 2015 at 6:43:42 AM UTC+5:30, SixString wrote:
>
> @Kristoffer Carlsson , I do appreciate your help and your clever use of 
> Yeppp, which is limited to reals.  I may be able to redesign my algorithm 
> with all reals and get faster execution with Julia than with Python, which 
> does not have a wrapper for Yeppp that I could find.  Doing so may also 
> involve vectorized dot products with the BLAS library.  Since I am 
> processing GB-sized vectors, this involves large temporary vectors, and I 
> may not have enough RAM.  Also, it contradicts the advice I was given 
> previously in this forum to write my loops in pure Julia for speed.  So I 
> would still like to hear from forum members about how to get parallelized 
> pure Julia code executing faster than single-threaded.  Maybe I have to 
> wait for Julia v0.5 for this to manifest.
>

Re: [julia-users] Re: Non-GPL Julia?

[Tony Kelman]

MKL contains Pardiso and a number of other sparse routines that can be 
quite useful and could be good alternatives to SuiteSparse (as well as 
providing some additional functionality that SuiteSparse does not have), 
but would of course need to have Julia bindings written for them. The API 
documentation for MKL is quite comprehensive so I don't expect this would 
be all that challenging, but work still needs to be done on the sparse 
linear algebra functionality in base to make things more flexible so you 
could easily swap out different backend solver libraries. The situation is 
a bit more complicated than with swapping out different dense Blas/Lapack 
implementations where the API's are standardized.


On Thursday, April 16, 2015 at 9:32:01 AM UTC-7, Viral Shah wrote:
>
> The useful parts of SuiteSparse are all GPL. So, for a GPL-free build, it 
> is straightforward to completely avoid using SuiteSparse.
>
> One of the things I want is to have a version of Julia built with Intel 
> compilers and linked to MKL. Julia can already use Intel's BLAS, LAPACK, 
> LIBM, and FFT routines. There is also a VML package for vector math 
> functions. The only big missing piece is sparse solvers - but perhaps that 
> is ok for people, who can use Intel's sparse solvers or MUMPS or something 
> else.
>
> -viral
>
> On Thursday, April 16, 2015 at 7:51:38 PM UTC+5:30, Isaiah wrote:
>>
>> I recently annotated the license list to give myself (and others) a 
>> quick-look grasp of the license situation:
>>
>>
>> https://github.com/JuliaLang/julia/commit/d2ee85d1135fd801f1230530f39f05369f6384df
>>
>> I agree with Tony that in the short-term, distributing a GPL-free binary 
>> ourselves is not a priority, but pull requests to make the situation 
>> clearer or to make a GPL-free build simpler would be fine. For example, 
>> there could be a NO_GPL Makefile variable, and a macro on the Julia side to 
>> annotate and selectively exclude GPL stuff from the system image (FFTW and 
>> Rmath should be, respectively, easy and very easy to exclude, however I'm 
>> not sure how deeply entangled the SuiteSparse stuff is).
>>
>>
>>
>> On Thu, Apr 16, 2015 at 10:04 AM, Tony Kelman > > wrote:
>>
>>> It's certainly a long-term goal. 0.4 is far enough behind-schedule 
>>> already that it's very unlikely to happen by then. Like most things in open 
>>> source, it's limited by available labor. People who want to see it happen 
>>> will need to help out if they want it to happen faster. For this particular 
>>> issue of GPL dependencies, the most useful places to contribute would be 
>>> helping set up BinDeps for the forked Rmath-julia library so it does not 
>>> need to be built by base and Distributions.jl can still work well and be 
>>> easy to install, and asking on the "New DFT API" pull request whether there 
>>> are specific areas where Steven Johnson needs help - likely answers are 
>>> benchmarking, conflict resolution to rebase to master, and setting up FFTW 
>>> as a package with automatic BinDeps etc.
>>>
>>> Removing things from Base has proven difficult to do smoothly, and while 
>>> it will be necessary to slim down the mandatory runtime dependencies for 
>>> embedding, static compilation, and less-restrictive licensing use cases, a 
>>> lot of work still needs to be done to figure out how to manage code 
>>> migrations in the least disruptive manner possible. I don't think this is 
>>> the primary concern of any core Julia developers or contributors at the 
>>> moment (in fact several people have said they would strongly prefer to not 
>>> remove any other code from Base until after 0.4.0 is released, and I agree 
>>> with that), but help and contributions are always welcome.
>>>
>>>
>>> On Wednesday, April 15, 2015 at 6:51:44 AM UTC-7, Sebastian Good wrote:

 Is producing a non-GPL Julia build still on the radar? It might be a 
 nice goal for the 0.4 release, even if we have to build it ourselves (e.g. 
 against MKL, etc.)

 On Monday, April 21, 2014 at 5:00:47 PM UTC-4, Steven G. Johnson wrote:
>
>
>
> On Monday, April 21, 2014 4:40:38 PM UTC-4, Tobias Knopp wrote:
>>
>> Yes this is awesome work you have done there. Do you plan to 
>> implement the real-data FFT, DCT and DST in pure Julia also? Then one 
>> could 
>> really think about moving FFTW into a package. Hopefully its author is 
>> ok 
>> with that ;-) 
>>
>
> I plan to implement real-data FFTs, and move FFTW into a package.
>
> Pure-Julia DCT and DST are not in my immediate plans (they are a PITA 
> to do right because there are 16 types, of which 8 are common); my 
> feeling 
> is that the need for these is uncommon enough that it's not terrible to 
> have these in a package instead of in Base.(Hadamard transforms and 
> MDCTs are also currently in packages.)
>

>>

Re: [julia-users] Re: Non-GPL Julia?

[Viral Shah]

The useful parts of SuiteSparse are all GPL. So, for a GPL-free build, it 
is straightforward to completely avoid using SuiteSparse.

One of the things I want is to have a version of Julia built with Intel 
compilers and linked to MKL. Julia can already use Intel's BLAS, LAPACK, 
LIBM, and FFT routines. There is also a VML package for vector math 
functions. The only big missing piece is sparse solvers - but perhaps that 
is ok for people, who can use Intel's sparse solvers or MUMPS or something 
else.

-viral

On Thursday, April 16, 2015 at 7:51:38 PM UTC+5:30, Isaiah wrote:
>
> I recently annotated the license list to give myself (and others) a 
> quick-look grasp of the license situation:
>
>
> https://github.com/JuliaLang/julia/commit/d2ee85d1135fd801f1230530f39f05369f6384df
>
> I agree with Tony that in the short-term, distributing a GPL-free binary 
> ourselves is not a priority, but pull requests to make the situation 
> clearer or to make a GPL-free build simpler would be fine. For example, 
> there could be a NO_GPL Makefile variable, and a macro on the Julia side to 
> annotate and selectively exclude GPL stuff from the system image (FFTW and 
> Rmath should be, respectively, easy and very easy to exclude, however I'm 
> not sure how deeply entangled the SuiteSparse stuff is).
>
>
>
> On Thu, Apr 16, 2015 at 10:04 AM, Tony Kelman  wrote:
>
>> It's certainly a long-term goal. 0.4 is far enough behind-schedule 
>> already that it's very unlikely to happen by then. Like most things in open 
>> source, it's limited by available labor. People who want to see it happen 
>> will need to help out if they want it to happen faster. For this particular 
>> issue of GPL dependencies, the most useful places to contribute would be 
>> helping set up BinDeps for the forked Rmath-julia library so it does not 
>> need to be built by base and Distributions.jl can still work well and be 
>> easy to install, and asking on the "New DFT API" pull request whether there 
>> are specific areas where Steven Johnson needs help - likely answers are 
>> benchmarking, conflict resolution to rebase to master, and setting up FFTW 
>> as a package with automatic BinDeps etc.
>>
>> Removing things from Base has proven difficult to do smoothly, and while 
>> it will be necessary to slim down the mandatory runtime dependencies for 
>> embedding, static compilation, and less-restrictive licensing use cases, a 
>> lot of work still needs to be done to figure out how to manage code 
>> migrations in the least disruptive manner possible. I don't think this is 
>> the primary concern of any core Julia developers or contributors at the 
>> moment (in fact several people have said they would strongly prefer to not 
>> remove any other code from Base until after 0.4.0 is released, and I agree 
>> with that), but help and contributions are always welcome.
>>
>>
>> On Wednesday, April 15, 2015 at 6:51:44 AM UTC-7, Sebastian Good wrote:
>>>
>>> Is producing a non-GPL Julia build still on the radar? It might be a 
>>> nice goal for the 0.4 release, even if we have to build it ourselves (e.g. 
>>> against MKL, etc.)
>>>
>>> On Monday, April 21, 2014 at 5:00:47 PM UTC-4, Steven G. Johnson wrote:



 On Monday, April 21, 2014 4:40:38 PM UTC-4, Tobias Knopp wrote:
>
> Yes this is awesome work you have done there. Do you plan to implement 
> the real-data FFT, DCT and DST in pure Julia also? Then one could really 
> think about moving FFTW into a package. Hopefully its author is ok with 
> that ;-) 
>

 I plan to implement real-data FFTs, and move FFTW into a package.

 Pure-Julia DCT and DST are not in my immediate plans (they are a PITA 
 to do right because there are 16 types, of which 8 are common); my feeling 
 is that the need for these is uncommon enough that it's not terrible to 
 have these in a package instead of in Base.(Hadamard transforms and 
 MDCTs are also currently in packages.)

>>>
>

[julia-users] Re: Best way of using code introduced in 0.4 in 0.3 builds?

[Tony Kelman]

Note that it's actually best to run the Compat.jl version-determining 
script based on the *merge commit* where a change gets introduced onto 
master, which is not usually the same thing as the commit that introduces 
the change itself (when it originates from a PR). The counting of number of 
commits since the last tag can potentially be different depending on how 
far back the pull request branched off from. Since we only build nightlies 
off of master, we should primarily target the 
number-of-commits-since-last-tag using the mainline of master to count. 
This could get slightly confused when bisecting down into specific branches 
of where a commit originated, but it's probably the more reliable option. 
Of course the relevance of the specific number during 0.4-dev goes down 
over time as people are less likely to be using builds from immediately 
around the time some change gets introduced.


On Wednesday, April 15, 2015 at 11:25:55 AM UTC-7, Seth wrote:
>
>
>
> On Wednesday, April 15, 2015 at 11:08:27 AM UTC-7, Steven G. Johnson wrote:
>>
>> On Wednesday, April 15, 2015 at 10:31:46 AM UTC-4, Seth wrote:
>>>
>>> 1) is getting Pair into 0.3 something that Compat.jl should handle, or 
>>> should it be a request to get it backported to the main 0.3 build?
>>>
>>  
>> Maybe it could go into Compat.  But isn't Pair mainly useful when you 
>> have the nice a => b syntax for Pair(a,b)?
>>
>>
> I'm using it because it provides a Base-supported "native" type that I can 
> use for graph edges (source and dest vertices are the elements of the 
> pair). The => construct is just an added bonus. In 0.3 I could default to 
> my own custom datatype, but it'd be nice if Pair were available in earlier 
> versions. 
>
>
> 2) what's the best way to determine the version number that introduced 
>>> Pair in 0.4? (I've tried git bisect but couldn't get a definitive answer.) 
>>> This would be the approach I'd take immediately: to have the old type 
>>> available if the version of Julia running didn't support Pair.
>>>
>>
>> I would look at git blame on the base/exports.jl file, to see when Pair 
>> was exported.  That turns up this commit:
>>
>>
>> https://github.com/JuliaLang/julia/commit/034b8f5599c3dcd3e770ba8af3a9c28ef2497532
>>
>>  To turn this into a version number, see the little shell script on the 
>> Compat.jl page -- it produces 0.4.0-dev+818 for this commit.
>>
>
> Thanks. I recall doing something similar a while back but couldn't 
> remember the precise steps.
>  
>

Re: [julia-users] Re: Non-GPL Julia?

[Isaiah Norton]

I recently annotated the license list to give myself (and others) a
quick-look grasp of the license situation:

https://github.com/JuliaLang/julia/commit/d2ee85d1135fd801f1230530f39f05369f6384df

I agree with Tony that in the short-term, distributing a GPL-free binary
ourselves is not a priority, but pull requests to make the situation
clearer or to make a GPL-free build simpler would be fine. For example,
there could be a NO_GPL Makefile variable, and a macro on the Julia side to
annotate and selectively exclude GPL stuff from the system image (FFTW and
Rmath should be, respectively, easy and very easy to exclude, however I'm
not sure how deeply entangled the SuiteSparse stuff is).



On Thu, Apr 16, 2015 at 10:04 AM, Tony Kelman  wrote:

> It's certainly a long-term goal. 0.4 is far enough behind-schedule already
> that it's very unlikely to happen by then. Like most things in open source,
> it's limited by available labor. People who want to see it happen will need
> to help out if they want it to happen faster. For this particular issue of
> GPL dependencies, the most useful places to contribute would be helping set
> up BinDeps for the forked Rmath-julia library so it does not need to be
> built by base and Distributions.jl can still work well and be easy to
> install, and asking on the "New DFT API" pull request whether there are
> specific areas where Steven Johnson needs help - likely answers are
> benchmarking, conflict resolution to rebase to master, and setting up FFTW
> as a package with automatic BinDeps etc.
>
> Removing things from Base has proven difficult to do smoothly, and while
> it will be necessary to slim down the mandatory runtime dependencies for
> embedding, static compilation, and less-restrictive licensing use cases, a
> lot of work still needs to be done to figure out how to manage code
> migrations in the least disruptive manner possible. I don't think this is
> the primary concern of any core Julia developers or contributors at the
> moment (in fact several people have said they would strongly prefer to not
> remove any other code from Base until after 0.4.0 is released, and I agree
> with that), but help and contributions are always welcome.
>
>
> On Wednesday, April 15, 2015 at 6:51:44 AM UTC-7, Sebastian Good wrote:
>>
>> Is producing a non-GPL Julia build still on the radar? It might be a nice
>> goal for the 0.4 release, even if we have to build it ourselves (e.g.
>> against MKL, etc.)
>>
>> On Monday, April 21, 2014 at 5:00:47 PM UTC-4, Steven G. Johnson wrote:
>>>
>>>
>>>
>>> On Monday, April 21, 2014 4:40:38 PM UTC-4, Tobias Knopp wrote:

 Yes this is awesome work you have done there. Do you plan to implement
 the real-data FFT, DCT and DST in pure Julia also? Then one could really
 think about moving FFTW into a package. Hopefully its author is ok with
 that ;-)

>>>
>>> I plan to implement real-data FFTs, and move FFTW into a package.
>>>
>>> Pure-Julia DCT and DST are not in my immediate plans (they are a PITA to
>>> do right because there are 16 types, of which 8 are common); my feeling is
>>> that the need for these is uncommon enough that it's not terrible to have
>>> these in a package instead of in Base.(Hadamard transforms and MDCTs
>>> are also currently in packages.)
>>>
>>

[julia-users] Re: Non-GPL Julia?

[Tony Kelman]

It's certainly a long-term goal. 0.4 is far enough behind-schedule already 
that it's very unlikely to happen by then. Like most things in open source, 
it's limited by available labor. People who want to see it happen will need 
to help out if they want it to happen faster. For this particular issue of 
GPL dependencies, the most useful places to contribute would be helping set 
up BinDeps for the forked Rmath-julia library so it does not need to be 
built by base and Distributions.jl can still work well and be easy to 
install, and asking on the "New DFT API" pull request whether there are 
specific areas where Steven Johnson needs help - likely answers are 
benchmarking, conflict resolution to rebase to master, and setting up FFTW 
as a package with automatic BinDeps etc.

Removing things from Base has proven difficult to do smoothly, and while it 
will be necessary to slim down the mandatory runtime dependencies for 
embedding, static compilation, and less-restrictive licensing use cases, a 
lot of work still needs to be done to figure out how to manage code 
migrations in the least disruptive manner possible. I don't think this is 
the primary concern of any core Julia developers or contributors at the 
moment (in fact several people have said they would strongly prefer to not 
remove any other code from Base until after 0.4.0 is released, and I agree 
with that), but help and contributions are always welcome.


On Wednesday, April 15, 2015 at 6:51:44 AM UTC-7, Sebastian Good wrote:
>
> Is producing a non-GPL Julia build still on the radar? It might be a nice 
> goal for the 0.4 release, even if we have to build it ourselves (e.g. 
> against MKL, etc.)
>
> On Monday, April 21, 2014 at 5:00:47 PM UTC-4, Steven G. Johnson wrote:
>>
>>
>>
>> On Monday, April 21, 2014 4:40:38 PM UTC-4, Tobias Knopp wrote:
>>>
>>> Yes this is awesome work you have done there. Do you plan to implement 
>>> the real-data FFT, DCT and DST in pure Julia also? Then one could really 
>>> think about moving FFTW into a package. Hopefully its author is ok with 
>>> that ;-) 
>>>
>>
>> I plan to implement real-data FFTs, and move FFTW into a package.
>>
>> Pure-Julia DCT and DST are not in my immediate plans (they are a PITA to 
>> do right because there are 16 types, of which 8 are common); my feeling is 
>> that the need for these is uncommon enough that it's not terrible to have 
>> these in a package instead of in Base.(Hadamard transforms and MDCTs 
>> are also currently in packages.)
>>
>

Re: [julia-users] Latest on wrapping C structs for use in Julia

[Isaiah Norton]

>
> (I've made some wrappers previously using an old build, although I can't
> get Clang.jl working at the moment)


I know there is a bug on OS X, I'll try to get it fixed this week. If there
is some other problem, please let me know.

On Thu, Apr 16, 2015 at 9:48 AM, Isaiah Norton 
wrote:

> The API looks quite small, so I would suggest to just type it out -- from
> a quick look, everything should be wrappable in pure Julia. e.g. the
> equivalent to the first part of hello.cpp you linked would be:
>
> julia> immutable BeagleInstanceDetails
>  resourceNumber::Int
>  resourceName::Ptr{Cchar}
>  implName::Ptr{Cchar}
>  implDescription::Ptr{Cchar}
>  flags::Clong
>end
>
> julia> retInfo = [BeagleInstanceDetails(0,0,0,0,0)]
> 1-element Array{BeagleInstanceDetails,1}:
>  BeagleInstanceDetails(0,Ptr{Int8} @0x,Ptr{Int8}
> @0x
> ,Ptr{Int8} @0x,0)
>
> julia> nPatterns=2
> 2
>
> julia> ccall((:beagleCreateInstance, "hmsbeagle64"), Int,
>  (Cint,Cint,Cint,Cint,Cint,Cint,Cint,Cint,Cint,Ptr{Int},
>   Cint,Clong,Clong,Ptr{BeagleInstanceDetails}),
>   3,2,3,4,nPatterns,1,4,1,0,C_NULL,0,0,0,retInfo)
> 0
>
> julia> retInfo
> 1-element Array{BeagleInstanceDetails,1}:
>  BeagleInstanceDetails(0,Ptr{Int8} @0x02a2d54c,Ptr{Int8}
> @0x02a2
> f040,Ptr{Int8} @0x003e3390,135320150)
>
> On Thu, Apr 16, 2015 at 9:12 AM, Simon Frost  wrote:
>
>> Dear All,
>>
>> I'm trying to wrap the BEAGLE library for use in Julia:
>>
>> https://github.com/beagle-dev/beagle-lib
>>
>> I've used SWIG in the past, which works fine for Python:
>>
>> https://github.com/beagle-dev/beagle-lib/tree/master/examples/swig_python
>>
>> and I'm currently hacking my way through R:
>>
>> https://github.com/sdwfrost/beagle-lib/tree/master/examples/swig_r
>>
>> The API isn't big at all, but does require me to initialise some pointers
>> to structs, which are filled in by reference. A toy example in C is here:
>>
>>
>> https://github.com/sdwfrost/beagle-lib/blob/master/examples/standalone/hellobeagle/src/hello.cpp
>>
>> I've looked through the docs in Julia, as well as Clang.jl (I've made
>> some wrappers previously using an old build, although I can't get Clang.jl
>> working at the moment), and StrPack.jl, and I was wondering whether anyone
>> had any pointers (no pun intended) to the current best practice for
>> wrapping a library like this? I work best from examples, so any suggestions
>> for a library with a similar API would be much appreciated.
>>
>> Best
>> Simon
>>
>
>

Re: [julia-users] Latest on wrapping C structs for use in Julia

[Isaiah Norton]

>
> so any suggestions for a library with a similar API would be much
> appreciated.


I usually point people to Nettle.jl which is very small but exemplifies a
few advanced ccall tricks.

On Thu, Apr 16, 2015 at 9:53 AM, Isaiah Norton 
wrote:

> (I've made some wrappers previously using an old build, although I can't
>> get Clang.jl working at the moment)
>
>
> I know there is a bug on OS X, I'll try to get it fixed this week. If
> there is some other problem, please let me know.
>
> On Thu, Apr 16, 2015 at 9:48 AM, Isaiah Norton 
> wrote:
>
>> The API looks quite small, so I would suggest to just type it out -- from
>> a quick look, everything should be wrappable in pure Julia. e.g. the
>> equivalent to the first part of hello.cpp you linked would be:
>>
>> julia> immutable BeagleInstanceDetails
>>  resourceNumber::Int
>>  resourceName::Ptr{Cchar}
>>  implName::Ptr{Cchar}
>>  implDescription::Ptr{Cchar}
>>  flags::Clong
>>end
>>
>> julia> retInfo = [BeagleInstanceDetails(0,0,0,0,0)]
>> 1-element Array{BeagleInstanceDetails,1}:
>>  BeagleInstanceDetails(0,Ptr{Int8} @0x,Ptr{Int8}
>> @0x
>> ,Ptr{Int8} @0x,0)
>>
>> julia> nPatterns=2
>> 2
>>
>> julia> ccall((:beagleCreateInstance, "hmsbeagle64"), Int,
>>  (Cint,Cint,Cint,Cint,Cint,Cint,Cint,Cint,Cint,Ptr{Int},
>>   Cint,Clong,Clong,Ptr{BeagleInstanceDetails}),
>>   3,2,3,4,nPatterns,1,4,1,0,C_NULL,0,0,0,retInfo)
>> 0
>>
>> julia> retInfo
>> 1-element Array{BeagleInstanceDetails,1}:
>>  BeagleInstanceDetails(0,Ptr{Int8} @0x02a2d54c,Ptr{Int8}
>> @0x02a2
>> f040,Ptr{Int8} @0x003e3390,135320150)
>>
>> On Thu, Apr 16, 2015 at 9:12 AM, Simon Frost  wrote:
>>
>>> Dear All,
>>>
>>> I'm trying to wrap the BEAGLE library for use in Julia:
>>>
>>> https://github.com/beagle-dev/beagle-lib
>>>
>>> I've used SWIG in the past, which works fine for Python:
>>>
>>> https://github.com/beagle-dev/beagle-lib/tree/master/examples/swig_python
>>>
>>> and I'm currently hacking my way through R:
>>>
>>> https://github.com/sdwfrost/beagle-lib/tree/master/examples/swig_r
>>>
>>> The API isn't big at all, but does require me to initialise some
>>> pointers to structs, which are filled in by reference. A toy example in C
>>> is here:
>>>
>>>
>>> https://github.com/sdwfrost/beagle-lib/blob/master/examples/standalone/hellobeagle/src/hello.cpp
>>>
>>> I've looked through the docs in Julia, as well as Clang.jl (I've made
>>> some wrappers previously using an old build, although I can't get Clang.jl
>>> working at the moment), and StrPack.jl, and I was wondering whether anyone
>>> had any pointers (no pun intended) to the current best practice for
>>> wrapping a library like this? I work best from examples, so any suggestions
>>> for a library with a similar API would be much appreciated.
>>>
>>> Best
>>> Simon
>>>
>>
>>
>

Re: [julia-users] Latest on wrapping C structs for use in Julia

[Isaiah Norton]

The API looks quite small, so I would suggest to just type it out -- from a
quick look, everything should be wrappable in pure Julia. e.g. the
equivalent to the first part of hello.cpp you linked would be:

julia> immutable BeagleInstanceDetails
 resourceNumber::Int
 resourceName::Ptr{Cchar}
 implName::Ptr{Cchar}
 implDescription::Ptr{Cchar}
 flags::Clong
   end

julia> retInfo = [BeagleInstanceDetails(0,0,0,0,0)]
1-element Array{BeagleInstanceDetails,1}:
 BeagleInstanceDetails(0,Ptr{Int8} @0x,Ptr{Int8}
@0x
,Ptr{Int8} @0x,0)

julia> nPatterns=2
2

julia> ccall((:beagleCreateInstance, "hmsbeagle64"), Int,
 (Cint,Cint,Cint,Cint,Cint,Cint,Cint,Cint,Cint,Ptr{Int},
  Cint,Clong,Clong,Ptr{BeagleInstanceDetails}),
  3,2,3,4,nPatterns,1,4,1,0,C_NULL,0,0,0,retInfo)
0

julia> retInfo
1-element Array{BeagleInstanceDetails,1}:
 BeagleInstanceDetails(0,Ptr{Int8} @0x02a2d54c,Ptr{Int8}
@0x02a2
f040,Ptr{Int8} @0x003e3390,135320150)

On Thu, Apr 16, 2015 at 9:12 AM, Simon Frost  wrote:

> Dear All,
>
> I'm trying to wrap the BEAGLE library for use in Julia:
>
> https://github.com/beagle-dev/beagle-lib
>
> I've used SWIG in the past, which works fine for Python:
>
> https://github.com/beagle-dev/beagle-lib/tree/master/examples/swig_python
>
> and I'm currently hacking my way through R:
>
> https://github.com/sdwfrost/beagle-lib/tree/master/examples/swig_r
>
> The API isn't big at all, but does require me to initialise some pointers
> to structs, which are filled in by reference. A toy example in C is here:
>
>
> https://github.com/sdwfrost/beagle-lib/blob/master/examples/standalone/hellobeagle/src/hello.cpp
>
> I've looked through the docs in Julia, as well as Clang.jl (I've made some
> wrappers previously using an old build, although I can't get Clang.jl
> working at the moment), and StrPack.jl, and I was wondering whether anyone
> had any pointers (no pun intended) to the current best practice for
> wrapping a library like this? I work best from examples, so any suggestions
> for a library with a similar API would be much appreciated.
>
> Best
> Simon
>

[julia-users] Re: Julia Installation Conflict with R

[Steven Sagaert]

Docker is actually pretty lightweight (compared to VMs). I'm personally 
looking forward to the day that Docker based desktop OSes become available 
(something like Snappy Ubuntu Core but not only for cloud & embedded but 
also for desktop). That solves "dependency hell" once and for all.

On Thursday, April 16, 2015 at 2:51:35 PM UTC+2, Tony Kelman wrote:
>
> Docker's extremely useful for some things, but also overkill here. It 
> sounds like Yudong (hi BTW, didn't know you used R at all) found a 
> perfectly good solution to the problem in the duplicated thread (probably 
> wasn't showing up immediately if the thread needed moderator approval) at 
> https://groups.google.com/forum/#!topic/julia-users/rK6gSIM822w - upgrade 
> R to a version that is compatible with the same pcre version as Julia. 
> Wasn't really a problem with Julia so much as a problem with R not having 
> upper-bound constraints on its pcre version requirement.
>
> -Tony
>
>
> On Thursday, April 16, 2015 at 12:40:50 AM UTC-7, Steven Sagaert wrote:
>>
>> Besides using the R distrib from revolutionanalytics.com (which is based 
>> on intel MKL) you could also completely isolate R & julia & their 
>> dependencies by running them in separate Docker containers. 
>>
>> On Tuesday, April 14, 2015 at 1:37:52 AM UTC+2, Yudong Ma wrote:
>>>
>>> Hi.
>>> I am pretty new to Julia, and I did manage to install Julia on Ubuntu 
>>> precise 64.
>>> Everything works except that the installation of Julia updates some 
>>> libraries and these updates makes the R shared lib /usr/lib/libR.so 
>>> complain that the symbol _pcre_valid_utf8 is undefined.
>>>
>>> The libraries updated by Julia that affect R are libpcre3, libpcrecpp0, 
>>> libpcre3-dev.
>>>
>>> I am wondering have any of julia users have encounted this issue, and 
>>> how should I resolve this issue?
>>> Best Regards
>>>
>>>

Re: [julia-users] pinv(0) != pinv([0])

[Rasmus Brandt]

Cool, thanks. -- Rasmus

Den torsdag 16 april 2015 kl. 13:08:42 UTC+2 skrev Andreas Noack:
>
> This has been fixed on master. I've just backported the fix to the release 
> branch so it should be okay in 0.3.8.
>
> 2015-04-16 4:05 GMT-04:00 Rasmus Brandt >:
>
>> Hey everyone, 
>>
>> I just stumbled over this behaviour in Julia-0.3.7, which seems a bit 
>> unintuitive to me:
>>
>> julia> pinv(0)
>> Inf
>>
>> julia> pinv([0])
>> 1x1 Array{Float64,2}:
>>  0.0
>>
>> In Matlab R2012a I get:
>>
>> >> pinv(0)
>>
>> ans =
>>
>>  0
>>
>> It seems that the definition
>> pinv(x::Number) = one(x)/x
>> satisfies the Moore-Penrose conditions for all x != 0.
>>
>> Is this intentional, or a bug?
>>
>> -- Rasmus
>>
>
>

[julia-users] Latest on wrapping C structs for use in Julia

[Simon Frost]

Dear All,

I'm trying to wrap the BEAGLE library for use in Julia:

https://github.com/beagle-dev/beagle-lib

I've used SWIG in the past, which works fine for Python:

https://github.com/beagle-dev/beagle-lib/tree/master/examples/swig_python

and I'm currently hacking my way through R:

https://github.com/sdwfrost/beagle-lib/tree/master/examples/swig_r

The API isn't big at all, but does require me to initialise some pointers 
to structs, which are filled in by reference. A toy example in C is here:

https://github.com/sdwfrost/beagle-lib/blob/master/examples/standalone/hellobeagle/src/hello.cpp

I've looked through the docs in Julia, as well as Clang.jl (I've made some 
wrappers previously using an old build, although I can't get Clang.jl 
working at the moment), and StrPack.jl, and I was wondering whether anyone 
had any pointers (no pun intended) to the current best practice for 
wrapping a library like this? I work best from examples, so any suggestions 
for a library with a similar API would be much appreciated.

Best
Simon

[julia-users] Re: My plugin for integrating Julia inside a Vim notebook

[Eduardo Lenz]

This is awesome ! Thank you very much !!!


On Wednesday, April 15, 2015 at 3:38:25 PM UTC-3, Thomas Baruchel wrote:
>
> Hi,
>
> I am new to Julia. In order to learn and experiment with it, I first 
> checked if wether it was easy or not
> to use Julia from my plugin: vim-notebook. It happened to work very well; 
> if you are interested by such
> a way of working: please, have a look at 
> https://github.com/baruchel/vim-notebook
> (you may look at the video though other interpreters than Julia are used 
> in this video).
>
> Best regards,
>
> tb.
>

[julia-users] Re: Julia Installation Conflict with R

[Tony Kelman]

Docker's extremely useful for some things, but also overkill here. It 
sounds like Yudong (hi BTW, didn't know you used R at all) found a 
perfectly good solution to the problem in the duplicated thread (probably 
wasn't showing up immediately if the thread needed moderator approval) 
at https://groups.google.com/forum/#!topic/julia-users/rK6gSIM822w - 
upgrade R to a version that is compatible with the same pcre version as 
Julia. Wasn't really a problem with Julia so much as a problem with R not 
having upper-bound constraints on its pcre version requirement.

-Tony


On Thursday, April 16, 2015 at 12:40:50 AM UTC-7, Steven Sagaert wrote:
>
> Besides using the R distrib from revolutionanalytics.com (which is based 
> on intel MKL) you could also completely isolate R & julia & their 
> dependencies by running them in separate Docker containers. 
>
> On Tuesday, April 14, 2015 at 1:37:52 AM UTC+2, Yudong Ma wrote:
>>
>> Hi.
>> I am pretty new to Julia, and I did manage to install Julia on Ubuntu 
>> precise 64.
>> Everything works except that the installation of Julia updates some 
>> libraries and these updates makes the R shared lib /usr/lib/libR.so 
>> complain that the symbol _pcre_valid_utf8 is undefined.
>>
>> The libraries updated by Julia that affect R are libpcre3, libpcrecpp0, 
>> libpcre3-dev.
>>
>> I am wondering have any of julia users have encounted this issue, and how 
>> should I resolve this issue?
>> Best Regards
>>
>>

Re: [julia-users] packages for keyword constructors

[Mauro]

I don't think there is a semi-standard.  Here my package:
https://github.com/mauro3/Parameters.jl/blob/master/examples/ex1.jl

On Thu, 2015-04-16 at 12:18, Tamas Papp  wrote:
> Hi,
>
> A comment for PR 6122 [1] mentions packages that define keyword
> constructors, which ones are these? Several snippets are floating around
> for macros that do this, but until this PR is merged I would rather use
> something semi-standard.
>
> Best,
>
> Tamas
>
> [1] https://github.com/JuliaLang/julia/pull/6122

Re: [julia-users] pinv(0) != pinv([0])

[Andreas Noack]

This has been fixed on master. I've just backported the fix to the release
branch so it should be okay in 0.3.8.

2015-04-16 4:05 GMT-04:00 Rasmus Brandt :

> Hey everyone,
>
> I just stumbled over this behaviour in Julia-0.3.7, which seems a bit
> unintuitive to me:
>
> julia> pinv(0)
> Inf
>
> julia> pinv([0])
> 1x1 Array{Float64,2}:
>  0.0
>
> In Matlab R2012a I get:
>
> >> pinv(0)
>
> ans =
>
>  0
>
> It seems that the definition
> pinv(x::Number) = one(x)/x
> satisfies the Moore-Penrose conditions for all x != 0.
>
> Is this intentional, or a bug?
>
> -- Rasmus
>

[julia-users] packages for keyword constructors

[Tamas Papp]

Hi,

A comment for PR 6122 [1] mentions packages that define keyword
constructors, which ones are these? Several snippets are floating around
for macros that do this, but until this PR is merged I would rather use
something semi-standard.

Best,

Tamas

[1] https://github.com/JuliaLang/julia/pull/6122

[julia-users] Re: acoustic simulations in Julia

[Niccolo' Antonello]

Hi Seven,

yes you are right it's too generic! I will change it to AcFdtd.jl since 
this stuff was done for room acoustics simulation!

https://github.com/nantonel/AcFdtd.jl

Thanks for pointing that out!

Niccolo'

(ps yes frequency domain is not best suited for auralization might be an 
application for this)

On Thursday, April 16, 2015 at 2:59:17 AM UTC+2, Steven G. Johnson wrote:
>
>
>
> On Wednesday, April 15, 2015 at 6:55:20 AM UTC-4, Niccolo' Antonello wrote:
>>
>> I uploaded this to:
>> https://github.com/nantonel/RIM.jl 
>> 
>> and:
>> https://github.com/nantonel/Fdtd.jl 
>> 
>>>
>>>
>>>
> Note that "FDTD" is a bit too generic ... the term could apply to any 
> time-dependent PDE, and is commonly used for Maxwell's equations.   I would 
> suggest something more specific, like ScalarWaveFDTD
>
> (Wouldn't FDFD, i.e. the frequency-domain scalar Helmholtz equation, be 
> more appropriate for this sort of problem?  Depends on how wide a bandwidth 
> you care about and what you want to simulate, I guess.)
>

Re: [julia-users] single-element tuples

[Kevin Squire]

That is correct.  I believe there is mention of it in "Calling C and
Fortran Functions" of the latest (v0.4) docs, but not sure about the v0.3
docs, and at any rate, it probably should at least be mentioned in the
Tuple docs.

Cheers,
   Kevin

On Thu, Apr 16, 2015 at 1:19 AM, Tamas Papp  wrote:

> Is (x,) the read-write syntax for single-element tuples?
>
> It seems to be so and it makes sense (to distinguish it from an
> expression surrounded by parentheses), just could not find where the
> manual talks about this.
>
> Best,
>
> Tamas
>

[julia-users] pinv(0) != pinv([0])

[Rasmus Brandt]

Hey everyone, 

I just stumbled over this behaviour in Julia-0.3.7, which seems a bit 
unintuitive to me:

julia> pinv(0)
Inf

julia> pinv([0])
1x1 Array{Float64,2}:
 0.0

In Matlab R2012a I get:

>> pinv(0)

ans =

 0

It seems that the definition
pinv(x::Number) = one(x)/x
satisfies the Moore-Penrose conditions for all x != 0.

Is this intentional, or a bug?

-- Rasmus

[julia-users] single-element tuples

[Tamas Papp]

Is (x,) the read-write syntax for single-element tuples?

It seems to be so and it makes sense (to distinguish it from an
expression surrounded by parentheses), just could not find where the
manual talks about this.

Best,

Tamas

[julia-users] Re: Julia Installation Conflict with R

[Steven Sagaert]

Besides using the R distrib from revolutionanalytics.com (which is based on 
intel MKL) you could also completely isolate R & julia & their dependencies 
by running them in separate Docker containers. 

On Tuesday, April 14, 2015 at 1:37:52 AM UTC+2, Yudong Ma wrote:
>
> Hi.
> I am pretty new to Julia, and I did manage to install Julia on Ubuntu 
> precise 64.
> Everything works except that the installation of Julia updates some 
> libraries and these updates makes the R shared lib /usr/lib/libR.so 
> complain that the symbol _pcre_valid_utf8 is undefined.
>
> The libraries updated by Julia that affect R are libpcre3, libpcrecpp0, 
> libpcre3-dev.
>
> I am wondering have any of julia users have encounted this issue, and how 
> should I resolve this issue?
> Best Regards
>
>

[julia-users] Re: Julia and Spark

[Steven Sagaert]

yes that's a solid approach. For my personal julia - java integrations I 
also run the JVM in a separate process.

On Wednesday, April 15, 2015 at 9:30:28 PM UTC+2, wil...@gmail.com wrote:
>
> 1) simply wrap the Spark java API via JavaCall. This is the low level 
>> approach. BTW I've experimented with javaCall and found it was unstable & 
>> also lacking functionality (e.g. there's no way to shutdown the jvm or 
>> create a pool of JVM analogous to DB connections) so that might need some 
>> work before trying the Spark integration.
>>
>
> Using JavaCall is not an option, especially when JVM became close-sourced, 
> see https://github.com/aviks/JavaCall.jl/issues/7.
>
> Python bindings are done through Py4J, which is RPC to JVM. If you look at 
> the sparkR , it is done in 
> a same way. sparkR uses a RPC interface to communicate with a Netty-based 
> Spark JVM backend that translates R calls into JVM calls, keeps 
> SparkContext on a JVM side, and ships serialized data to/from R.
>
> So it is just a matter of writing Julia RPC to JVM and wrapping necessary 
> Spark methods in a Julia friendly way. 
>