[julia-users] Re: Dimension Independent Array Access

[Christoph Ortner]

Dear Tim,

Many thanks - this was illuminating and helped me understand the 
bottleneck. But it seems I did not give the correct amount of information 
in my question. In fact, I also want to access A[ idx ] for general index 
vectors idx that do not necessarily belong to the L array.  For example, I 
may be given a set of vectors in an array R, d x K and want to access  
 A[ L[:, n] + R[:, m] ],
 then loop over n, m and do some calculations.

These sort of calculations are at the core of the code and I want the 
syntax as simple and intuitive as possible to avoid making mistakes.

Can I confirm something:  is it true that when I do
 A[ L[:, Lcol] ]
then L[:, Lcol] creates a new d-dimensional array and copies that data into 
that array? Can this at all be avoided?  (I believe this is the bottlenbeck 
in what I do?)


I've now tried this again in the form

module damod
export darray3
immutable darray3
data
end
export getindex
getindex(a::darray3, idx) = a.data[idx[1], idx[2],idx[3]]
end

This makes only a small difference. 

elapsed time: 0.163860853 seconds (10480 bytes allocated, 28.46% gc time)

vs some variant of your code:
elapsed time: 0.003819349 seconds (96 bytes allocated)


What strikes me as odd here is that *104,000,080 bytes* are being allocated. If 
L is an Int16 array, then it should be no more than 100^3 x 3 x 8 = 6,000,000 ?


Any further thoughts will be much appreciated.


   Christoph

Re: [julia-users] Metaprogramming: what's going on here/is there a better way?

[elextr]

On Tuesday, November 18, 2014 12:59:50 PM UTC+10, Randy Zwitch wrote:
>
> It would appear so...I swear that I tried that, but I guess I didn't try 
> that permutation!
>
> So what's it about the @eval macro that doesn't allow for regular string 
> interpolation, that I have to use the string() function instead of an 
> inline $?
>

The @eval macro quotes its arguments.  Within quoted code substitution is 
by Expr objects, not text, so it won't substitute into a string.

Cheers
Lex


>>

[julia-users] Re: Arrayfire and Julia

[Zahirul ALAM]

I second this.

On Monday, 17 November 2014 12:27:43 UTC-5, Test This wrote:
>
> Happy to see thus reaction from a core julia developer. Hope julia makes 
> parallel programming on CPUs and GPUs easier. 
>

[julia-users] Re: Arrayfire and Julia

[Zahirul ALAM]

May be somehow we will be able to integrate this with Julia so well that we 
will always have the first-mover advantage ;)

-zahir

On Monday, 17 November 2014 00:35:02 UTC-5, Viral Shah wrote:
>
> Wow, I did not know about this. We certainly should leverage this. The API 
> looks easy to call too from C, from the examples on their github page, and 
> that is good news for us.
>
> -viral
>
> On Saturday, November 15, 2014 5:22:17 AM UTC+5:30, Zahirul ALAM wrote:
>>
>> thanks. I have been using Julia for five months or so. I have not used 
>> the ccall function ever. I will try it out as soon as I am done my current 
>> project. 
>>
>> On Friday, 14 November 2014 18:29:09 UTC-5, Tony Kelman wrote:
>>>
>>> I had the same response, great that they open-sourced the library, and 
>>> wrapping it in a Julia package would be interesting and not that hard to 
>>> do. It just needs someone to put a little bit of time into it. How long 
>>> have you been using Julia? Try compiling the arrayfire library and writing 
>>> a few ccall's into it from Julia, it should be a pretty direct translation 
>>> of their C API.
>>>
>>>
>>> On Friday, November 14, 2014 2:59:01 PM UTC-8, Zahirul ALAM wrote:

 Arrayfire has a large library for GPU computing. They have decided to 
 make their codes open source. I am hoping that someone much more able than 
 me will write some sort of wrapper to use the Arrayfire library in Julia. 

 Here is the github link: https://github.com/arrayfire/arrayfire

Re: [julia-users] Metaprogramming: what's going on here/is there a better way?

[Randy Zwitch]

It would appear so...I swear that I tried that, but I guess I didn't try 
that permutation!

So what's it about the @eval macro that doesn't allow for regular string 
interpolation, that I have to use the string() function instead of an 
inline $?

On Monday, November 17, 2014 9:50:55 PM UTC-5, Jacob Quinn wrote:
>
> Can you just do
>
>
> funcname = (:get_help_configuration, :get_help_languages, 
> :get_help_privacy, :get_help_tos, :get_application_rate_limit_status)
> endpoint = ("help/configuration.json", "help/languages.json", 
> "help/privacy.json",  "help/tos.json", "application/rate_limit_status.json")
>
> for (func, endp) in Dict(funcname, endpoint)
> @eval begin function ($func)(; options=Dict{String, String}())
> 
> r = get_oauth(string("https://api.twitter.com/1.1/";, $endp), 
> options)
>
> return r.status == 200 ? JSON.parse(r.data) : r
>
> end
> end
> end
>
>
> ?
>
> On Mon, Nov 17, 2014 at 9:35 PM, Randy Zwitch  > wrote:
>
>> I've seen this type of function generation in other packages, and wanted 
>> to try it for myself. This file in Twitter.jl has 5 functions with the same 
>> overall structure:
>>
>> https://github.com/randyzwitch/Twitter.jl/blob/master/src/help.jl
>>
>>
>> Here's what I ended up doing, which works, but I've got no idea why I had 
>> to write the string interpolation the way I did. I went through many 
>> permutations here, so if someone could explain why the `:($(string("
>> https://api.twitter.com/1.1/";, $endp))` line needs to be written that 
>> way for string interpolation, it would be appreciated. And any improvements 
>> in general are welcome. 
>>
>>
>>
>> funcname = (:get_help_configuration, :get_help_languages, 
>> :get_help_privacy, :get_help_tos, :get_application_rate_limit_status)
>> endpoint = ("help/configuration.json", "help/languages.json", 
>> "help/privacy.json",  "help/tos.json", "application/rate_limit_status.json")
>>
>> for (func, endp) in Dict(funcname, endpoint)
>> @eval begin function ($func)(; options=Dict{String, String}())
>> 
>> r = get_oauth(:($(string("https://api.twitter.com/1.1/";, 
>> $endp))), options)
>>
>> return r.status == 200 ? JSON.parse(r.data) : r
>>
>> end
>> end
>> end
>>
>> Thanks!
>>
>
>

Re: [julia-users] Metaprogramming: what's going on here/is there a better way?

[Jacob Quinn]

Can you just do


funcname = (:get_help_configuration, :get_help_languages,
:get_help_privacy, :get_help_tos, :get_application_rate_limit_status)
endpoint = ("help/configuration.json", "help/languages.json",
"help/privacy.json",  "help/tos.json", "application/rate_limit_status.json")

for (func, endp) in Dict(funcname, endpoint)
@eval begin function ($func)(; options=Dict{String, String}())

r = get_oauth(string("https://api.twitter.com/1.1/";, $endp),
options)

return r.status == 200 ? JSON.parse(r.data) : r

end
end
end


?

On Mon, Nov 17, 2014 at 9:35 PM, Randy Zwitch 
wrote:

> I've seen this type of function generation in other packages, and wanted
> to try it for myself. This file in Twitter.jl has 5 functions with the same
> overall structure:
>
> https://github.com/randyzwitch/Twitter.jl/blob/master/src/help.jl
>
>
> Here's what I ended up doing, which works, but I've got no idea why I had
> to write the string interpolation the way I did. I went through many
> permutations here, so if someone could explain why the `:($(string("
> https://api.twitter.com/1.1/";, $endp))` line needs to be written that way
> for string interpolation, it would be appreciated. And any improvements in
> general are welcome.
>
>
>
> funcname = (:get_help_configuration, :get_help_languages,
> :get_help_privacy, :get_help_tos, :get_application_rate_limit_status)
> endpoint = ("help/configuration.json", "help/languages.json",
> "help/privacy.json",  "help/tos.json", "application/rate_limit_status.json")
>
> for (func, endp) in Dict(funcname, endpoint)
> @eval begin function ($func)(; options=Dict{String, String}())
>
> r = get_oauth(:($(string("https://api.twitter.com/1.1/";,
> $endp))), options)
>
> return r.status == 200 ? JSON.parse(r.data) : r
>
> end
> end
> end
>
> Thanks!
>

[julia-users] Metaprogramming: what's going on here/is there a better way?

[Randy Zwitch]

