Re: [julia-users] Re: tail active log

[adrian_lewis]

Thanks for the replies, 

For some reason only one chunk of data is printed even though the log is still 
being written to

  fh = open(last_sim_log)
  try
while true
  print(readline(fh))
end
  finally
close(fh)
  end

For readavailable(fh), I getting "no method matching readavailable(::IOStream)"

Many Thanks

Aidy

On 9/15/2016 at 4:24 PM, "Stefan Karpinski"  wrote:
>
>If you don't mind blocking when a complete line isn't available, 
>you can
>just call readline(io) repeatedly.
>
>On Thu, Sep 15, 2016 at 7:57 AM, Steven G. Johnson 
>
>wrote:
>
>>
>>
>> On Thursday, September 15, 2016 at 7:11:55 AM UTC-4, Adrian 
>Lewis wrote:
>>>
>>> I have an active log and I wondered how I could `tail -f` this 
>without
>>> running the Unix command?
>>
>>
>> Open the file and repeatedly call `readavailable`
>>

[julia-users] deprecating julia v0.3 -> are there still 0.3 users?

[Tony Kelman]

Note also that as of several weeks ago, METADATA is frozen for Julia 0.3 and 
unless specific exceptions are requested, we're not merging any new tags of 
packages that support Julia 0.3. The existing tags will be left as is.

[julia-users] Re: How would you use Julia in a real world R Setup ?

[Tsur Herman]

Thank you for the time you took to answer.

How do you go about debugging and inspecting? and making sure that changes 
you made gets compiled
and that you are not accidentally running a previously imported version of 
a function? 


On Thursday, September 15, 2016 at 10:11:21 PM UTC+3, Tsur Herman wrote:
>
> Hi , I am new here .
> Just started playing around with julia, my background is in Matlab c++ and 
> GPU computing(writing kernels)
>
> I am trying to figure out what will be good practice for rapid prototyping.
> How would you use Julia and Juno IDE for a research and development 
> project that will
> end up having numerous files and many lines of code , and a basic gui?
>
> Please share your experience  , thanks.
> Tsur
>
>
>

Re: [julia-users] Tracking down type instability

[Kristoffer Carlsson]

It looks fine because for both the SSAValues with "problems" you later have:

 p::Array{Float64,1} = SSAValue(15)

 l::Array{Int64,1} = SSAValue(17)

so they actually get correctly inferred.

As long as your variables list and return value is ok then things are most 
likely ok.

