[julia-users] Assigning a field in Python via reference

[Christoph Ortner]

I am trying to 

(1) create an array in Julia: 
X = rand(3,10)   


(2) convert it to a PyArray (no copy) : 
Xpy = PyArray(X)


(3) then assign this to a field of an object:   
pyobj["X"] = Xpy   orpyobj["X"] = Xpy.o or 

The aim is, when I modify X, then the data in pyobj[:X] should be modified 
as well. The way described above does not work. 

Is there a way to achieve this or is there a fundamental limitation?

Thank you.
 

[julia-users] Preferred MIME type for Julia

[Fengyang Wang]

What is the standard MIME type for Julia code?

My reading of the MIME standard leads to me think 
application/x-julia

is the accurate choice. However, I could only find few results on Google, 
and Julia doesn't currently recognize this as a text MIME.

Re: [julia-users] Implicit differentiation in Julia?

[Mathieu Taschereau-Dumouchel]

This is fantastic! Thank you very much.

On Thu, Sep 8, 2016 at 7:49 PM, Steven G. Johnson 
wrote:

>
>
> On Thursday, September 8, 2016 at 7:27:36 PM UTC-4, Steven G. Johnson
> wrote:
>>
>>
>>
>> On Thursday, September 8, 2016 at 4:18:42 PM UTC-4, Mathieu
>> Taschereau-Dumouchel wrote:
>>>
>>> Not quite because the x_i on the right-hand side also depend on a_j
>>
>>
>> If you just take the partial derivative of both sides with respect
>> to aₖ (for k = 1..N), you will see that (given the solution vector x) you
>> just get a *linear* system of equations for the gradient:
>>
>>∂xⱼ/∂aₖ - b aⱼ ∑ᵢ (xᵢ)ᵇ⁻¹ ∂xᵢ/∂aₖ = δⱼₖ ∑ᵢ (xᵢ)ᵇ
>>
>> Notice that the right-hand side is proportional to the identity matrix (δ
>> denotes the Kronecker delta).   So, just form the matrix corresponding to
>> the linear operator multiplying ∇ₐx on the left-hand side, and your
>> Jacobian matrix ∇ₐx will then be the inverse of this matrix multiplied by
>> ∑ᵢ (xᵢ)ᵇ.
>>
>
> More explicitly, if a and x are Julia 1d arrays, then your Jacobian
> matrix is (modulo algebra errors on my part):
>
>  ∇ₐx = inv(I - b * a * (x.').^(b-1)) * sum(x.^b)
>
>
> Note also that the matrix you are inverting is actually a rank-1 update to
> the identity matrix I, so you can compute ∇ₐx *much* more quickly (if
> needed) using the Woodbury
>  formula.
>

[julia-users] [ANN] Deconvolution.jl: library for deconvolution of digital signals

[Mosè Giordano]

Hi all,

I'm pleased to announce a new package: Deconvolution.jl 
.  It is part of the JuliaDSP 
 project and aims at providing a set of tools 
to deconvolve digital signals.  The package is released under the terms of 
MIT "Expat" License  and its documentation is available at 
http://deconvolutionjl.readthedocs.io/. 


Currently the package provides only one method, the Wiener deconvolution 
, but more will 
hopefully come in the future.  I will maintain the package (take care of 
bug reports and pull requests), but I do not plan to develop it because 
this is not my field of interest.  If someone is interested in taking over 
the package, please open an issue on GitHub.

Happy deconvolution,
Mosè

Re: [julia-users] Implicit differentiation in Julia?

[Steven G. Johnson]

On Thursday, September 8, 2016 at 7:27:36 PM UTC-4, Steven G. Johnson wrote:
>
>
>
> On Thursday, September 8, 2016 at 4:18:42 PM UTC-4, Mathieu 
> Taschereau-Dumouchel wrote:
>>
>> Not quite because the x_i on the right-hand side also depend on a_j
>
>
> If you just take the partial derivative of both sides with respect 
> to aₖ (for k = 1..N), you will see that (given the solution vector x) you 
> just get a *linear* system of equations for the gradient:
>
>∂xⱼ/∂aₖ - b aⱼ ∑ᵢ (xᵢ)ᵇ⁻¹ ∂xᵢ/∂aₖ = δⱼₖ ∑ᵢ (xᵢ)ᵇ
>
> Notice that the right-hand side is proportional to the identity matrix (δ 
> denotes the Kronecker delta).   So, just form the matrix corresponding to 
> the linear operator multiplying ∇ₐx on the left-hand side, and your 
> Jacobian matrix ∇ₐx will then be the inverse of this matrix multiplied by 
> ∑ᵢ (xᵢ)ᵇ.
>

More explicitly, if a and x are Julia 1d arrays, then your Jacobian matrix 
is (modulo algebra errors on my part):

 ∇ₐx = inv(I - b * a * (x.').^(b-1)) * sum(x.^b)


Note also that the matrix you are inverting is actually a rank-1 update to 
the identity matrix I, so you can compute ∇ₐx *much* more quickly (if 
needed) using the Woodbury 
 formula. 

[julia-users] Re: There is very little overhead calling Julia from C++

[Steven G. Johnson]

Except that in your example code, you aren't calling the Julia code through 
a raw C function pointer.   You are calling it through jl_call0, which 
*does* have a fair amount of overhead (which you aren't seeing because the 
function execution is expensive enough to hide the call overhead).

To get it down to C overhead, you need to generate a C function pointer 
with cfunction (or by using the undocumented Base.@ccallable macro, see 
#9400).  This is how we create low-overhead callback functions to pass to 
C, but you can do it from the C side as well. 
 See http://julialang.org/blog/2013/05/callback

[julia-users] Re: There is very little overhead calling Julia from C++

[K leo]

Stefan Karpinski's words (in 
https://groups.google.com/forum/#!searchin/julia-users/C$2B$2B$20call$20julia$20struct%7Csort:relevance/julia-users/KTMlJ15vzVA/2W3qOis7Kk8J)
 
explained the results:

There's also the issue that we can and do turn Julia functions into 
> C-callable function pointers that can be invoked from C as if they were C 
> function pointers – this currently has zero overhead and if the Julia 
> function is fast, then calling it from C will also be fast. If these 
> require interpreter state, then that would need to be a function call 
> argument to every C-callable function, which is at odds with many C APIs 
> (although good libraries do allow for a void* data argument). Maybe this 
> could be made to work, but my suspicion is that it would introduce too much 
> overhead and destroy our current ability to do zero-cost two-way interop 
> with C.


On Thursday, September 8, 2016 at 12:43:30 PM UTC+8, K leo wrote:
>
> I just did a test of calling a Julia function 100,000 times, both from 
> Julia and from C++.  The execution times are very close.  The results are 
> as follows.  This is on Xubuntu 16.04 64bits.
>
> ***Julia   **
>   | | |_| | | | (_| |  |  Version 0.5.0-rc3+0 (2016-08-22 23:43 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-unknown-linux-gnu
>
> julia> include("speedTest.jl")
> speedTest
>
> julia> speedTest.TestLoop()
> elapsed time: 3.21365718 seconds
> 3.21365718
>
>
> ***   C++***
> > g++ -o test -fPIC -I$JULIA_DIR/include/julia test3.cpp -L$JULIA_DIR/lib/ 
> -L$JULIA_DIR/lib/julia -lLLVM-3.7.1 -ljulia 
> $JULIA_DIR/lib/julia/libstdc++.so.6
> > ./test
> 3.22423
>
> The codes are shown below:
> Julai:
>
>> module speedTest
>>
>>
>>> function TestFunc()
>>
>> f=0.
>>
>> for i=1:1
>>
>> f += Float64(i*fld(3,2))*sqrt(rand()+1.)
>>
>> end
>>
>> end
>>
>>
>>> function TestLoop()
>>
>> tic()
>>
>> for i=1:10
>>
>> TestFunc()
>>
>> end
>>
>> toc()
>>
>> end
>>
>>
>>> end
>>
>>
> C++:
>
>> #include 
>>
>> #include 
>>
>> #include 
>>
>> using namespace std;
>>
>> typedef unsigned long long timestamp_t;
>>
>>
>>> static timestamp_t get_timestamp ()
>>
>> {
>>
>>   struct timeval now;
>>
>>   gettimeofday (&now, NULL);
>>
>>   return  now.tv_usec + (timestamp_t)now.tv_sec * 100;
>>
>> }
>>
>>
>>> int main(int argc, char *argv[])
>>
>> {
>>
>> jl_init(NULL);
>>
>>
>>> jl_load("speedTest.jl");
>>
>> jl_value_t * mod = (jl_value_t*)jl_eval_string("speedTest");
>>
>> jl_function_t * func = jl_get_function((jl_module_t*)mod,"TestFunc");
>>
>>
>>> timestamp_t t0 = get_timestamp();
>>
>>
>>> for(int i=1; i<10; i++) {
>>
>> jl_call0(func);
>>
>> }
>>
>>
>>> timestamp_t t1 = get_timestamp();
>>
>>
>>> double secs = (t1 - t0) / 100.0L;
>>
>> cout<< secs << endl;
>>
>>
>>> jl_atexit_hook(0);
>>
>> return 0;
>>
>> }
>>
>>
>>
>
>
>
>

Re: [julia-users] Implicit differentiation in Julia?

[Steven G. Johnson]

On Thursday, September 8, 2016 at 4:18:42 PM UTC-4, Mathieu 
Taschereau-Dumouchel wrote:
>
> Not quite because the x_i on the right-hand side also depend on a_j


If you just take the partial derivative of both sides with respect 
to aₖ (for k = 1..N), you will see that (given the solution vector x) you 
just get a *linear* system of equations for the gradient:

   ∂xⱼ/∂aₖ - b aⱼ ∑ᵢ (xᵢ)ᵇ⁻¹ ∂xᵢ/∂aₖ = δⱼₖ ∑ᵢ (xᵢ)ᵇ

Notice that the right-hand side is proportional to the identity matrix (δ 
denotes the Kronecker delta).   So, just form the matrix corresponding to 
the linear operator multiplying ∇ₐx on the left-hand side, and your 
Jacobian matrix ∇ₐx will then be the inverse of this matrix multiplied by 
∑ᵢ (xᵢ)ᵇ.

Re: [julia-users] slow for loops because of comparisons

[Yichao Yu]

On Thu, Sep 8, 2016 at 7:04 PM, DNF  wrote:

> But if branch prediction doesn't factor in, what is the explanation of
> this:
>

I didn't say it has no effect. It's irrelevant here because,

1. Having a branch turns off SIMD, which is the main factor
2. It's changing the problem. Different input will for sure have different
performance characteristics.


>
> *julia> *a *=* *rand*(5000);
>
> *julia> *b *=* *rand*(5000);
>
> *julia> *c *=* *rand*(5000) *+* 0.5;
> *julia> *d *=* *rand*(5000) *+* 1;
>
> *julia> **@time* *essai*(200,a,b);
>
>  14.607105 seconds (5 allocations: 1.922 KB)
>
>
> *julia> **@time* *essai*(200,a,c);
>
>   8.357925 seconds (5 allocations: 1.922 KB)
>
> *julia> **@time* *essai*(200,a,d);
>
>   3.159876 seconds (5 allocations: 1.922 KB)
>
>
> On Friday, September 9, 2016 at 12:53:46 AM UTC+2, Yichao Yu wrote:
>>
>> Shape is irrelevant since it doesn't affect the order in the loop at all.
>>
>> Branch prediction is not the issue here.
>>
>> The issue is optimizing memory access and simd.
>>
>> It is illegal to optimize the original code into `a[k] += ss1 > ss2`. It
>> is legal to optimize the `if ss1 > ss2 ak += 1 end` version to `ak += ss1 >
>> ss2` and this is the optimization LLVM should do but doesn't in this case.
>>
>> Also, the thing to look for to check if there's vectorization in llvm ir
>> is the vector type in the loop body like
>>
>> ```
>>   %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ]
>>   %offset.idx = or i64 %index, 1
>>   %20 = add i64 %offset.idx, -1
>>   %21 = getelementptr i64, i64* %19, i64 %20
>>   %22 = bitcast i64* %21 to <4 x i64>*
>>   store <4 x i64> zeroinitializer, <4 x i64>* %22, align 8
>>   %23 = getelementptr i64, i64* %21, i64 4
>>   %24 = bitcast i64* %23 to <4 x i64>*
>>   store <4 x i64> zeroinitializer, <4 x i64>* %24, align 8
>>   %25 = getelementptr i64, i64* %21, i64 8
>>   %26 = bitcast i64* %25 to <4 x i64>*
>>   store <4 x i64> zeroinitializer, <4 x i64>* %26, align 8
>>   %27 = getelementptr i64, i64* %21, i64 12
>>   %28 = bitcast i64* %27 to <4 x i64>*
>>   store <4 x i64> zeroinitializer, <4 x i64>* %28, align 8
>>   %index.next = add i64 %index, 16
>>   %29 = icmp eq i64 %index.next, %n.vec
>> ```
>>
>> having a BB named `vector.body` doesn't mean the loop is vectorized.
>>
>>
>>
>> On Thu, Sep 8, 2016 at 6:40 PM, 'Greg Plowman' via julia-users <
>> julia...@googlegroups.com> wrote:
>>
>>> The difference is probably simd.
>>>
>>> the branch will code will not use simd.
>>>
>>> Either of these should eliminate branch and allow simd.
>>> ak += ss1>ss2
>>> ak += ifelse(ss1>ss2, 1, 0)
>>>
>>> Check with @code_llvm, look for section vector.body
>>>
>>>
>>>  at 5:45:30 AM UTC+10, Dupont wrote:
>>>
 What is strange to me is that this is much slower


 function essai(n, s1, s2)
 a = Vector{Int64}(n)

 @inbounds for k = 1:n
 ak = 0
 for ss1 in s1, ss2 in s2
 if ss1 > ss2
 ak += 1
 end
 end
 a[k] = ak
 end
 end



>>

Re: [julia-users] slow for loops because of comparisons

[DNF]

Hmm. On the other hand I'm seeing this:
julia> a = rand(5000); 
julia> b = rand(5000); 
julia> c = rand(5000) - 0.5; 
julia> d = rand(5000) - 1; 

julia> @time essai(200,a,b); 
 14.561813 seconds (5 allocations: 1.922 KB) 

julia> @time essai(200,a,c); 
 12.003167 seconds (5 allocations: 1.922 KB) 

julia> @time essai(200,a,d); 
  9.199016 seconds (5 allocations: 1.922 KB)


So I concede it's not such a big part after all.

On Friday, September 9, 2016 at 1:04:32 AM UTC+2, DNF wrote:
>
> But if branch prediction doesn't factor in, what is the explanation of 
> this:
>
> *julia> *a *=* *rand*(5000);
>
> *julia> *b *=* *rand*(5000);
>
> *julia> *c *=* *rand*(5000) *+* 0.5;
> *julia> *d *=* *rand*(5000) *+* 1;
>
> *julia> **@time* *essai*(200,a,b);
>
>  14.607105 seconds (5 allocations: 1.922 KB)
>
>
> *julia> **@time* *essai*(200,a,c);
>
>   8.357925 seconds (5 allocations: 1.922 KB)
>
> *julia> **@time* *essai*(200,a,d);
>
>   3.159876 seconds (5 allocations: 1.922 KB)
>
>
> On Friday, September 9, 2016 at 12:53:46 AM UTC+2, Yichao Yu wrote:
>>
>> Shape is irrelevant since it doesn't affect the order in the loop at all.
>>
>> Branch prediction is not the issue here.
>>
>> The issue is optimizing memory access and simd.
>>
>> It is illegal to optimize the original code into `a[k] += ss1 > ss2`. It 
>> is legal to optimize the `if ss1 > ss2 ak += 1 end` version to `ak += ss1 > 
>> ss2` and this is the optimization LLVM should do but doesn't in this case.
>>
>> Also, the thing to look for to check if there's vectorization in llvm ir 
>> is the vector type in the loop body like
>>
>> ```
>>   %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ]
>>   %offset.idx = or i64 %index, 1
>>   %20 = add i64 %offset.idx, -1
>>   %21 = getelementptr i64, i64* %19, i64 %20
>>   %22 = bitcast i64* %21 to <4 x i64>*
>>   store <4 x i64> zeroinitializer, <4 x i64>* %22, align 8
>>   %23 = getelementptr i64, i64* %21, i64 4
>>   %24 = bitcast i64* %23 to <4 x i64>*
>>   store <4 x i64> zeroinitializer, <4 x i64>* %24, align 8
>>   %25 = getelementptr i64, i64* %21, i64 8
>>   %26 = bitcast i64* %25 to <4 x i64>*
>>   store <4 x i64> zeroinitializer, <4 x i64>* %26, align 8
>>   %27 = getelementptr i64, i64* %21, i64 12
>>   %28 = bitcast i64* %27 to <4 x i64>*
>>   store <4 x i64> zeroinitializer, <4 x i64>* %28, align 8
>>   %index.next = add i64 %index, 16
>>   %29 = icmp eq i64 %index.next, %n.vec
>> ```
>>
>> having a BB named `vector.body` doesn't mean the loop is vectorized.
>>
>>
>>
>> On Thu, Sep 8, 2016 at 6:40 PM, 'Greg Plowman' via julia-users <
>> julia...@googlegroups.com> wrote:
>>
>>> The difference is probably simd.
>>>
>>> the branch will code will not use simd.
>>>
>>> Either of these should eliminate branch and allow simd. 
>>> ak += ss1>ss2
>>> ak += ifelse(ss1>ss2, 1, 0)
>>>
>>> Check with @code_llvm, look for section vector.body
>>>
>>>
>>>  at 5:45:30 AM UTC+10, Dupont wrote:
>>>
 What is strange to me is that this is much slower


 function essai(n, s1, s2)
 a = Vector{Int64}(n)

 @inbounds for k = 1:n
 ak = 0
 for ss1 in s1, ss2 in s2
 if ss1 > ss2
 ak += 1
 end
 end
 a[k] = ak
 end
 end



>>

Re: [julia-users] slow for loops because of comparisons

[DNF]

But if branch prediction doesn't factor in, what is the explanation of this:

*julia> *a *=* *rand*(5000);

*julia> *b *=* *rand*(5000);

*julia> *c *=* *rand*(5000) *+* 0.5;
*julia> *d *=* *rand*(5000) *+* 1;

*julia> **@time* *essai*(200,a,b);

 14.607105 seconds (5 allocations: 1.922 KB)


*julia> **@time* *essai*(200,a,c);

  8.357925 seconds (5 allocations: 1.922 KB)

*julia> **@time* *essai*(200,a,d);

  3.159876 seconds (5 allocations: 1.922 KB)


On Friday, September 9, 2016 at 12:53:46 AM UTC+2, Yichao Yu wrote:
>
> Shape is irrelevant since it doesn't affect the order in the loop at all.
>
> Branch prediction is not the issue here.
>
> The issue is optimizing memory access and simd.
>
> It is illegal to optimize the original code into `a[k] += ss1 > ss2`. It 
> is legal to optimize the `if ss1 > ss2 ak += 1 end` version to `ak += ss1 > 
> ss2` and this is the optimization LLVM should do but doesn't in this case.
>
> Also, the thing to look for to check if there's vectorization in llvm ir 
> is the vector type in the loop body like
>
> ```
>   %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ]
>   %offset.idx = or i64 %index, 1
>   %20 = add i64 %offset.idx, -1
>   %21 = getelementptr i64, i64* %19, i64 %20
>   %22 = bitcast i64* %21 to <4 x i64>*
>   store <4 x i64> zeroinitializer, <4 x i64>* %22, align 8
>   %23 = getelementptr i64, i64* %21, i64 4
>   %24 = bitcast i64* %23 to <4 x i64>*
>   store <4 x i64> zeroinitializer, <4 x i64>* %24, align 8
>   %25 = getelementptr i64, i64* %21, i64 8
>   %26 = bitcast i64* %25 to <4 x i64>*
>   store <4 x i64> zeroinitializer, <4 x i64>* %26, align 8
>   %27 = getelementptr i64, i64* %21, i64 12
>   %28 = bitcast i64* %27 to <4 x i64>*
>   store <4 x i64> zeroinitializer, <4 x i64>* %28, align 8
>   %index.next = add i64 %index, 16
>   %29 = icmp eq i64 %index.next, %n.vec
> ```
>
> having a BB named `vector.body` doesn't mean the loop is vectorized.
>
>
>
> On Thu, Sep 8, 2016 at 6:40 PM, 'Greg Plowman' via julia-users <
> julia...@googlegroups.com > wrote:
>
>> The difference is probably simd.
>>
>> the branch will code will not use simd.
>>
>> Either of these should eliminate branch and allow simd. 
>> ak += ss1>ss2
>> ak += ifelse(ss1>ss2, 1, 0)
>>
>> Check with @code_llvm, look for section vector.body
>>
>>
>>  at 5:45:30 AM UTC+10, Dupont wrote:
>>
>>> What is strange to me is that this is much slower
>>>
>>>
>>> function essai(n, s1, s2)
>>> a = Vector{Int64}(n)
>>>
>>> @inbounds for k = 1:n
>>> ak = 0
>>> for ss1 in s1, ss2 in s2
>>> if ss1 > ss2
>>> ak += 1
>>> end
>>> end
>>> a[k] = ak
>>> end
>>> end
>>>
>>>
>>>
>

Re: [julia-users] slow for loops because of comparisons

[Yichao Yu]

Shape is irrelevant since it doesn't affect the order in the loop at all.

Branch prediction is not the issue here.

The issue is optimizing memory access and simd.

It is illegal to optimize the original code into `a[k] += ss1 > ss2`. It is
legal to optimize the `if ss1 > ss2 ak += 1 end` version to `ak += ss1 >
ss2` and this is the optimization LLVM should do but doesn't in this case.

Also, the thing to look for to check if there's vectorization in llvm ir is
the vector type in the loop body like

```
  %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ]
  %offset.idx = or i64 %index, 1
  %20 = add i64 %offset.idx, -1
  %21 = getelementptr i64, i64* %19, i64 %20
  %22 = bitcast i64* %21 to <4 x i64>*
  store <4 x i64> zeroinitializer, <4 x i64>* %22, align 8
  %23 = getelementptr i64, i64* %21, i64 4
  %24 = bitcast i64* %23 to <4 x i64>*
  store <4 x i64> zeroinitializer, <4 x i64>* %24, align 8
  %25 = getelementptr i64, i64* %21, i64 8
  %26 = bitcast i64* %25 to <4 x i64>*
  store <4 x i64> zeroinitializer, <4 x i64>* %26, align 8
  %27 = getelementptr i64, i64* %21, i64 12
  %28 = bitcast i64* %27 to <4 x i64>*
  store <4 x i64> zeroinitializer, <4 x i64>* %28, align 8
  %index.next = add i64 %index, 16
  %29 = icmp eq i64 %index.next, %n.vec
```

having a BB named `vector.body` doesn't mean the loop is vectorized.



On Thu, Sep 8, 2016 at 6:40 PM, 'Greg Plowman' via julia-users <
julia-users@googlegroups.com> wrote:

> The difference is probably simd.
>
> the branch will code will not use simd.
>
> Either of these should eliminate branch and allow simd.
> ak += ss1>ss2
> ak += ifelse(ss1>ss2, 1, 0)
>
> Check with @code_llvm, look for section vector.body
>
>
>  at 5:45:30 AM UTC+10, Dupont wrote:
>
>> What is strange to me is that this is much slower
>>
>>
>> function essai(n, s1, s2)
>> a = Vector{Int64}(n)
>>
>> @inbounds for k = 1:n
>> ak = 0
>> for ss1 in s1, ss2 in s2
>> if ss1 > ss2
>> ak += 1
>> end
>> end
>> a[k] = ak
>> end
>> end
>>
>>
>>

Re: [julia-users] slow for loops because of comparisons

['Greg Plowman' via julia-users]

The difference is probably simd.

the branch will code will not use simd.

Either of these should eliminate branch and allow simd. 
ak += ss1>ss2
ak += ifelse(ss1>ss2, 1, 0)

Check with @code_llvm, look for section vector.body


 at 5:45:30 AM UTC+10, Dupont wrote:

> What is strange to me is that this is much slower
>
>
> function essai(n, s1, s2)
> a = Vector{Int64}(n)
>
> @inbounds for k = 1:n
> ak = 0
> for ss1 in s1, ss2 in s2
> if ss1 > ss2
> ak += 1
> end
> end
> a[k] = ak
> end
> end
>
>
>

Re: [julia-users] calling julia functions in C++

[K leo]

jl_load and the following two are not in the documentation.  Specifically 
how to call function in one's own module.

jl_value_t * mod = (jl_value_t*)jl_eval_string("mymodule");
jl_function_t * func = jl_get_function((jl_module_t*)mod,"myfunction");


On Friday, September 9, 2016 at 1:26:54 AM UTC+8, Isaiah wrote:
>
> As far as I can tell, everything in this thread is covered in the 
> embedding section [http://docs.julialang.org/en/latest/manual/embedding/] 
> except for the note about `jl_load` usage. Care to make a pull-request? ;)
>
> On Thu, Sep 8, 2016 at 12:09 AM, K leo > 
> wrote:
>
>> Thank you.  This just saved my day.  Can someone please put this intro in 
>> the documentation?
>>
>> On Tuesday, June 30, 2015 at 11:58:18 PM UTC+8, Isaiah wrote:
>>>
>>> try
>>>
>>> jl_value_t * mod = (jl_value_t*)jl_eval_string("mymodule");
>>> jl_function_t * func = jl_get_function((jl_module_t*)mod,"myfunction");
>>>
>>> (jl_new_module creates a new module -- that's not what you want, because 
>>> the module containing your function is created when you eval "yourfile.jl")
>>>
>>> On Tue, Jun 30, 2015 at 11:47 AM, Kostas Tavlaridis-Gyparakis <
>>> kostas.t...@gmail.com> wrote:
>>>
 Ok, so first of all thanks a lot for all the help so far.
 So, now I try to follow the instructions and I write the following 
 three lines of code inside C++:

  jl_load("mymodule.jl");
 jl_value_t * mod = jl_eval_string("mymodule");
 jl_function_t * func = 
 jl_get_function(jl_new_module(mod),"myfunction");

 (the jl file and the module itself have the same name in this case 
 mymodule)
 But I do receive the following 2 errors when Eclipse compiles:

 1) error: invalid conversion from ‘void*’ to ‘jl_value_t* {aka 
 _jl_value_t*}’ [-fpermissive] (this is referring to  jl_value_t * mod = 
 jl_eval_string("mymodule");)

 2) error: cannot convert ‘jl_value_t* {aka _jl_value_t*}’ to ‘jl_sym_t* 
 {aka _jl_sym_t*}’ for argument ‘1’ to ‘jl_module_t* 
 jl_new_module(jl_sym_t*)’ (this referring to jl_function_t * func = 
 jl_get_function(jl_new_module(mod),"myfunction");)


 >No problem, no stupid questions. However, I would suggest that you 
 might want to spend some time getting really familiar with Julia by 
 itself, 
 before trying to use the embedding API. It might save a lot of time in the 
 long run.

 You are totally right on this, I am just trying first to check if it is 
 doable to do some combinations between C++ in Eclipse and Julia (such as 
 using functions written in
 Julia inside a C++ routine etc), because I am planning to connect a 
 large-scale C++ with Julia and before starting to studying Julia in full 
 detail and start writing proper
 code was thinking to do some small tests in connectivity between the 
 two. But it turns out that I don't know some very basic things to finish 
 this task.


 On Tuesday, June 30, 2015 at 5:32:53 PM UTC+2, Isaiah wrote:
>
> Sorry but I am not sure what you mean and how to "*evaluate your .jl 
>> file defining the module first*"?
>
>
> Ok, say you have a file:
>
> ```
> module mymod
> function foo() ... end
> end
> ```
>
> At the Julia prompt you would do:
>
> julia> include("myfile.jl")
>
> And then you have the module `mymod` available in the global 
> namespace. In C you can do the equivalent with:
>
> `jl_load("myfile.jl")`
>
> I am really new to Julia so maybe the question sounds really stupid, 
>> sorry for that
>
>
> No problem, no stupid questions. However, I would suggest that you 
> might want to spend some time getting really familiar with Julia by 
> itself, 
> before trying to use the embedding API. It might save a lot of time in 
> the 
> long run.
>
> On Tue, Jun 30, 2015 at 10:54 AM, Kostas Tavlaridis-Gyparakis <
> kostas.t...@gmail.com> wrote:
>
>> Sorry but I am not sure what you mean and how to "*evaluate your .jl 
>> file defining the module first*"?
>> (I am really new to Julia so maybe the question sounds really stupid, 
>> sorry for that)
>>
>>
>>
>>
>>
>> On Tuesday, June 30, 2015 at 4:28:54 PM UTC+2, Isaiah wrote:
>>>
>>> `jl_new_module` creates a new module. You must evaluate your .jl 
>>> file defining the module first, then to get a reference to the module 
>>> do:
>>>
>>> `jl_value_t* mod = jl_eval_string("MyModName");
>>>
>>> Then you can pass "mod" as the argument to `jl_get_function`.
>>>
>>> On Tue, Jun 30, 2015 at 10:16 AM, Kostas Tavlaridis-Gyparakis <
>>> kostas.t...@gmail.com> wrote:
>>>
 Hello,
 I am trying to write some function in Julia which I will be able to 
 call inside my C++ projects in Eclipse.
 In the docum

Re: [julia-users] slow for loops because of comparisons

[DNF]

Oh, by the way, you should use

rand(5000)

instead of 

rand(1, 5000)

Julia is column major oriented. I'm a bit surprised it makes so little (or 
no) difference here, though. I wonder if the compiler reorganizes it into a 
vector or something...

On Friday, September 9, 2016 at 12:21:17 AM UTC+2, DNF wrote:
>
> If you change your test to 
>
> a = rand(1,5000)
> b = rand(1,5000) + 1
>
> you will see significant speedup of you original code. This is a branch 
> prediction problem, isn't it? You are branching on the comparison of two 
> random vectors, that is the hardest thing you can ask for. Prediction will 
> be wrong half the time. If you increase the value of one of the vectors 
> prediction will be right pretty much all the time.
>
> If on the other hand, you use
> a += ss1 > ss2
>
> there is no branch at all, and there is no decision on which branch to 
> take.
>
>
> On Thursday, September 8, 2016 at 9:45:30 PM UTC+2, Dupont wrote:
>>
>> What is strange to me is that this is much slower
>>
>>
>> function essai(n, s1, s2)
>> a = Vector{Int64}(n)
>>
>> @inbounds for k = 1:n
>> ak = 0
>> for ss1 in s1, ss2 in s2
>> if ss1 > ss2
>> ak += 1
>> end
>> end
>> a[k] = ak
>> end
>> end
>>
>>
>>

Re: [julia-users] slow for loops because of comparisons

[DNF]

If you change your test to 

a = rand(1,5000)
b = rand(1,5000) + 1

you will see significant speedup of you original code. This is a branch 
prediction problem, isn't it? You are branching on the comparison of two 
random vectors, that is the hardest thing you can ask for. Prediction will 
be wrong half the time. If you increase the value of one of the vectors 
prediction will be right pretty much all the time.

If on the other hand, you use
a += ss1 > ss2

there is no branch at all, and there is no decision on which branch to take.


On Thursday, September 8, 2016 at 9:45:30 PM UTC+2, Dupont wrote:
>
> What is strange to me is that this is much slower
>
>
> function essai(n, s1, s2)
> a = Vector{Int64}(n)
>
> @inbounds for k = 1:n
> ak = 0
> for ss1 in s1, ss2 in s2
> if ss1 > ss2
> ak += 1
> end
> end
> a[k] = ak
> end
> end
>
>
>

Re: [julia-users] Implicit differentiation in Julia?

[Mathieu Taschereau-Dumouchel]

Not quite because the x_i on the right-hand side also depend on a_j

On Thursday, September 8, 2016, Tim Wheeler 
wrote:

> Isn't the gradient of x_j with respect to a_j just Sum_{j=1}^n (x_i)^b?
>
> On Thursday, September 8, 2016 at 1:08:51 PM UTC-7, Mathieu
> Taschereau-Dumouchel wrote:
>>
>> Hello everyone!
>>
>> I have the following system of n equations
>>
>> x_j= a_j * Sum_{j=1}^n (x_i)^b
>>
>> where 0> iterating on the equation. But I would like to know the gradient of the
>> each x_j with respect to a_j. I am wondering if I could use ForwardDiff.jl
>> or another Julia package in some way to do this. Any help would be
>> appreciated.
>>
>> Many thanks!
>>
>

[julia-users] Re: Maps in Julia?

[daycaster]

@kaj I had no idea anyone was using that. I must be more careful with updates!

[julia-users] Re: Implicit differentiation in Julia?

[Tim Wheeler]

Isn't the gradient of x_j with respect to a_j just Sum_{j=1}^n (x_i)^b?

On Thursday, September 8, 2016 at 1:08:51 PM UTC-7, Mathieu 
Taschereau-Dumouchel wrote:
>
> Hello everyone!
>
> I have the following system of n equations
>
> x_j= a_j * Sum_{j=1}^n (x_i)^b
>
> where 0 iterating on the equation. But I would like to know the gradient of the 
> each x_j with respect to a_j. I am wondering if I could use ForwardDiff.jl 
> or another Julia package in some way to do this. Any help would be 
> appreciated.
>
> Many thanks!
>

[julia-users] Re: RDatasets "UndefVarError: displaysize not defined"

[Lu Han]

I am using 0.4.6 and IJulia and got the same error. 

I checked the source code and found displaysize is a function from Julia 
Base.stream module.


It seems the Base.stream module cannot be imported in my Julia 0.4.6 for 
some reason. 

I am running several other programs which have been running for 3 days and 
may take 10 more hours to finish. So switching to another version is not an 
option for me at the moment. 

Here is a possible temporary solution I found. To replace outcome of the 
displaysize function with IJulia's system default setting.

find the relevent file in .julia\v0.4\DataFrames\src\
abstractdataframe\io.jl:181
and make the following change.
#tty_rows, tty_cols = Base.displaysize(io)
tty_rows = 30
tty_cols = 80









On Thursday, September 8, 2016 at 8:09:17 PM UTC+1, Alex Arslan wrote:
>
> If this is happening why I think it is, I have a DataFrames PR that should 
> fix it. Once that's merged I can tag a new version and things should 
> (fingers crossed!) be all good.
>
> On Monday, August 29, 2016 at 10:16:55 AM UTC-7, Rock Pereira wrote:
>>
>> Julia Version 0.4.6
>> Commit 2e358ce (2016-06-19 17:16 UTC)
>>
>> Windows 10
>>
>>
>> using RDatasets
>> RDatasets.datasets("rpart")
>>
>>
>>
>> UndefVarError: displaysize not defined
>>
>>  in writemime at 
>> C:\Users\Rock\.julia\v0.4\DataFrames\src\abstractdataframe\io.jl:181
>>  in sprint at iostream.jl:206
>>  in display_dict at 
>> C:\Users\Rock\.julia\v0.4\IJulia\src\execute_request.jl:38
>>  in execute_request at 
>> C:\Users\Rock\.julia\v0.4\IJulia\src\execute_request.jl:195
>>  in eventloop at C:\Users\Rock\.julia\v0.4\IJulia\src\IJulia.jl:138
>>  in anonymous at task.jl:447
>>
>>
>>

[julia-users] Implicit differentiation in Julia?

[Mathieu Taschereau-Dumouchel]

Hello everyone!

I have the following system of n equations

x_j= a_j * Sum_{j=1}^n (x_i)^b

where 0

Re: [julia-users] slow for loops because of comparisons

[Yichao Yu]

On Thu, Sep 8, 2016 at 3:45 PM, Dupont  wrote:

> What is strange to me is that this is much slower
>

Shouldn't be between 2ms and 13s
2s and 13s sounds more reasonable.

A branch in a loop is hard to optimize. LLVM obviously is not doing a very
good job here


>
>
> function essai(n, s1, s2)
> a = Vector{Int64}(n)
>
> @inbounds for k = 1:n
> ak = 0
> for ss1 in s1, ss2 in s2
> if ss1 > ss2
> ak += 1
> end
> end
> a[k] = ak
> end
> end
>
>
>

Re: [julia-users] slow for loops because of comparisons

[Dupont]

What is strange to me is that this is much slower


function essai(n, s1, s2)
a = Vector{Int64}(n)

@inbounds for k = 1:n
ak = 0
for ss1 in s1, ss2 in s2
if ss1 > ss2
ak += 1
end
end
a[k] = ak
end
end

Re: [julia-users] slow for loops because of comparisons

[Dupont]

Thank you,

That is much better. What I meant is to just leave a[k] += 1.

[julia-users] Re: RDatasets "UndefVarError: displaysize not defined"

[Alex Arslan]

If this is happening why I think it is, I have a DataFrames PR that should 
fix it. Once that's merged I can tag a new version and things should 
(fingers crossed!) be all good.

On Monday, August 29, 2016 at 10:16:55 AM UTC-7, Rock Pereira wrote:
>
> Julia Version 0.4.6
> Commit 2e358ce (2016-06-19 17:16 UTC)
>
> Windows 10
>
>
> using RDatasets
> RDatasets.datasets("rpart")
>
>
>
> UndefVarError: displaysize not defined
>
>  in writemime at 
> C:\Users\Rock\.julia\v0.4\DataFrames\src\abstractdataframe\io.jl:181
>  in sprint at iostream.jl:206
>  in display_dict at C:\Users\Rock\.julia\v0.4\IJulia\src\execute_request.jl:38
>  in execute_request at 
> C:\Users\Rock\.julia\v0.4\IJulia\src\execute_request.jl:195
>  in eventloop at C:\Users\Rock\.julia\v0.4\IJulia\src\IJulia.jl:138
>  in anonymous at task.jl:447
>
>
>

[julia-users] Re: Pkg.update() does not pull latest version?

[Alex Arslan]

If anyone knows how to fix ConjugatePriors, I'm all ears. I have a PR to 
update the dependencies but I quickly realized that getting it to work 
requires more than bumping versions, and I haven't been able to pinpoint 
exactly what needs to change.

On Tuesday, September 6, 2016 at 11:44:51 PM UTC-7, Kris De Meyer wrote:
>
> I noticed that in Distributions from 0.9 onward the Normal and MvNormal 
> distributions were parameterised on Real (similar to what I did for 
> PDMats). That work should have made my test fix in that pull request 
> obsolote. In other words, if ConjugatePriors was/is updated to work with 
> Distributions > v0.9, then the 2 line change I did in 
> https://github.com/JuliaStats/ConjugatePriors.jl/pull/10 
> 
>  shouldn't 
> even be there anymore. This would require more of a change to 
> ConjugatePriors than simply that test fix though. Has this been looked at?
>
>
> On Wednesday, September 7, 2016 at 4:46:04 AM UTC+1, Tony Kelman wrote:
>>
>> FengYang is right. Remove ConjugatePriors. That package needs a new tag 
>> that's compatible with the latest versions of its dependencies, otherwise 
>> having it installed is going to cause issues like this.
>>
>> I'm not sure what's needed beyond 
>> https://github.com/JuliaStats/ConjugatePriors.jl/pull/10 
>> 
>>
>>
>> On Tuesday, September 6, 2016 at 8:41:38 PM UTC-7, Tony Kelman wrote:
>>>
>>> Did you post your full Pkg.status() yet? Is something keeping you stuck 
>>> on StatsFuns 0.2.x? The only new upper bound I see in the METADATA versions 
>>> is from https://github.com/JuliaLang/METADATA.jl/pull/5613
>>>
>>>
>>> On Tuesday, September 6, 2016 at 4:09:07 PM UTC-7, Tim Wheeler wrote:

 Okay, here is the same thing but from my METADATA.

 Code:

 metadata_dir = "/home/tim/.julia/v0.4/METADATA"
 for (pkg, version) in Pkg.installed()

 reqfile = joinpath(metadata_dir, pkg, "versions", string(version), 
 "requires")

 if isfile(reqfile)
 lines = open(readlines, reqfile)
 println("#"^20)
 println(pkg)
 for line in lines
 print(line)
 end
 println("")
 end
 end




 On Tuesday, September 6, 2016 at 11:17:28 AM UTC-7, Tony Kelman wrote:
>
> I hate to have to say "RTFM" about this so often, but see 
> http://docs.julialang.org/en/release-0.4/manual/strings/#version-number-literals.
>  
> The trailing dash means including prereleases of the given version. 
> (Considering how unintuitive this is we should probably transition to 
> something clearer when we redesign Pkg.) The first number given is an 
> inclusive lower bound, and if a second number is given then it's an 
> exclusive upper bound.
>
> I see a few packages applying upper bounds to ForwardDiff, and a few 
> to MathProgBase and ReverseDiffSparse. I may have missed something (were 
> these taken from METADATA or the package directory? It should be the 
> former, sorry if I didn't say as much - METADATA can be changed 
> after-the-fact but tagged package content can't) but those don't look 
> like 
> they would conflict.
>
> On Tuesday, September 6, 2016 at 10:03:27 AM UTC-7, Tim Wheeler wrote:
>>
>> I wrote the script  and put the output in the attached file.
>>
>> I assume that the '-' at the end of a dep is an upperbound?
>>
>> On Tuesday, September 6, 2016 at 9:35:46 AM UTC-7, Tim Wheeler wrote:
>>>
>>> Ok, will do!
>>>
>>> On Tuesday, September 6, 2016 at 9:31:25 AM UTC-7, Tony Kelman wrote:

 There's a bug somewhere with that error message, I've seen it 
 points at the wrong package. If we can come up with a reproducible 
 test 
 case here it'll help for fixing the bug and making that message more 
 useful.

 It's almost certainly not Compat (I don't think anyone has ever 
 added an upper bound to a Compat dependency). Perhaps loop over 
 Pkg.installed() and display the contents of the REQUIRE file for the 
 specific tags you have currently installed, see who is upper-bounding 
 each 
 other? We do need better tools for debugging this kind of thing to 
 make it 
 easier to figure out what the dependency resolver is doing, which 
 bound 
 constraints are active etc.


 On Tuesday, September 6, 2016 at 9:25:53 AM UTC-7, Tim Wheeler 
 wrote:
>
> Okay - I removed GaussianMixtures and now it is complaining about 

[julia-users] Re: Maps in Julia?

['Philippe Roy' via julia-users]

@ J Luis : The GMT examples are impressive. I do like the look of the maps. 
I'll keep an eye on the GMT.jl package.

@ Kaj : Nice map too! 

from all your answers, I see that it's more than possible to do maps in 
Julia. I'll try your suggestions and see what is more convenient for me.

Thanks again!

Le jeudi 8 septembre 2016 14:45:52 UTC-4, J Luis a écrit :
>
> Hi,
>
> The GMT.jl  is still under 
> development, namely it's waiting for the next (this month) release of 
> GMT5.3, but it already gives you access to one of most powerful Mapping 
> Tools.
>
> quinta-feira, 8 de Setembro de 2016 às 19:33:47 UTC+1, Chris escreveu:
>>
>> This doesn't specifically answer your question, but I have used Basemap 
>> via PyCall without too much trouble in the past.
>>
>> On Thursday, September 8, 2016 at 2:05:53 PM UTC-4, Philippe Roy wrote:
>>>
>>> Hello!
>>>
>>> I'm trying to do a geographical map in Julia. Is that even possible? I 
>>> can't find any package similar to the Matlab Mapping Toolbox or Basemap for 
>>> Python. 
>>>
>>> Thanks for any info!
>>>
>>

[julia-users] Re: Maps in Julia?

[J Luis]

To give you guys an idea, these are all GMT mapping examples 



quinta-feira, 8 de Setembro de 2016 às 19:52:40 UTC+1, Chris escreveu:
>
> The PyCall README is quite comprehensive, and the Basemap documentation 
> has some good examples. Otherwise, I basically just used trial and error 
> until things worked the way I expected -- you get the hang of it eventually.
>
> On Thursday, September 8, 2016 at 2:47:12 PM UTC-4, Philippe Roy wrote:
>>
>> I guess using PyCall could work indeed. Is there some kind of tutorial 
>> about this matter (i.e. Basemap in Julia through pyCall) that you know of? 
>> I'm not really proficient in Julia and Python now (hoping to learn though!).
>>
>> Thanks! 
>>
>> Le jeudi 8 septembre 2016 14:33:47 UTC-4, Chris a écrit :
>>>
>>> This doesn't specifically answer your question, but I have used Basemap 
>>> via PyCall without too much trouble in the past.
>>>
>>> On Thursday, September 8, 2016 at 2:05:53 PM UTC-4, Philippe Roy wrote:

 Hello!

 I'm trying to do a geographical map in Julia. Is that even possible? I 
 can't find any package similar to the Matlab Mapping Toolbox or Basemap 
 for 
 Python. 

 Thanks for any info!

>>>

[julia-users] Re: RDatasets "UndefVarError: displaysize not defined"

[felipenoris]

I guess this is the same 
as https://github.com/JuliaStats/DataFrames.jl/issues/1058

Em quinta-feira, 8 de setembro de 2016 14:21:41 UTC-3, Jeremy McNees 
escreveu:
>
> Have the same Issue. No problem in the REPL, but does not work in IJulia.
>
> On Monday, August 29, 2016 at 5:13:52 PM UTC-4, Rock Pereira wrote:
>>
>> It also works in 0.4.6 in the REPL
>>
>

[julia-users] Re: Maps in Julia?

[Chris]

The PyCall README is quite comprehensive, and the Basemap documentation has 
some good examples. Otherwise, I basically just used trial and error until 
things worked the way I expected -- you get the hang of it eventually.

On Thursday, September 8, 2016 at 2:47:12 PM UTC-4, Philippe Roy wrote:
>
> I guess using PyCall could work indeed. Is there some kind of tutorial 
> about this matter (i.e. Basemap in Julia through pyCall) that you know of? 
> I'm not really proficient in Julia and Python now (hoping to learn though!).
>
> Thanks! 
>
> Le jeudi 8 septembre 2016 14:33:47 UTC-4, Chris a écrit :
>>
>> This doesn't specifically answer your question, but I have used Basemap 
>> via PyCall without too much trouble in the past.
>>
>> On Thursday, September 8, 2016 at 2:05:53 PM UTC-4, Philippe Roy wrote:
>>>
>>> Hello!
>>>
>>> I'm trying to do a geographical map in Julia. Is that even possible? I 
>>> can't find any package similar to the Matlab Mapping Toolbox or Basemap for 
>>> Python. 
>>>
>>> Thanks for any info!
>>>
>>

[julia-users] Re: Maps in Julia?

[Kaj Wiik]

Hi!

I have done some bits of code to make maps and calculate results for 
Finnish powered paragliding championships over the years, like this:
http://movasuunnistus.dy.fi/viitasaari2016/tulokset/suunnistus-viitasaari-2016-timlander.pdf

I use Cairo.jl via Luxor.jl and transform geographic coordinates (GNSS 
logger lat, lon) to UTM (cartesian, unit = metre) by calling libgeographic. 
The base maps are from open rasterized tiles from the Finnish National Land 
survey. 

Quite easy really, if there is need I could tidy up the code for a 
module...at least the libgeographic bit. The rest are quite specific to 
Finland.

On Thursday, September 8, 2016 at 9:05:53 PM UTC+3, Philippe Roy wrote:
>
> Hello!
>
> I'm trying to do a geographical map in Julia. Is that even possible? I 
> can't find any package similar to the Matlab Mapping Toolbox or Basemap for 
> Python. 
>
> Thanks for any info!
>

[julia-users] Re: Maps in Julia?

['Philippe Roy' via julia-users]

I guess using PyCall could work indeed. Is there some kind of tutorial 
about this matter (i.e. Basemap in Julia through pyCall) that you know of? 
I'm not really proficient in Julia and Python now (hoping to learn though!).

Thanks! 

Le jeudi 8 septembre 2016 14:33:47 UTC-4, Chris a écrit :
>
> This doesn't specifically answer your question, but I have used Basemap 
> via PyCall without too much trouble in the past.
>
> On Thursday, September 8, 2016 at 2:05:53 PM UTC-4, Philippe Roy wrote:
>>
>> Hello!
>>
>> I'm trying to do a geographical map in Julia. Is that even possible? I 
>> can't find any package similar to the Matlab Mapping Toolbox or Basemap for 
>> Python. 
>>
>> Thanks for any info!
>>
>

[julia-users] Re: Maps in Julia?

[J Luis]

Hi,

The GMT.jl  is still under development, 
namely it's waiting for the next (this month) release of GMT5.3, but it 
already gives you access to one of most powerful Mapping Tools.

quinta-feira, 8 de Setembro de 2016 às 19:33:47 UTC+1, Chris escreveu:
>
> This doesn't specifically answer your question, but I have used Basemap 
> via PyCall without too much trouble in the past.
>
> On Thursday, September 8, 2016 at 2:05:53 PM UTC-4, Philippe Roy wrote:
>>
>> Hello!
>>
>> I'm trying to do a geographical map in Julia. Is that even possible? I 
>> can't find any package similar to the Matlab Mapping Toolbox or Basemap for 
>> Python. 
>>
>> Thanks for any info!
>>
>

[julia-users] Re: Maps in Julia?

[Chris]

This doesn't specifically answer your question, but I have used Basemap via 
PyCall without too much trouble in the past.

On Thursday, September 8, 2016 at 2:05:53 PM UTC-4, Philippe Roy wrote:
>
> Hello!
>
> I'm trying to do a geographical map in Julia. Is that even possible? I 
> can't find any package similar to the Matlab Mapping Toolbox or Basemap for 
> Python. 
>
> Thanks for any info!
>

[julia-users] Maps in Julia?

['Philippe Roy' via julia-users]

Hello!

I'm trying to do a geographical map in Julia. Is that even possible? I 
can't find any package similar to the Matlab Mapping Toolbox or Basemap for 
Python. 

Thanks for any info!

Re: [julia-users] calling julia functions in C++

[Isaiah Norton]

As far as I can tell, everything in this thread is covered in the embedding
section [http://docs.julialang.org/en/latest/manual/embedding/] except for
the note about `jl_load` usage. Care to make a pull-request? ;)

On Thu, Sep 8, 2016 at 12:09 AM, K leo  wrote:

> Thank you.  This just saved my day.  Can someone please put this intro in
> the documentation?
>
> On Tuesday, June 30, 2015 at 11:58:18 PM UTC+8, Isaiah wrote:
>>
>> try
>>
>> jl_value_t * mod = (jl_value_t*)jl_eval_string("mymodule");
>> jl_function_t * func = jl_get_function((jl_module_t*)mod,"myfunction");
>>
>> (jl_new_module creates a new module -- that's not what you want, because
>> the module containing your function is created when you eval "yourfile.jl")
>>
>> On Tue, Jun 30, 2015 at 11:47 AM, Kostas Tavlaridis-Gyparakis <
>> kostas.t...@gmail.com> wrote:
>>
>>> Ok, so first of all thanks a lot for all the help so far.
>>> So, now I try to follow the instructions and I write the following three
>>> lines of code inside C++:
>>>
>>>  jl_load("mymodule.jl");
>>> jl_value_t * mod = jl_eval_string("mymodule");
>>> jl_function_t * func = jl_get_function(jl_new_module(
>>> mod),"myfunction");
>>>
>>> (the jl file and the module itself have the same name in this case
>>> mymodule)
>>> But I do receive the following 2 errors when Eclipse compiles:
>>>
>>> 1) error: invalid conversion from ‘void*’ to ‘jl_value_t* {aka
>>> _jl_value_t*}’ [-fpermissive] (this is referring to  jl_value_t * mod =
>>> jl_eval_string("mymodule");)
>>>
>>> 2) error: cannot convert ‘jl_value_t* {aka _jl_value_t*}’ to ‘jl_sym_t*
>>> {aka _jl_sym_t*}’ for argument ‘1’ to ‘jl_module_t*
>>> jl_new_module(jl_sym_t*)’ (this referring to jl_function_t * func =
>>> jl_get_function(jl_new_module(mod),"myfunction");)
>>>
>>>
>>> >No problem, no stupid questions. However, I would suggest that you
>>> might want to spend some time getting really familiar with Julia by itself,
>>> before trying to use the embedding API. It might save a lot of time in the
>>> long run.
>>>
>>> You are totally right on this, I am just trying first to check if it is
>>> doable to do some combinations between C++ in Eclipse and Julia (such as
>>> using functions written in
>>> Julia inside a C++ routine etc), because I am planning to connect a
>>> large-scale C++ with Julia and before starting to studying Julia in full
>>> detail and start writing proper
>>> code was thinking to do some small tests in connectivity between the
>>> two. But it turns out that I don't know some very basic things to finish
>>> this task.
>>>
>>>
>>> On Tuesday, June 30, 2015 at 5:32:53 PM UTC+2, Isaiah wrote:

 Sorry but I am not sure what you mean and how to "*evaluate your .jl
> file defining the module first*"?


 Ok, say you have a file:

 ```
 module mymod
 function foo() ... end
 end
 ```

 At the Julia prompt you would do:

 julia> include("myfile.jl")

 And then you have the module `mymod` available in the global namespace.
 In C you can do the equivalent with:

 `jl_load("myfile.jl")`

 I am really new to Julia so maybe the question sounds really stupid,
> sorry for that


 No problem, no stupid questions. However, I would suggest that you
 might want to spend some time getting really familiar with Julia by itself,
 before trying to use the embedding API. It might save a lot of time in the
 long run.

 On Tue, Jun 30, 2015 at 10:54 AM, Kostas Tavlaridis-Gyparakis <
 kostas.t...@gmail.com> wrote:

> Sorry but I am not sure what you mean and how to "*evaluate your .jl
> file defining the module first*"?
> (I am really new to Julia so maybe the question sounds really stupid,
> sorry for that)
>
>
>
>
>
> On Tuesday, June 30, 2015 at 4:28:54 PM UTC+2, Isaiah wrote:
>>
>> `jl_new_module` creates a new module. You must evaluate your .jl file
>> defining the module first, then to get a reference to the module do:
>>
>> `jl_value_t* mod = jl_eval_string("MyModName");
>>
>> Then you can pass "mod" as the argument to `jl_get_function`.
>>
>> On Tue, Jun 30, 2015 at 10:16 AM, Kostas Tavlaridis-Gyparakis <
>> kostas.t...@gmail.com> wrote:
>>
>>> Hello,
>>> I am trying to write some function in Julia which I will be able to
>>> call inside my C++ projects in Eclipse.
>>> In the documentation there is this
>>> 
>>> example on how to call a function of julia from an existing module.
>>> So, what I have done was to create my own module where inside I
>>> included my function and then my
>>> understanding is that I should be using "jl_new_module(jl_sym_t
>>> *name);" instead of jl_base_module.
>>> But I am not sure (in case my assumption that this is the correct

[julia-users] Re: RDatasets "UndefVarError: displaysize not defined"

[Jeremy McNees]

Have the same Issue. No problem in the REPL, but does not work in IJulia.

On Monday, August 29, 2016 at 5:13:52 PM UTC-4, Rock Pereira wrote:
>
> It also works in 0.4.6 in the REPL
>

Re: [julia-users] Re: PSA: New package registration requirements

[Tony Kelman]

You can modify the branch on your metadata fork and remove some of the tag 
files. Usually Pkg.publish is used after just one or two local Pkg.tag's.

Re: [julia-users] Re: PSA: New package registration requirements

[Deniz Yuret]

How can I specify which tags are registered?  I think the default commands
I used (Pkg.tag,register, and publish) ended up trying to register all
existing tags in metadata.

On Thu, Sep 8, 2016, 18:47 Tony Kelman  wrote:

> git tags that don't get registered in metadata should be fine. What were
> you seeing happen?

Re: [julia-users] Re: How to shuffle the order of matrix by rows

[Matt Bauman]

Even simpler: use the built-in `randperm(n)`.  You can even use the `end` 
keyword within the indexing expression as a shorthand for the dimension's 
length:

julia> A = rand(1:100, 5, 3)
5×3 Array{Int64,2}:
 15  57   20
 74  92  100
 17  89   31
 82  12   29
 93   9   66

julia> A[randperm(end), :]
5×3 Array{Int64,2}:
 17  89   31
 82  12   29
 74  92  100
 15  57   20
 93   9   66


On Thursday, September 8, 2016 at 8:03:45 AM UTC-5, Michael Borregaard 
wrote:
>
> I would just
>
> using StatsBase
>
> function shufflerows(a::AbstractMatrix)
> n = size(a, 1)
> ord = sample(1:n, n, replace = false)
> a[ord,:]
> end
>
> a = rand(5,5)
> shufflerows(a)
>
>
>

Re: [julia-users] slow for loops because of comparisons

[Yichao Yu]

On Thu, Sep 8, 2016 at 12:03 PM, Dupont  wrote:

> Dear users,
>
> I would like to speed up the following code.
>
> function essai(n,s1,s2)
>   a = zeros(Int64,n)
>   ss1::Float64 = 0.
>   ss2::Float64 = 0.
>   @inbounds begin
> for k=1:n
>   for i=1:length(s1)
> ss1 = s1[i]
> for j=1:length(s2)
>   ss2 = s2[j]
>   if ss1>ss2
> a[k] += 1
>   end
> end
>   end
> end
>   end
> end
>
> a = rand(1,5000)
> b = rand(1,5000)
> essai(1,a,b)
> @time essai(200,a,b)
>
> On my computer, if I remove the *if*, it runs in 2ms and 13s otherwise.
> Could it be there is a way to speed it up without change the "algorithm"?
>

A few other note, you are not returning a so the functions is functionally
a no-op

Also what do you mean by `remove the if`, I don't think you can get such a
speed up if you just remove the branch and making `a[k] += 1` unconditional
(it will speed it up since it can do a few optimizations much more easily)
If you remove the if and the assignment then it's trivial for llvm to see
that the loop is no-op so it's not running any code at all.


>
> Thank you for your help
>
>
>

Re: [julia-users] slow for loops because of comparisons

[Yichao Yu]

On Thu, Sep 8, 2016 at 12:11 PM, Yichao Yu  wrote:

>
> On Thu, Sep 8, 2016 at 12:03 PM, Dupont  wrote:
>
>>
>> function essai(n,s1,s2)
>>   a = zeros(Int64,n)
>>   ss1::Float64 = 0.
>>   ss2::Float64 = 0.
>>   @inbounds begin
>> for k=1:n
>>   for i=1:length(s1)
>> ss1 = s1[i]
>> for j=1:length(s2)
>>   ss2 = s2[j]
>>   if ss1>ss2
>> a[k] += 1
>>   end
>> end
>>   end
>> end
>>   end
>> end
>>
>> a = rand(1,5000)
>> b = rand(1,5000)
>> essai(1,a,b)
>> @time essai(200,a,b)
>>
>
>
> function essai(n,s1,s2)
> a = zeros(Int64,n)
> ss1::Float64 = 0.
> ss2::Float64 = 0.
> @inbounds for k = 1:n
> ak = a[k]
> for i = 1:length(s1)
> ss1 = s1[i]
> for j = 1:length(s2)
> ak += ss1 > s2[j]
> end
> end
> a[k] = ak
> end
> end
>

And just to make the code cleaner/shorter

function essai(n, s1, s2)
a = Vector{Int64}(n)
@inbounds for k = 1:n
ak = 0
for ss1 in s1, ss2 in s2
ak += ss1 > ss2
end
a[k] = ak
end
end

Re: [julia-users] slow for loops because of comparisons

[Yichao Yu]

On Thu, Sep 8, 2016 at 12:03 PM, Dupont  wrote:

>
> function essai(n,s1,s2)
>   a = zeros(Int64,n)
>   ss1::Float64 = 0.
>   ss2::Float64 = 0.
>   @inbounds begin
> for k=1:n
>   for i=1:length(s1)
> ss1 = s1[i]
> for j=1:length(s2)
>   ss2 = s2[j]
>   if ss1>ss2
> a[k] += 1
>   end
> end
>   end
> end
>   end
> end
>
> a = rand(1,5000)
> b = rand(1,5000)
> essai(1,a,b)
> @time essai(200,a,b)
>


function essai(n,s1,s2)
a = zeros(Int64,n)
ss1::Float64 = 0.
ss2::Float64 = 0.
@inbounds for k = 1:n
ak = a[k]
for i = 1:length(s1)
ss1 = s1[i]
for j = 1:length(s2)
ak += ss1 > s2[j]
end
end
a[k] = ak
end
end

[julia-users] slow for loops because of comparisons

[Dupont]

Dear users,

I would like to speed up the following code.

function essai(n,s1,s2)
  a = zeros(Int64,n)
  ss1::Float64 = 0.
  ss2::Float64 = 0.
  @inbounds begin
for k=1:n
  for i=1:length(s1)
ss1 = s1[i]
for j=1:length(s2)
  ss2 = s2[j]
  if ss1>ss2
a[k] += 1
  end
end
  end
end
  end
end

a = rand(1,5000)
b = rand(1,5000)
essai(1,a,b)
@time essai(200,a,b)

On my computer, if I remove the *if*, it runs in 2ms and 13s otherwise. 
Could it be there is a way to speed it up without change the "algorithm"?

Thank you for your help

Re: [julia-users] Re: PSA: New package registration requirements

[Tony Kelman]

git tags that don't get registered in metadata should be fine. What were you 
seeing happen?

[julia-users] Re: Running Julia in Ubuntu

[Lutfullah Tomak]

I didn't say it is required in general in Android. Mostly, we need a way to 
compile fortran based dependencies.
Google uses llvm compiler toolchain(called android ndk) for native apps but it 
doesn't have fortran compiler yet.
If those dependencies are left out, julia can be built plainly without FFTW, 
Blas, and lapack. Other than that only a terminal interface would be required.

[julia-users] Re: Running Julia in Ubuntu

[Páll Haraldsson]

On Thursday, September 8, 2016 at 1:53:17 PM UTC, Lutfullah Tomak wrote:
>
> There are some non-root google play apps(debian noroot 
>  by pelya and GNURoot Debian 
>  by corbin) that basically 
> provide
> chroot into another linux system by using proot library.
>

I was aware of debian-noroot "Debian running on Android [..] This app is 
NOT full Debian OS - it is a compatibility layer, which allows you to run 
Debian applications."

Are you saying that is needed (it includes a lot)? I'm thinking what you 
could minimally get away with. I'm thinking Android Julia applications, not 
Debian Julia applications. I know other GUI (with complications..), and 
even "Hello world" (CLI style wouldn't work), just putting that aside 
(non-"Linux"/X11 compatibility), what does Julia itself require?

Only 
https://en.wikipedia.org/wiki/Chroot [or proot, that I'm not familiar with]

command required?

-- 
Palli.
 

> `Chroot`ing is not using a VM but using a boxed system under a regular 
> android(or any unix) system.
> AFAIK,it runs programs natively but some filesystem and socket 
> operations(or some privileged operations)
> go through proot(or used chroot library) library to simulate a root system.
>
> On Thursday, September 8, 2016 at 4:26:09 PM UTC+3, Páll Haraldsson wrote:
>>
>> On Tuesday, September 6, 2016 at 8:21:48 PM UTC, Lutfullah Tomak wrote:
>>>
>>> I use julia 0.4.6 package from Debian Stretch in arm cpu(with chroot 
>>> environment in my android phone). It works well and IJulia works too.
>>>
>>
>> You mean you use Julia straight on Android, not on Debian or Ubuntu (in a 
>> VM under Android)? Interesting.. I had heard of the latter in a VM.
>>
>> I think I know what chroot is, not quite a VM, lightweight, and you get 
>> the file system hierarchy you expect. Was that the point?
>>
>> [Android isn't strictly supported, only the Linux [kernel], but this 
>> indicates to me that nothing more in userspace is needed and only file 
>> system changes/chroot is needed (if that..).]
>>
>>
>>
>>> On Tuesday, September 6, 2016 at 11:12:24 PM UTC+3, Angshuman Goswami 
>>> wrote:

 Anyone has a working version of Julia running on ARM processors?

 On Thursday, September 1, 2016 at 10:15:05 PM UTC-4, Josh Langsfeld 
 wrote:
>
> This link is only to an archive of the source code; you would still 
> have to build julia after downloading this.
>
> Ideally what you want is an ARM binary that's version 0.4 instead of a 
> nightly build but I don't see anywhere obvious where that can be 
> downloaded.
>
> RobotOS will start working on 0.5 and up eventually, but you may still 
> need to wait a few weeks.
>
> On Thursday, September 1, 2016 at 7:52:09 PM UTC-4, Angshuman Goswami 
> wrote:
>>
>> But there is no folder /bin/julia in the one I downloaded from 
>> https://github.com/JuliaLang/julia/releases/tag/v0.4.6
>>
>> What should be the simlink when I try to build with this ??
>>
>> On Thursday, September 1, 2016 at 6:52:41 PM UTC-4, Kaj Wiik wrote:
>>>
>>> Hi!
>>>
>>> You symlink a wrong file, first 
>>> sudo rm /usr/local/bin/julia.h
>>>
>>> The correct symlink line is
>>> sudo ln -s /opt/julia-0.4.6/bin/julia  /usr/local/bin
>>>
>>> On Friday, September 2, 2016 at 1:11:07 AM UTC+3, Angshuman Goswami 
>>> wrote:

 I have downloaded the Julia 0.4.6 from the repository: 
 https://github.com/JuliaLang/julia/releases/tag/v0.4.6
 I extracted the folder and copied to opt folder
 sudo ln -s /opt/julia-0.4.6/src/julia.h  /usr/local/bin

 I made the folder executable using sudo chmod +x *

 But I am getting the error:
 bash: julia: command not found




 On Thursday, September 1, 2016 at 5:38:10 PM UTC-4, Angshuman 
 Goswami wrote:
>
> I want to use Julia 0.4.6. Can you guide me through the process as 
> if I am a novice
> On Thursday, September 1, 2016 at 2:24:43 AM UTC-4, Lutfullah 
> Tomak wrote:
>>
>> You've already built julia I guess. You need to install python 
>> using ubuntu's package system. In command prompt
>> sudo apt-get install `pkg-name`
>> will install the package you want to install by asking you your 
>> password.
>> For python
>> sudo apt-get install python
>> will install python. Close prompt and open julia and try again 
>> building PyCall.jl by Pkg.build().
>>
>> On Wednesday, August 31, 2016 at 11:48:32 PM UTC+3, Angshuman 
>> Goswami wrote:
>>>
>>> I don't get how to do that. 
>>>
>>> Can you please tell me the steps. Its all too confusing and I am 
>>> very new to Ubuntu or 

Re: [julia-users] Re: Is it better to call Julia from C++ or call C++ from Julia?

[Tim Holy]

On Thursday, September 8, 2016 6:31:37 AM CDT Páll Haraldsson wrote:
> Not sure I understand ("this case"), in another thread Tim Holy cautioned 
> that C++ would not be inlined into Julia functions, as Julia functions can 
> be.

My caution was for the opposite direction: you can't inline julia functions 
into C++.

--Tim

[julia-users] Re: Running Julia in Ubuntu

[Lutfullah Tomak]

There are some non-root google play apps(debian noroot 
 by pelya and GNURoot Debian 
 by corbin) that basically 
provide
chroot into another linux system by using proot library. `Chroot`ing is not 
using a VM but using a boxed system under a regular android(or any unix) 
system.
AFAIK,it runs programs natively but some filesystem and socket 
operations(or some privileged operations)
go through proot(or used chroot library) library to simulate a root system.

On Thursday, September 8, 2016 at 4:26:09 PM UTC+3, Páll Haraldsson wrote:
>
> On Tuesday, September 6, 2016 at 8:21:48 PM UTC, Lutfullah Tomak wrote:
>>
>> I use julia 0.4.6 package from Debian Stretch in arm cpu(with chroot 
>> environment in my android phone). It works well and IJulia works too.
>>
>
> You mean you use Julia straight on Android, not on Debian or Ubuntu (in a 
> VM under Android)? Interesting.. I had heard of the latter in a VM.
>
> I think I know what chroot is, not quite a VM, lightweight, and you get 
> the file system hierarchy you expect. Was that the point?
>
> [Android isn't strictly supported, only the Linux [kernel], but this 
> indicates to me that nothing more in userspace is needed and only file 
> system changes/chroot is needed (if that..).]
>
>
>
>> On Tuesday, September 6, 2016 at 11:12:24 PM UTC+3, Angshuman Goswami 
>> wrote:
>>>
>>> Anyone has a working version of Julia running on ARM processors?
>>>
>>> On Thursday, September 1, 2016 at 10:15:05 PM UTC-4, Josh Langsfeld 
>>> wrote:

 This link is only to an archive of the source code; you would still 
 have to build julia after downloading this.

 Ideally what you want is an ARM binary that's version 0.4 instead of a 
 nightly build but I don't see anywhere obvious where that can be 
 downloaded.

 RobotOS will start working on 0.5 and up eventually, but you may still 
 need to wait a few weeks.

 On Thursday, September 1, 2016 at 7:52:09 PM UTC-4, Angshuman Goswami 
 wrote:
>
> But there is no folder /bin/julia in the one I downloaded from 
> https://github.com/JuliaLang/julia/releases/tag/v0.4.6
>
> What should be the simlink when I try to build with this ??
>
> On Thursday, September 1, 2016 at 6:52:41 PM UTC-4, Kaj Wiik wrote:
>>
>> Hi!
>>
>> You symlink a wrong file, first 
>> sudo rm /usr/local/bin/julia.h
>>
>> The correct symlink line is
>> sudo ln -s /opt/julia-0.4.6/bin/julia  /usr/local/bin
>>
>> On Friday, September 2, 2016 at 1:11:07 AM UTC+3, Angshuman Goswami 
>> wrote:
>>>
>>> I have downloaded the Julia 0.4.6 from the repository: 
>>> https://github.com/JuliaLang/julia/releases/tag/v0.4.6
>>> I extracted the folder and copied to opt folder
>>> sudo ln -s /opt/julia-0.4.6/src/julia.h  /usr/local/bin
>>>
>>> I made the folder executable using sudo chmod +x *
>>>
>>> But I am getting the error:
>>> bash: julia: command not found
>>>
>>>
>>>
>>>
>>> On Thursday, September 1, 2016 at 5:38:10 PM UTC-4, Angshuman 
>>> Goswami wrote:

 I want to use Julia 0.4.6. Can you guide me through the process as 
 if I am a novice
 On Thursday, September 1, 2016 at 2:24:43 AM UTC-4, Lutfullah Tomak 
 wrote:
>
> You've already built julia I guess. You need to install python 
> using ubuntu's package system. In command prompt
> sudo apt-get install `pkg-name`
> will install the package you want to install by asking you your 
> password.
> For python
> sudo apt-get install python
> will install python. Close prompt and open julia and try again 
> building PyCall.jl by Pkg.build().
>
> On Wednesday, August 31, 2016 at 11:48:32 PM UTC+3, Angshuman 
> Goswami wrote:
>>
>> I don't get how to do that. 
>>
>> Can you please tell me the steps. Its all too confusing and I am 
>> very new to Ubuntu or Julia. Mostly used to work on Matlab. I have 
>> no idea 
>> how to install dependancies
>>
>> On Wednesday, August 31, 2016 at 3:26:40 AM UTC-4, Kaj Wiik wrote:
>>>
>>> Ah, sorry, I assumed you are using x86_64. Find the arm binary 
>>> tarball and follow the instructions otherwise. See
>>> https://github.com/JuliaLang/julia/blob/master/README.arm.md
>>>
>>>
>>> On Wednesday, August 31, 2016 at 9:54:38 AM UTC+3, Lutfullah 
>>> Tomak wrote:

 You are on an arm cpu so Conda cannot install python for you. 
 Also, you tried downloading x86 cpu linux binaries, instead try 
 arm 
 nightlies.
 To get away with PyCall issues you have to manually install all 
 depe

[julia-users] tail => PollingFileWatcher

[adrian_lewis]

Hi, 

I am looking for something like a Unix tail on a log generated by another 
process.

I know there isn't a tail function in Julia. Is there an example of using 
the PollingFileWatcher?

Thanks

Aidy

Re: [julia-users] Re: Is it better to call Julia from C++ or call C++ from Julia?

[Páll Haraldsson]

On Tuesday, September 6, 2016 at 8:13:57 PM UTC, Bart Janssens wrote:
>
>
>
> On Tue, Sep 6, 2016 at 5:25 PM Páll Haraldsson  > wrote:
>
>>
>> As far as I understand:
>>
>> https://github.com/barche/CxxWrap.jl
>>
>> should also be [as, not faster or slower] fast. Meaning runtime speed (of 
>> not development speed).
>>
>
> CxxWrap.jl actually has a slightly higher overhead: many calls are 
> diverted to a C++ std::function, which has an inherent overhead. CxxWrap 
> includes a benchmark (in the package test suite) where all elements of a 
> 5000-element Float64 array are divided by 2, using the function in the 
> loop. Timings on Linux with julia0.5-rc3 are:
> - Pure C++ and pure Julia are the same at 0.06 s
> - ccall on a C function or a CxxWrap C++ function that can be called as a 
> C function: 0.09 s
> - CxxWrap function in the general case: 0.14 s
>
> Normally Cxx.jl should be faster since it can inline in this case.
>

Not sure I understand ("this case"), in another thread Tim Holy cautioned 
that C++ would not be inlined into Julia functions, as Julia functions can 
be.

[I understand you can debug Julia and C++ code, with Gallium, e.g. from one 
language to the next, that is across function boundaries.]

[julia-users] Re: Running Julia in Ubuntu

[Páll Haraldsson]

On Tuesday, September 6, 2016 at 8:21:48 PM UTC, Lutfullah Tomak wrote:
>
> I use julia 0.4.6 package from Debian Stretch in arm cpu(with chroot 
> environment in my android phone). It works well and IJulia works too.
>

You mean you use Julia straight on Android, not on Debian or Ubuntu (in a 
VM under Android)? Interesting.. I had heard of the latter in a VM.

I think I know what chroot is, not quite a VM, lightweight, and you get the 
file system hierarchy you expect. Was that the point?

[Android isn't strictly supported, only the Linux [kernel], but this 
indicates to me that nothing more in userspace is needed and only file 
system changes/chroot is needed (if that..).]



> On Tuesday, September 6, 2016 at 11:12:24 PM UTC+3, Angshuman Goswami 
> wrote:
>>
>> Anyone has a working version of Julia running on ARM processors?
>>
>> On Thursday, September 1, 2016 at 10:15:05 PM UTC-4, Josh Langsfeld wrote:
>>>
>>> This link is only to an archive of the source code; you would still have 
>>> to build julia after downloading this.
>>>
>>> Ideally what you want is an ARM binary that's version 0.4 instead of a 
>>> nightly build but I don't see anywhere obvious where that can be downloaded.
>>>
>>> RobotOS will start working on 0.5 and up eventually, but you may still 
>>> need to wait a few weeks.
>>>
>>> On Thursday, September 1, 2016 at 7:52:09 PM UTC-4, Angshuman Goswami 
>>> wrote:

 But there is no folder /bin/julia in the one I downloaded from 
 https://github.com/JuliaLang/julia/releases/tag/v0.4.6

 What should be the simlink when I try to build with this ??

 On Thursday, September 1, 2016 at 6:52:41 PM UTC-4, Kaj Wiik wrote:
>
> Hi!
>
> You symlink a wrong file, first 
> sudo rm /usr/local/bin/julia.h
>
> The correct symlink line is
> sudo ln -s /opt/julia-0.4.6/bin/julia  /usr/local/bin
>
> On Friday, September 2, 2016 at 1:11:07 AM UTC+3, Angshuman Goswami 
> wrote:
>>
>> I have downloaded the Julia 0.4.6 from the repository: 
>> https://github.com/JuliaLang/julia/releases/tag/v0.4.6
>> I extracted the folder and copied to opt folder
>> sudo ln -s /opt/julia-0.4.6/src/julia.h  /usr/local/bin
>>
>> I made the folder executable using sudo chmod +x *
>>
>> But I am getting the error:
>> bash: julia: command not found
>>
>>
>>
>>
>> On Thursday, September 1, 2016 at 5:38:10 PM UTC-4, Angshuman Goswami 
>> wrote:
>>>
>>> I want to use Julia 0.4.6. Can you guide me through the process as 
>>> if I am a novice
>>> On Thursday, September 1, 2016 at 2:24:43 AM UTC-4, Lutfullah Tomak 
>>> wrote:

 You've already built julia I guess. You need to install python 
 using ubuntu's package system. In command prompt
 sudo apt-get install `pkg-name`
 will install the package you want to install by asking you your 
 password.
 For python
 sudo apt-get install python
 will install python. Close prompt and open julia and try again 
 building PyCall.jl by Pkg.build().

 On Wednesday, August 31, 2016 at 11:48:32 PM UTC+3, Angshuman 
 Goswami wrote:
>
> I don't get how to do that. 
>
> Can you please tell me the steps. Its all too confusing and I am 
> very new to Ubuntu or Julia. Mostly used to work on Matlab. I have no 
> idea 
> how to install dependancies
>
> On Wednesday, August 31, 2016 at 3:26:40 AM UTC-4, Kaj Wiik wrote:
>>
>> Ah, sorry, I assumed you are using x86_64. Find the arm binary 
>> tarball and follow the instructions otherwise. See
>> https://github.com/JuliaLang/julia/blob/master/README.arm.md
>>
>>
>> On Wednesday, August 31, 2016 at 9:54:38 AM UTC+3, Lutfullah 
>> Tomak wrote:
>>>
>>> You are on an arm cpu so Conda cannot install python for you. 
>>> Also, you tried downloading x86 cpu linux binaries, instead try arm 
>>> nightlies.
>>> To get away with PyCall issues you have to manually install all 
>>> depencies. 
>>>
>>> On Wednesday, August 31, 2016 at 7:53:24 AM UTC+3, Angshuman 
>>> Goswami wrote:

 When i performed build again errors cropped up.

 Pkg.build("PyCall")
 WARNING: unable to determine host cpu name.
 INFO: Building PyCall
 INFO: No system-wide Python was found; got the following error:
 could not spawn `/usr/local/lib/python2.7 -c "import 
 distutils.sysconfig; 
 print(distutils.sysconfig.get_config_var('VERSION'))"`: permission 
 denied 
 (EACCES)
 using the Python distribution in the Conda package
 INFO: Downloading miniconda installer ...
 

[julia-users] Re: julia-python module missing sys.ji julia-0.5.0-0.20160822.fc24.x86_64

[Neal Becker]

Páll Haraldsson wrote:

> On Thursday, September 8, 2016 at 12:20:56 PM UTC, Neal Becker wrote:
>  
> 
>> Are these nightlies incomplete, or has this file changed?  Does
>> https://pypi.python.org/pypi/julia
> 
> 
> I wasn't aware of this.. I only knew of pyjulia to call Julia from Python
> (not yet registered at PyPy, butbeen talked about).
> 
> Are you sure you need/want IPython support? I'm not sure, maybe pyjulia
> handles that also, or only that package (does it use pyjulia?).
> 
> [Then there is PyCall.jl to call in the other direction; and even
> Polyglot.jl]
> 
> 
> 
>>
>> need update for julia-0.5?
>>
>>

OK, I didn't realize there was both https://pypi.python.org/pypi/julia as 
well as pyjulia.

I installed
https://github.com/JuliaInterop/pyjulia

and it seems to be working!  I'm happy.

[julia-users] Re: RandIP A random IP generator for Large scale network mapping.

[Páll Haraldsson]

FYI: There's also:

https://github.com/JuliaWeb/IPNets.jl

[And a thread on it, if I recall just an announcement.]

Didn't look into it much

[julia-users] Re: RandIP A random IP generator for Large scale network mapping.

[Páll Haraldsson]

On Tuesday, August 30, 2016 at 3:34:49 PM UTC, Páll Haraldsson wrote:
>
> On Tuesday, August 30, 2016 at 5:26:29 AM UTC, Jacob Yates wrote:
>>
>> I've been working on porting a script I wrote in python to julia and have 
>> been having some issues with the script freezing.
>>
>> So pretty much all this script does is generate a random IP address and 
>> checks to see if its valid(the Python version will give http error codes) 
>> then logs the results for further analysis.
>>
>> function gen_ip()
>> ip = Any[]
>> for i in rand(1:255, 4)
>> push!(ip, i)
>> end
>> global ipaddr = join(ip, ".")
>> end
>>
>  
> [..]
>
> println("Bactrace: ", backtrace())
>>
>
> Note, there is a type for IP addresses, done like: ip"127.0.0.1" (should 
> also work for IPv6) or:
>
> gen_ip() = IPv4(rand(0:256^4-1)) #not sure why you excluded 0 in 1:255 
> (might want to exclude some IPs but not as much as you did?), or used 
> global.
>

gen_ip() = IPv4(begin r=rand(1:254); r >= 10 ? r+1 : r end, rand(0:255), 
rand(0:255), 
rand(0:255))

is possibly what you want. 0.x.x.x and 10.x.x.x are private networks and 
you seemed to want to exclude the former, and if also the latter then the 
new version does that. I forget, you where excluding 0 for the x-es, isn't 
that just plain wrong (except maybe for the last one)?



> http://docs.julialang.org/en/release-0.4/manual/networking-and-streams/
>
> Generally global is bad form, and I'm not sure, but it might have 
> something to do with @async not working, as I guess it's not "thread-safe" 
> or related..
>
> -- 
> Palli.
>
>  
>  
>

[julia-users] Re: julia-python module missing sys.ji julia-0.5.0-0.20160822.fc24.x86_64

[Páll Haraldsson]

On Thursday, September 8, 2016 at 12:20:56 PM UTC, Neal Becker wrote:
 

> Are these nightlies incomplete, or has this file changed?  Does 
> https://pypi.python.org/pypi/julia


I wasn't aware of this.. I only knew of pyjulia to call Julia from Python 
(not yet registered at PyPy, butbeen talked about).

Are you sure you need/want IPython support? I'm not sure, maybe pyjulia 
handles that also, or only that package (does it use pyjulia?).

[Then there is PyCall.jl to call in the other direction; and even 
Polyglot.jl]



>
> need update for julia-0.5? 
>
>

Re: [julia-users] Re: How to shuffle the order of matrix by rows

[Michael Borregaard]

I would just

using StatsBase

function shufflerows(a::AbstractMatrix)
n = size(a, 1)
ord = sample(1:n, n, replace = false)
a[ord,:]
end

a = rand(5,5)
shufflerows(a)

Re: [julia-users] Re: ran into problem compiling C embedded with julia using mingw-w64 gcc on windows

[Henri Girard]

I use xenial and I compiled and use julia-0.5-rc3 without any change


Le 08/09/2016 à 03:04, K leo a écrit :
I just ran that example on Ubuntu with Julia 0.5.  I found I did have 
to change a few things to make it run.


export JULIA_DIR=
export JULIA_HOME=$JULIA_DIR/bin
export PATH=$JULIA_HOME:$PATH
export LD_LIBRARY_PATH=$JULIA_DIR/lib:$LD_LIBRARY_PATH

And when I compile it, I used the following statement:
g++ -o test -fPIC -I$JULIA_DIR/include/julia test.cpp 
-L$JULIA_DIR/lib/ -L$JULIA_DIR/lib/julia -lLLVM-3.7.1 -ljulia 
$JULIA_DIR/lib/julia/libstdc++.so.6


But these are for Linux, not sure if it would help you on Windows 
(which I abandoned about 10 years ago).

[julia-users] julia-python module missing sys.ji julia-0.5.0-0.20160822.fc24.x86_64

[Neal Becker]

I'm trying out the julia python module using julia nightlie
julia-0.5.0-0.20160822.fc24.x86_64


I fixed one problem in
julia/core.py:

 println(Libdl.dlpath(Libdl.dlopen(\"libjulia\")))

but now I'm stuck because core.py looks for

sys.si

But it seems nothing in
https://copr.fedorainfracloud.org/coprs/nalimilan/julia-nightlies/

provides this file.

Are these nightlies incomplete, or has this file changed?  Does
https://pypi.python.org/pypi/julia

need update for julia-0.5?

Re: [julia-users] There is very little overhead calling Julia from C++

[Tim Holy]

Keep in mind that statements like "very little overhead" depend entirely on 
what you're comparing against. Your TestFunc is quite expensive, so it's not 
surprising that how it's called adds little overhead. If you called a much 
cheaper function, you might come to a rather different conclusion. I'm not 
saying you can't/shouldn't do this, but you should be aware that your 
conclusions may not generalize to all usage patterns.

For example, much of what makes julia fun is the fact that you can build up 
complicated functionality from "atomic" pieces that do very little work on 
their own, and julia links them all together (using a great deal of inlining) 
to deliver awesome performance. Presumably you'll lose those advantages when 
calling individual functions from C++.

Best,
--Tim

On Wednesday, September 7, 2016 9:43:29 PM CDT K leo wrote:
> I just did a test of calling a Julia function 100,000 times, both from
> Julia and from C++.  The execution times are very close.  The results are
> as follows.  This is on Xubuntu 16.04 64bits.
> 
> ***Julia   **
> 
>   | | |_| | | | (_| |  |  Version 0.5.0-rc3+0 (2016-08-22 23:43 UTC)
> 
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> 
> |__/   |  x86_64-unknown-linux-gnu
> 
> julia> include("speedTest.jl")
> speedTest
> 
> julia> speedTest.TestLoop()
> elapsed time: 3.21365718 seconds
> 3.21365718
> 
> 
> ***   C++***
> 
> > g++ -o test -fPIC -I$JULIA_DIR/include/julia test3.cpp -L$JULIA_DIR/lib/
> 
> -L$JULIA_DIR/lib/julia -lLLVM-3.7.1 -ljulia
> $JULIA_DIR/lib/julia/libstdc++.so.6
> 
> > ./test
> 
> 3.22423
> 
> The codes are shown below:
> 
> Julai:
> > module speedTest
> > 
> >> function TestFunc()
> >> 
> > f=0.
> > 
> > for i=1:1
> > 
> > f += Float64(i*fld(3,2))*sqrt(rand()+1.)
> > 
> > end
> > 
> > end
> > 
> >> function TestLoop()
> >> 
> > tic()
> > 
> > for i=1:10
> > 
> > TestFunc()
> > 
> > end
> > 
> > toc()
> > 
> > end
> > 
> >> end
> 
> C++:
> > #include 
> > 
> > #include 
> > 
> > #include 
> > 
> > using namespace std;
> > 
> > typedef unsigned long long timestamp_t;
> > 
> >> static timestamp_t get_timestamp ()
> > 
> > {
> > 
> >   struct timeval now;
> >   
> >   gettimeofday (&now, NULL);
> >   
> >   return  now.tv_usec + (timestamp_t)now.tv_sec * 100;
> > 
> > }
> > 
> >> int main(int argc, char *argv[])
> > 
> > {
> > 
> > jl_init(NULL);
> > 
> >> jl_load("speedTest.jl");
> > 
> > jl_value_t * mod = (jl_value_t*)jl_eval_string("speedTest");
> > 
> > jl_function_t * func = jl_get_function((jl_module_t*)mod,"TestFunc");
> > 
> >> timestamp_t t0 = get_timestamp();
> >> 
> >> 
> >> for(int i=1; i<10; i++) {
> >> 
> > jl_call0(func);
> > 
> > }
> > 
> >> timestamp_t t1 = get_timestamp();
> >> 
> >> 
> >> double secs = (t1 - t0) / 100.0L;
> > 
> > cout<< secs << endl;
> > 
> >> jl_atexit_hook(0);
> > 
> > return 0;
> > 
> > }

[julia-users] Re: Julia Reference Card

[john lynch]

No.  It was originally left out because the Python card had a section on 
Object Orientation but I don't plan to do an equivalent so I've renumbered 
the sections.

On Wednesday, September 7, 2016 at 11:35:33 PM UTC+10, Sisyphuss wrote:
>
> There is no Section 3?
>
>
> On Wednesday, September 7, 2016 at 12:04:29 AM UTC+2, john lynch wrote:
>>
>> Thanks for the compliment.  I have fixed it in the pdf and the associated 
>> odt.
>>
>

[julia-users] Re: TreeMap in Julia

[Ján Adamčák]

Thanks,

great to know. 
At this moment I do not have time to cooperate, but I believe I'll help you 
in the future.


Dňa streda, 7. septembra 2016 19:59:21 UTC+2 Randy Zwitch napísal(-a):
>
> Vega.jl has the capability to render one, but doesn't yet have an 
> easy-to-use function defined:
>
> https://github.com/johnmyleswhite/Vega.jl/issues/109
>
> You would need to translate the example JSON string into the 
> VegaVisualization composite type in Julia, which can be slightly 
> frustrating the first few times you do it, but eventually gets easier.
>
> I'd love a pull request if you plan on tackling this!
>
> On Wednesday, September 7, 2016 at 5:02:25 AM UTC-4, Ján Adamčák wrote:
>>
>> Hi, 
>>
>> Is there a tool for drawing Tree Map in Julia?
>> I want draw something like this:
>>
>>
>> 
>>
>>
>>
>>
>>
>>