I've seen this type of function generation in other packages, and wanted to 
try it for myself. This file in Twitter.jl has 5 functions with the same 
overall structure:

https://github.com/randyzwitch/Twitter.jl/blob/master/src/help.jl


Here's what I ended up doing, which works, but I've got no idea why I had 
to write the string interpolation the way I did. I went through many 
permutations here, so if someone could explain why the 
`:($(string("https://api.twitter.com/1.1/";, 
$endp))` line needs to be written that way for string interpolation, it 
would be appreciated. And any improvements in general are welcome. 



funcname = (:get_help_configuration, :get_help_languages, 
:get_help_privacy, :get_help_tos, :get_application_rate_limit_status)
endpoint = ("help/configuration.json", "help/languages.json", 
"help/privacy.json",  "help/tos.json", "application/rate_limit_status.json")

for (func, endp) in Dict(funcname, endpoint)
@eval begin function ($func)(; options=Dict{String, String}())

r = get_oauth(:($(string("https://api.twitter.com/1.1/";, $endp))), 
options)

return r.status == 200 ? JSON.parse(r.data) : r

end
end
end

Thanks!

Re: [julia-users] Concrete parametric types

[i . costigan]

Yeah realised that just after I posted my message :S

On Monday, 17 November 2014 13:07:42 UTC+11, Jameson wrote:
>
> <: is the subtype operator
> :: is the isa operator
> You can't (currently) express conditions of the form you want (except as 
> assertions in the constructor)
> On Sun, Nov 16, 2014 at 8:03 PM > wrote:
>
>> I've got a parametric type:
>>
>> immutable SplineInterpolator{N<:Integer} <: Interpolator1D end
>>
>> NB:
>>
>> abstract Interpolator
>> abstract Interpolator1D <: Interpolator
>>
>> Now, when I try to create the concrete type...
>>
>> SplineInterpolator{3}
>>
>> ...I get the following error message:
>>
>> ERROR: type: SplineInterpolator: in N, expected N<:Integer, got Int64
>>
>> NB that typeof(3) <: Integer returns true
>>
>> Why am I get this error message? Using Julia 0.3.2 on OS X 10.10
>>
>> Thanks
>>
>

Re: [julia-users] SymTridiagonal

[Eka Palamadai]

Thanks.
Fortunately (or unfortunately) i have to use julia, and will have to make 
noise
where something is confusing. 

On Monday, November 17, 2014 1:26:09 PM UTC-5, Tim Holy wrote:
>
> Your best bet, then, is to decide as quickly as possible whether you want 
> to 
> use Julia. If you start reading here: 
>
> http://docs.julialang.org/en/latest/manual/faq/#what-does-type-stable-mean 
>
> you'll maximize your chances of quickly discovering other things that will 
> likely annoy you :-). While only the section I directly linked to is 
> necessary 
> to understand why `ones(n,1)` can't return a Vector, you should also be 
> sure 
> to read the next 2 sections on DomainErrors and machine arithmetic, just 
> to 
> make sure you've drunk the full cup's worth of annoyance. 
>
> Then you'll be in a good position to make an informed judgment about 
> whether 
> you want to accept the hassles in exchange for the benefits the type 
> system 
> provides. 
>
> Best, 
> --Tim 
>
> On Monday, November 17, 2014 10:02:07 AM Eka Palamadai wrote: 
> > I don't know what matlab does. 
> > 
> > As a user, ones(n,1) and ones(n) both return me a vector, and it is 
> > confusing to find that ones(n,1) !=  ones(n). 
> > 
> > On Monday, November 17, 2014 12:53:25 PM UTC-5, Tim Holy wrote: 
> > > What's intuitive is very dependent upon your background. If you're 
> coming 
> > > from 
> > > Matlab, for example, "everything is a matrix" and Matlab does this 
> > > extraordinarily-confusing thing: 
> > > 
> > > ones(3,3,3) gives me a 3d array; 
> > > ones(3,3) gives me a 2d array; 
> > > but 
> > > 
> > > >> ones(3) 
> > > 
> > > ans = 
> > > 
> > >  1 1 1 
> > >  1 1 1 
> > >  1 1 1 
> > > 
> > > Why the heck did it give me a 2d matrix when I asked for a 
> 1-dimensional 
> > > vector of 1s? 
> > > 
> > > Julia is much more consistent: the dimensionality of the created 
> object is 
> > > equal to the number of indices you supply. If you ask for something 
> that's 
> > > 3x1, that's the size you'll get out; perforce, that is a 2d array. 
> > > 
> > > --Tim 
> > > 
> > > On Monday, November 17, 2014 09:41:10 AM Eka Palamadai wrote: 
> > > > "which I think is reasonable" is a subjective argument. 
> > > > It would be helpful if the type system is intuitive and 
> non-confusing to 
> > > > programmers. 
> > > > 
> > > > On Monday, November 17, 2014 12:24:58 PM UTC-5, Andreas Noack wrote: 
> > > > > Semantically, ones(n,1) creates a vector and not a matrix. 
> > > > > 
> > > > > I'd rather say that in MATLAB ones(n,1) creates a vector. 
> > > > > 
> > > > > This has been discussed many times on the list and in issues. In 
> > > > > particular, see the famous 
> > > 
> > > https://github.com/JuliaLang/julia/issues/4774 
> > > 
> > > > > . 
> > > > > 
> > > > > In Julia, Vector{T} and Matrix{T} are aliases for Array{T,1} and 
> > > > > Array{T,2} which I think is reasonable. The questions are to what 
> > > 
> > > extend a 
> > > 
> > > > > nx1 Matrix should work similarly to a Vector and a Vector should 
> work 
> > > > > similarly to a nx1 Matrix. That is the discussion in the issue 
> > > 
> > > mentioned, 
> > > 
> > > > > and it is actually more subtle than one would expect. 
> > > > > 
> > > > > 2014-11-17 12:04 GMT-05:00 Eka Palamadai  > > 
> > > > 
> > > 
> > > > >> Semantically, ones(n,1) creates a vector and not a matrix. 
> > > > >> Why is ones(n,1) different from ones(n)? 
> > > > >> The type system is very confusing and non-intuitive. 
> > > > >> 
> > > > >> On Sunday, November 16, 2014 7:28:28 PM UTC-5, Andreas Noack 
> wrote: 
> > > > >>> The input should be two Vectors, but your first argument is a 
> Matrix 
> > > > >>> 
> > > > >>> 2014-11-16 19:25 GMT-05:00 Eka Palamadai : 
> > > >  SymTridiagonal does not seem to work properly. 
> > > >  
> > > >  For e.g, the following snippet fails. 
> > > >  
> > > >  julia> n=10 ; 
> > > >  A=SymTridiagonal(2*ones(n,1), -1*ones(n-1)); 
> > > >  ERROR: `convert` has no method matching 
> > > >  convert(::Type{SymTridiagonal{T}}, 
> > > >  
> > > >  ::Array{Float64,2}, ::Array{Float64,1}) 
> > > >    
> > > >   in call at base.jl:34 
> > > >  
> > > >  Any thoughts? 
>
>

Re: [julia-users] Dimension Independent Array Access

[Tim Holy]

You can do a lot better by dispatching on the dimension of A. Something like 
this:

mygetindex{T}(A::AbstractArray{T,2}, L, Lcol) = A[L[1,Lcol], L[2,Lcol]]
mygetindex{T}(A::AbstractArray{T,3}, L, Lcol) = A[L[1,Lcol], L[2,Lcol], 
L[3,Lcol]]

Put your timing loops in a function so you take advantage of inference. For 
example:

function accesseach(A, L)
dummy = 0.0
for Lcol = 1:size(L, 2)
dummy = mygetindex(A, L, Lcol)
end
dummy
end

julia> L = Array(Int, 3, N^3);

julia> idx = 1; for k = 1:N, j = 1:N, i = 1:N
   L[1,idx] = i
   L[2,idx] = j
   L[3,idx] = k
   idx += 1
   end

julia> accesseach(A, L)
0.4109242495731802

julia> @time accesseach(A, L)
elapsed time: 0.006461321 seconds (13824 bytes allocated)
0.4109242495731802

As you can see, quite a bit faster.

--Tim