On Friday, September 16, 2016 at 4:37:09 AM UTC+2, Yichao Yu wrote:
>
> On Thu, Sep 15, 2016 at 10:08 AM, Ben Ward  > wrote: 
> > Hi I have two functions and a function which calls them: 
> > 
> > @inline function expected_distance(::Type{JukesCantor69}, p::Float64) 
> > return -0.75 * log(1 - 4 * p / 3) 
> > end 
> > 
> > @inline function variance(::Type{JukesCantor69}, p::Float64, l::Int64) 
> > return p * (1 - p) / (((1 - 4 * p / 3) ^ 2) * l) 
> > end 
> > 
> > function distance{A<:NucleotideAlphabet}(::Type{JukesCantor69}, 
> > seqs::Vector{BioSequence{A}}) 
> > p, l = distance(Proportion{AnyMutation}, seqs) 
> > D = Vector{Float64}(length(p)) 
> > V = Vector{Float64}(length(p)) 
> > @inbounds for i in 1:length(p) 
> > D[i] = expected_distance(JukesCantor69, p[i]) 
> > V[i] = variance(JukesCantor69, p[i], l[i]) 
> > end 
> > return D, V 
> > end 
> > 
> > But I'm seeing type uncertainty: 
> > 
> > @code_warntype distance(JukesCantor69, dnas) 
> > 
> > Variables: 
> > 
> >   #self#::Bio.Var.#distance 
> > 
> >   #unused#::Type{Bio.Var.JukesCantor69} 
> > 
> >   seqs::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1} 
> > 
> >   p::Array{Float64,1} 
> > 
> >   l::Array{Int64,1} 
> > 
> >   #temp#@_6::Int64 
> > 
> >   D::Array{Float64,1} 
> > 
> >   V::Array{Float64,1} 
> > 
> >   #temp#@_9::Int64 
> > 
> >   i::Int64 
> > 
> > 
> > Body: 
> > 
> >   begin 
> > 
> >   SSAValue(0) = $(Expr(:invoke, LambdaInfo for 
> > distance(::Type{Bio.Var.Proportion{Bio.Var.AnyMutation}}, 
> > ::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1}), 
> > :(Bio.Var.distance), Bio.Var.Proportion{Bio.Var.AnyMutation}, :(seqs))) 
> > 
> >   #temp#@_6::Int64 = $(QuoteNode(1)) 
> > 
> >   SSAValue(15) = 
> > (Base.getfield)(SSAValue(0),1)::Union{Array{Float64,1},Array{Int64,1}} 
>
> I guess we should probably print ssavalue types to make this easier to 
> analyse 
>
> There's likely no type instability and the warning here is just spurious 
>
> > 
> >   SSAValue(16) = (Base.box)(Int64,(Base.add_int)(1,1)) 
> > 
> >   p::Array{Float64,1} = SSAValue(15) 
> > 
> >   #temp#@_6::Int64 = SSAValue(16) 
> > 
> >   SSAValue(17) = 
> > (Base.getfield)(SSAValue(0),2)::Union{Array{Float64,1},Array{Int64,1}} 
> > 
> >   SSAValue(18) = (Base.box)(Int64,(Base.add_int)(2,1)) 
> > 
> >   l::Array{Int64,1} = SSAValue(17) 
> > 
> >   #temp#@_6::Int64 = SSAValue(18) # line 314: 
> > 
> >   SSAValue(7) = (Base.arraylen)(p::Array{Float64,1})::Int64 
> > 
> >   D::Array{Float64,1} = 
> > 
> (Core.ccall)(:jl_alloc_array_1d,(Core.apply_type)(Core.Array,Float64,1)::Type{Array{Float64,1}},(Core.svec)(Core.Any,Core.Int)::SimpleVector,Array{Float64,1},0,SSAValue(7),0)::Array{Float64,1}
>  
>
> > # line 315: 
> > 
> >   SSAValue(9) = (Base.arraylen)(p::Array{Float64,1})::Int64 
> > 
> >   V::Array{Float64,1} = 
> > 
> (Core.ccall)(:jl_alloc_array_1d,(Core.apply_type)(Core.Array,Float64,1)::Type{Array{Float64,1}},(Core.svec)(Core.Any,Core.Int)::SimpleVector,Array{Float64,1},0,SSAValue(9),0)::Array{Float64,1}
>  
>
> > # line 316: 
> > 
> >   $(Expr(:inbounds, true)) 
> > 
> >   SSAValue(11) = (Base.arraylen)(p::Array{Float64,1})::Int64 
> > 
> >   SSAValue(19) = 
> > 
> (Base.select_value)((Base.sle_int)(1,SSAValue(11))::Bool,SSAValue(11),(Base.box)(Int64,(Base.sub_int)(1,1)))::Int64
>  
>
> > 
> >   #temp#@_9::Int64 = 1 
> > 
> >   22: 
> > 
> >   unless (Base.box)(Base.Bool,(Base.not_int)((#temp#@_9::Int64 === 
> > (Base.box)(Int64,(Base.add_int)(SSAValue(19),1)))::Bool)) goto 43 
> > 
> >   SSAValue(20) = #temp#@_9::Int64 
> > 
> >   SSAValue(21) = 
> (Base.box)(Int64,(Base.add_int)(#temp#@_9::Int64,1)) 
> > 
> >   i::Int64 = SSAValue(20) 
> > 
> >   #temp#@_9::Int64 = SSAValue(21) # line 317: 
> > 
> >   SSAValue(12) = 
> (Base.arrayref)(p::Array{Float64,1},i::Int64)::Float64 
> > 
> >   $(Expr(:inbounds, false)) 
> > 
> >   # meta: location /Users/bward/.julia/v0.5/Bio/src/var/distances.jl 
> > expected_distance 69 
> > 
> >   SSAValue(13) = $(Expr(:invoke, LambdaInfo for log(::Float64), 
> > :(Bio.Var.log), 
> > 
> :((Base.box)(Base.Float64,(Base.sub_float)((Base.box)(Float64,(Base.sitofp)(Float64,1)),(Base.box)(Base.Float64,(Base.div_float)((Base.box)(Base.Float64,(Base.mul_float)((Base.box)(Float64,(Base.sitofp)(Float64,4)),SSAValue(12))),(Base.box)(Float64,(Base.sitofp)(Float64,3)
>  
>
> > 
> >   # meta: pop location 
> > 
> >   $(Expr(:inbounds, :pop)) 
> > 
> >   SSAValue(5) = 
> > (Base.box)(Base.Float64,(Base.mul_float)(-0.75,SSAValue(13))) 
> > 
> > 
> > 
> 

Re: [julia-users] Julia embedding -- Create Dict variable from C?

[Harald Held]

OK, thanks for the clarification and explanations! I'll go for the second 
option you described then.

On Thursday, September 15, 2016 at 12:33:22 AM UTC+2, Yichao Yu wrote:
>
> On Wed, Sep 14, 2016 at 4:12 PM, Harald Held  > wrote: 
> > I'm playing around with embedding Julia in a C application and figured 
> out 
> > how to create and set scalars, arrays, and tuples from C successfully. 
> > 
> > What's missing for what I'm trying to do is to create a dictionary in C 
> that 
> > is then set to a Julia variable and used in a Julia script. However, I 
> > couldn't find any information on how to achieve that. Is that even 
> possible? 
> > If so, what is the appropriate type in C to allocate? 
>
> Dict is not a builtin type. It's just a normal julia type that doesn't 
> have a good mapping in C so there's no builtin API for it. 
> When dealing with such types for embedding, your options are, 
>
> 1. If you want to rely on the internal implementation detail of the 
> type, you can declare type in C with the same field as they appear in 
> julia code and manipulate the fields. (You probably don't want to use 
> Dict this way) 
> 2. Call julia functions to create/manipulate the object. This can 
> either be done by getting the function object and calling them with 
> `jl_apply` or `jl_call*` functions, or by getting a C callable 
> function pointer with `cfunction` julia function or `jl_function_ptr` 
> C API. This is the preferred option for handling complex objects like 
> dict. 
>
> > I guess I could just create two arrays (one holding the keys, the other 
> the 
> > values), zip them, and create a Dict from that result (in Julia code!) 
> -- 
> > but that would not be a pure C solution which I would prefer. 
>
> It's hard to say what counts as "pure C solution" since the object you 
> want to handle is implemented in pure julia. Unless you want to 
> reimplement it in pure C there's no pure C solution. 
>
> > 
> > Thanks for any hints and advice on that issue! 
>

[julia-users] Error when assigning values to an object

[varun7rs]

Hello,

I have some trouble using types in Julia. Thanks to some earlier help, I 
was able to define type Physical Node and save it in a file MyClasses.jl

module MyClasses

using DataArrays

type PhyNode{T}

  ID::Int64
  name::AbstractString
  x::Float64
  y::Float64
  inEdges::Vector{T}
  outEdges::Vector{T}

end

end

I intend to import MyClasses module to another file test.jl where I want to 
create a set of nodes. So, I wrote the following code:

importall MyClasses

nodelist = []

for a in max_nodes
push!(nodelist, PhyNode(1, Atlanta, 32.3, 54.7))
end



But I get an error pointing to the line with the push! function. The error 
says something about include_string at base/loading.jl:288 etc.,
I also tried removing the push function and only getting an object of type 
PhysicalNode (z = PhyNode(1, Atlanta, 32.3, 54.7)) but that showed the same 
error too.
The values that I'm assigning are read out from an XML file and the name 
Atlanta is of type ASCIIString while the rest of them are in the respective 
formats as usual.
Since I'm new to Julia, I'm finding it hard to exactly find out the reason 
for this behaviour. Can you please help me?

[julia-users] TIOBE Headline: Julia enters top 50 for the first time

[Jeffrey Sarnoff]

> It was a matter of time until Julia would hit the top 50. This month it 
> did so. The Julia programming language is meant for numerical computing. It 
> combines functional programming paradigms with high speed. In other words, 
> readable and stable code that performs. Chances are high that Julia will 
> gain even more popularity the next few months.


 The TIOBE Programming Community index is an indicator 
of the popularity of programming languages. 


 (thanks to Bill Hart for posting the link at nemo-dev)

[julia-users] Error when assigning values to an object

[Lutfullah Tomak]

It is related to the `importall` part of code. It can be that the files are not 
in the same directory but I'm not sure. Also, [] creates an Array with element 
type of Any. Giving it a type annotation may help peeformance ei TypeofArray[].

[julia-users] Re: Error when assigning values to an object

[varun7rs]

The files are indeed in the same directory and I also added the path of 
these files to the variable LOAD_PATH as well. But still, I get the same 
error.

On Friday, 16 September 2016 09:49:45 UTC+2, Lutfullah Tomak wrote:
>
> It is related to the `importall` part of code. It can be that the files 
> are not in the same directory but I'm not sure. Also, [] creates an Array 
> with element type of Any. Giving it a type annotation may help peeformance 
> ei TypeofArray[].

[julia-users] deprecating julia v0.3 -> are there still 0.3 users?

[Andreas Lobinger]

Hello colleagues,

some packages have started, some are in the process to fix their 
requirements to julia > v0.3. 
My question, especially to the universities/teaching communities: are there 
still 0.3 users?
(and maybe you provide a 'why' along that)

Wishing a happy day,
Andreas

Re: [julia-users] Re: Vector Field operators (gradient, divergence, curl) in Julia

[Matjaz Licer]

Thank you all!

On 14 September 2016 at 00:41, Steven G. Johnson 
wrote:

> Both ForwardDiff and ReverseDiff source solve a different problem (taking
> the derivative of a user-supplied function f(x)).  The Matlab and NumPy
> gradient functions, instead, take an array (not a function) and compute
> differences of adjacent elements of the array, returning a new array.
>

[julia-users] julia installation broken

[Michael Borregaard]

Hi, Is this the right forum for troubleshooting / issues with my julia 
install?

I have kept having problems with packages giving error on precompile, 
rendering julia unusable. I then reinstalled julia-0.5-rc4, and removed my 
.julia folder from my home dir to do a fresh install. Now, Julia fails with 
an error message when I do Pkg.update():

julia> Pkg.update()
INFO: Initializing package repository /Users/michael/.julia/v0.5
INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
ERROR: SystemError (with /Users/michael/.julia/v0.5/METADATA): rmdir: 
Directory not empty
 in #systemerror#51 at ./error.jl:34 [inlined]
 in (::Base.#kw##systemerror)(::Array{Any,1}, ::Base.#systemerror, 
::Symbol, ::Bool) at ./:0
 in #rm#7(::Bool, ::Bool, ::Function, ::String) at ./file.jl:125
 in #rm#7(::Bool, ::Bool, ::Function, ::String) at 
/Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 in (::Base.Filesystem.#kw##rm)(::Array{Any,1}, ::Base.Filesystem.#rm, 
::String) at ./:0
 in init(::String, ::String) at ./pkg/dir.jl:62
 in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, 
::Vararg{Any,N}) at ./pkg/dir.jl:28
 in update() at ./pkg/pkg.jl:210

I assums that a completely clean install should work. Are there keys to 
delete etc that will give me a properly clean install? I am on Mac OS X 
(newest version).
Thanks!

[julia-users] Re: Error when assigning values to an object

[randmstring]

The error I'm getting is something like 

ERROR: LoadError: UndefVarError: PhyNode not defined

So since you used importall instead of using, you need to the qualified 
MyClasses.PhyNode. If you do, you'll probably get some error about

ERROR: LoadError: MethodError: `convert` has no method matching 
convert(::Type{MyClasses.PhyNode{T}}, ::Int64, ::ASCIIString, ::Float64, 
::Float64)

unless you have another constructor for PhyNode, since you need to provide 
the two vectors for inEdges and outEdges as well. Long story short: 
Something like 

push!(nodelist, MyClasses.PhyNode(1, Atlanta, 32.3, 54.7, [], []))

should work, though you should probably specify the type and maybe size of 
the vectors (depending on what you want to do with them).

Am Freitag, 16. September 2016 10:02:08 UTC+2 schrieb varu...@gmail.com:
>
> The files are indeed in the same directory and I also added the path of 
> these files to the variable LOAD_PATH as well. But still, I get the same 
> error.
>
> On Friday, 16 September 2016 09:49:45 UTC+2, Lutfullah Tomak wrote:
>>
>> It is related to the `importall` part of code. It can be that the files 
>> are not in the same directory but I'm not sure. Also, [] creates an Array 
>> with element type of Any. Giving it a type annotation may help peeformance 
>> ei TypeofArray[].
>
>

[julia-users] Re: 'which' functionality, similar to applicable

[Fengyang Wang]

In addition to Mauro's answer, programatically, you can do 
which(issymmetric, Tuple{typeof(fill(NaN, 1, 1))}), which is almost your 
preferred syntax.

[julia-users] Julia 0.4 cannot infer types in Val{}-function

[Mauro]

Consider

  immutable A
  a::Int
  b::Float64
  end
  aa = A(4,5)

  f{ab}(aa, ::Val{ab}) = getfield(aa, ab)
  @code_warntype f(aa, Val{:b}())

In Julia 0.5 the inferred return type is Float64, however, in 0.4 it's
Union{Int,Float64}.  Is there a way to make this type stable in 0.4?

(Needed in Parameters.jl, see
https://github.com/mauro3/Parameters.jl/pull/13#issuecomment-247687338 )

[julia-users] Return type of broadcast

[Fengyang Wang]

julia> foo(x) = 0
foo (generic function with 1 method)

julia> foo(x::Int) = 0.0
foo (generic function with 2 methods)

julia> foo.(Any[1, 2, 3])
3-element Array{Float64,1}:
 0.0
 0.0
 0.0

julia> foo.(Number[1, 2, 3])
3-element Array{Number,1}:
 0.0
 0.0
 0.0

My understanding was that the actual return type should be used for 
nonempty collections, instead of the promote_op business, so the return 
value of foo.(Number[1, 2, 3]) should be a Vector{Float64}. (Both map and 
comprehensions have that behaviour.) This seems not to be the case. Is this 
planned to be fixed, or is my understanding of broadcast's semantics 
incorrect?

[julia-users] Re: Help on building Julia with Intel MKL on Windows?

[Zhong Pan]

I completely restarted the build process from fresh (git clone). In 
addition to the renaming and copying .lib and .dll files, I also did some 
many configuration of environmental variables before the build. 
These are mostly based on 
what 
C:\IntelSWTools\compilers_and_libraries_2017.0.109\windows\mkl\bin\mklvars.bat 
would have done.

export 
MKLROOT=/c/IntelSWTools/compilers_and_libraries_2017.0.109/windows/mkl
export MKL_TARGET_ARCH=intel64
export 
REDIST=/c/IntelSWTools/compilers_and_libraries_2017.0.109/windows/redist
export MKL_LP64_ILP64=lp64
export 
LIB=/c/IntelSWTools/compilers_and_libraries_2017.0.109/windows/tbb/lib/intel64/vc_mt:/C/IntelSWTools/compilers_and_libraries_2017.0.109/windows/mkl/lib/intel64:/C/IntelSWTools/compilers_and_libraries_2017.0.109/windows/compiler/lib/intel64
export 
INCLUDE=/C/IntelSWTools/compilers_and_libraries_2017.0.109/windows/mkl/include

Now I am stuck at a different place:

Making install in SVD
Making install in SYM
libtool: compile:  gcc -m64 -DTIME_WITH_SYS_TIME=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 
-DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 
-DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 
-DMPFR_HAVE_INTMAX_MAX=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 
-DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 
-DHAVE_NEARBYINT=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=\".libs/\" 
-DHAVE_ATTRIBUTE_MODE=1 -I. -I../src -I../src -DSRCDIR=\".\" 
-I/c/users/zpan/Documents/GitHub/julia/usr/include -DNPRINTF_L -DNPRINTF_T 
-DNPRINTF_J -MT random2.lo -MD -MP -MF .deps/random2.Tpo -c random2.c 
 -DDLL_EXPORT -DPIC -o .libs/random2.o
mv: cannot stat 
'/c/users/zpan/Documents/GitHub/julia/usr/bin/libarpack-2.dll': No such 
file or directory
make[1]: *** [Makefile:1331: 
/c/users/zpan/Documents/GitHub/julia/usr/bin/libarpack.dll] Error 1
make[1]: *** Waiting for unfinished jobs

I cannot find libarpack-2.dll or libarpack.dll anywhere.

BTW, I bumped into a folder under MKL installation: 
C:\IntelSWTools\compilers_and_libraries_2017.0.109\windows\mkl\lib\intel64_win_mic
The files inside seems to be Linux-like library files, but I don't know how 
they should be used:

zpan@WSPWORK 
C:\IntelSWTools\compilers_and_libraries_2017.0.109\windows\mkl\lib\intel64_win_mic
> dir
 Volume in drive C is Windows7_OS
 Volume Serial Number is 4131-0400

 Directory of 
C:\IntelSWTools\compilers_and_libraries_2017.0.109\windows\mkl\lib\intel64_win_mic

09/16/2016  15:02  .
09/16/2016  15:02  ..
08/01/2016  18:3619,309,845 libmkl_ao_worker.so
08/01/2016  18:30 2,119,960 libmkl_blas95_ilp64.a
08/01/2016  18:30 2,147,752 libmkl_blas95_lp64.a
08/01/2016  18:34   153,164,198 libmkl_core.a
08/01/2016  18:36   122,863,997 libmkl_core.so
08/01/2016  18:3424,628,804 libmkl_intel_ilp64.a
08/01/2016  18:3610,850,199 libmkl_intel_ilp64.so
08/01/2016  18:3426,277,006 libmkl_intel_lp64.a
08/01/2016  18:3612,012,951 libmkl_intel_lp64.so
08/01/2016  18:3452,875,578 libmkl_intel_thread.a
08/01/2016  18:3640,692,525 libmkl_intel_thread.so
08/01/2016  18:3225,226,176 libmkl_lapack95_ilp64.a
08/01/2016  18:3125,654,272 libmkl_lapack95_lp64.a
08/01/2016  18:36 5,128,544 libmkl_rt.so
08/01/2016  18:3430,265,120 libmkl_sequential.a
08/01/2016  18:3624,301,227 libmkl_sequential.so
08/01/2016  18:3432,158,354 libmkl_tbb_thread.a
08/01/2016  18:3625,593,814 libmkl_tbb_thread.so
09/16/2016  15:02  locale
  18 File(s)635,270,322 bytes
   3 Dir(s)  31,684,468,736 bytes free

[julia-users] Re: Help on building Julia with Intel MKL on Windows?

[Tony Kelman]

mic probably means xeon phi, so that's likely for cross compiling to a xeon phi 
device from a windows host. Based on the sizes of the .lib files, I take what I 
said back, those probably are static libraries. I did this many months ago and 
have a Make.user somewhere.

Before you spend too much time on this, how sure are you that MKL will make a 
major difference over openblas on your application? openblas is close in 
performance to MKl on many, but not quite all operations. In some cases it may 
even be faster. Open source Julia is much better supported against openblas, 
especially on Windows. There are avenues for commercial supported Julia as well.

[julia-users] Re: Tracking down type instability

[Ben Ward]

function 
distance{T<:MutationType,A<:NucleotideAlphabet}(::Type{Proportion{T}}, 
seqs::Vector{BioSequence{A}})
d, l = distance(Count{T}, seqs)
D = Vector{Float64}(length(d))
@inbounds @simd for i in 1:length(D)
D[i] = d[i] / l[i]
end
return D, l
end

*julia> **@code_llvm distance(Proportion{AnyMutation}, dnas2)*


define %jl_value_t* @julia_distance_70450(%jl_value_t*, %jl_value_t*) #0 {

top:

  %2 = call %jl_value_t*** @jl_get_ptls_states() #1

  %3 = alloca [17 x %jl_value_t*], align 8

  %.sub = getelementptr inbounds [17 x %jl_value_t*], [17 x %jl_value_t*]* 
%3, i64 0, i64 0

  %4 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 2

  %5 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 3

  %6 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 4

  %7 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 5

  %8 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 6

  %9 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 7

  %10 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 8

  %11 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 9

  %12 = bitcast [17 x %jl_value_t*]* %3 to i64*

  %13 = bitcast %jl_value_t** %4 to i8*

  call void @llvm.memset.p0i8.i64(i8* %13, i8 0, i64 120, i32 8, i1 false)

  store i64 30, i64* %12, align 8

  %14 = bitcast %jl_value_t*** %2 to i64*

  %15 = load i64, i64* %14, align 8

  %16 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 1

  %17 = bitcast %jl_value_t** %16 to i64*

  store i64 %15, i64* %17, align 8

  store %jl_value_t** %.sub, %jl_value_t*** %2, align 8

  %18 = call %jl_value_t* @julia_seqmatrix_70452(%jl_value_t* %1, 
%jl_value_t* inttoptr (i64 13078874632 to %jl_value_t*)) #0

  store %jl_value_t* %18, %jl_value_t** %4, align 8

  store %jl_value_t* %18, %jl_value_t** %5, align 8

  %19 = call %jl_value_t* @julia_count_mutations_70454(%jl_value_t* 
inttoptr (i64 4687660080 to %jl_value_t*), %jl_value_t* %18) #0

  store %jl_value_t* %19, %jl_value_t** %6, align 8

  %20 = getelementptr inbounds %jl_value_t, %jl_value_t* %19, i64 0, i32 0

  %21 = load %jl_value_t*, %jl_value_t** %20, align 8

  store %jl_value_t* %21, %jl_value_t** %7, align 8

  %22 = getelementptr inbounds %jl_value_t, %jl_value_t* %19, i64 1, i32 0

  %23 = load %jl_value_t*, %jl_value_t** %22, align 8

  store %jl_value_t* %23, %jl_value_t** %8, align 8

  store %jl_value_t* %21, %jl_value_t** %9, align 8

  %24 = getelementptr inbounds %jl_value_t, %jl_value_t* %21, i64 1

  %25 = bitcast %jl_value_t* %24 to i64*

  %26 = load i64, i64* %25, align 8

  %27 = call %jl_value_t* inttoptr (i64 4388816272 to %jl_value_t* 
(%jl_value_t*, i64)*)(%jl_value_t* inttoptr (i64 4473018288 to 
%jl_value_t*), i64 %26)

  store %jl_value_t* %27, %jl_value_t** %10, align 8

  store %jl_value_t* %27, %jl_value_t** %11, align 8

  %28 = getelementptr inbounds %jl_value_t, %jl_value_t* %27, i64 1

  %29 = bitcast %jl_value_t* %28 to i64*

  %30 = load i64, i64* %29, align 8

  %31 = icmp sgt i64 %30, 0

  %32 = select i1 %31, i64 %30, i64 0

  %33 = call { i64, i1 } @llvm.ssub.with.overflow.i64(i64 %32, i64 1)

  %34 = extractvalue { i64, i1 } %33, 1

  br i1 %34, label %fail.split, label %top.top.split_crit_edge


top.top.split_crit_edge:  ; preds = %top

  %35 = extractvalue { i64, i1 } %33, 0

  %36 = call { i64, i1 } @llvm.sadd.with.overflow.i64(i64 %35, i64 1)

  %37 = extractvalue { i64, i1 } %36, 1

  br i1 %37, label %fail12, label %top.split.top.split.split_crit_edge


top.split.top.split.split_crit_edge:  ; preds = 
%top.top.split_crit_edge

  %38 = extractvalue { i64, i1 } %36, 0

  %39 = icmp slt i64 %38, 1

  br i1 %39, label %L11, label %if15.lr.ph


L11.loopexit: ; preds = %if15

  br label %L11


L11:  ; preds = %L11.loopexit, 
%top.split.top.split.split_crit_edge

  %40 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 13

  %41 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 14

  %42 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 15

  %43 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
i64 16

  store %jl_value_t* %27, %jl_value_t** %40, align 8

  %44 = bitcast %jl_value_t*** %2 to i8*

  %45 = call %jl_value_t* @jl_gc_pool_alloc(i8* %44, i32 1408, i32 32)

  %46 = getelementptr inbounds %jl_value_t, %jl_value_t* %45, i64 -1, i32 0

  store %jl_value_t* inttoptr (i64 4723475120 to %jl_value_t*), 
%jl_value_t** %46, align 8

  store %jl_value_t* %45, %jl_value_t** %41, align 8

  store %jl_value_t* %27, %jl_value_t** %42, align 8

  %47 = getelementptr inbounds %jl_value_t, %jl_value_t* %45, i64 0, i32 0

  store %jl_value_t* 

[julia-users] Re: Tracking down type instability

[Ralph Smith]

The integer vectors d and l have to be converted to floats before division. 
Vectorization at this point means that the compiler writes code to use wide 
registers to do more than one at a time (and lots of extra logic to handle 
alignment and stragglers).
Something in the chain (LLVM front end, I suspect) seems ignorant or 
unhappy about the packed conversion instructions on recent Intel chips 
(they are not emitted on my build of v0.5rc4 from source, targeted for 
native Haswell architecture).  What you show should still compile to a 
pretty fast loop.

Surely this is not your bottleneck?

On Friday, September 16, 2016 at 8:12:53 PM UTC-4, Ben Ward wrote:
>
> function 
> distance{T<:MutationType,A<:NucleotideAlphabet}(::Type{Proportion{T}}, 
> seqs::Vector{BioSequence{A}})
> d, l = distance(Count{T}, seqs)
> D = Vector{Float64}(length(d))
> @inbounds @simd for i in 1:length(D)
> D[i] = d[i] / l[i]
> end
> return D, l
> end
>
> *julia> **@code_llvm distance(Proportion{AnyMutation}, dnas2)*
>
>
> define %jl_value_t* @julia_distance_70450(%jl_value_t*, %jl_value_t*) #0 {
>
> top:
>
>   %2 = call %jl_value_t*** @jl_get_ptls_states() #1
>
>   %3 = alloca [17 x %jl_value_t*], align 8
>
>   %.sub = getelementptr inbounds [17 x %jl_value_t*], [17 x %jl_value_t*]* 
> %3, i64 0, i64 0
>
>   %4 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
> i64 2
>
>   %5 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
> i64 3
>
>   %6 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
> i64 4
>
>   %7 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
> i64 5
>
>   %8 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
> i64 6
>
>   %9 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
> i64 7
>
>   %10 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
> i64 8
>
>   %11 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
> i64 9
>
>   %12 = bitcast [17 x %jl_value_t*]* %3 to i64*
>
>   %13 = bitcast %jl_value_t** %4 to i8*
>
>   call void @llvm.memset.p0i8.i64(i8* %13, i8 0, i64 120, i32 8, i1 false)
>
>   store i64 30, i64* %12, align 8
>
>   %14 = bitcast %jl_value_t*** %2 to i64*
>
>   %15 = load i64, i64* %14, align 8
>
>   %16 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
> i64 1
>
>   %17 = bitcast %jl_value_t** %16 to i64*
>
>   store i64 %15, i64* %17, align 8
>
>   store %jl_value_t** %.sub, %jl_value_t*** %2, align 8
>
>   %18 = call %jl_value_t* @julia_seqmatrix_70452(%jl_value_t* %1, 
> %jl_value_t* inttoptr (i64 13078874632 to %jl_value_t*)) #0
>
>   store %jl_value_t* %18, %jl_value_t** %4, align 8
>
>   store %jl_value_t* %18, %jl_value_t** %5, align 8
>
>   %19 = call %jl_value_t* @julia_count_mutations_70454(%jl_value_t* 
> inttoptr (i64 4687660080 to %jl_value_t*), %jl_value_t* %18) #0
>
>   store %jl_value_t* %19, %jl_value_t** %6, align 8
>
>   %20 = getelementptr inbounds %jl_value_t, %jl_value_t* %19, i64 0, i32 0
>
>   %21 = load %jl_value_t*, %jl_value_t** %20, align 8
>
>   store %jl_value_t* %21, %jl_value_t** %7, align 8
>
>   %22 = getelementptr inbounds %jl_value_t, %jl_value_t* %19, i64 1, i32 0
>
>   %23 = load %jl_value_t*, %jl_value_t** %22, align 8
>
>   store %jl_value_t* %23, %jl_value_t** %8, align 8
>
>   store %jl_value_t* %21, %jl_value_t** %9, align 8
>
>   %24 = getelementptr inbounds %jl_value_t, %jl_value_t* %21, i64 1
>
>   %25 = bitcast %jl_value_t* %24 to i64*
>
>   %26 = load i64, i64* %25, align 8
>
>   %27 = call %jl_value_t* inttoptr (i64 4388816272 to %jl_value_t* 
> (%jl_value_t*, i64)*)(%jl_value_t* inttoptr (i64 4473018288 to 
> %jl_value_t*), i64 %26)
>
>   store %jl_value_t* %27, %jl_value_t** %10, align 8
>
>   store %jl_value_t* %27, %jl_value_t** %11, align 8
>
>   %28 = getelementptr inbounds %jl_value_t, %jl_value_t* %27, i64 1
>
>   %29 = bitcast %jl_value_t* %28 to i64*
>
>   %30 = load i64, i64* %29, align 8
>
>   %31 = icmp sgt i64 %30, 0
>
>   %32 = select i1 %31, i64 %30, i64 0
>
>   %33 = call { i64, i1 } @llvm.ssub.with.overflow.i64(i64 %32, i64 1)
>
>   %34 = extractvalue { i64, i1 } %33, 1
>
>   br i1 %34, label %fail.split, label %top.top.split_crit_edge
>
>
> top.top.split_crit_edge:  ; preds = %top
>
>   %35 = extractvalue { i64, i1 } %33, 0
>
>   %36 = call { i64, i1 } @llvm.sadd.with.overflow.i64(i64 %35, i64 1)
>
>   %37 = extractvalue { i64, i1 } %36, 1
>
>   br i1 %37, label %fail12, label %top.split.top.split.split_crit_edge
>
>
> top.split.top.split.split_crit_edge:  ; preds = 
> %top.top.split_crit_edge
>
>   %38 = extractvalue { i64, i1 } %36, 0
>
>   %39 = icmp slt i64 %38, 1
>
>   br i1 %39, label %L11, label %if15.lr.ph
>
>
> L11.loopexit: ; preds = %if15
>
>   br label %L11
>
>
> L11:  ; preds = %L11.loopexit, 
> 

[julia-users] Re: Tracking down type instability

[Ralph Smith]

A correction: the native Haswell build does use packed conversions for 
32-bit integers, and valiantly mixes unpacked conversions with packed 
division for 64-bit.  I didn't see any of this from the pre-built binaries.

On Friday, September 16, 2016 at 10:22:16 PM UTC-4, Ralph Smith wrote:
>
> The integer vectors d and l have to be converted to floats before 
> division. Vectorization at this point means that the compiler writes code 
> to use wide registers to do more than one at a time (and lots of extra 
> logic to handle alignment and stragglers).
> Something in the chain (LLVM front end, I suspect) seems ignorant or 
> unhappy about the packed conversion instructions on recent Intel chips 
> (they are not emitted on my build of v0.5rc4 from source, targeted for 
> native Haswell architecture).  What you show should still compile to a 
> pretty fast loop.
>
> Surely this is not your bottleneck?
>
> On Friday, September 16, 2016 at 8:12:53 PM UTC-4, Ben Ward wrote:
>>
>> function 
>> distance{T<:MutationType,A<:NucleotideAlphabet}(::Type{Proportion{T}}, 
>> seqs::Vector{BioSequence{A}})
>> d, l = distance(Count{T}, seqs)
>> D = Vector{Float64}(length(d))
>> @inbounds @simd for i in 1:length(D)
>> D[i] = d[i] / l[i]
>> end
>> return D, l
>> end
>>
>> *julia> **@code_llvm distance(Proportion{AnyMutation}, dnas2)*
>>
>>
>> define %jl_value_t* @julia_distance_70450(%jl_value_t*, %jl_value_t*) #0 {
>>
>> top:
>>
>>   %2 = call %jl_value_t*** @jl_get_ptls_states() #1
>>
>>   %3 = alloca [17 x %jl_value_t*], align 8
>>
>>   %.sub = getelementptr inbounds [17 x %jl_value_t*], [17 x 
>> %jl_value_t*]* %3, i64 0, i64 0
>>
>>   %4 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
>> i64 2
>>
>>   %5 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
>> i64 3
>>
>>   %6 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
>> i64 4
>>
>>   %7 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
>> i64 5
>>
>>   %8 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
>> i64 6
>>
>>   %9 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 0, 
>> i64 7
>>
>>   %10 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 
>> 0, i64 8
>>
>>   %11 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 
>> 0, i64 9
>>
>>   %12 = bitcast [17 x %jl_value_t*]* %3 to i64*
>>
>>   %13 = bitcast %jl_value_t** %4 to i8*
>>
>>   call void @llvm.memset.p0i8.i64(i8* %13, i8 0, i64 120, i32 8, i1 false)
>>
>>   store i64 30, i64* %12, align 8
>>
>>   %14 = bitcast %jl_value_t*** %2 to i64*
>>
>>   %15 = load i64, i64* %14, align 8
>>
>>   %16 = getelementptr [17 x %jl_value_t*], [17 x %jl_value_t*]* %3, i64 
>> 0, i64 1
>>
>>   %17 = bitcast %jl_value_t** %16 to i64*
>>
>>   store i64 %15, i64* %17, align 8
>>
>>   store %jl_value_t** %.sub, %jl_value_t*** %2, align 8
>>
>>   %18 = call %jl_value_t* @julia_seqmatrix_70452(%jl_value_t* %1, 
>> %jl_value_t* inttoptr (i64 13078874632 to %jl_value_t*)) #0
>>
>>   store %jl_value_t* %18, %jl_value_t** %4, align 8
>>
>>   store %jl_value_t* %18, %jl_value_t** %5, align 8
>>
>>   %19 = call %jl_value_t* @julia_count_mutations_70454(%jl_value_t* 
>> inttoptr (i64 4687660080 to %jl_value_t*), %jl_value_t* %18) #0
>>
>>   store %jl_value_t* %19, %jl_value_t** %6, align 8
>>
>>   %20 = getelementptr inbounds %jl_value_t, %jl_value_t* %19, i64 0, i32 0
>>
>>   %21 = load %jl_value_t*, %jl_value_t** %20, align 8
>>
>>   store %jl_value_t* %21, %jl_value_t** %7, align 8
>>
>>   %22 = getelementptr inbounds %jl_value_t, %jl_value_t* %19, i64 1, i32 0
>>
>>   %23 = load %jl_value_t*, %jl_value_t** %22, align 8
>>
>>   store %jl_value_t* %23, %jl_value_t** %8, align 8
>>
>>   store %jl_value_t* %21, %jl_value_t** %9, align 8
>>
>>   %24 = getelementptr inbounds %jl_value_t, %jl_value_t* %21, i64 1
>>
>>   %25 = bitcast %jl_value_t* %24 to i64*
>>
>>   %26 = load i64, i64* %25, align 8
>>
>>   %27 = call %jl_value_t* inttoptr (i64 4388816272 to %jl_value_t* 
>> (%jl_value_t*, i64)*)(%jl_value_t* inttoptr (i64 4473018288 to 
>> %jl_value_t*), i64 %26)
>>
>>   store %jl_value_t* %27, %jl_value_t** %10, align 8
>>
>>   store %jl_value_t* %27, %jl_value_t** %11, align 8
>>
>>   %28 = getelementptr inbounds %jl_value_t, %jl_value_t* %27, i64 1
>>
>>   %29 = bitcast %jl_value_t* %28 to i64*
>>
>>   %30 = load i64, i64* %29, align 8
>>
>>   %31 = icmp sgt i64 %30, 0
>>
>>   %32 = select i1 %31, i64 %30, i64 0
>>
>>   %33 = call { i64, i1 } @llvm.ssub.with.overflow.i64(i64 %32, i64 1)
>>
>>   %34 = extractvalue { i64, i1 } %33, 1
>>
>>   br i1 %34, label %fail.split, label %top.top.split_crit_edge
>>
>>
>> top.top.split_crit_edge:  ; preds = %top
>>
>>   %35 = extractvalue { i64, i1 } %33, 0
>>
>>   %36 = call { i64, i1 } @llvm.sadd.with.overflow.i64(i64 %35, i64 1)
>>
>>   %37 = extractvalue { i64, i1 } %36, 1
>>
>>   br i1 %37, label 

[julia-users] Re: Help on building Julia with Intel MKL on Windows?

[Zhong Pan]

I saw benchmarks showing impressive speedup using Anaconda + MKL vs. open 
source library. For 
example, https://github.com/ContinuumIO/mkl-optimizations-benchmarks

For my application, a representative problem would be split-step Fourier 
method (https://en.wikipedia.org/wiki/Split-step_method). This would 
involve multiple arrays (e.g. 8), each containing tens of thousands to 
hundreds of thousands of complex values, going through FFT - array 
calculation - inverse FFT - array calculation... repeated many many times. 
There could be dozens of parameter combinations to run the calculation on, 
which could be parallelized. Currently the calculation is done in Matlab 
with some use of GPU, which is reasonably fast but not fast enough. Python 
would be slow for this situation as each step depends on previous step in a 
nonlinear way so the loop cannot be vectorized. I was hoping to convert the 
Matlab project into Julia to gain significant speedup (fast Julia base + 
MKL + GPU) on a single 6-core machine. If then I can get a few machines to 
work together to test different parameter sets that'd be even better - 
realistic limitation is we have to stick with Windows and won't have a real 
cluster.

Based on the instructions, building Julia with MKL seems to be easy on 
Linux. I didn't realize it could be this hard for Windows, at least for me.

Commercial distribution of Julia could be an option if the license fee is 
low (people got spoiled by Anaconda). However, I don't see one that 
supports MKL yet. 



On Friday, September 16, 2016 at 5:46:39 PM UTC-5, Tony Kelman wrote:
>
> mic probably means xeon phi, so that's likely for cross compiling to a 
> xeon phi device from a windows host. Based on the sizes of the .lib files, 
> I take what I said back, those probably are static libraries. I did this 
> many months ago and have a Make.user somewhere.
>
> Before you spend too much time on this, how sure are you that MKL will 
> make a major difference over openblas on your application? openblas is 
> close in performance to MKl on many, but not quite all operations. In some 
> cases it may even be faster. Open source Julia is much better supported 
> against openblas, especially on Windows. There are avenues for commercial 
> supported Julia as well.
>

[julia-users] Julia NetCDF usage of subsetting with start and count

[MLicer]

Dear all,

i am trying to read *one* *specific* elevation [Lat x Lon x Time] timestep 
in a large NetCDF file using Julia NetCDF. I've tried the syntax (along 
with many variations to the theme):

timestep = 17
el=ncread(fname,"elevation",start=[1,1,timestep], count=[-1, -1, 1])

which returns the following error:

ERROR: LoadError: MethodError: `__ncread#17__` has no method matching 
__ncread#17__(::Array{Any,1}, ::Array{Int64,1}, ::ASCIIString, 
::ASCIIString)


Can anyone help me get this right? What is wrong with my syntax? It's very 
time consuming to read the entire variable just to subset it to one 
timestep in the next line.

I appreciate all the work done on the NetCDF.jl package very much, but i 
feel that documentation (and users) would benefit from some concrete 
examples like the one i am mentioning.

Thanks so much!

Re: [julia-users] 'which' functionality, similar to applicable

[Mauro]

Do you mean

@which sin(6)

?

On Fri, 2016-09-16 at 03:13, Marco Cognetta wrote:
> Hi all,
>
> I know about methods() and applicable(), but is there a way to tell, given a 
> multiple dispatch method name and a possible input, which method specifically 
> would be called (the line number and the parameter types/function signature)? 
> When I was trying to determine which of a method with many, very similar 
> dispatches, would be called on a certain input, I had to resort to putting 
> print statements in every candidate and rebuilding Julia, which was 
> inefficient.
>
> Example:
> which(issymmetric, fill(NaN, 1, 1))
> Would return the file and like of the issymmetric method that would be called 
> when supplied this input (there are many to choose from).
>
> If nothing like this exists, it seems like a good feature to add. It is not 
> always immediately clear which method will be called when there are only 
> slight differences in the parameter types.
>
> Thanks in advance.

[julia-users] 'which' functionality, similar to applicable

[Marco Cognetta]

Hi all,

I know about methods() and applicable(), but is there a way to tell, given a 
multiple dispatch method name and a possible input, which method specifically 
would be called (the line number and the parameter types/function signature)? 
When I was trying to determine which of a method with many, very similar 
dispatches, would be called on a certain input, I had to resort to putting 
print statements in every candidate and rebuilding Julia, which was inefficient.

Example:
which(issymmetric, fill(NaN, 1, 1))
Would return the file and like of the issymmetric method that would be called 
when supplied this input (there are many to choose from).

If nothing like this exists, it seems like a good feature to add. It is not 
always immediately clear which method will be called when there are only slight 
differences in the parameter types.

Thanks in advance.

[julia-users] Debuging with Juno

[Tsur Herman]

did any one managed to get that working?

I am getting an error Base.active_repl not defined .
However debugging somewhat works in julia shell .

I personally think that the ability to comfortably step into functions, 
including what is considered system packages is crucial
for the language to take off. 

So does anyone have any clue as to why is this happening? 
  

[julia-users] keyword arguments are distinct from positional arguments?

[Neal Becker]

In read the julialang doc, I'm getting the impression that keyword arguments 
are entirely distinct from positional arguments?

In python, all arguments can be used either positional or keyword.  Julia is 
more restrictive here?  I need to decide a-priori if an argument is one or 
the other?

[julia-users] Re: Error when assigning values to an object

['Greg Plowman' via julia-users]

Export PhyNode from MyClass module.

[julia-users] Re: Error when assigning values to an object

[varun7rs]

Oh, thanks so much! It fixed my problem. But, is there a way to just write 
PhyNode(blah, blah, blah) instead of the cumbersome MyClasses.PhyNode ? I 
tried using MyClasses and it reported the same error as well.

On Friday, 16 September 2016 12:11:18 UTC+2, randm...@gmail.com wrote:
>
> The error I'm getting is something like 
>
> ERROR: LoadError: UndefVarError: PhyNode not defined
>
> So since you used importall instead of using, you need to the qualified 
> MyClasses.PhyNode. If you do, you'll probably get some error about
>
> ERROR: LoadError: MethodError: `convert` has no method matching 
> convert(::Type{MyClasses.PhyNode{T}}, ::Int64, ::ASCIIString, ::Float64, 
> ::Float64)
>
> unless you have another constructor for PhyNode, since you need to 
> provide the two vectors for inEdges and outEdges as well. Long story 
> short: Something like 
>
> push!(nodelist, MyClasses.PhyNode(1, Atlanta, 32.3, 54.7, [], []))
>
> should work, though you should probably specify the type and maybe size of 
> the vectors (depending on what you want to do with them).
>
> Am Freitag, 16. September 2016 10:02:08 UTC+2 schrieb varu...@gmail.com:
>>
>> The files are indeed in the same directory and I also added the path of 
>> these files to the variable LOAD_PATH as well. But still, I get the same 
>> error.
>>
>> On Friday, 16 September 2016 09:49:45 UTC+2, Lutfullah Tomak wrote:
>>>
>>> It is related to the `importall` part of code. It can be that the files 
>>> are not in the same directory but I'm not sure. Also, [] creates an Array 
>>> with element type of Any. Giving it a type annotation may help peeformance 
>>> ei TypeofArray[].
>>
>>

[julia-users] Re: Error when assigning values to an object

[varun7rs]

Thanks for answering all of my nooby questions. Julia is cool again!

On Friday, 16 September 2016 14:20:53 UTC+2, randm...@gmail.com wrote:
>
> Sure, just export what you want available when using your Module -- 
> that's useful anyways for defining a public API. Also have a look at the 
> Julia 
> documentation , 
> which describes all that pretty nicely.
>
> Am Freitag, 16. 
> September 2016 14:04:02 UTC+2 schrieb varu...@gmail.com:
>>
>> Oh, thanks so much! It fixed my problem. But, is there a way to just 
>> write PhyNode(blah, blah, blah) instead of the cumbersome MyClasses.PhyNode 
>> ? I tried using MyClasses and it reported the same error as well.
>>
>> On Friday, 16 September 2016 12:11:18 UTC+2, randm...@gmail.com wrote:
>>>
>>> The error I'm getting is something like 
>>>
>>> ERROR: LoadError: UndefVarError: PhyNode not defined
>>>
>>> So since you used importall instead of using, you need to the qualified 
>>> MyClasses.PhyNode. If you do, you'll probably get some error about
>>>
>>> ERROR: LoadError: MethodError: `convert` has no method matching 
>>> convert(::Type{MyClasses.PhyNode{T}}, ::Int64, ::ASCIIString, ::Float64, 
>>> ::Float64)
>>>
>>> unless you have another constructor for PhyNode, since you need to 
>>> provide the two vectors for inEdges and outEdges as well. Long story 
>>> short: Something like 
>>>
>>> push!(nodelist, MyClasses.PhyNode(1, Atlanta, 32.3, 54.7, [], []))
>>>
>>> should work, though you should probably specify the type and maybe size 
>>> of the vectors (depending on what you want to do with them).
>>>
>>> Am Freitag, 16. September 2016 10:02:08 UTC+2 schrieb varu...@gmail.com:

 The files are indeed in the same directory and I also added the path of 
 these files to the variable LOAD_PATH as well. But still, I get the same 
 error.

 On Friday, 16 September 2016 09:49:45 UTC+2, Lutfullah Tomak wrote:
>
> It is related to the `importall` part of code. It can be that the 
> files are not in the same directory but I'm not sure. Also, [] creates an 
> Array with element type of Any. Giving it a type annotation may help 
> peeformance ei TypeofArray[].

Re: [julia-users] Debuging with Juno

[Mike Innes]

We have some patches for recent changes to Gallium.jl which are very soon
to be tagged, so this will all work very soon.

On Fri, 16 Sep 2016, 13:29 Tsur Herman,  wrote:

> did any one managed to get that working?
>
> I am getting an error Base.active_repl not defined .
> However debugging somewhat works in julia shell .
>
> I personally think that the ability to comfortably step into functions,
> including what is considered system packages is crucial
> for the language to take off.
>
> So does anyone have any clue as to why is this happening?
>
>

[julia-users] Re: Error when assigning values to an object

[randmstring]

Sure, just export what you want available when using your Module -- that's 
useful anyways for defining a public API. Also have a look at the Julia 
documentation , 
which describes all that pretty nicely.

Am Freitag, 16. 
September 2016 14:04:02 UTC+2 schrieb varu...@gmail.com:
>
> Oh, thanks so much! It fixed my problem. But, is there a way to just write 
> PhyNode(blah, blah, blah) instead of the cumbersome MyClasses.PhyNode ? I 
> tried using MyClasses and it reported the same error as well.
>
> On Friday, 16 September 2016 12:11:18 UTC+2, randm...@gmail.com wrote:
>>
>> The error I'm getting is something like 
>>
>> ERROR: LoadError: UndefVarError: PhyNode not defined
>>
>> So since you used importall instead of using, you need to the qualified 
>> MyClasses.PhyNode. If you do, you'll probably get some error about
>>
>> ERROR: LoadError: MethodError: `convert` has no method matching 
>> convert(::Type{MyClasses.PhyNode{T}}, ::Int64, ::ASCIIString, ::Float64, 
>> ::Float64)
>>
>> unless you have another constructor for PhyNode, since you need to 
>> provide the two vectors for inEdges and outEdges as well. Long story 
>> short: Something like 
>>
>> push!(nodelist, MyClasses.PhyNode(1, Atlanta, 32.3, 54.7, [], []))
>>
>> should work, though you should probably specify the type and maybe size 
>> of the vectors (depending on what you want to do with them).
>>
>> Am Freitag, 16. September 2016 10:02:08 UTC+2 schrieb varu...@gmail.com:
>>>
>>> The files are indeed in the same directory and I also added the path of 
>>> these files to the variable LOAD_PATH as well. But still, I get the same 
>>> error.
>>>
>>> On Friday, 16 September 2016 09:49:45 UTC+2, Lutfullah Tomak wrote:

 It is related to the `importall` part of code. It can be that the files 
 are not in the same directory but I'm not sure. Also, [] creates an Array 
 with element type of Any. Giving it a type annotation may help peeformance 
 ei TypeofArray[].
>>>
>>>

Re: [julia-users] keyword arguments are distinct from positional arguments?

[Mauro]

On Fri, 2016-09-16 at 13:45, Neal Becker wrote:
> In read the julialang doc, I'm getting the impression that keyword arguments
> are entirely distinct from positional arguments?

Yes they are distinct.  Also note that keyword arguments currently carry
a performance penalty, although that should change at some stage.

> In python, all arguments can be used either positional or keyword.  Julia is
> more restrictive here?  I need to decide a-priori if an argument is one or
> the other?

Yep.  Note, you can also set default values for positional arguments.

[julia-users] Re: Tracking down type instability

[Ben Ward]

The code for that function not shown is rather similar to the version that 
is shown:

function 
distance{T<:MutationType,A<:NucleotideAlphabet}(::Type{Proportion{T}}, 
seqs::Vector{BioSequence{A}})
d, l = distance(Count{T}, seqs)
D = Vector{Float64}(length(d))
@inbounds for i in 1:length(D)
D[i] = d[i] / l[i]
end
return D, l
end

Which has a @code_warntype which seems ok:

*julia> **@code_warntype distance(Proportion{AnyMutation}, dnas2)*

Variables:

  #self#::Bio.Var.#distance

  #unused#::Type{Bio.Var.Proportion{Bio.Var.AnyMutation}}

  seqs@_3::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1}

  d::Array{Int64,1}

  l::Array{Int64,1}

  #temp#@_6::Int64

  D::Array{Float64,1}

  #temp#@_8::Int64

  i::Int64

  seqs@_10::Array{Bio.Seq.DNANucleotide,2}


Body:

  begin 

  $(Expr(:inbounds, false))

  # meta: location /Users/bward/.julia/v0.5/Bio/src/var/distances.jl 
distance 133

  # meta: location 
/Users/bward/.julia/v0.5/Bio/src/var/mutation_counting.jl count_mutations 
263

  seqs@_10::Array{Bio.Seq.DNANucleotide,2} = $(Expr(:invoke, LambdaInfo 
for seqmatrix(::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1}, 
::Symbol), :(Bio.Var.seqmatrix), :(seqs@_3), :(:seq)))

  # meta: pop location

  # meta: pop location

  $(Expr(:inbounds, :pop))

  SSAValue(0) = $(Expr(:invoke, LambdaInfo for 
count_mutations(::Type{Bio.Var.AnyMutation}, 
::Array{Bio.Seq.DNANucleotide,2}), :(Bio.Var.count_mutations), 
Bio.Var.AnyMutation, :(seqs@_10)))

  #temp#@_6::Int64 = $(QuoteNode(1))

  SSAValue(9) = (Base.getfield)(SSAValue(0),1)::Array{Int64,1}

  SSAValue(10) = (Base.box)(Int64,(Base.add_int)(1,1))

  d::Array{Int64,1} = SSAValue(9)

  #temp#@_6::Int64 = SSAValue(10)

  SSAValue(11) = (Base.getfield)(SSAValue(0),2)::Array{Int64,1}

  SSAValue(12) = (Base.box)(Int64,(Base.add_int)(2,1))

  l::Array{Int64,1} = SSAValue(11)

  #temp#@_6::Int64 = SSAValue(12) # line 256:

  SSAValue(6) = (Base.arraylen)(d::Array{Int64,1})::Int64

  D::Array{Float64,1} = 
(Core.ccall)(:jl_alloc_array_1d,(Core.apply_type)(Core.Array,Float64,1)::Type{Array{Float64,1}},(Core.svec)(Core.Any,Core.Int)::SimpleVector,Array{Float64,1},0,SSAValue(6),0)::Array{Float64,1}
 
# line 257:

  $(Expr(:inbounds, true))

  SSAValue(8) = (Base.arraylen)(D::Array{Float64,1})::Int64

  SSAValue(13) = 
(Base.select_value)((Base.sle_int)(1,SSAValue(8))::Bool,SSAValue(8),(Base.box)(Int64,(Base.sub_int)(1,1)))::Int64

  #temp#@_8::Int64 = 1

  26: 

  unless (Base.box)(Base.Bool,(Base.not_int)((#temp#@_8::Int64 === 
(Base.box)(Int64,(Base.add_int)(SSAValue(13),1)))::Bool)) goto 37

  SSAValue(14) = #temp#@_8::Int64

  SSAValue(15) = (Base.box)(Int64,(Base.add_int)(#temp#@_8::Int64,1))

  i::Int64 = SSAValue(14)

  #temp#@_8::Int64 = SSAValue(15) # line 258:

  SSAValue(5) = 
(Base.box)(Base.Float64,(Base.div_float)((Base.box)(Float64,(Base.sitofp)(Float64,(Base.arrayref)(d::Array{Int64,1},i::Int64)::Int64)),(Base.box)(Float64,(Base.sitofp)(Float64,(Base.arrayref)(l::Array{Int64,1},i::Int64)::Int64

  
(Base.arrayset)(D::Array{Float64,1},SSAValue(5),i::Int64)::Array{Float64,1}

  35: 

  goto 26

  37: 

  $(Expr(:inbounds, :pop)) # line 260:

  return 
(Core.tuple)(D::Array{Float64,1},l::Array{Int64,1})::Tuple{Array{Float64,1},Array{Int64,1}}

  end::Tuple{Array{Float64,1},Array{Int64,1}}

But then again the loop in this function is also not vectorised which I 
struggle to see why... unless division can't be.

On Friday, September 16, 2016 at 3:27:47 AM UTC+1, Ralph Smith wrote:
>
> SSAValue(15) = (Base.getfield)(SSAValue(0),1)
> *::Union{Array{Float64,1},Array{Int64,1}}*
>
>
> indicates that the first element of SSAValue(0) is ambiguous. Earlier it 
> shows that this means p from
>
> p, l = distance(Proportion{AnyMutation}, seqs)
>
> which we can't analyze from what you show here.
>
> On Thursday, September 15, 2016 at 10:08:16 AM UTC-4, Ben Ward wrote:
>>
>> Hi I have two functions and a function which calls them:
>>
>> @inline function expected_distance(::Type{JukesCantor69}, p::Float64)
>> return -0.75 * log(1 - 4 * p / 3)
>> end
>>
>> @inline function variance(::Type{JukesCantor69}, p::Float64, l::Int64)
>> return p * (1 - p) / (((1 - 4 * p / 3) ^ 2) * l)
>> end
>>
>> function distance{A<:NucleotideAlphabet}(::Type{JukesCantor69}, 
>> seqs::Vector{BioSequence{A}})
>> p, l = distance(Proportion{AnyMutation}, seqs)
>> D = Vector{Float64}(length(p))
>> V = Vector{Float64}(length(p))
>> @inbounds for i in 1:length(p)
>> D[i] = expected_distance(JukesCantor69, p[i])
>> V[i] = variance(JukesCantor69, p[i], l[i])
>> end
>> return D, V
>> end
>>
>> But I'm seeing type uncertainty:
>>
>> *@code_warntype distance(JukesCantor69, dnas)*
>>
>> Variables:
>>
>>   #self#::Bio.Var.#distance
>>
>>   #unused#::Type{Bio.Var.JukesCantor69}
>>

[julia-users] Re: How would you use Julia in a real world R Setup ?

[Chris Rackauckas]

The tooling for debugging is still growing. Gallium.jl with Juno is nice, 
but I still do a lot of println debugging. As Gallium/Juno matures I use it 
more and more often.

To make sure you're not using old versions, quit the REPL. In Juno, that's 
Ctrl+j Ctrl+k. You can hit that command almost instantly, and if you have 
the process server enabled (which I think will be introduced and be the 
default in the next version they are tagging?) then Juno already has a 
process started that is waiting for you, so there is no delay after doing 
this. Since there's really no delay, I do this after every Pkg.update(), 
most of the time when things need to re-compile (you can specifically 
highlight and evaluate a method to recompile it, but I find that quitting 
the REPL like this is so easy that I tend to overuse it), or just out of 
caution I'll use it. Another Juno command which is good to know is Ctrl+j 
Ctrl+c which will clear the console. 

On Friday, September 16, 2016 at 12:19:08 AM UTC-7, Tsur Herman wrote:
>
> Thank you for the time you took to answer.
>
> How do you go about debugging and inspecting? and making sure that changes 
> you made gets compiled
> and that you are not accidentally running a previously imported version of 
> a function? 
>
>
> On Thursday, September 15, 2016 at 10:11:21 PM UTC+3, Tsur Herman wrote:
>>
>> Hi , I am new here .
>> Just started playing around with julia, my background is in Matlab c++ 
>> and GPU computing(writing kernels)
>>
>> I am trying to figure out what will be good practice for rapid 
>> prototyping.
>> How would you use Julia and Juno IDE for a research and development 
>> project that will
>> end up having numerous files and many lines of code , and a basic gui?
>>
>> Please share your experience  , thanks.
>> Tsur
>>
>>
>>

Re: [julia-users] Tracking down type instability

[Ben Ward]

I see, but I thought I'd like to try and remove the instability as I wonder 
if it's one of the things preventing vectorisation of the @inbounds loop in 
the `distance` function.

On Friday, September 16, 2016 at 7:54:33 AM UTC+1, Kristoffer Carlsson 
wrote:
>
> It looks fine because for both the SSAValues with "problems" you later 
> have:
>
>  p::Array{Float64,1} = SSAValue(15)
>
>  l::Array{Int64,1} = SSAValue(17)
>
> so they actually get correctly inferred.
>
> As long as your variables list and return value is ok then things are most 
> likely ok.
>
> On Friday, September 16, 2016 at 4:37:09 AM UTC+2, Yichao Yu wrote:
>>
>> On Thu, Sep 15, 2016 at 10:08 AM, Ben Ward  wrote: 
>> > Hi I have two functions and a function which calls them: 
>> > 
>> > @inline function expected_distance(::Type{JukesCantor69}, p::Float64) 
>> > return -0.75 * log(1 - 4 * p / 3) 
>> > end 
>> > 
>> > @inline function variance(::Type{JukesCantor69}, p::Float64, l::Int64) 
>> > return p * (1 - p) / (((1 - 4 * p / 3) ^ 2) * l) 
>> > end 
>> > 
>> > function distance{A<:NucleotideAlphabet}(::Type{JukesCantor69}, 
>> > seqs::Vector{BioSequence{A}}) 
>> > p, l = distance(Proportion{AnyMutation}, seqs) 
>> > D = Vector{Float64}(length(p)) 
>> > V = Vector{Float64}(length(p)) 
>> > @inbounds for i in 1:length(p) 
>> > D[i] = expected_distance(JukesCantor69, p[i]) 
>> > V[i] = variance(JukesCantor69, p[i], l[i]) 
>> > end 
>> > return D, V 
>> > end 
>> > 
>> > But I'm seeing type uncertainty: 
>> > 
>> > @code_warntype distance(JukesCantor69, dnas) 
>> > 
>> > Variables: 
>> > 
>> >   #self#::Bio.Var.#distance 
>> > 
>> >   #unused#::Type{Bio.Var.JukesCantor69} 
>> > 
>> >   seqs::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1} 
>> > 
>> >   p::Array{Float64,1} 
>> > 
>> >   l::Array{Int64,1} 
>> > 
>> >   #temp#@_6::Int64 
>> > 
>> >   D::Array{Float64,1} 
>> > 
>> >   V::Array{Float64,1} 
>> > 
>> >   #temp#@_9::Int64 
>> > 
>> >   i::Int64 
>> > 
>> > 
>> > Body: 
>> > 
>> >   begin 
>> > 
>> >   SSAValue(0) = $(Expr(:invoke, LambdaInfo for 
>> > distance(::Type{Bio.Var.Proportion{Bio.Var.AnyMutation}}, 
>> > ::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1}), 
>> > :(Bio.Var.distance), Bio.Var.Proportion{Bio.Var.AnyMutation}, :(seqs))) 
>> > 
>> >   #temp#@_6::Int64 = $(QuoteNode(1)) 
>> > 
>> >   SSAValue(15) = 
>> > (Base.getfield)(SSAValue(0),1)::Union{Array{Float64,1},Array{Int64,1}} 
>>
>> I guess we should probably print ssavalue types to make this easier to 
>> analyse 
>>
>> There's likely no type instability and the warning here is just spurious 
>>
>> > 
>> >   SSAValue(16) = (Base.box)(Int64,(Base.add_int)(1,1)) 
>> > 
>> >   p::Array{Float64,1} = SSAValue(15) 
>> > 
>> >   #temp#@_6::Int64 = SSAValue(16) 
>> > 
>> >   SSAValue(17) = 
>> > (Base.getfield)(SSAValue(0),2)::Union{Array{Float64,1},Array{Int64,1}} 
>> > 
>> >   SSAValue(18) = (Base.box)(Int64,(Base.add_int)(2,1)) 
>> > 
>> >   l::Array{Int64,1} = SSAValue(17) 
>> > 
>> >   #temp#@_6::Int64 = SSAValue(18) # line 314: 
>> > 
>> >   SSAValue(7) = (Base.arraylen)(p::Array{Float64,1})::Int64 
>> > 
>> >   D::Array{Float64,1} = 
>> > 
>> (Core.ccall)(:jl_alloc_array_1d,(Core.apply_type)(Core.Array,Float64,1)::Type{Array{Float64,1}},(Core.svec)(Core.Any,Core.Int)::SimpleVector,Array{Float64,1},0,SSAValue(7),0)::Array{Float64,1}
>>  
>>
>> > # line 315: 
>> > 
>> >   SSAValue(9) = (Base.arraylen)(p::Array{Float64,1})::Int64 
>> > 
>> >   V::Array{Float64,1} = 
>> > 
>> (Core.ccall)(:jl_alloc_array_1d,(Core.apply_type)(Core.Array,Float64,1)::Type{Array{Float64,1}},(Core.svec)(Core.Any,Core.Int)::SimpleVector,Array{Float64,1},0,SSAValue(9),0)::Array{Float64,1}
>>  
>>
>> > # line 316: 
>> > 
>> >   $(Expr(:inbounds, true)) 
>> > 
>> >   SSAValue(11) = (Base.arraylen)(p::Array{Float64,1})::Int64 
>> > 
>> >   SSAValue(19) = 
>> > 
>> (Base.select_value)((Base.sle_int)(1,SSAValue(11))::Bool,SSAValue(11),(Base.box)(Int64,(Base.sub_int)(1,1)))::Int64
>>  
>>
>> > 
>> >   #temp#@_9::Int64 = 1 
>> > 
>> >   22: 
>> > 
>> >   unless (Base.box)(Base.Bool,(Base.not_int)((#temp#@_9::Int64 === 
>> > (Base.box)(Int64,(Base.add_int)(SSAValue(19),1)))::Bool)) goto 43 
>> > 
>> >   SSAValue(20) = #temp#@_9::Int64 
>> > 
>> >   SSAValue(21) = 
>> (Base.box)(Int64,(Base.add_int)(#temp#@_9::Int64,1)) 
>> > 
>> >   i::Int64 = SSAValue(20) 
>> > 
>> >   #temp#@_9::Int64 = SSAValue(21) # line 317: 
>> > 
>> >   SSAValue(12) = 
>> (Base.arrayref)(p::Array{Float64,1},i::Int64)::Float64 
>> > 
>> >   $(Expr(:inbounds, false)) 
>> > 
>> >   # meta: location 
>> /Users/bward/.julia/v0.5/Bio/src/var/distances.jl 
>> > expected_distance 69 
>> > 
>> >   SSAValue(13) = $(Expr(:invoke, LambdaInfo for log(::Float64), 
>> > :(Bio.Var.log), 
>> > 
>> 

Re: [julia-users] Tracking down type instability

[Yichao Yu]

On Sep 16, 2016 11:30 AM, "Ben Ward"  wrote:
>
> I see, but I thought I'd like to try and remove the instability as I
wonder if it's one of the things preventing vectorisation of the @inbounds
loop in the `distance` function.

Log can't be vectorized. Not yet at least.

>
>
> On Friday, September 16, 2016 at 7:54:33 AM UTC+1, Kristoffer Carlsson
wrote:
>>
>> It looks fine because for both the SSAValues with "problems" you later
have:
>>
>>  p::Array{Float64,1} = SSAValue(15)
>>
>>  l::Array{Int64,1} = SSAValue(17)
>>
>>
>> so they actually get correctly inferred.
>>
>> As long as your variables list and return value is ok then things are
most likely ok.
>>
>> On Friday, September 16, 2016 at 4:37:09 AM UTC+2, Yichao Yu wrote:
>>>
>>> On Thu, Sep 15, 2016 at 10:08 AM, Ben Ward 
wrote:
>>> > Hi I have two functions and a function which calls them:
>>> >
>>> > @inline function expected_distance(::Type{JukesCantor69}, p::Float64)
>>> > return -0.75 * log(1 - 4 * p / 3)
>>> > end
>>> >
>>> > @inline function variance(::Type{JukesCantor69}, p::Float64,
l::Int64)
>>> > return p * (1 - p) / (((1 - 4 * p / 3) ^ 2) * l)
>>> > end
>>> >
>>> > function distance{A<:NucleotideAlphabet}(::Type{JukesCantor69},
>>> > seqs::Vector{BioSequence{A}})
>>> > p, l = distance(Proportion{AnyMutation}, seqs)
>>> > D = Vector{Float64}(length(p))
>>> > V = Vector{Float64}(length(p))
>>> > @inbounds for i in 1:length(p)
>>> > D[i] = expected_distance(JukesCantor69, p[i])
>>> > V[i] = variance(JukesCantor69, p[i], l[i])
>>> > end
>>> > return D, V
>>> > end
>>> >
>>> > But I'm seeing type uncertainty:
>>> >
>>> > @code_warntype distance(JukesCantor69, dnas)
>>> >
>>> > Variables:
>>> >
>>> >   #self#::Bio.Var.#distance
>>> >
>>> >   #unused#::Type{Bio.Var.JukesCantor69}
>>> >
>>> >   seqs::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1}
>>> >
>>> >   p::Array{Float64,1}
>>> >
>>> >   l::Array{Int64,1}
>>> >
>>> >   #temp#@_6::Int64
>>> >
>>> >   D::Array{Float64,1}
>>> >
>>> >   V::Array{Float64,1}
>>> >
>>> >   #temp#@_9::Int64
>>> >
>>> >   i::Int64
>>> >
>>> >
>>> > Body:
>>> >
>>> >   begin
>>> >
>>> >   SSAValue(0) = $(Expr(:invoke, LambdaInfo for
>>> > distance(::Type{Bio.Var.Proportion{Bio.Var.AnyMutation}},
>>> > ::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1}),
>>> > :(Bio.Var.distance), Bio.Var.Proportion{Bio.Var.AnyMutation},
:(seqs)))
>>> >
>>> >   #temp#@_6::Int64 = $(QuoteNode(1))
>>> >
>>> >   SSAValue(15) =
>>> >
(Base.getfield)(SSAValue(0),1)::Union{Array{Float64,1},Array{Int64,1}}
>>>
>>> I guess we should probably print ssavalue types to make this easier to
analyse
>>>
>>> There's likely no type instability and the warning here is just
spurious
>>>
>>> >
>>> >   SSAValue(16) = (Base.box)(Int64,(Base.add_int)(1,1))
>>> >
>>> >   p::Array{Float64,1} = SSAValue(15)
>>> >
>>> >   #temp#@_6::Int64 = SSAValue(16)
>>> >
>>> >   SSAValue(17) =
>>> >
(Base.getfield)(SSAValue(0),2)::Union{Array{Float64,1},Array{Int64,1}}
>>> >
>>> >   SSAValue(18) = (Base.box)(Int64,(Base.add_int)(2,1))
>>> >
>>> >   l::Array{Int64,1} = SSAValue(17)
>>> >
>>> >   #temp#@_6::Int64 = SSAValue(18) # line 314:
>>> >
>>> >   SSAValue(7) = (Base.arraylen)(p::Array{Float64,1})::Int64
>>> >
>>> >   D::Array{Float64,1} =
>>> >
(Core.ccall)(:jl_alloc_array_1d,(Core.apply_type)(Core.Array,Float64,1)::Type{Array{Float64,1}},(Core.svec)(Core.Any,Core.Int)::SimpleVector,Array{Float64,1},0,SSAValue(7),0)::Array{Float64,1}

>>> > # line 315:
>>> >
>>> >   SSAValue(9) = (Base.arraylen)(p::Array{Float64,1})::Int64
>>> >
>>> >   V::Array{Float64,1} =
>>> >
(Core.ccall)(:jl_alloc_array_1d,(Core.apply_type)(Core.Array,Float64,1)::Type{Array{Float64,1}},(Core.svec)(Core.Any,Core.Int)::SimpleVector,Array{Float64,1},0,SSAValue(9),0)::Array{Float64,1}

>>> > # line 316:
>>> >
>>> >   $(Expr(:inbounds, true))
>>> >
>>> >   SSAValue(11) = (Base.arraylen)(p::Array{Float64,1})::Int64
>>> >
>>> >   SSAValue(19) =
>>> >
(Base.select_value)((Base.sle_int)(1,SSAValue(11))::Bool,SSAValue(11),(Base.box)(Int64,(Base.sub_int)(1,1)))::Int64

>>> >
>>> >   #temp#@_9::Int64 = 1
>>> >
>>> >   22:
>>> >
>>> >   unless (Base.box)(Base.Bool,(Base.not_int)((#temp#@_9::Int64
===
>>> > (Base.box)(Int64,(Base.add_int)(SSAValue(19),1)))::Bool)) goto 43
>>> >
>>> >   SSAValue(20) = #temp#@_9::Int64
>>> >
>>> >   SSAValue(21) =
(Base.box)(Int64,(Base.add_int)(#temp#@_9::Int64,1))
>>> >
>>> >   i::Int64 = SSAValue(20)
>>> >
>>> >   #temp#@_9::Int64 = SSAValue(21) # line 317:
>>> >
>>> >   SSAValue(12) =
(Base.arrayref)(p::Array{Float64,1},i::Int64)::Float64
>>> >
>>> >   $(Expr(:inbounds, false))
>>> >
>>> >   # meta: location
/Users/bward/.julia/v0.5/Bio/src/var/distances.jl
>>> > expected_distance 69
>>> >
>>> >   SSAValue(13) = $(Expr(:invoke, LambdaInfo for log(::Float64),

Re: [julia-users] Re: tail active log

[Stefan Karpinski]

You'd want something more like this:

open(last_sim_log) do fh
while !eof(fh)
print(readline(fh))
end
end


This does a couple of things:

   1. Use the open(...) do fh ... end construct to ensure file closing.
   2. Check for stream end using eof(fh) instead of catching an error.


On Fri, Sep 16, 2016 at 5:06 AM,  wrote:

> Thanks for the replies,
>
> For some reason only one chunk of data is printed even though the log is
> still being written to
>
>   fh = open(last_sim_log)
>   try
> while true
>   print(readline(fh))
> end
>   finally
> close(fh)
>   end
>
> For readavailable(fh), I getting "no method matching
> readavailable(::IOStream)"
>
> Many Thanks
>
> Aidy
>
> On 9/15/2016 at 4:24 PM, "Stefan Karpinski"  wrote:
> >
> >If you don't mind blocking when a complete line isn't available,
> >you can
> >just call readline(io) repeatedly.
> >
> >On Thu, Sep 15, 2016 at 7:57 AM, Steven G. Johnson
> >
> >wrote:
> >
> >>
> >>
> >> On Thursday, September 15, 2016 at 7:11:55 AM UTC-4, Adrian
> >Lewis wrote:
> >>>
> >>> I have an active log and I wondered how I could `tail -f` this
> >without
> >>> running the Unix command?
> >>
> >>
> >> Open the file and repeatedly call `readavailable`
> >>
>
>

[julia-users] Re: wrapping a julia package

[Páll Haraldsson]

On Friday, September 16, 2016 at 4:29:33 PM UTC, Páll Haraldsson wrote:
>
> This is an inserting question in general, first for the specific:
>

Obviously "interesting" question.. Didn't mean to rely on spell check..

[julia-users] Re: julia installation broken

[Jeffrey Sarnoff]

I have had this happen, too.  My suggestion is  grounded in persistence 
rather than deep mastery of Julia's structural and file relationships.
So someone else may have a more studied approach with some explaining. 
 Until then,

quit() Julia.
To have an new install be really clean, first cd  to /.julia/ 
and delete the directory `v0.5` -- if that is overkill because you do not 
want to redo many Pkg.add()s then cd v0.5 and delete the METADATA directory 
the REQUIRE file and the META_BRANCH file and the entry for whatever 
packages you had added just before this difficulty (including those that 
have hiccuped on precompile).   
now delete and then reget the most current binary for your system 
julia-0.5.0-rc4-osx10.7+.dmg 

install
Then start julia and quit().  Then start Julia and do Pkg.update() then 
quit().
Then start julia and do Pkg.add() for 1 package you want then quit(). then 
start julia and do using  (so it precompiles) and quit().
now try using that package.






On Friday, September 16, 2016 at 4:43:06 AM UTC-4, Michael Borregaard wrote:
>
> Hi, Is this the right forum for troubleshooting / issues with my julia 
> install?
>
> I have kept having problems with packages giving error on precompile, 
> rendering julia unusable. I then reinstalled julia-0.5-rc4, and removed my 
> .julia folder from my home dir to do a fresh install. Now, Julia fails with 
> an error message when I do Pkg.update():
>
> julia> Pkg.update()
> INFO: Initializing package repository /Users/michael/.julia/v0.5
> INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
> ERROR: SystemError (with /Users/michael/.julia/v0.5/METADATA): rmdir: 
> Directory not empty
>  in #systemerror#51 at ./error.jl:34 [inlined]
>  in (::Base.#kw##systemerror)(::Array{Any,1}, ::Base.#systemerror, 
> ::Symbol, ::Bool) at ./:0
>  in #rm#7(::Bool, ::Bool, ::Function, ::String) at ./file.jl:125
>  in #rm#7(::Bool, ::Bool, ::Function, ::String) at 
> /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
>  in (::Base.Filesystem.#kw##rm)(::Array{Any,1}, ::Base.Filesystem.#rm, 
> ::String) at ./:0
>  in init(::String, ::String) at ./pkg/dir.jl:62
>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, 
> ::Vararg{Any,N}) at ./pkg/dir.jl:28
>  in update() at ./pkg/pkg.jl:210
>
> I assums that a completely clean install should work. Are there keys to 
> delete etc that will give me a properly clean install? I am on Mac OS X 
> (newest version).
> Thanks!
>

[julia-users] Re: wrapping a julia package

[Páll Haraldsson]

On Friday, September 16, 2016 at 4:29:33 PM UTC, Páll Haraldsson wrote:
  

> `ARGB32` uses a `UInt32` representation of color,
>
> [I didn't see RGBA, only alpha in upper bits.. so unless I overlooked, may 
> not work, since bits not in the same order:]
>
>  

> " reinterpret(type, A)
>
> Change the type-interpretation of a block of memory. [..]"
>
>
> for the 32-bit pixel values?
>
> Maybe you can do just that without any wrapper, if that is only needed, to 
> get the new type-name (assuming you can and there are no name classes with 
> importing two packages that define say Color..)?
>

I guess, when alpha is in the low bits, you could do something like:

reinterpret(UInt32, UInt32(rotate_left(pixel))) # given that function was 
available..

but I guess it would be slow.. ROL (I'm justed to from assembly) couldn't 
be optimized away, in most or even any cases..


I'm not sure why, there are just [arithmetic] shift left and right in Julia 
and languages I'm familiar with.. I guess because you can build from that 
from: 

reinterpret(UInt32, UInt32(pixel<<8))

and more.

Not sure that version would be easier for the optimizer..

Best would be if there already is already also a RGBA32 type (or you could 
add it).

-- 
Palli.

[julia-users] Re: wrapping a julia package

[Páll Haraldsson]

This is an inserting question in general, first for the specific:

A.
I took a quick look at the code:

https://github.com/zyedidia/SFML.jl/commit/2e6ebee0a6dca85486563ea6f99decc595e831fa

type Color
r::Uint8
g::Uint8
b::Uint8
a::Uint8


Then Colors.jl seemed overkill and maybe not with what you wanted, seems 
ColorTypes.jl is it (split off from Colors.jl?); and it by default uses 
floating-point, but I also see:

typealias U8 UFixed8

and:

https://github.com/JuliaGraphics/ColorTypes.jl/blob/be848d6777c71ef36a619be7218083183d0f0d7e/src/types.jl#L269

RGB24(r::UFixed8, g::UFixed8, b::UFixed8) = _RGB24(reinterpret(r), 
reinterpret(g), reinterpret(b))

[..]

`ARGB32` uses a `UInt32` representation of color,

[I didn't see RGBA, only alpha in upper bits.. so unless I overlooked, may 
not work, since bits not in the same order:]


So you're thinking if you can have a wrapper that does:

http://docs.julialang.org/en/release-0.4/stdlib/arrays/?highlight=reinterpret

" reinterpret(type, A)

Change the type-interpretation of a block of memory. [..]"


for the 32-bit pixel values?

Maybe you can do just that without any wrapper, if that is only needed, to 
get the new type-name (assuming you can and there are no name classes with 
importing two packages that define say Color..)?


B. If you want a new wrapper, then in essence you have a new API, and I'm 
not sure it's advised (or to fork the library..) here (or in general); most 
would not know of the other API and/or understandably assume the official 
wrapper is the best.. If you could change the API in SFML.jl (in 
cooperation with the author), I guess that is best. Then you brake code for 
others (unless you that packages keeps two APIs, at least for a while).

-- 
Palli.

On Friday, August 26, 2016 at 8:10:33 AM UTC, jw3126 wrote:
>
> I want to use a julia package (SFML.jl), which defines its own types for 
> lots of basic things like 2d vectors, rectangles colors etc. 
> It would be cool however if one could use its functionality with "standard 
> types", like colors from Colors.jl, StaticArrays.jl vectors, 
> GeometryTypes.jl rectangles etc.
> Now SFML.jl is an interface to the C++ library SFML with zero julia 
> dependencies and its types mirror that of SFML. So I guess changing SFML.jl 
> is not the way to go here. Instead I am thinking about wrapping SFML.jl 
> such that function inputs and outputs are automatically converted between 
> "standard types" and "SFML.jl types.
> I guess using meta-programming it should be possible to loop over all 
> methods defined in SFML.jl and compose them with the appropriate 
> conversions? Is this the way to go? Is there an example, where such a thing 
> was applied to another package?
>

[julia-users] Re: Tracking down type instability

[Kristoffer Carlsson]

What if you add @simd after @inbounds?

On Friday, September 16, 2016 at 5:48:00 PM UTC+2, Ben Ward wrote:
>
> The code for that function not shown is rather similar to the version that 
> is shown:
>
> function 
> distance{T<:MutationType,A<:NucleotideAlphabet}(::Type{Proportion{T}}, 
> seqs::Vector{BioSequence{A}})
> d, l = distance(Count{T}, seqs)
> D = Vector{Float64}(length(d))
> @inbounds for i in 1:length(D)
> D[i] = d[i] / l[i]
> end
> return D, l
> end
>
> Which has a @code_warntype which seems ok:
>
> *julia> **@code_warntype distance(Proportion{AnyMutation}, dnas2)*
>
> Variables:
>
>   #self#::Bio.Var.#distance
>
>   #unused#::Type{Bio.Var.Proportion{Bio.Var.AnyMutation}}
>
>   seqs@_3::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1}
>
>   d::Array{Int64,1}
>
>   l::Array{Int64,1}
>
>   #temp#@_6::Int64
>
>   D::Array{Float64,1}
>
>   #temp#@_8::Int64
>
>   i::Int64
>
>   seqs@_10::Array{Bio.Seq.DNANucleotide,2}
>
>
> Body:
>
>   begin 
>
>   $(Expr(:inbounds, false))
>
>   # meta: location /Users/bward/.julia/v0.5/Bio/src/var/distances.jl 
> distance 133
>
>   # meta: location 
> /Users/bward/.julia/v0.5/Bio/src/var/mutation_counting.jl count_mutations 
> 263
>
>   seqs@_10::Array{Bio.Seq.DNANucleotide,2} = $(Expr(:invoke, 
> LambdaInfo for 
> seqmatrix(::Array{Bio.Seq.BioSequence{Bio.Seq.DNAAlphabet{4}},1}, 
> ::Symbol), :(Bio.Var.seqmatrix), :(seqs@_3), :(:seq)))
>
>   # meta: pop location
>
>   # meta: pop location
>
>   $(Expr(:inbounds, :pop))
>
>   SSAValue(0) = $(Expr(:invoke, LambdaInfo for 
> count_mutations(::Type{Bio.Var.AnyMutation}, 
> ::Array{Bio.Seq.DNANucleotide,2}), :(Bio.Var.count_mutations), 
> Bio.Var.AnyMutation, :(seqs@_10)))
>
>   #temp#@_6::Int64 = $(QuoteNode(1))
>
>   SSAValue(9) = (Base.getfield)(SSAValue(0),1)::Array{Int64,1}
>
>   SSAValue(10) = (Base.box)(Int64,(Base.add_int)(1,1))
>
>   d::Array{Int64,1} = SSAValue(9)
>
>   #temp#@_6::Int64 = SSAValue(10)
>
>   SSAValue(11) = (Base.getfield)(SSAValue(0),2)::Array{Int64,1}
>
>   SSAValue(12) = (Base.box)(Int64,(Base.add_int)(2,1))
>
>   l::Array{Int64,1} = SSAValue(11)
>
>   #temp#@_6::Int64 = SSAValue(12) # line 256:
>
>   SSAValue(6) = (Base.arraylen)(d::Array{Int64,1})::Int64
>
>   D::Array{Float64,1} = 
> (Core.ccall)(:jl_alloc_array_1d,(Core.apply_type)(Core.Array,Float64,1)::Type{Array{Float64,1}},(Core.svec)(Core.Any,Core.Int)::SimpleVector,Array{Float64,1},0,SSAValue(6),0)::Array{Float64,1}
>  
> # line 257:
>
>   $(Expr(:inbounds, true))
>
>   SSAValue(8) = (Base.arraylen)(D::Array{Float64,1})::Int64
>
>   SSAValue(13) = 
> (Base.select_value)((Base.sle_int)(1,SSAValue(8))::Bool,SSAValue(8),(Base.box)(Int64,(Base.sub_int)(1,1)))::Int64
>
>   #temp#@_8::Int64 = 1
>
>   26: 
>
>   unless (Base.box)(Base.Bool,(Base.not_int)((#temp#@_8::Int64 === 
> (Base.box)(Int64,(Base.add_int)(SSAValue(13),1)))::Bool)) goto 37
>
>   SSAValue(14) = #temp#@_8::Int64
>
>   SSAValue(15) = (Base.box)(Int64,(Base.add_int)(#temp#@_8::Int64,1))
>
>   i::Int64 = SSAValue(14)
>
>   #temp#@_8::Int64 = SSAValue(15) # line 258:
>
>   SSAValue(5) = 
> (Base.box)(Base.Float64,(Base.div_float)((Base.box)(Float64,(Base.sitofp)(Float64,(Base.arrayref)(d::Array{Int64,1},i::Int64)::Int64)),(Base.box)(Float64,(Base.sitofp)(Float64,(Base.arrayref)(l::Array{Int64,1},i::Int64)::Int64
>
>   
> (Base.arrayset)(D::Array{Float64,1},SSAValue(5),i::Int64)::Array{Float64,1}
>
>   35: 
>
>   goto 26
>
>   37: 
>
>   $(Expr(:inbounds, :pop)) # line 260:
>
>   return 
> (Core.tuple)(D::Array{Float64,1},l::Array{Int64,1})::Tuple{Array{Float64,1},Array{Int64,1}}
>
>   end::Tuple{Array{Float64,1},Array{Int64,1}}
>
> But then again the loop in this function is also not vectorised which I 
> struggle to see why... unless division can't be.
>
> On Friday, September 16, 2016 at 3:27:47 AM UTC+1, Ralph Smith wrote:
>>
>> SSAValue(15) = (Base.getfield)(SSAValue(0),1)
>> *::Union{Array{Float64,1},Array{Int64,1}}*
>>
>>
>> indicates that the first element of SSAValue(0) is ambiguous. Earlier it 
>> shows that this means p from
>>
>> p, l = distance(Proportion{AnyMutation}, seqs)
>>
>> which we can't analyze from what you show here.
>>
>> On Thursday, September 15, 2016 at 10:08:16 AM UTC-4, Ben Ward wrote:
>>>
>>> Hi I have two functions and a function which calls them:
>>>
>>> @inline function expected_distance(::Type{JukesCantor69}, p::Float64)
>>> return -0.75 * log(1 - 4 * p / 3)
>>> end
>>>
>>> @inline function variance(::Type{JukesCantor69}, p::Float64, l::Int64)
>>> return p * (1 - p) / (((1 - 4 * p / 3) ^ 2) * l)
>>> end
>>>
>>> function distance{A<:NucleotideAlphabet}(::Type{JukesCantor69}, 
>>> seqs::Vector{BioSequence{A}})
>>> p, l = distance(Proportion{AnyMutation}, seqs)
>>> D = Vector{Float64}(length(p))
>>> V = Vector{Float64}(length(p))
>>> 

Re: [julia-users] Re: wrapping a julia package

[Tim Holy]

Yes, the idea of wrappers that reinterpret or convert makes sense.

On Friday, September 16, 2016 9:29:33 AM CDT Páll Haraldsson wrote:
> type Color
> r::Uint8
> g::Uint8
> b::Uint8
> a::Uint8

RGBA{U8} is bitwise identical to this, so you can use reinterpret as needed.

--Tim

[julia-users] Re: Help on building Julia with Intel MKL on Windows?

[Zhong Pan]

BTW I have re-installed Intel MKL in a folder without any spaces in the 
path name, so you may notice the location changed. Not sure if it helps, 
just trying.

[julia-users] Re: Idea: Julia Standard Libraries and Distributions

[Chris Rackauckas]

I think some of this I just answered 
here: https://github.com/JuliaLang/julia/issues/18389 . Here's a quote:

I think a good way to go forward is to start making some metapackages held 
> by the Julia orgs. For example, FFT could move out of Base into JuliaMath, 
> and there can be a standard Math.jl which simply re-exports the "Julia 
> standard math library" using Reexport.jl. This would have agreed on 
> packages (with version requirements?) for a specific domain. JuliaMath 
> could have Math.jl metapackage, JuliaStats could have a Stats.jl 
> metapackage, etc.
>
> I think this is better than just lumping them all together into a SciBase 
> because 
> "Science" is huge: the ML people will want the machine learning stack in 
> there, there's a whole statistics stack which replicates base R, if you 
> want to replicate MATLAB/SciPy then you'd want some differential equations 
> solvers which are large packages themselves, arguably PyCall and everything 
> associated is "standard Julia". I think using Math, Stats is both 
> succinct and informative to others if you share your script, and move the 
> discussion of "standards" to a more domain specific level.
>
> Does anyone see any design issues that may arise due to using Reexport 
> here (other than the fact that it's a personal repo)? Or does anyone else 
> have a good design?
>

Metapackages fix your first issue since they can lump a bunch of packages 
together, and import a bunch together as well. I think the Julia 
organizations (JuliaMath, JuliaStats, JuliaOpt, etc.) are good communities 
for deciding a base distribution in their own domains, which is why I am 
think that maybe it should be domain specific: each main JuliaDomain org 
has a Domain.jl  package which you can add with Pkg.add("Domain"), and use 
with `using Domain`. Math, Stats, Opt would then be curated separately by 
people who are engaged in the specific communities (with overlap of course 
since it's open source). A using statement for a few of these still isn't 
too bad, and "using Math, Stats" is both succinct and solves the 
reproducibility problem noted earlier (and that line could easily be added 
a .juliarc file, maybe a function could be added, auto_using("Math"), to 
automatically update the .juliarc? Don't like the name).

For your other issues, the fixes are happening by "upgrading the 
community". The packages are updating rapidly mostly because many of the 
packages themselves are really young and haven't finished adding all of 
their "basic" features. The Orgs have a good approval process. 

As for packages created by non-computing specialists, scientific computing 
is a pretty unique domain where a non-computing specialist may be the only 
person who can implement a specific package at the highest level of 
performance / sophistication. This means it's less about finding software 
developers to do the work, rather it's about teaching and helping domain 
specialists make a package. Julia has already been doing this to some 
extent: requiring CI testing and documentation, and policing the packages a 
bit for version requirements. I think Tony Kelman has done a great job at 
being a good "gatekeeper" to METADATA (I've learned a lot from him, thanks 
Tony!). 

Thus I think the proper way to move forward there is to setup Julia 
software development guidelines, and push for people to follow those 
guidelines. I tried to help out by writing a blog post which explains most 
of the steps 
,
 
but I think a good guideline with "the proper way to make/manage/make a 
Julia package" will be helpful in the long run for non-software development 
experts, and then whenever these principles aren't followed one can just be 
pointed to there with an explanation of why it's a good practice and how to 
do it.

On Thursday, September 15, 2016 at 4:45:25 AM UTC-7, Jeremy Cavanagh wrote:
>
>
> Hi Everyone,
>
> There are many comments with which I agree. Chris has put forward many 
> good ideas, I also use Java and find the install/upgrade system excellent. 
> There is no problem with having lots of APIs in the distribution since they 
> are not loaded into you code unless specifically required. I see a couple 
> of things that are a problem with Julia which I would like to see some 
> changes/improvements in. 
>
> The first is the way that packages are added is really quite tedious and 
> time consuming (I suspect this is a result of its REPL origin) which could 
> possibly be streamlined with some kind of gui based application.
>
> The second is that the group working on the Julia language (unlike Java) 
> are not also providing the bulk of the packages that help to improve the 
> functionality and usefulness of Julia. So how would you decide on a 
> suitable base distribution if the bulk are third party packages? 
>
> There is another "problem" (I can't quite think of the correct term)