On Monday, November 17, 2014 12:01:08 PM Christoph Ortner wrote:
> I would appreciate advise how to best implement the following:
> 
> I have an  N^d  array  A, where  the dimension  d  depends on the
> application (d \in \{1, 2, 3\}). Somewhere else I have a list L which is a
>  d x M  array or integers corresponding to points/elements in this array,
> e.g. if
>  L[:, 3] == [5, 2, 8]
> then A would be N^3 and
> M[L[1,3], L[2,3], L[3,3]]
> would read
> A[5, 2, 8]
> 
> The difficulty is that I would like to read from A in a *fast*
> dimension-independent way. My only idea was to define a type and overload
> getindex, setindex! ; see below. If I tested this correctly, then I only
> loose a factor of two in terms of both speed and memory.
> 
> I am slightly worried that it is a non-standard access to a standard array.
>  + I'd love to get that factor 2 back. Hence, I'd like to know whether
> there are faster / more elegant alternatives, or just other ways of doing
> this?
> 
> 
> 
> module damod
> 
> 
> 
> export darray
> 
> immutable type darray
> 
> data
> 
> dim
> 
> end
> 
> 
> 
> function darray(A)
> 
> return darray(A, length(size(A)))
> 
> end
> 
> 
> 
> export getindex
> 
> function getindex(A::darray, ii)
> 
> if A.dim == 2
> 
> return A.data[ii[1], ii[2]]
> 
> elseif A.dim == 3
> 
> return A.data[ii[1], ii[2], ii[3]]
> 
> end
> 
> end
> 
> end
> 
> 
> 
> using damod
> 
> N = 100
> 
> a = darray(rand(N, N, N))
> 
> @timefor n = 1:N, m=1:N, k=1:N; dummy = a[[n,m,k]] end
> 
> @timefor n = 1:N, m=1:N, k=1:N; dummy = a.data[n,m,k] end
> 
> @timefor n = 1:N, m=1:N, k=1:N; dummy = a[[n,m,k]] end
> 
> @timefor n = 1:N, m=1:N, k=1:N; dummy = a.data[n,m,k] end
> 
> @timefor n = 1:N, m=1:N, k=1:N; dummy = a[[n,m,k]] end
> 
> @timefor n = 1:N, m=1:N, k=1:N; dummy = a.data[n,m,k] end
> 
> 
> 
> 
> 
> 
> 
> elapsed time: 0.470031905 seconds (128633244 bytes allocated, 11.90% gc
> time) elapsed time: 0.209358484 seconds (48565624 bytes allocated, 8.98% gc
> time) elapsed time: 0.42617227 seconds (128641396 bytes allocated, 16.12%
> gc time) elapsed time: 0.21529278 seconds (48565624 bytes allocated, 10.65%
> gc time) elapsed time: 0.457094657 seconds (128565624 bytes allocated,
> 14.37% gc time) elapsed time: 0.201969234 seconds (48565624 bytes
> allocated, 10.24% gc time)

[julia-users] Re: Help with metaprogramming

[Greg Plowman]

 Thanks Simon and Tim.

[julia-users] Dimension Independent Array Access

[Christoph Ortner]

I would appreciate advise how to best implement the following:

I have an  N^d  array  A, where  the dimension  d  depends on the 
application (d \in \{1, 2, 3\}). Somewhere else I have a list L which is a 
 d x M  array or integers corresponding to points/elements in this array, 
e.g. if 
 L[:, 3] == [5, 2, 8]
then A would be N^3 and 
M[L[1,3], L[2,3], L[3,3]] 
would read
A[5, 2, 8]

The difficulty is that I would like to read from A in a *fast* 
dimension-independent way. My only idea was to define a type and overload 
getindex, setindex! ; see below. If I tested this correctly, then I only 
loose a factor of two in terms of both speed and memory. 

I am slightly worried that it is a non-standard access to a standard array. 
 + I'd love to get that factor 2 back. Hence, I'd like to know whether 
there are faster / more elegant alternatives, or just other ways of doing 
this?



module damod

 

export darray

immutable type darray

data

dim

end

 

function darray(A)

return darray(A, length(size(A)))

end

 

export getindex

function getindex(A::darray, ii)

if A.dim == 2

return A.data[ii[1], ii[2]]

elseif A.dim == 3

return A.data[ii[1], ii[2], ii[3]]

end

end

end

 

using damod

N = 100

a = darray(rand(N, N, N))

@timefor n = 1:N, m=1:N, k=1:N; dummy = a[[n,m,k]] end

@timefor n = 1:N, m=1:N, k=1:N; dummy = a.data[n,m,k] end

@timefor n = 1:N, m=1:N, k=1:N; dummy = a[[n,m,k]] end

@timefor n = 1:N, m=1:N, k=1:N; dummy = a.data[n,m,k] end

@timefor n = 1:N, m=1:N, k=1:N; dummy = a[[n,m,k]] end

@timefor n = 1:N, m=1:N, k=1:N; dummy = a.data[n,m,k] end

 

 

 

elapsed time: 0.470031905 seconds (128633244 bytes allocated, 11.90% gc time)
elapsed time: 0.209358484 seconds (48565624 bytes allocated, 8.98% gc time)
elapsed time: 0.42617227 seconds (128641396 bytes allocated, 16.12% gc time)
elapsed time: 0.21529278 seconds (48565624 bytes allocated, 10.65% gc time)
elapsed time: 0.457094657 seconds (128565624 bytes allocated, 14.37% gc time)
elapsed time: 0.201969234 seconds (48565624 bytes allocated, 10.24% gc time)

Re: [julia-users] SymTridiagonal

[Jeff Waller]

As a user, ones(n,1) and ones(n) both return me a vector, and it is 
> confusing to find that ones(n,1) !=  ones(n)
>

I was where you are now a few months ago.  It's a learning cure thing, I 
think, because now I don't make that mistake
anymore or I'm like, oh yea, of course and change it 2 seconds later.  But 
to a new user it can be uninviting and not
easily solved with just more documentation.  

The question to me is what is the tradeoff?  For a semi-experienced user 
like me, it looks like Julia is trying to pick
a spot of convenience while trying to retain access to optimization.  The 
convenience part is the REPL, no requirement
for variable type declaration, no function type return declaration,  and on 
the other hand types and an options for variable
type declaration to allow the JIT to better optimize.  Your experience sits 
right where those to conflicting things are fighting
it out right now, and this wall-of-text doesn't help you out any.

I think this might be helped by having more  verbose error messages 
(optionally).

[julia-users] capture STDIN character by character, turning off REPL.

[Gustavo Goretkin]

I would like to capture STDIN character by character, without any 
characters going to the REPL. 

Right now if I have

function stdio_producer()
while true
c = read(STDIN,Char)
if c == '\e'
println("Done")
break
else
print(":"); print(c)
produce(c)
end
end
end

it only captures every other character.

Thanks,
Gustavo

Re: [julia-users] BinDeps: How to access include path?

[Milan Bouchet-Valat]

Le lundi 17 novembre 2014 à 08:42 -0500, Erik Schnetter a écrit :
> On Mon, Nov 17, 2014 at 3:15 AM, Milan Bouchet-Valat  
> wrote:
> > Le dimanche 16 novembre 2014 à 15:41 -0500, Erik Schnetter a écrit :
> >> I see.
> >>
> >> I was afraid that the C structs may change in between different
> >> versions of the library. If the structs are re-analyzed when the
> >> wrapper is installed, this would not be an issue.
> > Stable libraries shouldn't change their structs, except when releasing
> > new major versions. In that case even classic C programs will break, so
> > it's not really something to worry about specifically for Julia code.
> > Ideally your package should download a version series known to work, so
> > things don't break even a breaking version is released.
> 
> In this context, most library users will build from source. I would
> not expect binary compatibility. So C programs would not break.
Well, if they access the fields of the structs they may well break. But
anyway, you will get more or less as much stability when building from
source as when using binaries, as AFAIK libraries usually break API and
ABI at the same time.

> It is not possible to choose a particular version when installing e.g.
> via apt-get or homebrew.
As regards apt-get at least usually only one version is available for a
given distro, so if it's not the correct one you need to find another
method. I don't know about homebrew.

> > And if a new major version is released and the structs change, other
> > things are likely to change too, so that your code will break anyway.
> > That's what SOVERSION is used for usually.
> 
> I'm not choosing a particular soversion either. I don't think that is
> even supported with BinDeps?
Indeed, I don't think it is, but I'd argue in the long term some version
checking should be implemented.


Regards

> -erik
> 
> > My two cents
> >
> >
> >> On Sun, Nov 16, 2014 at 2:58 PM, Tim Holy  wrote:
> >> > The only person who needs to use Clang.jl is the package developer. Clang
> >> > writes *.jl files that save you the trouble of keyboarding all the julia
> >> > equivalents of the C structs. It also generates the ccall wrappers. You 
> >> > then
> >> > write your package on top of those generated files. Clang is therefore 
> >> > only a
> >> > dependency for the developer, not for the user. That said, if you've 
> >> > already
> >> > written all your types, Clang won't provide you with much benefit.
> >> >
> >> > Quite a few packages use Clang, but one I've been involved with is 
> >> > CUDArt.jl.
> >> >
> >> > --Tim
> >> >
> >> >
> >> > On Sunday, November 16, 2014 01:01:42 PM Erik Schnetter wrote:
> >> >> Thanks for all the pointers! Things are now working fine without
> >> >> wrapper functions but with 120 lines of immutable type declarations.
> >> >> Clang.jl sounds interesting, but would probably make hwloc.jl too
> >> >> difficult to use if it is a prerequisite. Let's see how often the
> >> >> structs of hwloc change with future versions.
> >> >>
> >> >> hwloc is a portable library that determines the number of cores (and
> >> >> many other properties) of the local machine: see
> >> >> .
> >> >>
> >> >> -erik
> >> >>
> >> >> On Sun, Nov 16, 2014 at 12:41 PM, Jake Bolewski 
> >> > wrote:
> >> >> > No need to flatten if everything is immutable.  This file has some
> >> >> > examples
> >> >> > of wrapping structs of structs
> >> >> > https://github.com/jakebolewski/LibGit2.jl/blob/cac78b5c03531b5afbcb0ae042
> >> >> > 538dd351527752/src/types.jl#L19.>
> >> >> > On Sunday, November 16, 2014 12:33:39 PM UTC-5, Tim Holy wrote:
> >> >> >> AFAIK no need to flatten.
> >> >> >>
> >> >> >> Since Isaiah didn't advertise it himself, I'll mention his Clang.jl
> >> >> >> package,
> >> >> >> which I've found to be a big help in such situations. It's just 
> >> >> >> possible
> >> >> >> you
> >> >> >> may not need any C glue code.
> >> >> >>
> >> >> >> --Tim
> >> >> >>
> >> >> >> On Sunday, November 16, 2014 12:15:50 PM Erik Schnetter wrote:
> >> >> >> > Thanks for the pointers on immutable types.
> >> >> >> >
> >> >> >> > Is it possible to access structs inside structs this way? That a
> >> >> >> > struct inside a struct, not a pointer inside a struct. Is an 
> >> >> >> > immutable
> >> >> >> > type again a bits type? Or do I need to flatten the structs to make
> >> >> >> > this work?
> >> >> >> >
> >> >> >> > -erik
> >> >> >> >
> >> >> >> > On Sun, Nov 16, 2014 at 11:16 AM, Isaiah Norton 
> >> >> >> > 
> >> >> >>
> >> >> >> wrote:
> >> >> >> > >> The library defines some C structs that are part of the API. My
> >> >> >> > >> current approach uses wrapper C functions to access struct 
> >> >> >> > >> elements.
> >> >> >> > >> Is there a better way?
> >> >> >> > >
> >> >> >> > > It depends how complicated are the structs. Structs can often be
> >> >> >> > > reflected
> >> >> >> > > as Julia types, as long as isbits(TypeName) == true, and accessed
> >> >> >> > > with
> >>

Re: [julia-users] SymTridiagonal

[Douglas Bates]

On Monday, November 17, 2014 12:02:07 PM UTC-6, Eka Palamadai wrote:
>
> I don't know what matlab does.
>
> As a user, ones(n,1) and ones(n) both return me a vector, and it is 
> confusing to find that ones(n,1) !=  ones(n).
>

As Andreas and Tim have tried to say, your claim that  "ones(n,1) and 
ones(n) both return me a vector" is incorrect.

julia> ones(3,1)
3x1 Array{Float64,2}:
 1.0
 1.0
 1.0

julia> ones(3)
3-element Array{Float64,1}:
 1.0
 1.0
 1.0

 The first is a matrix with 3 rows and 1 column.  The second is a vector. 
 That's why they are not equal.


> On Monday, November 17, 2014 12:53:25 PM UTC-5, Tim Holy wrote:
>>
>> What's intuitive is very dependent upon your background. If you're coming 
>> from 
>> Matlab, for example, "everything is a matrix" and Matlab does this 
>> extraordinarily-confusing thing: 
>>
>> ones(3,3,3) gives me a 3d array; 
>> ones(3,3) gives me a 2d array; 
>> but 
>>
>> >> ones(3) 
>>
>> ans = 
>>
>>  1 1 1 
>>  1 1 1 
>>  1 1 1 
>>
>> Why the heck did it give me a 2d matrix when I asked for a 1-dimensional 
>> vector of 1s? 
>>
>> Julia is much more consistent: the dimensionality of the created object 
>> is 
>> equal to the number of indices you supply. If you ask for something 
>> that's 
>> 3x1, that's the size you'll get out; perforce, that is a 2d array. 
>>
>> --Tim 
>>
>>
>>
>> On Monday, November 17, 2014 09:41:10 AM Eka Palamadai wrote: 
>> > "which I think is reasonable" is a subjective argument. 
>> > It would be helpful if the type system is intuitive and non-confusing 
>> to 
>> > programmers. 
>> > 
>> > On Monday, November 17, 2014 12:24:58 PM UTC-5, Andreas Noack wrote: 
>> > > Semantically, ones(n,1) creates a vector and not a matrix. 
>> > > 
>> > > I'd rather say that in MATLAB ones(n,1) creates a vector. 
>> > > 
>> > > This has been discussed many times on the list and in issues. In 
>> > > particular, see the famous 
>> https://github.com/JuliaLang/julia/issues/4774 
>> > > . 
>> > > 
>> > > In Julia, Vector{T} and Matrix{T} are aliases for Array{T,1} and 
>> > > Array{T,2} which I think is reasonable. The questions are to what 
>> extend a 
>> > > nx1 Matrix should work similarly to a Vector and a Vector should work 
>> > > similarly to a nx1 Matrix. That is the discussion in the issue 
>> mentioned, 
>> > > and it is actually more subtle than one would expect. 
>> > > 
>> > > 2014-11-17 12:04 GMT-05:00 Eka Palamadai > > 
>> > > 
>> > >> Semantically, ones(n,1) creates a vector and not a matrix. 
>> > >> Why is ones(n,1) different from ones(n)? 
>> > >> The type system is very confusing and non-intuitive. 
>> > >> 
>> > >> On Sunday, November 16, 2014 7:28:28 PM UTC-5, Andreas Noack wrote: 
>> > >>> The input should be two Vectors, but your first argument is a 
>> Matrix 
>> > >>> 
>> > >>> 2014-11-16 19:25 GMT-05:00 Eka Palamadai : 
>> >  SymTridiagonal does not seem to work properly. 
>> >  
>> >  For e.g, the following snippet fails. 
>> >  
>> >  julia> n=10 ; 
>> >  A=SymTridiagonal(2*ones(n,1), -1*ones(n-1)); 
>> >  ERROR: `convert` has no method matching 
>> >  convert(::Type{SymTridiagonal{T}}, 
>> >  
>> >  ::Array{Float64,2}, ::Array{Float64,1}) 
>> >    
>> >   in call at base.jl:34 
>> >  
>> >  Any thoughts? 
>>
>>

[julia-users] Re: try/catch by exception type

[Simon Danisch]

What about using multiple dispatch?
handle(::ExceptionType1, ::MyObject) = ...
handle(::ExceptionType2, ::MyObject) = ...
handle(::ExceptionType3, ::MyObject) = ...
handle(e::Exception, ::MyObject) = rethrow(e)
try 
 # Access a dict here 
catch e 
   handle(e, dict)
end 

Am Montag, 17. November 2014 15:49:24 UTC+1 schrieb Luthaf:
>
> Hello ! 
>
> Is there a way to catch an exception by type in Julia ? Coming from 
> python, I am very tempted to do this kind of things: 
> ``` 
> try 
>  # Access a dict here 
> catch e 
>  if isa(KeyError, e) 
>  # Handle the KeyError, as I know what to do in that case 
>  else 
> # Re-throw to upper level 
>  throw(e) 
> end 
> ``` 
> But that is a lot of boilerplate when used many times. 
>
> Maybe it is not the Julia way to express this kind of problem (handling 
> one type of exception, while letting the others go up), but I could not 
> find something about it. 
> I can not just remove all the exceptions as some of them are thrown by 
> Base. 
>
>
> Thank for yours answers ! 
> Guillaume 
>

Re: [julia-users] SymTridiagonal

[Tim Holy]

Your best bet, then, is to decide as quickly as possible whether you want to 
use Julia. If you start reading here:

http://docs.julialang.org/en/latest/manual/faq/#what-does-type-stable-mean

you'll maximize your chances of quickly discovering other things that will 
likely annoy you :-). While only the section I directly linked to is necessary 
to understand why `ones(n,1)` can't return a Vector, you should also be sure 
to read the next 2 sections on DomainErrors and machine arithmetic, just to 
make sure you've drunk the full cup's worth of annoyance.

Then you'll be in a good position to make an informed judgment about whether 
you want to accept the hassles in exchange for the benefits the type system 
provides.

Best,
--Tim

On Monday, November 17, 2014 10:02:07 AM Eka Palamadai wrote:
> I don't know what matlab does.
> 
> As a user, ones(n,1) and ones(n) both return me a vector, and it is
> confusing to find that ones(n,1) !=  ones(n).
> 
> On Monday, November 17, 2014 12:53:25 PM UTC-5, Tim Holy wrote:
> > What's intuitive is very dependent upon your background. If you're coming
> > from
> > Matlab, for example, "everything is a matrix" and Matlab does this
> > extraordinarily-confusing thing:
> > 
> > ones(3,3,3) gives me a 3d array;
> > ones(3,3) gives me a 2d array;
> > but
> > 
> > >> ones(3)
> > 
> > ans =
> > 
> >  1 1 1
> >  1 1 1
> >  1 1 1
> > 
> > Why the heck did it give me a 2d matrix when I asked for a 1-dimensional
> > vector of 1s?
> > 
> > Julia is much more consistent: the dimensionality of the created object is
> > equal to the number of indices you supply. If you ask for something that's
> > 3x1, that's the size you'll get out; perforce, that is a 2d array.
> > 
> > --Tim
> > 
> > On Monday, November 17, 2014 09:41:10 AM Eka Palamadai wrote:
> > > "which I think is reasonable" is a subjective argument.
> > > It would be helpful if the type system is intuitive and non-confusing to
> > > programmers.
> > > 
> > > On Monday, November 17, 2014 12:24:58 PM UTC-5, Andreas Noack wrote:
> > > > Semantically, ones(n,1) creates a vector and not a matrix.
> > > > 
> > > > I'd rather say that in MATLAB ones(n,1) creates a vector.
> > > > 
> > > > This has been discussed many times on the list and in issues. In
> > > > particular, see the famous
> > 
> > https://github.com/JuliaLang/julia/issues/4774
> > 
> > > > .
> > > > 
> > > > In Julia, Vector{T} and Matrix{T} are aliases for Array{T,1} and
> > > > Array{T,2} which I think is reasonable. The questions are to what
> > 
> > extend a
> > 
> > > > nx1 Matrix should work similarly to a Vector and a Vector should work
> > > > similarly to a nx1 Matrix. That is the discussion in the issue
> > 
> > mentioned,
> > 
> > > > and it is actually more subtle than one would expect.
> > > > 
> > > > 2014-11-17 12:04 GMT-05:00 Eka Palamadai  > 
> > >
> > 
> > > >> Semantically, ones(n,1) creates a vector and not a matrix.
> > > >> Why is ones(n,1) different from ones(n)?
> > > >> The type system is very confusing and non-intuitive.
> > > >> 
> > > >> On Sunday, November 16, 2014 7:28:28 PM UTC-5, Andreas Noack wrote:
> > > >>> The input should be two Vectors, but your first argument is a Matrix
> > > >>> 
> > > >>> 2014-11-16 19:25 GMT-05:00 Eka Palamadai :
> > >  SymTridiagonal does not seem to work properly.
> > >  
> > >  For e.g, the following snippet fails.
> > >  
> > >  julia> n=10 ;
> > >  A=SymTridiagonal(2*ones(n,1), -1*ones(n-1));
> > >  ERROR: `convert` has no method matching
> > >  convert(::Type{SymTridiagonal{T}},
> > >  
> > >  ::Array{Float64,2}, ::Array{Float64,1})
> > >   
> > >   in call at base.jl:34
> > >  
> > >  Any thoughts?

Re: [julia-users] SymTridiagonal

[Eka Palamadai]

I don't know what matlab does.

As a user, ones(n,1) and ones(n) both return me a vector, and it is 
confusing to find that ones(n,1) !=  ones(n).

On Monday, November 17, 2014 12:53:25 PM UTC-5, Tim Holy wrote:
>
> What's intuitive is very dependent upon your background. If you're coming 
> from 
> Matlab, for example, "everything is a matrix" and Matlab does this 
> extraordinarily-confusing thing: 
>
> ones(3,3,3) gives me a 3d array; 
> ones(3,3) gives me a 2d array; 
> but 
>
> >> ones(3) 
>
> ans = 
>
>  1 1 1 
>  1 1 1 
>  1 1 1 
>
> Why the heck did it give me a 2d matrix when I asked for a 1-dimensional 
> vector of 1s? 
>
> Julia is much more consistent: the dimensionality of the created object is 
> equal to the number of indices you supply. If you ask for something that's 
> 3x1, that's the size you'll get out; perforce, that is a 2d array. 
>
> --Tim 
>
>
>
> On Monday, November 17, 2014 09:41:10 AM Eka Palamadai wrote: 
> > "which I think is reasonable" is a subjective argument. 
> > It would be helpful if the type system is intuitive and non-confusing to 
> > programmers. 
> > 
> > On Monday, November 17, 2014 12:24:58 PM UTC-5, Andreas Noack wrote: 
> > > Semantically, ones(n,1) creates a vector and not a matrix. 
> > > 
> > > I'd rather say that in MATLAB ones(n,1) creates a vector. 
> > > 
> > > This has been discussed many times on the list and in issues. In 
> > > particular, see the famous 
> https://github.com/JuliaLang/julia/issues/4774 
> > > . 
> > > 
> > > In Julia, Vector{T} and Matrix{T} are aliases for Array{T,1} and 
> > > Array{T,2} which I think is reasonable. The questions are to what 
> extend a 
> > > nx1 Matrix should work similarly to a Vector and a Vector should work 
> > > similarly to a nx1 Matrix. That is the discussion in the issue 
> mentioned, 
> > > and it is actually more subtle than one would expect. 
> > > 
> > > 2014-11-17 12:04 GMT-05:00 Eka Palamadai  > 
> > > 
> > >> Semantically, ones(n,1) creates a vector and not a matrix. 
> > >> Why is ones(n,1) different from ones(n)? 
> > >> The type system is very confusing and non-intuitive. 
> > >> 
> > >> On Sunday, November 16, 2014 7:28:28 PM UTC-5, Andreas Noack wrote: 
> > >>> The input should be two Vectors, but your first argument is a Matrix 
> > >>> 
> > >>> 2014-11-16 19:25 GMT-05:00 Eka Palamadai : 
> >  SymTridiagonal does not seem to work properly. 
> >  
> >  For e.g, the following snippet fails. 
> >  
> >  julia> n=10 ; 
> >  A=SymTridiagonal(2*ones(n,1), -1*ones(n-1)); 
> >  ERROR: `convert` has no method matching 
> >  convert(::Type{SymTridiagonal{T}}, 
> >  
> >  ::Array{Float64,2}, ::Array{Float64,1}) 
> >    
> >   in call at base.jl:34 
> >  
> >  Any thoughts? 
>
>

Re: [julia-users] SymTridiagonal

[Tim Holy]

What's intuitive is very dependent upon your background. If you're coming from 
Matlab, for example, "everything is a matrix" and Matlab does this 
extraordinarily-confusing thing:

ones(3,3,3) gives me a 3d array;
ones(3,3) gives me a 2d array;
but

>> ones(3)

ans =

 1 1 1
 1 1 1
 1 1 1

Why the heck did it give me a 2d matrix when I asked for a 1-dimensional 
vector of 1s? 

Julia is much more consistent: the dimensionality of the created object is 
equal to the number of indices you supply. If you ask for something that's 
3x1, that's the size you'll get out; perforce, that is a 2d array.

--Tim



On Monday, November 17, 2014 09:41:10 AM Eka Palamadai wrote:
> "which I think is reasonable" is a subjective argument.
> It would be helpful if the type system is intuitive and non-confusing to
> programmers.
> 
> On Monday, November 17, 2014 12:24:58 PM UTC-5, Andreas Noack wrote:
> > Semantically, ones(n,1) creates a vector and not a matrix.
> > 
> > I'd rather say that in MATLAB ones(n,1) creates a vector.
> > 
> > This has been discussed many times on the list and in issues. In
> > particular, see the famous https://github.com/JuliaLang/julia/issues/4774
> > .
> > 
> > In Julia, Vector{T} and Matrix{T} are aliases for Array{T,1} and
> > Array{T,2} which I think is reasonable. The questions are to what extend a
> > nx1 Matrix should work similarly to a Vector and a Vector should work
> > similarly to a nx1 Matrix. That is the discussion in the issue mentioned,
> > and it is actually more subtle than one would expect.
> > 
> > 2014-11-17 12:04 GMT-05:00 Eka Palamadai >
> > 
> >> Semantically, ones(n,1) creates a vector and not a matrix.
> >> Why is ones(n,1) different from ones(n)?
> >> The type system is very confusing and non-intuitive.
> >> 
> >> On Sunday, November 16, 2014 7:28:28 PM UTC-5, Andreas Noack wrote:
> >>> The input should be two Vectors, but your first argument is a Matrix
> >>> 
> >>> 2014-11-16 19:25 GMT-05:00 Eka Palamadai :
>  SymTridiagonal does not seem to work properly.
>  
>  For e.g, the following snippet fails.
>  
>  julia> n=10 ;
>  A=SymTridiagonal(2*ones(n,1), -1*ones(n-1));
>  ERROR: `convert` has no method matching
>  convert(::Type{SymTridiagonal{T}},
>  
>  ::Array{Float64,2}, ::Array{Float64,1})
>   
>   in call at base.jl:34
>  
>  Any thoughts?

Re: [julia-users] SymTridiagonal

[Eka Palamadai]

"which I think is reasonable" is a subjective argument.
It would be helpful if the type system is intuitive and non-confusing to 
programmers.

On Monday, November 17, 2014 12:24:58 PM UTC-5, Andreas Noack wrote:
>
> Semantically, ones(n,1) creates a vector and not a matrix.
>
> I'd rather say that in MATLAB ones(n,1) creates a vector.
>
> This has been discussed many times on the list and in issues. In 
> particular, see the famous https://github.com/JuliaLang/julia/issues/4774
> . 
>
> In Julia, Vector{T} and Matrix{T} are aliases for Array{T,1} and 
> Array{T,2} which I think is reasonable. The questions are to what extend a 
> nx1 Matrix should work similarly to a Vector and a Vector should work 
> similarly to a nx1 Matrix. That is the discussion in the issue mentioned, 
> and it is actually more subtle than one would expect.
>
> 2014-11-17 12:04 GMT-05:00 Eka Palamadai >
> :
>
>> Semantically, ones(n,1) creates a vector and not a matrix.
>> Why is ones(n,1) different from ones(n)?
>> The type system is very confusing and non-intuitive.
>>
>> On Sunday, November 16, 2014 7:28:28 PM UTC-5, Andreas Noack wrote:
>>>
>>> The input should be two Vectors, but your first argument is a Matrix
>>>
>>> 2014-11-16 19:25 GMT-05:00 Eka Palamadai :
>>>
 SymTridiagonal does not seem to work properly.

 For e.g, the following snippet fails.

 julia> n=10 ; 
 A=SymTridiagonal(2*ones(n,1), -1*ones(n-1));
 ERROR: `convert` has no method matching convert(::Type{SymTridiagonal{T}}, 
 ::Array{Float64,2}, ::Array{Float64,1})
  in call at base.jl:34

 Any thoughts?

>>>
>>>
>

[julia-users] Re: Arrayfire and Julia

[Test This]

Happy to see thus reaction from a core julia developer. Hope julia makes 
parallel programming on CPUs and GPUs easier. 

Re: [julia-users] SymTridiagonal

[Andreas Noack]

>
> Semantically, ones(n,1) creates a vector and not a matrix.

I'd rather say that in MATLAB ones(n,1) creates a vector.

This has been discussed many times on the list and in issues. In
particular, see the famous https://github.com/JuliaLang/julia/issues/4774.

In Julia, Vector{T} and Matrix{T} are aliases for Array{T,1} and Array{T,2}
which I think is reasonable. The questions are to what extend a nx1 Matrix
should work similarly to a Vector and a Vector should work similarly to a
nx1 Matrix. That is the discussion in the issue mentioned, and it is
actually more subtle than one would expect.

2014-11-17 12:04 GMT-05:00 Eka Palamadai :

> Semantically, ones(n,1) creates a vector and not a matrix.
> Why is ones(n,1) different from ones(n)?
> The type system is very confusing and non-intuitive.
>
> On Sunday, November 16, 2014 7:28:28 PM UTC-5, Andreas Noack wrote:
>>
>> The input should be two Vectors, but your first argument is a Matrix
>>
>> 2014-11-16 19:25 GMT-05:00 Eka Palamadai :
>>
>>> SymTridiagonal does not seem to work properly.
>>>
>>> For e.g, the following snippet fails.
>>>
>>> julia> n=10 ;
>>> A=SymTridiagonal(2*ones(n,1), -1*ones(n-1));
>>> ERROR: `convert` has no method matching convert(::Type{SymTridiagonal{T}},
>>> ::Array{Float64,2}, ::Array{Float64,1})
>>>  in call at base.jl:34
>>>
>>> Any thoughts?
>>>
>>
>>

Re: [julia-users] SymTridiagonal

[Eka Palamadai]

Semantically, ones(n,1) creates a vector and not a matrix.
Why is ones(n,1) different from ones(n)?
The type system is very confusing and non-intuitive.

On Sunday, November 16, 2014 7:28:28 PM UTC-5, Andreas Noack wrote:
>
> The input should be two Vectors, but your first argument is a Matrix
>
> 2014-11-16 19:25 GMT-05:00 Eka Palamadai >
> :
>
>> SymTridiagonal does not seem to work properly.
>>
>> For e.g, the following snippet fails.
>>
>> julia> n=10 ; 
>> A=SymTridiagonal(2*ones(n,1), -1*ones(n-1));
>> ERROR: `convert` has no method matching 
>> convert(::Type{SymTridiagonal{T}}, ::Array{Float64,2}, ::Array{Float64,1})
>>  in call at base.jl:34
>>
>> Any thoughts?
>>
>
>

Re: [julia-users] help() doesn't work in REPL in julia-0.4.0-1439 from julianightlies PPA

[Omar Antolín Camarena]

Well, as of julia-0.4.0-1454~ubuntu14.04.1 It still happens. By the way, I 
was wrong about which package to blame, it's not julia-doc but  julia 
itself (julia-doc contains the manual and other documentation, but the 
basic help strings the REPL help() functions prints are actually in the 
julia package).

I'm pretty sure this is a .deb package problem and not an issue with Julia 
itself, so I'll tell the PPA maintainer.

On Sunday, November 16, 2014 10:21:01 PM UTC-5, Isaiah wrote:
>
> If this is not fixed now, please file an issue.
>
> On Thu, Nov 13, 2014 at 5:30 PM, Omar Antolín Camarena <
> omar.a...@gmail.com > wrote:
>
>> The julianightlies PPA at some point moved the documentation into a 
>> separate package, julia-doc, that seems to have a slight problem:
>>
>> julia> help(help)
>> ERROR: could not open file /usr/share/doc/julia/helpdb.jl
>>  in include at ./boot.jl:242
>>  in include_from_node1 at ./loading.jl:128
>>  in evalfile at loading.jl:168 (repeats 2 times)
>>  in init_help at help.jl:39
>>  in help at help.jl:89
>>  in help at help.jl:166
>>  in help at help.jl:181
>>
>> My guess is that the problem is that, as is common in Debian packages, 
>> the files in the julia-doc package are gzipped and the help() function 
>> doesn't expect that.
>> Indeed, after running
>>
>> sudo gunzip /usr/share/doc/julia/helpdb.jl.gz
>>
>> the help() function seems to work in the REPL again.
>>
>>
>

Re: [julia-users] try/catch by exception type

[John Myles White]

Yes, we are civilized after all.

 -- John

On Nov 17, 2014, at 2:53 PM, Luthaf  wrote:

> Ok, thank you !
> 
> So the way to go is "better ask for permission than for forgiveness" !
> 
> John Myles White a écrit :
>> 
>> I don't believe this is possible in Julia right now.
>> 
>> Which is ok in this case, since working with a KeyError is a very un-Julian 
>> way to check for key existence. You'll want to use haskey instead.
>> 
>>  -- John
>> 
>> On Nov 17, 2014, at 2:49 PM, Luthaf  wrote:
>> 
>>> Hello !
>>> 
>>> Is there a way to catch an exception by type in Julia ? Coming from python, 
>>> I am very tempted to do this kind of things:
>>> ```
>>> try
>>># Access a dict here
>>> catch e
>>>if isa(KeyError, e)
>>># Handle the KeyError, as I know what to do in that case
>>>else
>>> # Re-throw to upper level
>>>throw(e)
>>> end
>>> ```
>>> But that is a lot of boilerplate when used many times.
>>> 
>>> Maybe it is not the Julia way to express this kind of problem (handling one 
>>> type of exception, while letting the others go up), but I could not find 
>>> something about it.
>>> I can not just remove all the exceptions as some of them are thrown by Base.
>>> 
>>> 
>>> Thank for yours answers !
>>> Guillaume
>> 

Re: [julia-users] try/catch by exception type

[Luthaf]

Ok, thank you !

So the way to go is "better ask for permission than for forgiveness" !

John Myles White a écrit :

I don't believe this is possible in Julia right now.

Which is ok in this case, since working with a KeyError is a very un-Julian way 
to check for key existence. You'll want to use haskey instead.

  -- John

On Nov 17, 2014, at 2:49 PM, Luthaf  wrote:


Hello !

Is there a way to catch an exception by type in Julia ? Coming from python, I 
am very tempted to do this kind of things:
```
try
# Access a dict here
catch e
if isa(KeyError, e)
# Handle the KeyError, as I know what to do in that case
else
# Re-throw to upper level
throw(e)
end
```
But that is a lot of boilerplate when used many times.

Maybe it is not the Julia way to express this kind of problem (handling one 
type of exception, while letting the others go up), but I could not find 
something about it.
I can not just remove all the exceptions as some of them are thrown by Base.


Thank for yours answers !
Guillaume

Re: [julia-users] try/catch by exception type

[John Myles White]

I don't believe this is possible in Julia right now.

Which is ok in this case, since working with a KeyError is a very un-Julian way 
to check for key existence. You'll want to use haskey instead.

 -- John

On Nov 17, 2014, at 2:49 PM, Luthaf  wrote:

> Hello !
> 
> Is there a way to catch an exception by type in Julia ? Coming from python, I 
> am very tempted to do this kind of things:
> ```
> try
># Access a dict here
> catch e
>if isa(KeyError, e)
># Handle the KeyError, as I know what to do in that case
>else
> # Re-throw to upper level
>throw(e)
> end
> ```
> But that is a lot of boilerplate when used many times.
> 
> Maybe it is not the Julia way to express this kind of problem (handling one 
> type of exception, while letting the others go up), but I could not find 
> something about it.
> I can not just remove all the exceptions as some of them are thrown by Base.
> 
> 
> Thank for yours answers !
> Guillaume

Re: [julia-users] try/catch by exception type

[Jacob Quinn]

Check out the somewhat lengthy, but informative thread on developing
additional functionality with regards to exception handling.
https://github.com/JuliaLang/julia/issues/7026

-Jacob

On Mon, Nov 17, 2014 at 9:49 AM, Luthaf  wrote:

> Hello !
>
> Is there a way to catch an exception by type in Julia ? Coming from
> python, I am very tempted to do this kind of things:
> ```
> try
> # Access a dict here
> catch e
> if isa(KeyError, e)
> # Handle the KeyError, as I know what to do in that case
> else
> # Re-throw to upper level
> throw(e)
> end
> ```
> But that is a lot of boilerplate when used many times.
>
> Maybe it is not the Julia way to express this kind of problem (handling
> one type of exception, while letting the others go up), but I could not
> find something about it.
> I can not just remove all the exceptions as some of them are thrown by
> Base.
>
>
> Thank for yours answers !
> Guillaume
>

[julia-users] Re: How should I structure my code?

[yfractal]

macro need_m()
:(m * 20)
end

function algoX()
m = 10
@need_m
end

algoX()

# 200



I think you can create two similar macro to solve your problem.
But i think this is bad practice.

I think you should create some code without a scope, as I know, the macro 
can do such thing.

Justas _於 2014年11月17日星期一UTC+8上午4時25分26秒寫道：
>
> Lets say I have this kind of code. How could I access variable M in 
> compute() function? 
> function algoX(data)
>   M,N = size(data)
>   param = 20
>
>   computeSomething()
> end
>
> export
> function computeSomething()
>   a = compute()
> end
>
> function compute()
>   # Needs variable M
>   M * param
> end
>
> I do not want to nest all functions, because then I wont be able to export 
> them for testing. Also I do not want to pass variable M to 
> computeSomething() and then pass to compute(). What should I do?
>
>
>

[julia-users] try/catch by exception type

[Luthaf]

Hello !

Is there a way to catch an exception by type in Julia ? Coming from 
python, I am very tempted to do this kind of things:

```
try
# Access a dict here
catch e
if isa(KeyError, e)
# Handle the KeyError, as I know what to do in that case
else
# Re-throw to upper level
throw(e)
end
```
But that is a lot of boilerplate when used many times.

Maybe it is not the Julia way to express this kind of problem (handling 
one type of exception, while letting the others go up), but I could not 
find something about it.

I can not just remove all the exceptions as some of them are thrown by Base.


Thank for yours answers !
Guillaume

Re: [julia-users] BinDeps: How to access include path?

[Erik Schnetter]

On Mon, Nov 17, 2014 at 3:15 AM, Milan Bouchet-Valat  wrote:
> Le dimanche 16 novembre 2014 à 15:41 -0500, Erik Schnetter a écrit :
>> I see.
>>
>> I was afraid that the C structs may change in between different
>> versions of the library. If the structs are re-analyzed when the
>> wrapper is installed, this would not be an issue.
> Stable libraries shouldn't change their structs, except when releasing
> new major versions. In that case even classic C programs will break, so
> it's not really something to worry about specifically for Julia code.
> Ideally your package should download a version series known to work, so
> things don't break even a breaking version is released.

In this context, most library users will build from source. I would
not expect binary compatibility. So C programs would not break.

It is not possible to choose a particular version when installing e.g.
via apt-get or homebrew.

> And if a new major version is released and the structs change, other
> things are likely to change too, so that your code will break anyway.
> That's what SOVERSION is used for usually.

I'm not choosing a particular soversion either. I don't think that is
even supported with BinDeps?

-erik

> My two cents
>
>
>> On Sun, Nov 16, 2014 at 2:58 PM, Tim Holy  wrote:
>> > The only person who needs to use Clang.jl is the package developer. Clang
>> > writes *.jl files that save you the trouble of keyboarding all the julia
>> > equivalents of the C structs. It also generates the ccall wrappers. You 
>> > then
>> > write your package on top of those generated files. Clang is therefore 
>> > only a
>> > dependency for the developer, not for the user. That said, if you've 
>> > already
>> > written all your types, Clang won't provide you with much benefit.
>> >
>> > Quite a few packages use Clang, but one I've been involved with is 
>> > CUDArt.jl.
>> >
>> > --Tim
>> >
>> >
>> > On Sunday, November 16, 2014 01:01:42 PM Erik Schnetter wrote:
>> >> Thanks for all the pointers! Things are now working fine without
>> >> wrapper functions but with 120 lines of immutable type declarations.
>> >> Clang.jl sounds interesting, but would probably make hwloc.jl too
>> >> difficult to use if it is a prerequisite. Let's see how often the
>> >> structs of hwloc change with future versions.
>> >>
>> >> hwloc is a portable library that determines the number of cores (and
>> >> many other properties) of the local machine: see
>> >> .
>> >>
>> >> -erik
>> >>
>> >> On Sun, Nov 16, 2014 at 12:41 PM, Jake Bolewski 
>> > wrote:
>> >> > No need to flatten if everything is immutable.  This file has some
>> >> > examples
>> >> > of wrapping structs of structs
>> >> > https://github.com/jakebolewski/LibGit2.jl/blob/cac78b5c03531b5afbcb0ae042
>> >> > 538dd351527752/src/types.jl#L19.>
>> >> > On Sunday, November 16, 2014 12:33:39 PM UTC-5, Tim Holy wrote:
>> >> >> AFAIK no need to flatten.
>> >> >>
>> >> >> Since Isaiah didn't advertise it himself, I'll mention his Clang.jl
>> >> >> package,
>> >> >> which I've found to be a big help in such situations. It's just 
>> >> >> possible
>> >> >> you
>> >> >> may not need any C glue code.
>> >> >>
>> >> >> --Tim
>> >> >>
>> >> >> On Sunday, November 16, 2014 12:15:50 PM Erik Schnetter wrote:
>> >> >> > Thanks for the pointers on immutable types.
>> >> >> >
>> >> >> > Is it possible to access structs inside structs this way? That a
>> >> >> > struct inside a struct, not a pointer inside a struct. Is an 
>> >> >> > immutable
>> >> >> > type again a bits type? Or do I need to flatten the structs to make
>> >> >> > this work?
>> >> >> >
>> >> >> > -erik
>> >> >> >
>> >> >> > On Sun, Nov 16, 2014 at 11:16 AM, Isaiah Norton 
>> >> >>
>> >> >> wrote:
>> >> >> > >> The library defines some C structs that are part of the API. My
>> >> >> > >> current approach uses wrapper C functions to access struct 
>> >> >> > >> elements.
>> >> >> > >> Is there a better way?
>> >> >> > >
>> >> >> > > It depends how complicated are the structs. Structs can often be
>> >> >> > > reflected
>> >> >> > > as Julia types, as long as isbits(TypeName) == true, and accessed
>> >> >> > > with
>> >> >> > > unsafe_load (see for example PyCall's definitions of PyObject_*).
>> >> >> > > Some
>> >> >> > > tricky spots include fixed-size arrays and unions (strictly 
>> >> >> > > speaking
>> >> >> > > you
>> >> >> > > can make an aggregate element having the maximal size in the union,
>> >> >> > > and
>> >> >> > > then do bitshifts manually. but there is no automatic support).
>> >> >> > >
>> >> >> > > There is also the StrPack.jl package, which calculates the
>> >> >> > > appropriate
>> >> >> > > memory layout for a given struct and provides
>> >> >> > > serialization/deserialization.>
>> >> >> > >
>> >> >> > >> I thus I need to build this wrapper file as well. I created a
>> >> >> > >> SimpleBuild rule for this. However, I need to know the path where
>> >> >> > >> BinDeps installed (or found) the hea

Re: [julia-users] Re: How should I structure my code?

[Milan Bouchet-Valat]

Le dimanche 16 novembre 2014 à 15:40 -0800, Justas _ a écrit :
> I totally agree that it is good to pass variable M to compute(). But
> to do that, I need to pass M to computeSomething(), which does not use
> M at all, and then pass it down to compute. I think it is the best to
> use Type and pass it as a holder of M and param.
> 
I'm not sure what you mean in your last sentence, but I think it's good
practice to pass M to computeSomething() and then to compute(), so that
it's clear what variables affect the behavior of these functions. If you
don't respect this hierarchical organization, you quickly end up not
knowing which global variables affect which code, and everything becomes
very confusing.

> Also I tried this
> 
>   export foo
>   function foo(f)
> function bar(b)
>   return b * 2
> end
> 
> 
> return f
>   end
> 
> 
> 
> 
> 
> and I could not access bar(). Is this snippet correct?
>From where did you try to access it?


Regards

Re: [julia-users] BinDeps: How to access include path?

[Milan Bouchet-Valat]

Le dimanche 16 novembre 2014 à 15:41 -0500, Erik Schnetter a écrit :
> I see.
> 
> I was afraid that the C structs may change in between different
> versions of the library. If the structs are re-analyzed when the
> wrapper is installed, this would not be an issue.
Stable libraries shouldn't change their structs, except when releasing
new major versions. In that case even classic C programs will break, so
it's not really something to worry about specifically for Julia code.
Ideally your package should download a version series known to work, so
things don't break even a breaking version is released.

And if a new major version is released and the structs change, other
things are likely to change too, so that your code will break anyway.
That's what SOVERSION is used for usually.

My two cents


> On Sun, Nov 16, 2014 at 2:58 PM, Tim Holy  wrote:
> > The only person who needs to use Clang.jl is the package developer. Clang
> > writes *.jl files that save you the trouble of keyboarding all the julia
> > equivalents of the C structs. It also generates the ccall wrappers. You then
> > write your package on top of those generated files. Clang is therefore only 
> > a
> > dependency for the developer, not for the user. That said, if you've already
> > written all your types, Clang won't provide you with much benefit.
> >
> > Quite a few packages use Clang, but one I've been involved with is 
> > CUDArt.jl.
> >
> > --Tim
> >
> >
> > On Sunday, November 16, 2014 01:01:42 PM Erik Schnetter wrote:
> >> Thanks for all the pointers! Things are now working fine without
> >> wrapper functions but with 120 lines of immutable type declarations.
> >> Clang.jl sounds interesting, but would probably make hwloc.jl too
> >> difficult to use if it is a prerequisite. Let's see how often the
> >> structs of hwloc change with future versions.
> >>
> >> hwloc is a portable library that determines the number of cores (and
> >> many other properties) of the local machine: see
> >> .
> >>
> >> -erik
> >>
> >> On Sun, Nov 16, 2014 at 12:41 PM, Jake Bolewski 
> > wrote:
> >> > No need to flatten if everything is immutable.  This file has some
> >> > examples
> >> > of wrapping structs of structs
> >> > https://github.com/jakebolewski/LibGit2.jl/blob/cac78b5c03531b5afbcb0ae042
> >> > 538dd351527752/src/types.jl#L19.>
> >> > On Sunday, November 16, 2014 12:33:39 PM UTC-5, Tim Holy wrote:
> >> >> AFAIK no need to flatten.
> >> >>
> >> >> Since Isaiah didn't advertise it himself, I'll mention his Clang.jl
> >> >> package,
> >> >> which I've found to be a big help in such situations. It's just possible
> >> >> you
> >> >> may not need any C glue code.
> >> >>
> >> >> --Tim
> >> >>
> >> >> On Sunday, November 16, 2014 12:15:50 PM Erik Schnetter wrote:
> >> >> > Thanks for the pointers on immutable types.
> >> >> >
> >> >> > Is it possible to access structs inside structs this way? That a
> >> >> > struct inside a struct, not a pointer inside a struct. Is an immutable
> >> >> > type again a bits type? Or do I need to flatten the structs to make
> >> >> > this work?
> >> >> >
> >> >> > -erik
> >> >> >
> >> >> > On Sun, Nov 16, 2014 at 11:16 AM, Isaiah Norton 
> >> >>
> >> >> wrote:
> >> >> > >> The library defines some C structs that are part of the API. My
> >> >> > >> current approach uses wrapper C functions to access struct 
> >> >> > >> elements.
> >> >> > >> Is there a better way?
> >> >> > >
> >> >> > > It depends how complicated are the structs. Structs can often be
> >> >> > > reflected
> >> >> > > as Julia types, as long as isbits(TypeName) == true, and accessed
> >> >> > > with
> >> >> > > unsafe_load (see for example PyCall's definitions of PyObject_*).
> >> >> > > Some
> >> >> > > tricky spots include fixed-size arrays and unions (strictly speaking
> >> >> > > you
> >> >> > > can make an aggregate element having the maximal size in the union,
> >> >> > > and
> >> >> > > then do bitshifts manually. but there is no automatic support).
> >> >> > >
> >> >> > > There is also the StrPack.jl package, which calculates the
> >> >> > > appropriate
> >> >> > > memory layout for a given struct and provides
> >> >> > > serialization/deserialization.>
> >> >> > >
> >> >> > >> I thus I need to build this wrapper file as well. I created a
> >> >> > >> SimpleBuild rule for this. However, I need to know the path where
> >> >> > >> BinDeps installed (or found) the header files so that I can compile
> >> >> > >> this file. How do I access this information?
> >> >> > >
> >> >> > > This is going to be package-manager and build-tool specific, and I
> >> >> > > don't
> >> >> > > know if there is any abstraction/helper for includes in BinDeps yet.
> >> >> > >
> >> >> > > On Sun, Nov 16, 2014 at 10:09 AM, Erik Schnetter 
> >> >> > >
> >> >> > > wrote:
> >> >> > >> I want to wrap a library (hwloc) for Julia. This is working fine.
> >> >> > >>
> >> >> > >> The library defines some C structs that are part of the API. My
>