Re: [julia-users] Re: Calling all users of ParallelAccelerator.

[DrTodd13]

You may also want to look at another IntelLabs project on GitHub called Latte. 
It provides a DSL for deep neural networks in Julia. 

Todd 

- Original Message -

From: pev...@gmail.com 
To: "julia-users"  
Sent: Friday, July 22, 2016 8:07:19 PM 
Subject: [julia-users] Re: Calling all users of ParallelAccelerator. 




Hi Todd, 



I have tried several times to use ParallelAccelerator to speed up my toy Neural 
Network library, but I never had any significant performance boost. I like the 
idea of the project a lot, sadly I was never able to fully utilise it. 

Best wishes, 
Tomas 

[julia-users] Re: Which package downgrades other packages?

[Jeffrey Sarnoff]

+1

On Friday, July 22, 2016 at 10:24:30 PM UTC-4, Tony Kelman wrote:
>
> Maybe a useful function to write and submit to PkgDev would be go through 
> all installed packages, check the METADATA requires file for all the 
> installed versions and display a list of upper-bounded dependencies and 
> which package is responsible for each. A little bit of code might go a long 
> way in making this more discoverable.

[julia-users] Re: Calling all users of ParallelAccelerator.

[pevnak]

>
> Hi Todd,
>
I have tried several times to use ParallelAccelerator to speed up my toy 
Neural Network library, but I never had any significant performance boost. 
I like the idea of the project a lot, sadly I was never able to fully 
utilise it.

Best wishes,
Tomas 

[julia-users] Re: Error on indexing of UTF8String

[Jeffrey Sarnoff]

This is explained here unicode-and-utf-8 
.
You want to use `nextind`: 
 name2="김아무개"
name2[1]
'김'
nextind(name2,1)
4
name2[4]
'아'
name2[ nextind(name2,4) ]
'무'
name2[nextind(name2,nextind(name2,4))]
'개'





On Friday, July 22, 2016 at 10:23:26 PM UTC-4, Joungmin Lee wrote:
>
> Hi, I've been dealing with some strings including asian characters.
>  
> In case of indexing of ASCIIString, there's no problem. 
> But when dealing with a UTF8String, I could get only 1st and last 
> characters.
>  
>
> julia> name1="John Doe"
> "John Doe"
>
> julia> name2="김아무개"
> "김아무개"
>
> julia> name3="近藤雅子"
> "近藤雅子"
>
> julia> name1[1]
> 'J'
>
> julia> name1[2]
> 'o'
>
> julia> name2[1]
> '김'
>
> julia> name2[2]
> ERROR: UnicodeError: invalid character index
>  in next at unicode/utf8.jl:65
>  in getindex at strings/basic.jl:37
>
> julia> name3[1]
> '近'
>
> julia> name3[2]
> ERROR: UnicodeError: invalid character index
>  in next at unicode/utf8.jl:65
>  in getindex at strings/basic.jl:37
>
> julia> name3[end]
> '子'
>
> julia> name3[end-1]
> ERROR: UnicodeError: invalid character index
>  in next at unicode/utf8.jl:65
>  in getindex at strings/basic.jl:37
> julia>
>
>  
> Is this result a bug? Otherwise do I miss something?
>
> Joungmin
>  
>

Re: [julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

[Tony Kelman]

You're probably thinking of linux sonames with dots. Windows doesn't have that, 
the dash in the name is a libtool convention for the best approximation you can 
get to allowing multiple versions of the library to be installed side by side, 
and different applications to link to different versions. The linker doesn't 
know about this convention on Windows, it's usually handled by libtool with 
associated .la or .dll.a files.

[julia-users] Which package downgrades other packages?

[Tony Kelman]

Maybe a useful function to write and submit to PkgDev would be go through all 
installed packages, check the METADATA requires file for all the installed 
versions and display a list of upper-bounded dependencies and which package is 
responsible for each. A little bit of code might go a long way in making this 
more discoverable.

[julia-users] Error on indexing of UTF8String

[Joungmin Lee]

Hi, I've been dealing with some strings including asian characters.
 
In case of indexing of ASCIIString, there's no problem. 
But when dealing with a UTF8String, I could get only 1st and last 
characters.
 

julia> name1="John Doe"
"John Doe"

julia> name2="김아무개"
"김아무개"

julia> name3="近藤雅子"
"近藤雅子"

julia> name1[1]
'J'

julia> name1[2]
'o'

julia> name2[1]
'김'

julia> name2[2]
ERROR: UnicodeError: invalid character index
 in next at unicode/utf8.jl:65
 in getindex at strings/basic.jl:37

julia> name3[1]
'近'

julia> name3[2]
ERROR: UnicodeError: invalid character index
 in next at unicode/utf8.jl:65
 in getindex at strings/basic.jl:37

julia> name3[end]
'子'

julia> name3[end-1]
ERROR: UnicodeError: invalid character index
 in next at unicode/utf8.jl:65
 in getindex at strings/basic.jl:37
julia>

 
Is this result a bug? Otherwise do I miss something?

Joungmin
 

Re: [julia-users] Re: Installs .5.0 dev on unbuntu instead of .4.6

[Fisher, Christopher]

Thanks everyone. I couldn't figure out a solution based on installing the
binaries (I'm new to linux) or the forum. In my case, John's code worked
for me, except I had to omit --reinstall julia from the last command.

I think part of this issue was that a file was left behind when I installed
a nightly, causing it to grab the old .5.0 dev version.  My best guess is
that the first command (sudo apt-add-repository --remove
ppa:staticfloat/julianightlies) removed this file.

Hopefully the installation process isn't this convoluted in the future!

Thanks again.

On Fri, Jul 22, 2016 at 8:45 PM, John Best  wrote:

> Make sure you're using the release ppa (sudo add-apt-repository
> ppa:staticfloat/juliareleases)and not the nightlies ppa (sudo
> apt-add-repository ppa:staticfloat/julianightlies). Try
>
>
> sudo apt-add-repository --remove ppa:staticfloat/julianightlies
> sudo apt-add-repository ppa:staticfloat/juliareleases
> sudo apt-get update
> sudo apt-get install --reinstall julia
>
> (not positive on the last command, but it's worth a try).
>
> See http://askubuntu.com/questions/307/how-can-ppas-be-removed for removing 
> repos.
>
>
> On Friday, July 22, 2016 at 3:43:21 PM UTC-8, Christopher Fisher wrote:
>>
>> Hi all-
>>
>> I'm trying reinstall Julia .4.6 on Ubuntu 16.04. For some reason when I
>> follow the platform specific instructions,
>>  it installs .5.0 dev
>> instead of the stable version .4.6. Is there a way to install .4.6?
>> Unfortunately, .5 dev is unstable and doesn't work with Juno.
>>
>> Thanks in advance for your help.
>>
>

Re: [julia-users] Re: Strange performance issue in filling in a matrix column

[Michael Prange]

I'm new to Julia and do not know how to file a performance issue, but I am 
happy to do it. Can you point me to the right place?

Sent from my phone

> On Jul 22, 2016, at 18:09, Stefan Karpinski  wrote:
> 
> Can you file a performance issue? The built-in circshift should not have 
> these performance issues.
> 
>> On Fri, Jul 22, 2016 at 4:18 PM, Michael Prange  wrote:
>> I just discovered that Julia already has a function for circularly shifting 
>> the data in an array: circshift(A, shifts). However, its performance is 
>> worst of all. Using this new method,
>> 
>> function fill_W4!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, ishift::Int)
>> @assert(size(W,1) == length(w), "Dimension mismatch between W and w")
>> W[:,icol] = circshift(w,[ishift,])
>> return
>> end
>> 
>> 
>> the resulting timings are given by (with new random numbers)
>> 
>> fill_W!: 0.002918 seconds (4 allocations: 160 bytes) 
>> fill_W1!: 0.006440 seconds (10 allocations: 7.630 MB) 
>> fill_W2!: 0.009244 seconds (8 allocations: 7.630 MB, 21.61% gc time) 
>> fill_W3!: 0.002014 seconds (8 allocations: 352 bytes) 
>> fill_W4!: 0.049601 seconds (19 allocations: 30.518 MB, 3.63% gc time)
>> 
>> I would have expected the built-in method circshift to achieve the best 
>> results, but it is worst in all categories: time, allocations and memory.
>> 
>> Michael
>> 
>>> On Friday, July 22, 2016 at 2:23:16 PM UTC-4, Michael Prange wrote:
>>> Gunnar,
>>> 
>>> Thank you for your explanation of the extra allocations and the tip about 
>>> sub. I implemented a version with sub as fill_W3!:
>>> 
>>> function fill_W3!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
>>> ishift::Int)
>>> @assert(size(W,1) == length(w), "Dimension mismatch between W and w")
>>> W[(ishift+1):end,icol] = sub(w, 1:(length(w)-ishift))
>>> W[1:ishift,icol] = sub(w, (length(w)-ishift+1):length(w))
>>> return
>>> end
>>> 
>>> Is this what you had in mind? I reran the tests above (with new random 
>>> numbers) and had the following results:
>>> 
>>> fill_W!: 0.003234 seconds (4 allocations: 160 bytes) 
>>> fill_W1!: 0.005898 seconds (9 allocations: 7.630 MB) 
>>> fill_W2!: 0.005904 seconds (7 allocations: 7.630 MB) 
>>> fill_W3!: 0.002347 seconds (8 allocations: 352 bytes)
>>> 
>>> Using sub consistently achieves better times that fill_W!, even through it 
>>> uses twice the number of allocations than fill_W!. This seems to be the way 
>>> to go.
>>> 
>>> Michael
>>> 
 On Thursday, July 21, 2016 at 5:35:47 PM UTC-4, Gunnar Farnebäck wrote:
 fill_W1! allocates memory because it makes copies when constructing the 
 right hand sides. fill_W2 allocates memory in order to construct the 
 comprehensions (that you then discard). In both cases memory allocation 
 could plausibly be avoided by a sufficiently smart compiler, but until 
 Julia becomes that smart, have a look at the sub function to provide views 
 instead of copies for the right hand sides of fill_W1!.
 
> On Thursday, July 21, 2016 at 5:07:34 PM UTC+2, Michael Prange wrote:
> I'm a new user, so have mercy in your responses. 
> 
> I've written a method that takes a matrix and vector as input and then 
> fills in column icol of that matrix with the vector of given values that 
> have been shifted upward by ishift indices with periodic boundary 
> conditions. To make this clear, given the matrix
> 
> W = [1  2
> 3  4
> 5  6]
> 
> the vector w = [7  8  9], icol = 2 and ishift = 1, the new value of W is 
> given by
> 
> W = [1  8
> 3  9
> 5  7]
> 
> I need a fast way of doing this for large matrices. I wrote three methods 
> that should (In my naive mind) give the same performance results, but 
> @time reports otherwise.  The method definitions and the performance 
> results are given below. Can someone teach me why the results are so 
> different? The method fill_W! is too wordy for my tastes, but the more 
> compact notation in fill_W1! and fill_W2! achieve poorer results. Any why 
> do these latter two methods allocate so much memory when the whole point 
> of these methods is to use already-allocated memory.
> 
> Michael
> 
> ### Definitions
> 
> 
> function fill_W1!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
> ishift::Int)
> @assert(size(W,1) == length(w), "Dimension mismatch between W and w")
> W[1:(end-ishift),icol] = w[(ishift+1):end]
> W[(end-(ishift-1)):end,icol] = w[1:ishift]
> return
> end
> 
> 
> function fill_W2!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
> ishift::Int)
> @assert(size(W,1) == length(w), "Dimension mismatch between W and w")
> [W[i,icol] = w[i+ishift] for i in 1:(length(w)-ishift)]
> [W[end-ishift+i,icol] = w[i] for i in 1:ishift]
> 

[julia-users] Re: Installs .5.0 dev on unbuntu instead of .4.6

[John Best]

Make sure you're using the release ppa (sudo add-apt-repository 
ppa:staticfloat/juliareleases)and not the nightlies ppa (sudo 
apt-add-repository ppa:staticfloat/julianightlies). Try


sudo apt-add-repository --remove ppa:staticfloat/julianightlies
sudo apt-add-repository ppa:staticfloat/juliareleases
sudo apt-get update
sudo apt-get install --reinstall julia

(not positive on the last command, but it's worth a try).

See http://askubuntu.com/questions/307/how-can-ppas-be-removed for removing 
repos.


On Friday, July 22, 2016 at 3:43:21 PM UTC-8, Christopher Fisher wrote:
>
> Hi all-
>
> I'm trying reinstall Julia .4.6 on Ubuntu 16.04. For some reason when I 
> follow the platform specific instructions, 
>  it installs .5.0 dev 
> instead of the stable version .4.6. Is there a way to install .4.6? 
> Unfortunately, .5 dev is unstable and doesn't work with Juno. 
>
> Thanks in advance for your help. 
>

[julia-users] Re: Installs .5.0 dev on unbuntu instead of .4.6

[cdm]

this thread may be of interest to you:

https://groups.google.com/forum/#!searchin/julia-users/PPA|sort:date/julia-users/7jl-NBGaaTI/VtFM7S5GBQAJ



On Friday, July 22, 2016 at 4:43:21 PM UTC-7, Christopher Fisher wrote:
>
> Hi all-
>
> I'm trying reinstall Julia .4.6 on Ubuntu 16.04. For some reason when I 
> follow the platform specific instructions, 
>  it installs .5.0 dev 
> instead of the stable version .4.6. Is there a way to install .4.6? 
> Unfortunately, .5 dev is unstable and doesn't work with Juno. 
>
> Thanks in advance for your help. 
>

Re: [julia-users] Installs .5.0 dev on unbuntu instead of .4.6

[Yichao Yu]

On Fri, Jul 22, 2016 at 7:43 PM, Christopher Fisher
 wrote:
> Hi all-
>
> I'm trying reinstall Julia .4.6 on Ubuntu 16.04. For some reason when I
> follow the platform specific instructions, it installs .5.0 dev instead of
> the stable version .4.6. Is there a way to install .4.6? Unfortunately, .5
> dev is unstable and doesn't work with Juno.

Use the generic binary.

>
> Thanks in advance for your help.

[julia-users] Installs .5.0 dev on unbuntu instead of .4.6

[Christopher Fisher]

Hi all-

I'm trying reinstall Julia .4.6 on Ubuntu 16.04. For some reason when I 
follow the platform specific instructions, 
 it installs .5.0 dev instead 
of the stable version .4.6. Is there a way to install .4.6? Unfortunately, 
.5 dev is unstable and doesn't work with Juno. 

Thanks in advance for your help. 

Re: [julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

['Bill Hart' via julia-users]

Well, I thought that when you link against libgmp normally, it doesn't care 
that the filename is libgmp-16.dll. I thought the linker just took care of 
it for you, So I was surprised by this behaviour. I might just be confused 
though.

On Friday, 22 July 2016 22:30:50 UTC+2, Tony Kelman wrote:
>
> Fragile how? The -16 is part of the library name.

Re: [julia-users] Pipeline interoperability with IOStream and IOBuffer

[Steven G. Johnson]

On Friday, July 22, 2016 at 8:55:44 AM UTC-4, Tom Breloff wrote:
>
> To be fair, he was told, in that issue, that julia-users was a more 
> appropriate place to ask this type of question. 


No, he was told to ask on julia-users about usage questions — in this case, 
if he can't figure out how to write from an IOBuffer to an IOStream or to a 
process.  (No changes to Base are required to do this.)

In contrast, if you want to continue to press for changes to the Julia 
standard library, the correct forum is the Github issue.

[julia-users] Which package downgrades other packages?

[David Anthoff]

I have a lot packages installed, but none pinned by myself. A whole bunch of
packages are at versions that are not up-to-date (e.g. MathProgBase is at
0.4.3, way behind), even after Pkg.update().

 

I guess there must be some package that has an upper limit on one of its
requirements, and that probably blocks everything. Is there some easy way
for me to identify the package that is holding everything back? I did look
through all the direct dependencies of MathProgBase, but none of them
explains this.

 

Cheers,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

Re: [julia-users] Re: Strange performance issue in filling in a matrix column

[Stefan Karpinski]

Can you file a performance issue? The built-in circshift should not have
these performance issues.

On Fri, Jul 22, 2016 at 4:18 PM, Michael Prange  wrote:

> I just discovered that Julia already has a function for circularly
> shifting the data in an array: circshift(A, shifts). However, its
> performance is worst of all. Using this new method,
>
> function fill_W4!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, ishift::Int
> )
> @assert(size(W,1) == length(w), "Dimension mismatch between W and w")
> W[:,icol] = circshift(w,[ishift,])
> return
> end
>
>
> the resulting timings are given by (with new random numbers)
>
> fill_W!: 0.002918 seconds (4 allocations: 160 bytes)
> fill_W1!: 0.006440 seconds (10 allocations: 7.630 MB)
> fill_W2!: 0.009244 seconds (8 allocations: 7.630 MB, 21.61% gc time)
> fill_W3!: 0.002014 seconds (8 allocations: 352 bytes)
> fill_W4!: 0.049601 seconds (19 allocations: 30.518 MB, 3.63% gc time)
>
>
> I would have expected the built-in method circshift to achieve the best
> results, but it is worst in all categories: time, allocations and memory.
>
> Michael
>
> On Friday, July 22, 2016 at 2:23:16 PM UTC-4, Michael Prange wrote:
>>
>> Gunnar,
>>
>> Thank you for your explanation of the extra allocations and the tip about
>> sub. I implemented a version with sub as fill_W3!:
>>
>> function fill_W3!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF},
>> ishift::Int)
>> @assert(size(W,1) == length(w), "Dimension mismatch between W and w")
>> W[(ishift+1):end,icol] = sub(w, 1:(length(w)-ishift))
>> W[1:ishift,icol] = sub(w, (length(w)-ishift+1):length(w))
>> return
>> end
>>
>> Is this what you had in mind? I reran the tests above (with new random
>> numbers) and had the following results:
>>
>> fill_W!: 0.003234 seconds (4 allocations: 160 bytes)
>> fill_W1!: 0.005898 seconds (9 allocations: 7.630 MB)
>> fill_W2!: 0.005904 seconds (7 allocations: 7.630 MB)
>> fill_W3!: 0.002347 seconds (8 allocations: 352 bytes)
>>
>> Using sub consistently achieves better times that fill_W!, even through it 
>> uses twice the number of allocations than fill_W!. This seems to be the way 
>> to go.
>>
>>
>> Michael
>>
>>
>> On Thursday, July 21, 2016 at 5:35:47 PM UTC-4, Gunnar Farnebäck wrote:
>>>
>>> fill_W1! allocates memory because it makes copies when constructing the
>>> right hand sides. fill_W2 allocates memory in order to construct the
>>> comprehensions (that you then discard). In both cases memory allocation
>>> could plausibly be avoided by a sufficiently smart compiler, but until
>>> Julia becomes that smart, have a look at the sub function to provide views
>>> instead of copies for the right hand sides of fill_W1!.
>>>
>>> On Thursday, July 21, 2016 at 5:07:34 PM UTC+2, Michael Prange wrote:

 I'm a new user, so have mercy in your responses.

 I've written a method that takes a matrix and vector as input and then
 fills in column icol of that matrix with the vector of given values that
 have been shifted upward by ishift indices with periodic boundary
 conditions. To make this clear, given the matrix

 W = [1  2
 3  4
 5  6]

 the vector w = [7  8  9], icol = 2 and ishift = 1, the new value of W
 is given by

 W = [1  8
 3  9
 5  7]

 I need a fast way of doing this for large matrices. I wrote three
 methods that should (In my naive mind) give the same performance results,
 but @time reports otherwise.  The method definitions and the performance
 results are given below. Can someone teach me why the results are so
 different? The method fill_W! is too wordy for my tastes, but the more
 compact notation in fill_W1! and fill_W2! achieve poorer results. Any why
 do these latter two methods allocate so much memory when the whole point of
 these methods is to use already-allocated memory.

 Michael

 ### Definitions


 function fill_W1!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF},
 ishift::Int)
 @assert(size(W,1) == length(w), "Dimension mismatch between W and
 w")
 W[1:(end-ishift),icol] = w[(ishift+1):end]
 W[(end-(ishift-1)):end,icol] = w[1:ishift]
 return
 end


 function fill_W2!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF},
 ishift::Int)
 @assert(size(W,1) == length(w), "Dimension mismatch between W and
 w")
 [W[i,icol] = w[i+ishift] for i in 1:(length(w)-ishift)]
 [W[end-ishift+i,icol] = w[i] for i in 1:ishift]
 return
 end


 function fill_W!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF},
 ishift::Int)
 @assert(size(W,1) == length(w), "Dimension mismatch between W and
 w")
 n = length(w)
 for j in 1:(n-ishift)
 W[j,icol] = w[j+ishift]
 end
 for j in (n-(ishift-1)):n
 W[j,icol] = 

Re: [julia-users] How to make an unsafe_string safe?

[Jeffrey Sarnoff]

Thank you.

Re: [julia-users] IBM Power port

[Paulito Palmes]

Hi Viral,

Yes, the binary image works without problems in Power8 ;). As expected, it
complains that it cannot execute in Power7.

I finished compiling in both power7 and power8 using the /tmp. The errors
are still the same:

Power8:
--
CC src/gc.o
CC src/gc-debug.o
CC src/gc-pages.o
CC src/jlapi.o
CC src/signal-handling.o
CC src/safepoint.o
CC src/jloptions.o
CC src/timing.o
CC src/codegen.o
CC src/jitlayers.o
CC src/disasm.o
CC src/debuginfo.o
CC src/llvm-simdloop.o
CC src/llvm-ptls.o
CC src/llvm-gcroot.o
CC src/cgmemmgr.o
LINK usr/lib/libjulia.so.0.5.0
CC ui/repl.o
LINK usr/bin/julia
PERL base/pcre_h.jl
PERL base/errno_h.jl
PERL base/build_h.jl.phony
PERL base/fenv_constants.jl
PERL base/file_constants.jl
PERL base/uv_constants.jl
PERL base/version_git.jl.phony
JULIA usr/lib/julia/inference.ji
LLVM ERROR: unable to evaluate offset to undefined symbol ''
make[1]: *** [/tmp/julia/usr/lib/julia/inference.ji] Error 1
make: *** [julia-inference] Error 2



Power7:
---
  CC src/signal-handling.o
CC src/safepoint.o
CC src/jloptions.o
CC src/timing.o
CC src/codegen.o
CC src/jitlayers.o
CC src/disasm.o
CC src/debuginfo.o
CC src/llvm-simdloop.o
CC src/llvm-ptls.o
CC src/llvm-gcroot.o
CC src/cgmemmgr.o
LINK usr/lib/libjulia.so.0.5.0
CC ui/repl.o
LINK usr/bin/julia
PERL base/pcre_h.jl
PERL base/errno_h.jl
PERL base/build_h.jl.phony
PERL base/fenv_constants.jl
PERL base/file_constants.jl
PERL base/uv_constants.jl
PERL base/version_git.jl.phony
JULIA usr/lib/julia/inference.ji
LLVM ERROR: unable to evaluate offset to undefined symbol ''
*** Error in `/tmp/julia/usr/bin/julia': free(): invalid pointer:
0x01000d27a588 ***
=== Backtrace: =
/lib64/libc.so.6(+0xaffa4)[0x3fff8a43ffa4]
/lib64/libstdc++.so.6(_ZdlPv-0xdc2a0)[0x3fff88da9b28]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xf8884)[0x3fff8a758884]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xf8978)[0x3fff8a758978]
/lib64/libc.so.6(__cxa_finalize-0x18145c)[0x3fff8a3f4b04]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x4f118)[0x3fff8a6af118]
/lib64/ld64.so.1(+0x186c0)[0x3fff8ab586c0]
/lib64/libc.so.6(+0x6460c)[0x3fff8a3f460c]
/lib64/libc.so.6(exit-0x1818c4)[0x3fff8a3f464c]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm18report_fatal_errorERKNS_5TwineEb-0xe2c7c4)[0x3fff894930c4]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZNK4llvm11MCAsmLayout15getSymbolOffsetERKNS_8MCSymbolE-0x2064ec)[0x3fff8a10175c]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZNK4llvm11MCAssembler13evaluateFixupERKNS_11MCAsmLayoutERKNS_7MCFixupEPKNS_10MCFragmentERNS_7MCValueERm-0x206338)[0x3fff8a101920]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm11MCAssembler11handleFixupERKNS_11MCAsmLayoutERNS_10MCFragmentERKNS_7MCFixupE-0x205f74)[0x3fff8a101cf4]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm11MCAssembler6FinishEv-0x204fb0)[0x3fff8a102d38]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm16MCObjectStreamer10FinishImplEv-0x1e5d54)[0x3fff8a122e94]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm13MCELFStreamer10FinishImplEv-0x1f2b48)[0x3fff8a115930]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm10MCStreamer6FinishEv-0x1dd0ec)[0x3fff8a12c43c]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm10AsmPrinter14doFinalizationERNS_6ModuleE-0x600d28)[0x3fff89cf0640]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so(+0x43e200)[0x3fff892ee200]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm13FPPassManager14doFinalizationERNS_6ModuleE-0x7a7b98)[0x3fff89b3e2e0]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE-0x79af18)[0x3fff89b4b850]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm6legacy11PassManager3runERNS_6ModuleE-0x79ad44)[0x3fff89b4ba34]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x11ed04)[0x3fff8a77ed04]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x1260fc)[0x3fff8a7860fc]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x126e4c)[0x3fff8a786e4c]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x1270b8)[0x3fff8a7870b8]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xd6e28)[0x3fff8a736e28]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xdded4)[0x3fff8a73ded4]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(jl_apply_generic-0x1bbd94)[0x3fff8a6c7fac]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x826a8)[0x3fff8a6e26a8]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x82078)[0x3fff8a6e2078]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x82e1c)[0x3fff8a6e2e1c]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x83368)[0x3fff8a6e3368]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xa3980)[0x3fff8a703980]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x742e8)[0x3fff8a6d42e8]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(jl_load-0x18170c)[0x3fff8a704474]

Re: [julia-users] IBM Power port

[Paulito Palmes]

HI VIral,

I am also hoping that once IBM sees the potential of Julia+IBM Power for
doing HPC and analytics, they will formally support the Julia development
in the future just like what they did with the docker and other open source
initiatives.

On Fri, Jul 22, 2016 at 9:07 PM, Paulito Palmes  wrote:

> Hi Viral,
>
> Yes, the binary image works without problems in Power8 ;). As expected, it
> complains that it cannot execute in Power7.
>
> I finished compiling in both power7 and power8 using the /tmp. The errors
> are still the same:
>
> Power8:
> --
> CC src/gc.o
> CC src/gc-debug.o
> CC src/gc-pages.o
> CC src/jlapi.o
> CC src/signal-handling.o
> CC src/safepoint.o
> CC src/jloptions.o
> CC src/timing.o
> CC src/codegen.o
> CC src/jitlayers.o
> CC src/disasm.o
> CC src/debuginfo.o
> CC src/llvm-simdloop.o
> CC src/llvm-ptls.o
> CC src/llvm-gcroot.o
> CC src/cgmemmgr.o
> LINK usr/lib/libjulia.so.0.5.0
> CC ui/repl.o
> LINK usr/bin/julia
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> LLVM ERROR: unable to evaluate offset to undefined symbol ''
> make[1]: *** [/tmp/julia/usr/lib/julia/inference.ji] Error 1
> make: *** [julia-inference] Error 2
> 
>
>
> Power7:
> ---
>   CC src/signal-handling.o
> CC src/safepoint.o
> CC src/jloptions.o
> CC src/timing.o
> CC src/codegen.o
> CC src/jitlayers.o
> CC src/disasm.o
> CC src/debuginfo.o
> CC src/llvm-simdloop.o
> CC src/llvm-ptls.o
> CC src/llvm-gcroot.o
> CC src/cgmemmgr.o
> LINK usr/lib/libjulia.so.0.5.0
> CC ui/repl.o
> LINK usr/bin/julia
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> LLVM ERROR: unable to evaluate offset to undefined symbol ''
> *** Error in `/tmp/julia/usr/bin/julia': free(): invalid pointer:
> 0x01000d27a588 ***
> === Backtrace: =
> /lib64/libc.so.6(+0xaffa4)[0x3fff8a43ffa4]
> /lib64/libstdc++.so.6(_ZdlPv-0xdc2a0)[0x3fff88da9b28]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xf8884)[0x3fff8a758884]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xf8978)[0x3fff8a758978]
> /lib64/libc.so.6(__cxa_finalize-0x18145c)[0x3fff8a3f4b04]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x4f118)[0x3fff8a6af118]
> /lib64/ld64.so.1(+0x186c0)[0x3fff8ab586c0]
> /lib64/libc.so.6(+0x6460c)[0x3fff8a3f460c]
> /lib64/libc.so.6(exit-0x1818c4)[0x3fff8a3f464c]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm18report_fatal_errorERKNS_5TwineEb-0xe2c7c4)[0x3fff894930c4]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZNK4llvm11MCAsmLayout15getSymbolOffsetERKNS_8MCSymbolE-0x2064ec)[0x3fff8a10175c]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZNK4llvm11MCAssembler13evaluateFixupERKNS_11MCAsmLayoutERKNS_7MCFixupEPKNS_10MCFragmentERNS_7MCValueERm-0x206338)[0x3fff8a101920]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm11MCAssembler11handleFixupERKNS_11MCAsmLayoutERNS_10MCFragmentERKNS_7MCFixupE-0x205f74)[0x3fff8a101cf4]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm11MCAssembler6FinishEv-0x204fb0)[0x3fff8a102d38]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm16MCObjectStreamer10FinishImplEv-0x1e5d54)[0x3fff8a122e94]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm13MCELFStreamer10FinishImplEv-0x1f2b48)[0x3fff8a115930]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm10MCStreamer6FinishEv-0x1dd0ec)[0x3fff8a12c43c]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm10AsmPrinter14doFinalizationERNS_6ModuleE-0x600d28)[0x3fff89cf0640]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so(+0x43e200)[0x3fff892ee200]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm13FPPassManager14doFinalizationERNS_6ModuleE-0x7a7b98)[0x3fff89b3e2e0]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE-0x79af18)[0x3fff89b4b850]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm6legacy11PassManager3runERNS_6ModuleE-0x79ad44)[0x3fff89b4ba34]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x11ed04)[0x3fff8a77ed04]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x1260fc)[0x3fff8a7860fc]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x126e4c)[0x3fff8a786e4c]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x1270b8)[0x3fff8a7870b8]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xd6e28)[0x3fff8a736e28]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xdded4)[0x3fff8a73ded4]
>
> 

Re: [julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

[Tony Kelman]

Fragile how? The -16 is part of the library name.

[julia-users] Re: Strange performance issue in filling in a matrix column

[Michael Prange]

I just discovered that Julia already has a function for circularly shifting 
the data in an array: circshift(A, shifts). However, its performance is 
worst of all. Using this new method,

function fill_W4!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, ishift::Int)
@assert(size(W,1) == length(w), "Dimension mismatch between W and w")
W[:,icol] = circshift(w,[ishift,])
return
end


the resulting timings are given by (with new random numbers)

fill_W!: 0.002918 seconds (4 allocations: 160 bytes) 
fill_W1!: 0.006440 seconds (10 allocations: 7.630 MB) 
fill_W2!: 0.009244 seconds (8 allocations: 7.630 MB, 21.61% gc time) 
fill_W3!: 0.002014 seconds (8 allocations: 352 bytes) 
fill_W4!: 0.049601 seconds (19 allocations: 30.518 MB, 3.63% gc time)


I would have expected the built-in method circshift to achieve the best 
results, but it is worst in all categories: time, allocations and memory.

Michael

On Friday, July 22, 2016 at 2:23:16 PM UTC-4, Michael Prange wrote:
>
> Gunnar,
>
> Thank you for your explanation of the extra allocations and the tip about 
> sub. I implemented a version with sub as fill_W3!:
>
> function fill_W3!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
> ishift::Int)
> @assert(size(W,1) == length(w), "Dimension mismatch between W and w")
> W[(ishift+1):end,icol] = sub(w, 1:(length(w)-ishift))
> W[1:ishift,icol] = sub(w, (length(w)-ishift+1):length(w))
> return
> end
>
> Is this what you had in mind? I reran the tests above (with new random 
> numbers) and had the following results:
>
> fill_W!: 0.003234 seconds (4 allocations: 160 bytes) 
> fill_W1!: 0.005898 seconds (9 allocations: 7.630 MB) 
> fill_W2!: 0.005904 seconds (7 allocations: 7.630 MB) 
> fill_W3!: 0.002347 seconds (8 allocations: 352 bytes)
>
> Using sub consistently achieves better times that fill_W!, even through it 
> uses twice the number of allocations than fill_W!. This seems to be the way 
> to go.
>
>
> Michael
>
>
> On Thursday, July 21, 2016 at 5:35:47 PM UTC-4, Gunnar Farnebäck wrote:
>>
>> fill_W1! allocates memory because it makes copies when constructing the 
>> right hand sides. fill_W2 allocates memory in order to construct the 
>> comprehensions (that you then discard). In both cases memory allocation 
>> could plausibly be avoided by a sufficiently smart compiler, but until 
>> Julia becomes that smart, have a look at the sub function to provide views 
>> instead of copies for the right hand sides of fill_W1!.
>>
>> On Thursday, July 21, 2016 at 5:07:34 PM UTC+2, Michael Prange wrote:
>>>
>>> I'm a new user, so have mercy in your responses. 
>>>
>>> I've written a method that takes a matrix and vector as input and then 
>>> fills in column icol of that matrix with the vector of given values that 
>>> have been shifted upward by ishift indices with periodic boundary 
>>> conditions. To make this clear, given the matrix
>>>
>>> W = [1  2
>>> 3  4
>>> 5  6]
>>>
>>> the vector w = [7  8  9], icol = 2 and ishift = 1, the new value of W is 
>>> given by
>>>
>>> W = [1  8
>>> 3  9
>>> 5  7]
>>>
>>> I need a fast way of doing this for large matrices. I wrote three 
>>> methods that should (In my naive mind) give the same performance results, 
>>> but @time reports otherwise.  The method definitions and the performance 
>>> results are given below. Can someone teach me why the results are so 
>>> different? The method fill_W! is too wordy for my tastes, but the more 
>>> compact notation in fill_W1! and fill_W2! achieve poorer results. Any why 
>>> do these latter two methods allocate so much memory when the whole point of 
>>> these methods is to use already-allocated memory.
>>>
>>> Michael
>>>
>>> ### Definitions
>>>
>>>
>>> function fill_W1!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
>>> ishift::Int)
>>> @assert(size(W,1) == length(w), "Dimension mismatch between W and w"
>>> )
>>> W[1:(end-ishift),icol] = w[(ishift+1):end]
>>> W[(end-(ishift-1)):end,icol] = w[1:ishift]
>>> return
>>> end
>>>
>>>
>>> function fill_W2!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
>>> ishift::Int)
>>> @assert(size(W,1) == length(w), "Dimension mismatch between W and w"
>>> )
>>> [W[i,icol] = w[i+ishift] for i in 1:(length(w)-ishift)]
>>> [W[end-ishift+i,icol] = w[i] for i in 1:ishift]
>>> return
>>> end
>>>
>>>
>>> function fill_W!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
>>> ishift::Int)
>>> @assert(size(W,1) == length(w), "Dimension mismatch between W and w"
>>> )
>>> n = length(w)
>>> for j in 1:(n-ishift)
>>> W[j,icol] = w[j+ishift]
>>> end
>>> for j in (n-(ishift-1)):n
>>> W[j,icol] = w[j-(n-ishift)]
>>> end
>>> end
>>>
>>>
>>> # Performance Results
>>> julia>
>>> W = rand(100,2)
>>> w = rand(100)
>>> println("fill_W!:")
>>> println(@time fill_W!(W, 2, w, 2))
>>> println("fill_W1!:")
>>> println(@time fill_W1!(W, 2, w, 2))
>>> println("fill_W2!:")
>>> println(@time 

[julia-users] How to make an unsafe_string safe?

[Jeffrey Sarnoff]

I have a ccall to a library that returns a C-string `cstr = ccall(__)`.  I 
understand that v0.5/current practice is to do `jstr = unsafe_string(cstr)` 
upon obtaining `cstr`.
The cstr is freed by another ccall.  If I want to use or return that string 
as a Julia String type, do I need to do something more before/after freeing 
the cstr?

Re: [julia-users] IBM Power port

[Viral Shah]

I am hoping we can have beta support from the 0.5 release onwards for 
sequential julia. We were able to do this work due to some small support from 
IBM. Hopefully, as more users use Julia on Power and HPC systems, there may be 
a way to sustain this through the right form of funding. For now, I just keep 
pushing julia on other architectures as a hobby. :-)

-viral

> On Jul 22, 2016, at 3:54 PM, Viral Shah  wrote:
> 
> I am hoping we can have beta support from the 0.5 release onwards for 
> sequential julia. We were able to do this work due to some small support from 
> IBM. Hopefully, as more users use Julia on Power and HPC systems, there may 
> be a way to sustain this through the right form of funding. For now, I just 
> keep building julia on newer architectures as a hobby. :-)
> 
> -viral
> 
> 
> 
>> On Jul 22, 2016, at 3:28 PM, Paulito Palmes  wrote:
>> 
>> Hi Viral,
>> 
>> Thanks. I have already informed the sysad to check the time sync of the 
>> servers to avoid future issues.
>> 
>> I'll try to compile in local disks and get back to you. 
>> 
>> Yes, I understand it may take some work to create the bin image but highly 
>> appreciate the fact that Julia will run now in power architecture. I think 
>> it was several months ago when a fellow IBMer from US tried to port it in 
>> power machine and had discussion here also but had some issues. It will be 
>> cool if Julia will support power architecture in time for 1.0 release...
>> 
>> On Fri, Jul 22, 2016 at 7:51 PM, Viral Shah  wrote:
>> It appears to me that you are building on some kind of a network filesystem 
>> and timestamps are getting messed up. Can you build in /tmp or somewhere, 
>> which may be guaranteed to have local storage and hence avoid these clock 
>> issues?
>> 
>> If still doesn’t work, I will create some binaries and upload and put up all 
>> the instructions. Since openblas still has some issues to be fixed on power, 
>> I am using an ATLAS build (of which we are using the latest RC), and 
>> packaging it all up is going to be some work.
>> 
>> 
>> -viral
>> 
>> 
>> 
>>> On Jul 22, 2016, at 1:50 PM, Paulito Palmes  wrote:
>>> 
>>> This problem might be specific to Redhat? Unfortunately, I don't have 
>>> debian-based Power system running to test.
>>> 
>>> On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes  wrote:
>>> Here's the error using Power8: same error which happens during linking.
>>> 
>>> Can you send me the tarballs of successfully compiled image in Power8?
>>> 
>>> -
>>> 
>>>LINK usr/lib/libjulia.so.0.5.0
>>> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
>>> make[1]: Warning: File `../src/julia_version.h' has modification time 228 s 
>>> in the future
>>>CC ui/repl.o
>>>LINK usr/bin/julia
>>> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
>>>PERL base/pcre_h.jl
>>>PERL base/errno_h.jl
>>>PERL base/build_h.jl.phony
>>>PERL base/fenv_constants.jl
>>>PERL base/file_constants.jl
>>>PERL base/uv_constants.jl
>>>PERL base/version_git.jl.phony
>>>JULIA usr/lib/julia/inference.ji
>>> LLVM ERROR: unable to evaluate offset to undefined symbol ''
>>> make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji] Error 
>>> 1
>>> make: *** [julia-inference] Error 2
>>> 
>>> 
>>> On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes  wrote:
>>> It caused a core-dump during linking ;( in Power7
>>> 
>>> ...
>>> CC src/cgmemmgr.o
>>>LINK usr/lib/libjulia.so.0.5.0
>>>CC ui/repl.o
>>>LINK usr/bin/julia
>>>PERL base/pcre_h.jl
>>>PERL base/errno_h.jl
>>>PERL base/build_h.jl.phony
>>>PERL base/fenv_constants.jl
>>>PERL base/file_constants.jl
>>>PERL base/uv_constants.jl
>>>PERL base/version_git.jl.phony
>>>JULIA usr/lib/julia/inference.ji
>>> /bin/sh: line 1: 28699 Segmentation fault  (core dumped) 
>>> /home/paulpalm/julia/usr/bin/julia -C native --output-ji 
>>> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
>>> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
>>> make: *** [julia-inference] Error 2
>>> 
>>> 
>>> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes  wrote:
>>> I'm compiling in both Power7 and Power8 and not yet finished. I started 
>>> with make -j 20 but after some time, it had errors. Then I switch to make 
>>> -j 1 but takes time to finish. I hope it will compile in both power7 and 
>>> power8.
>>> 
>>> I'll wait and try to check if I can fix some obvious errors. Otherwise, 
>>> I'll ask the tarball so that I can check the difference from what I have 
>>> specially which objects were not compiled.
>>> 
>>> thanks.
>>> 
>>> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
>>> Did it go through? I usually build with make -j 20 on the 

Re: [julia-users] IBM Power port

[Paulito Palmes]

Hi Viral,

Thanks. I have already informed the sysad to check the time sync of the
servers to avoid future issues.

I'll try to compile in local disks and get back to you.

Yes, I understand it may take some work to create the bin image but highly
appreciate the fact that Julia will run now in power architecture. I think
it was several months ago when a fellow IBMer from US tried to port it in
power machine and had discussion here also but had some issues. It will be
cool if Julia will support power architecture in time for 1.0 release...

On Fri, Jul 22, 2016 at 7:51 PM, Viral Shah  wrote:

> It appears to me that you are building on some kind of a network
> filesystem and timestamps are getting messed up. Can you build in /tmp or
> somewhere, which may be guaranteed to have local storage and hence avoid
> these clock issues?
>
> If still doesn’t work, I will create some binaries and upload and put up
> all the instructions. Since openblas still has some issues to be fixed on
> power, I am using an ATLAS build (of which we are using the latest RC), and
> packaging it all up is going to be some work.
>
>
> -viral
>
>
>
> > On Jul 22, 2016, at 1:50 PM, Paulito Palmes  wrote:
> >
> > This problem might be specific to Redhat? Unfortunately, I don't have
> debian-based Power system running to test.
> >
> > On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes 
> wrote:
> > Here's the error using Power8: same error which happens during linking.
> >
> > Can you send me the tarballs of successfully compiled image in Power8?
> >
> > -
> >
> > LINK usr/lib/libjulia.so.0.5.0
> > make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> > make[1]: Warning: File `../src/julia_version.h' has modification time
> 228 s in the future
> > CC ui/repl.o
> > LINK usr/bin/julia
> > make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> > PERL base/pcre_h.jl
> > PERL base/errno_h.jl
> > PERL base/build_h.jl.phony
> > PERL base/fenv_constants.jl
> > PERL base/file_constants.jl
> > PERL base/uv_constants.jl
> > PERL base/version_git.jl.phony
> > JULIA usr/lib/julia/inference.ji
> > LLVM ERROR: unable to evaluate offset to undefined symbol ''
> > make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji]
> Error 1
> > make: *** [julia-inference] Error 2
> >
> >
> > On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes 
> wrote:
> > It caused a core-dump during linking ;( in Power7
> >
> > ...
> > CC src/cgmemmgr.o
> > LINK usr/lib/libjulia.so.0.5.0
> > CC ui/repl.o
> > LINK usr/bin/julia
> > PERL base/pcre_h.jl
> > PERL base/errno_h.jl
> > PERL base/build_h.jl.phony
> > PERL base/fenv_constants.jl
> > PERL base/file_constants.jl
> > PERL base/uv_constants.jl
> > PERL base/version_git.jl.phony
> > JULIA usr/lib/julia/inference.ji
> > /bin/sh: line 1: 28699 Segmentation fault  (core dumped)
> /home/paulpalm/julia/usr/bin/julia -C native --output-ji
> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
> > make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
> > make: *** [julia-inference] Error 2
> >
> >
> > On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes 
> wrote:
> > I'm compiling in both Power7 and Power8 and not yet finished. I started
> with make -j 20 but after some time, it had errors. Then I switch to make
> -j 1 but takes time to finish. I hope it will compile in both power7 and
> power8.
> >
> > I'll wait and try to check if I can fix some obvious errors. Otherwise,
> I'll ask the tarball so that I can check the difference from what I have
> specially which objects were not compiled.
> >
> > thanks.
> >
> > On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
> > Did it go through? I usually build with make -j 20 on the machines that
> have enough cores. Let me know if you still want me to create the tarball.
> Using ATLAS makes the whole thing a bit nonstandard for creating
> distributions, but I’ll see what I can do if needed.
> >
> > -viral
> >
> > > On Jul 22, 2016, at 10:50 AM, Paulito Palmes 
> wrote:
> > >
> > > Ah, forgot to update Make.user
> > >
> > >
> > > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
> wrote:
> > > Hi,
> > >
> > > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64
> #1 SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
> > >
> > > Red Hat Enterprise Linux Server release 7.2 (Maipo)
> > > --
> > > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/
> CC=gcc FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY=
> USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1
> DYNAMIC_ARCH=1 MAKE_NB_JOBS=0
> > > dynamic.c: In function ‘support_avx’:
> > > dynamic.c:107:3: 

Re: [julia-users] IBM Power port

[Paulito Palmes]

great!!! thanks very much

On Fri, Jul 22, 2016 at 8:49 PM, Viral Shah  wrote:

> I was able to sucessfully package julia. Files are here. You have to also
> download the libtatlas.so and put it on your LD_LIBRARY_PATH.
>
>
> https://drive.google.com/folderview?id=0B0rXlkvSbIfhR1RsbUV2VkpFMFk=sharing
>
> -viral
>
>
>
> > On Jul 22, 2016, at 2:51 PM, Viral Shah  wrote:
> >
> > It appears to me that you are building on some kind of a network
> filesystem and timestamps are getting messed up. Can you build in /tmp or
> somewhere, which may be guaranteed to have local storage and hence avoid
> these clock issues?
> >
> > If still doesn’t work, I will create some binaries and upload and put up
> all the instructions. Since openblas still has some issues to be fixed on
> power, I am using an ATLAS build (of which we are using the latest RC), and
> packaging it all up is going to be some work.
> >
> >
> > -viral
> >
> >
> >
> >> On Jul 22, 2016, at 1:50 PM, Paulito Palmes  wrote:
> >>
> >> This problem might be specific to Redhat? Unfortunately, I don't have
> debian-based Power system running to test.
> >>
> >> On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes 
> wrote:
> >> Here's the error using Power8: same error which happens during linking.
> >>
> >> Can you send me the tarballs of successfully compiled image in Power8?
> >>
> >> -
> >>
> >>LINK usr/lib/libjulia.so.0.5.0
> >> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> >> make[1]: Warning: File `../src/julia_version.h' has modification time
> 228 s in the future
> >>CC ui/repl.o
> >>LINK usr/bin/julia
> >> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> >>PERL base/pcre_h.jl
> >>PERL base/errno_h.jl
> >>PERL base/build_h.jl.phony
> >>PERL base/fenv_constants.jl
> >>PERL base/file_constants.jl
> >>PERL base/uv_constants.jl
> >>PERL base/version_git.jl.phony
> >>JULIA usr/lib/julia/inference.ji
> >> LLVM ERROR: unable to evaluate offset to undefined symbol ''
> >> make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji]
> Error 1
> >> make: *** [julia-inference] Error 2
> >>
> >>
> >> On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes 
> wrote:
> >> It caused a core-dump during linking ;( in Power7
> >>
> >> ...
> >> CC src/cgmemmgr.o
> >>LINK usr/lib/libjulia.so.0.5.0
> >>CC ui/repl.o
> >>LINK usr/bin/julia
> >>PERL base/pcre_h.jl
> >>PERL base/errno_h.jl
> >>PERL base/build_h.jl.phony
> >>PERL base/fenv_constants.jl
> >>PERL base/file_constants.jl
> >>PERL base/uv_constants.jl
> >>PERL base/version_git.jl.phony
> >>JULIA usr/lib/julia/inference.ji
> >> /bin/sh: line 1: 28699 Segmentation fault  (core dumped)
> /home/paulpalm/julia/usr/bin/julia -C native --output-ji
> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
> >> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
> >> make: *** [julia-inference] Error 2
> >>
> >>
> >> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes 
> wrote:
> >> I'm compiling in both Power7 and Power8 and not yet finished. I started
> with make -j 20 but after some time, it had errors. Then I switch to make
> -j 1 but takes time to finish. I hope it will compile in both power7 and
> power8.
> >>
> >> I'll wait and try to check if I can fix some obvious errors. Otherwise,
> I'll ask the tarball so that I can check the difference from what I have
> specially which objects were not compiled.
> >>
> >> thanks.
> >>
> >> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
> >> Did it go through? I usually build with make -j 20 on the machines that
> have enough cores. Let me know if you still want me to create the tarball.
> Using ATLAS makes the whole thing a bit nonstandard for creating
> distributions, but I’ll see what I can do if needed.
> >>
> >> -viral
> >>
> >>> On Jul 22, 2016, at 10:50 AM, Paulito Palmes 
> wrote:
> >>>
> >>> Ah, forgot to update Make.user
> >>>
> >>>
> >>> On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
> wrote:
> >>> Hi,
> >>>
> >>> Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64
> #1 SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
> >>>
> >>> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> >>> --
> >>> make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/
> CC=gcc FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY=
> USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1
> DYNAMIC_ARCH=1 MAKE_NB_JOBS=0
> >>> dynamic.c: In function ‘support_avx’:
> >>> dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
> [-Wimplicit-function-declaration]
> >>>   cpuid(1, , , , );
> >>>   ^
> >>> dynamic.c:97:3: 

Re: [julia-users] IBM Power port

[Viral Shah]

I was able to sucessfully package julia. Files are here. You have to also 
download the libtatlas.so and put it on your LD_LIBRARY_PATH.

https://drive.google.com/folderview?id=0B0rXlkvSbIfhR1RsbUV2VkpFMFk=sharing

-viral



> On Jul 22, 2016, at 2:51 PM, Viral Shah  wrote:
> 
> It appears to me that you are building on some kind of a network filesystem 
> and timestamps are getting messed up. Can you build in /tmp or somewhere, 
> which may be guaranteed to have local storage and hence avoid these clock 
> issues?
> 
> If still doesn’t work, I will create some binaries and upload and put up all 
> the instructions. Since openblas still has some issues to be fixed on power, 
> I am using an ATLAS build (of which we are using the latest RC), and 
> packaging it all up is going to be some work.
> 
> 
> -viral
> 
> 
> 
>> On Jul 22, 2016, at 1:50 PM, Paulito Palmes  wrote:
>> 
>> This problem might be specific to Redhat? Unfortunately, I don't have 
>> debian-based Power system running to test.
>> 
>> On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes  wrote:
>> Here's the error using Power8: same error which happens during linking.
>> 
>> Can you send me the tarballs of successfully compiled image in Power8?
>> 
>> -
>> 
>>LINK usr/lib/libjulia.so.0.5.0
>> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
>> make[1]: Warning: File `../src/julia_version.h' has modification time 228 s 
>> in the future
>>CC ui/repl.o
>>LINK usr/bin/julia
>> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
>>PERL base/pcre_h.jl
>>PERL base/errno_h.jl
>>PERL base/build_h.jl.phony
>>PERL base/fenv_constants.jl
>>PERL base/file_constants.jl
>>PERL base/uv_constants.jl
>>PERL base/version_git.jl.phony
>>JULIA usr/lib/julia/inference.ji
>> LLVM ERROR: unable to evaluate offset to undefined symbol ''
>> make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji] Error 1
>> make: *** [julia-inference] Error 2
>> 
>> 
>> On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes  wrote:
>> It caused a core-dump during linking ;( in Power7
>> 
>> ...  
>> CC src/cgmemmgr.o
>>LINK usr/lib/libjulia.so.0.5.0
>>CC ui/repl.o
>>LINK usr/bin/julia
>>PERL base/pcre_h.jl
>>PERL base/errno_h.jl
>>PERL base/build_h.jl.phony
>>PERL base/fenv_constants.jl
>>PERL base/file_constants.jl
>>PERL base/uv_constants.jl
>>PERL base/version_git.jl.phony
>>JULIA usr/lib/julia/inference.ji
>> /bin/sh: line 1: 28699 Segmentation fault  (core dumped) 
>> /home/paulpalm/julia/usr/bin/julia -C native --output-ji 
>> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
>> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
>> make: *** [julia-inference] Error 2
>> 
>> 
>> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes  wrote:
>> I'm compiling in both Power7 and Power8 and not yet finished. I started with 
>> make -j 20 but after some time, it had errors. Then I switch to make -j 1 
>> but takes time to finish. I hope it will compile in both power7 and power8.
>> 
>> I'll wait and try to check if I can fix some obvious errors. Otherwise, I'll 
>> ask the tarball so that I can check the difference from what I have 
>> specially which objects were not compiled.
>> 
>> thanks.
>> 
>> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
>> Did it go through? I usually build with make -j 20 on the machines that have 
>> enough cores. Let me know if you still want me to create the tarball. Using 
>> ATLAS makes the whole thing a bit nonstandard for creating distributions, 
>> but I’ll see what I can do if needed.
>> 
>> -viral
>> 
>>> On Jul 22, 2016, at 10:50 AM, Paulito Palmes  wrote:
>>> 
>>> Ah, forgot to update Make.user
>>> 
>>> 
>>> On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes  wrote:
>>> Hi,
>>> 
>>> Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1 SMP 
>>> Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
>>> 
>>> Red Hat Enterprise Linux Server release 7.2 (Maipo)
>>> --
>>> make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc 
>>> FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1 
>>> GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1 
>>> MAKE_NB_JOBS=0
>>> dynamic.c: In function ‘support_avx’:
>>> dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’ 
>>> [-Wimplicit-function-declaration]
>>>   cpuid(1, , , , );
>>>   ^
>>> dynamic.c:97:3: error: impossible register constraint in ‘asm’
>>>   __asm__ __volatile__
>>>   ^
>>> make[3]: *** [dynamic.o] Error 1
>>> make[2]: *** [libs] Error 1
>>> \033[33;1m*** Clean the OpenBLAS build with 'make -C deps clean-openblas'. 
>>> 

Re: [julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

['Bill Hart' via julia-users]

I found the issue. The dll is called libgmp-16.dll. But Julia expects the 
full name of the dll to be provided, i.e. libgmp-16, not just libgmp. This 
seems a bit fragile to me.

Bill.

Re: [julia-users] Composite Type Array

[Cameron McBride]

On Fri, Jul 22, 2016 at 3:09 PM, Cameron McBride 
wrote:

> julia> function get_event(v::Vector{ExampleEvent}, i)
>  n = length(v)
>  if i > n
>for j in n:i
>push!(v, ExampleEvent("",0,0,0,0,0,0)) # default values
>end
>  end
>  v[i]
>end
>

haha, that creates one extra element (ExampleEvent row) on the first pass.
Whoops. Here is a quick fix. Likely better ways to do all this, just
kicking it further.

julia> function get_event(v::Vector{ExampleEvent}, i)
 n = length(v)
 if i > n
   i1 = n > 0 ? n : 1
   for x in i1:i
   push!(v, ExampleEvent("",0,0,0,0,0,0)) # default values
   end
 end
 v[i]
   end

Cameron

Re: [julia-users] Re: Working with DataFrame columns types that are Nullable

[Jacob Quinn]

You are correct. There are properties of NullableArrays required for proper
data transfer/handling, but I still wanted users to get a familiar type
back. I'm definitely helping out with
https://github.com/JuliaStats/DataFrames.jl/pull/1008 to ensure DataFrames
gets ported over as quickly as possible.

-Jacob


On Fri, Jul 22, 2016 at 1:10 PM, John Best  wrote:

> Yeah, that's why I was surprised to get the Nullables. It's probably
> ODBC.jl anticipating the DataFrames.jl switch.
>
>
>> As far as I know, DataFrames are only backed by DataArrays. (I believe
>> there's current work being done to upgrade the speed and type stability of
>> DataFrames, in part by using Nullables.)
>>
>> It might be helpful to write a little convenience function like
>>
>> f(n) = isnull(n) ? NA : get(n)
>>
>> I will say I've found DataArrays to be super finicky when inferring
>> types. YMMV.
>>
>

Re: [julia-users] Composite Type Array

[Jared Crean]

I think what you are looking for is a constructor for your new type that 
uses incomplete initialization


type ExampleEvent

fld1::ASCIIString
fld2::Int16
fld3::Int64
fld4::Int64
fld5::Int64
fld6::Int64
fld7::Int64

function ExampleEvent(fld1, fld2)
  obj = new()  # create new object, without assigning values to 
fields
  obj.fld1 = fld1
  obj.fld2 = fld2

  return obj
end
end

  Now you can use this constructor when assigning elements to the array

   events = Vector{ExampleEvent}(1000)
   for i=1:10
  events[i] = ExampleEvent("abc", i)
   end
   events[5].fld3 = 7  # assign to previously undefined field

   Note that you will get an error if you try to read a value from a field 
that hasn't been set yet:

   event = ExampleEvent("abc", 2)
   y = event.fld3  # error, accessing undefined reference

  Best,
Jared Crean

On Friday, July 22, 2016 at 2:38:27 PM UTC-4, maxe...@gmail.com wrote:
>
>
> Thanks Cameron. 
>
> What I wanted to do was assign values to fields but the example you posted 
> requires me to pass values to all fields in my type. 
>
> If I do: events[1] = ExampleEvent("asdf",123), julia throws an error since 
> I need to pass values to ALL my type's fields. I don't always have to use 
> all fields & sometimes do not have data for all fields, thus I don't want 
> to be obligated to pass even null values to them since it is 
> verbose/excessive. Nor do I want to rewrite constructors for all fields 
> since I already have named fields for sake of programming ease. 
>
> See what I mean? 
>
> Moreover, let's say I've filled 10 elements of my 1000 element array & a 
> few milliseconds later I get a value for element 5, fld3. How do I index 
> into element 5 of the events Vector & ONLY set fld3? 
>
> Yes I've seen push! & looks good but I'm pretty religious about 
> precallocating in any lang even if it is much larger than needed since 
> processing these datasets require as much efficiency as possible.
>
> I think more intuitive Composite Type Arrays for morons like me would make 
> Juila much easier to work with since I've seen a fair amount of 
> uncertainty/confusion from people having similar conceptual use cases. I 
> know I'm thinking from a perspective of other language(s) but some language 
> constructs are there because they work & make a programmer's life easier. 
> Is there an easy way to set field value(s) whenever I get them? 
>
> On Friday, July 22, 2016 at 2:01:41 PM UTC-4, Cameron McBride wrote:
>>
>> Your ExampleEvent is completely analagous to a C-like struct. With 
>> Stefan's bit, you now have a single dimension array of ExampleEvent type 
>> (hence ndims(events) is 1). 
>>
>> You can do this:
>> julia> events[1] = ExampleEvent("asdf",2,3,4,5,6,7)
>> ExampleEvent("asdf",2,3,4,5,6,7)
>>
>> And if you have more, you can do this: 
>> julia> push!(events, ExampleEvent("ghjk", 2,3,4,5,6,7))
>> 1001-element Array{ExampleEvent,1}:
>> ExampleEvent("asdf",2,3,4,5,6,7)
>>  #undef
>>⋮
>>  #undef
>> ExampleEvent("ghjk",2,3,4,5,6,7)
>>
>> Cameron
>>
>> On Fri, Jul 22, 2016 at 1:48 PM,  wrote:
>>
>>> Thanks Stefan!
>>>
>>> I thought it would be like declaring a struct array in c/c++ i.e. 
>>> something like ExampleEvent events[2][1000]; Then set each field in the 
>>> events array as I encounter the required value in my algo: e.g. 
>>> events[1][1].fld1 = "ABC";  events[1][1].fld2 = 123;   etc
>>>
>>> How do I access elements in the events Vector since ndims(events) = 1? I 
>>> don't see anything in the docs about indexing into a preallocated Vector 
>>> data structure. I see methods like push! splice! etc but not anything that 
>>> will let me use the elements of my preallocation on the fly. 
>>>
>>>
>>> On Thursday, July 21, 2016 at 3:21:54 PM UTC-4, Stefan Karpinski wrote:

 It's a little unclear what you want to do that you can't figure out how 
 to accomplish. You can allocate an uninitialized vector of ExampleEvent 
 objects:

 julia> type ExampleEvent
fld1::ASCIIString
fld2::Int16
fld3::Int64
fld4::Int64
fld5::Int64
fld6::Int64
fld7::Int64
end

 julia> events = Vector{ExampleEvent}(1000)
 1000-element Array{ExampleEvent,1}:
  #undef
  #undef
  #undef
⋮
  #undef
  #undef
  #undef




 On Thu, Jul 21, 2016 at 2:51 PM,  wrote:

>
> Hi 
>
> I was working on processing large data sets & historically I've used 
> structs in C++ & other languages for this type of task. I attempted to 
> use 
> a Composite Type in Julia & preallocate a large array before filling it 
> w/values as my algo processes the data. 
>
> My example was:
>
> type 

Re: [julia-users] IBM Power port

[Viral Shah]

It appears to me that you are building on some kind of a network filesystem and 
timestamps are getting messed up. Can you build in /tmp or somewhere, which may 
be guaranteed to have local storage and hence avoid these clock issues?

If still doesn’t work, I will create some binaries and upload and put up all 
the instructions. Since openblas still has some issues to be fixed on power, I 
am using an ATLAS build (of which we are using the latest RC), and packaging it 
all up is going to be some work.


-viral



> On Jul 22, 2016, at 1:50 PM, Paulito Palmes  wrote:
> 
> This problem might be specific to Redhat? Unfortunately, I don't have 
> debian-based Power system running to test.
> 
> On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes  wrote:
> Here's the error using Power8: same error which happens during linking.
> 
> Can you send me the tarballs of successfully compiled image in Power8?
> 
> -
> 
> LINK usr/lib/libjulia.so.0.5.0
> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> make[1]: Warning: File `../src/julia_version.h' has modification time 228 s 
> in the future
> CC ui/repl.o
> LINK usr/bin/julia
> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> LLVM ERROR: unable to evaluate offset to undefined symbol ''
> make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji] Error 1
> make: *** [julia-inference] Error 2
> 
> 
> On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes  wrote:
> It caused a core-dump during linking ;( in Power7
> 
> ...  
> CC src/cgmemmgr.o
> LINK usr/lib/libjulia.so.0.5.0
> CC ui/repl.o
> LINK usr/bin/julia
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> /bin/sh: line 1: 28699 Segmentation fault  (core dumped) 
> /home/paulpalm/julia/usr/bin/julia -C native --output-ji 
> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
> make: *** [julia-inference] Error 2
> 
> 
> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes  wrote:
> I'm compiling in both Power7 and Power8 and not yet finished. I started with 
> make -j 20 but after some time, it had errors. Then I switch to make -j 1 but 
> takes time to finish. I hope it will compile in both power7 and power8.
> 
> I'll wait and try to check if I can fix some obvious errors. Otherwise, I'll 
> ask the tarball so that I can check the difference from what I have specially 
> which objects were not compiled.
> 
> thanks.
> 
> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
> Did it go through? I usually build with make -j 20 on the machines that have 
> enough cores. Let me know if you still want me to create the tarball. Using 
> ATLAS makes the whole thing a bit nonstandard for creating distributions, but 
> I’ll see what I can do if needed.
> 
> -viral
> 
> > On Jul 22, 2016, at 10:50 AM, Paulito Palmes  wrote:
> >
> > Ah, forgot to update Make.user
> >
> >
> > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes  wrote:
> > Hi,
> >
> > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1 SMP 
> > Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
> >
> > Red Hat Enterprise Linux Server release 7.2 (Maipo)
> > --
> > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc 
> > FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1 
> > GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1 
> > MAKE_NB_JOBS=0
> > dynamic.c: In function ‘support_avx’:
> > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’ 
> > [-Wimplicit-function-declaration]
> >cpuid(1, , , , );
> >^
> > dynamic.c:97:3: error: impossible register constraint in ‘asm’
> >__asm__ __volatile__
> >^
> > make[3]: *** [dynamic.o] Error 1
> > make[2]: *** [libs] Error 1
> > \033[33;1m*** Clean the OpenBLAS build with 'make -C deps clean-openblas'. 
> > Rebuild with 'make OPENBLAS_USE_THREAD=0' if OpenBLAS had trouble linking 
> > libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were 
> > errors building SandyBridge support. Both these options can also be used 
> > simultaneously. ***\033[0m
> > make[1]: *** 
> > [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so] 
> > Error 1
> > make: *** 

Re: [julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

['Bill Hart' via julia-users]

The errors are precisely the same if I invoke Julia with --inline=no.

Bill.

On 22 July 2016 at 20:25, Bill Hart  wrote:

> What's totally bizarre about this, apart from the lack of traceback
> information, is that this is precisely the same as the code used in Julia
> itself in gmp.jl.
>
> Bill.
>
> On 22 July 2016 at 20:09, 'Bill Hart' via julia-users <
> julia-users@googlegroups.com> wrote:
>
>> I've narrowed it down to an issue in the following snippet of code which
>> is in __init__ in our package:
>>
>>ccall((:__gmp_set_memory_functions, libgmp), Void,
>>   (Ptr{Void},Ptr{Void},Ptr{Void}),
>>   cglobal(:jl_gc_counted_malloc),
>>   cglobal(:jl_gc_counted_realloc_with_old_size),
>>   cglobal(:jl_gc_counted_free))
>>
>> Can anyone see what could possibly be wrong with this? It works just fine
>> on Linux, but not Windows 64.
>>
>> Note, we define libgmp as follows (which I am sure is correct):
>>
>> const pkgdir = realpath(joinpath(dirname(@__FILE__), ".."))
>> const libdir = joinpath(pkgdir, "local", "lib")
>> const libgmp = joinpath(pkgdir, "local", "lib", "libgmp")
>>
>> Bill.
>>
>
>

Re: [julia-users] Composite Type Array

[maxent219]

Thanks Cameron. 

What I wanted to do was assign values to fields but the example you posted 
requires me to pass values to all fields in my type. 

If I do: events[1] = ExampleEvent("asdf",123), julia throws an error since 
I need to pass values to ALL my type's fields. I don't always have to use 
all fields & sometimes do not have data for all fields, thus I don't want 
to be obligated to pass even null values to them since it is 
verbose/excessive. Nor do I want to rewrite constructors for all fields 
since I already have named fields for sake of programming ease. 

See what I mean? 

Moreover, let's say I've filled 10 elements of my 1000 element array & a 
few milliseconds later I get a value for element 5, fld3. How do I index 
into element 5 of the events Vector & ONLY set fld3? 

Yes I've seen push! & looks good but I'm pretty religious about 
precallocating in any lang even if it is much larger than needed since 
processing these datasets require as much efficiency as possible.

I think more intuitive Composite Type Arrays for morons like me would make 
Juila much easier to work with since I've seen a fair amount of 
uncertainty/confusion from people having similar conceptual use cases. I 
know I'm thinking from a perspective of other language(s) but some language 
constructs are there because they work & make a programmer's life easier. 
Is there an easy way to set field value(s) whenever I get them? 

On Friday, July 22, 2016 at 2:01:41 PM UTC-4, Cameron McBride wrote:
>
> Your ExampleEvent is completely analagous to a C-like struct. With 
> Stefan's bit, you now have a single dimension array of ExampleEvent type 
> (hence ndims(events) is 1). 
>
> You can do this:
> julia> events[1] = ExampleEvent("asdf",2,3,4,5,6,7)
> ExampleEvent("asdf",2,3,4,5,6,7)
>
> And if you have more, you can do this: 
> julia> push!(events, ExampleEvent("ghjk", 2,3,4,5,6,7))
> 1001-element Array{ExampleEvent,1}:
> ExampleEvent("asdf",2,3,4,5,6,7)
>  #undef
>⋮
>  #undef
> ExampleEvent("ghjk",2,3,4,5,6,7)
>
> Cameron
>
> On Fri, Jul 22, 2016 at 1:48 PM,  wrote:
>
>> Thanks Stefan!
>>
>> I thought it would be like declaring a struct array in c/c++ i.e. 
>> something like ExampleEvent events[2][1000]; Then set each field in the 
>> events array as I encounter the required value in my algo: e.g. 
>> events[1][1].fld1 = "ABC";  events[1][1].fld2 = 123;   etc
>>
>> How do I access elements in the events Vector since ndims(events) = 1? I 
>> don't see anything in the docs about indexing into a preallocated Vector 
>> data structure. I see methods like push! splice! etc but not anything that 
>> will let me use the elements of my preallocation on the fly. 
>>
>>
>> On Thursday, July 21, 2016 at 3:21:54 PM UTC-4, Stefan Karpinski wrote:
>>>
>>> It's a little unclear what you want to do that you can't figure out how 
>>> to accomplish. You can allocate an uninitialized vector of ExampleEvent 
>>> objects:
>>>
>>> julia> type ExampleEvent
>>>fld1::ASCIIString
>>>fld2::Int16
>>>fld3::Int64
>>>fld4::Int64
>>>fld5::Int64
>>>fld6::Int64
>>>fld7::Int64
>>>end
>>>
>>> julia> events = Vector{ExampleEvent}(1000)
>>> 1000-element Array{ExampleEvent,1}:
>>>  #undef
>>>  #undef
>>>  #undef
>>>⋮
>>>  #undef
>>>  #undef
>>>  #undef
>>>
>>>
>>>
>>>
>>> On Thu, Jul 21, 2016 at 2:51 PM,  wrote:
>>>

 Hi 

 I was working on processing large data sets & historically I've used 
 structs in C++ & other languages for this type of task. I attempted to use 
 a Composite Type in Julia & preallocate a large array before filling it 
 w/values as my algo processes the data. 

 My example was:

 type ExampleEvent

 fld1::ASCIIString
 fld2::Int16
 fld3::Int64
 fld4::Int64
 fld5::Int64
 fld6::Int64
 fld7::Int64

 end

 I googled around & from what I found, & all the docs examples I tried 
 out, there isn't an obvious way to declare an array of composite type 
 without having to do some work arounds. 

 I liked the language in several other respects but it seems to be 
 missing helpful tools to make the programmer's life easy. Am I missing 
 something? If not, why is a data structure like this not easily available? 

 thanks in advance

 best,
 A 

>>>
>>>
>

[julia-users] Re: A workaround to use "." to access class member functions - is it unJulian?

[Jeffrey Sarnoff]

(big step ..!)

On Friday, July 22, 2016 at 2:28:09 PM UTC-4, Zhong Pan wrote:
>
> OK, I admit, it's ugly. :-) 
>
> Now I realize it's also wrong. In the example, the 
> inner-constructor-created member function split() cannot see member 
> variable "N"; it can only see parameter "n" that is passed in from outside. 
> If the code changes N later on, the split() function will be using a stale 
> value. 
>
>
>

Re: [julia-users] IBM Power port

[Paulito Palmes]

It caused a core-dump during linking ;( in Power7

...
CC src/cgmemmgr.o
LINK usr/lib/libjulia.so.0.5.0
CC ui/repl.o
LINK usr/bin/julia
PERL base/pcre_h.jl
PERL base/errno_h.jl
PERL base/build_h.jl.phony
PERL base/fenv_constants.jl
PERL base/file_constants.jl
PERL base/uv_constants.jl
PERL base/version_git.jl.phony
JULIA usr/lib/julia/inference.ji
/bin/sh: line 1: 28699 Segmentation fault  (core dumped)
/home/paulpalm/julia/usr/bin/julia -C native --output-ji
/home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
make: *** [julia-inference] Error 2


On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes  wrote:

> I'm compiling in both Power7 and Power8 and not yet finished. I started
> with make -j 20 but after some time, it had errors. Then I switch to make
> -j 1 but takes time to finish. I hope it will compile in both power7 and
> power8.
>
> I'll wait and try to check if I can fix some obvious errors. Otherwise,
> I'll ask the tarball so that I can check the difference from what I have
> specially which objects were not compiled.
>
> thanks.
>
> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
>
>> Did it go through? I usually build with make -j 20 on the machines that
>> have enough cores. Let me know if you still want me to create the tarball.
>> Using ATLAS makes the whole thing a bit nonstandard for creating
>> distributions, but I’ll see what I can do if needed.
>>
>> -viral
>>
>> > On Jul 22, 2016, at 10:50 AM, Paulito Palmes  wrote:
>> >
>> > Ah, forgot to update Make.user
>> >
>> >
>> > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
>> wrote:
>> > Hi,
>> >
>> > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1
>> SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
>> >
>> > Red Hat Enterprise Linux Server release 7.2 (Maipo)
>> > --
>> > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc
>> FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1
>> GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1
>> MAKE_NB_JOBS=0
>> > dynamic.c: In function ‘support_avx’:
>> > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
>> [-Wimplicit-function-declaration]
>> >cpuid(1, , , , );
>> >^
>> > dynamic.c:97:3: error: impossible register constraint in ‘asm’
>> >__asm__ __volatile__
>> >^
>> > make[3]: *** [dynamic.o] Error 1
>> > make[2]: *** [libs] Error 1
>> > \033[33;1m*** Clean the OpenBLAS build with 'make -C deps
>> clean-openblas'. Rebuild with 'make OPENBLAS_USE_THREAD=0' if OpenBLAS had
>> trouble linking libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM'
>> if there were errors building SandyBridge support. Both these options can
>> also be used simultaneously. ***\033[0m
>> > make[1]: ***
>> [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
>> Error 1
>> > make: *** [julia-deps] Error 2
>> > --
>> >
>> > On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes 
>> wrote:
>> > Hi Viral,
>> >
>> > uname -a is:
>> > > Linux abc.com 3.10.0-327.18.2.el7.ppc64le #1 SMP Fri Apr 8 05:10:45
>> EDT 2016 ppc64le ppc64le ppc64le GNU/Linux
>> >
>> > and using Power8: Red Hat Enterprise Linux Server release 7.2 (Maipo)
>> >
>> >
>> > Can you send me the tarball image of Julia compiled in Power8? I would
>> like to test it if the problem is only during compilation. Since I have no
>> git access on this machine, I used make -C deps getall to pull the deps
>> before copying the source files to Power8. It may be possible the deps were
>> not properly resolved?
>> >
>> > On Fri, Jul 22, 2016 at 1:58 PM, Viral Shah  wrote:
>> > Not sure what to do here. Is the filesystem NFS or something? Perhaps
>> just try building again with make -j 1.
>> >
>> > What is uname -a?
>> >
>> > -viral
>> >
>> >
>> > On Jul 22, 2016 8:52 AM, "Paulito Palmes"  wrote:
>> > Hi,
>> >
>> > I'm compiling using Red Hat Enterprise Linux Server release 7.2 in
>> Power8 and I got this error:
>> >
>> > ./julia/usr/lib64/libunwind*.a: No such file or directory
>> >
>> >
>> > the make process didn't create usr/lib64 and the libunwind*.a are in
>> usr/lib
>> >
>> > I created the links of libunwind*.a in usr/lib64
>> >
>> > but got these errors during compile:
>> >
>> > make[2]: Warning: File
>> `/home/paulpalm/julia/deps/srccache/patchelf-0.9/aclocal.m4' has
>> modification time 293 s in the future
>> >
>> >  cd /home/paulpalm/julia/deps/srccache/patchelf-0.9 && /bin/sh
>> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing
>> automake-1.15 --foreign
>> >
>> > /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing: line
>> 81: automake-1.15: command not found
>> >
>> > WARNING: 

Re: [julia-users] IBM Power port

[Paulito Palmes]

This problem might be specific to Redhat? Unfortunately, I don't have
debian-based Power system running to test.

On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes  wrote:

> Here's the error using Power8: same error which happens during linking.
>
> Can you send me the tarballs of successfully compiled image in Power8?
>
> -
>
> LINK usr/lib/libjulia.so.0.5.0
> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> make[1]: Warning: File `../src/julia_version.h' has modification time 228
> s in the future
> CC ui/repl.o
> LINK usr/bin/julia
> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> LLVM ERROR: unable to evaluate offset to undefined symbol ''
> make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji]
> Error 1
> make: *** [julia-inference] Error 2
>
>
> On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes  wrote:
>
>> It caused a core-dump during linking ;( in Power7
>>
>> ...
>> CC src/cgmemmgr.o
>> LINK usr/lib/libjulia.so.0.5.0
>> CC ui/repl.o
>> LINK usr/bin/julia
>> PERL base/pcre_h.jl
>> PERL base/errno_h.jl
>> PERL base/build_h.jl.phony
>> PERL base/fenv_constants.jl
>> PERL base/file_constants.jl
>> PERL base/uv_constants.jl
>> PERL base/version_git.jl.phony
>> JULIA usr/lib/julia/inference.ji
>> /bin/sh: line 1: 28699 Segmentation fault  (core dumped)
>> /home/paulpalm/julia/usr/bin/julia -C native --output-ji
>> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
>> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
>> make: *** [julia-inference] Error 2
>>
>>
>> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes 
>> wrote:
>>
>>> I'm compiling in both Power7 and Power8 and not yet finished. I started
>>> with make -j 20 but after some time, it had errors. Then I switch to make
>>> -j 1 but takes time to finish. I hope it will compile in both power7 and
>>> power8.
>>>
>>> I'll wait and try to check if I can fix some obvious errors. Otherwise,
>>> I'll ask the tarball so that I can check the difference from what I have
>>> specially which objects were not compiled.
>>>
>>> thanks.
>>>
>>> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
>>>
 Did it go through? I usually build with make -j 20 on the machines that
 have enough cores. Let me know if you still want me to create the tarball.
 Using ATLAS makes the whole thing a bit nonstandard for creating
 distributions, but I’ll see what I can do if needed.

 -viral

 > On Jul 22, 2016, at 10:50 AM, Paulito Palmes 
 wrote:
 >
 > Ah, forgot to update Make.user
 >
 >
 > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
 wrote:
 > Hi,
 >
 > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64
 #1 SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
 >
 > Red Hat Enterprise Linux Server release 7.2 (Maipo)
 > --
 > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/
 CC=gcc FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY=
 USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1
 DYNAMIC_ARCH=1 MAKE_NB_JOBS=0
 > dynamic.c: In function ‘support_avx’:
 > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
 [-Wimplicit-function-declaration]
 >cpuid(1, , , , );
 >^
 > dynamic.c:97:3: error: impossible register constraint in ‘asm’
 >__asm__ __volatile__
 >^
 > make[3]: *** [dynamic.o] Error 1
 > make[2]: *** [libs] Error 1
 > \033[33;1m*** Clean the OpenBLAS build with 'make -C deps
 clean-openblas'. Rebuild with 'make OPENBLAS_USE_THREAD=0' if OpenBLAS had
 trouble linking libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM'
 if there were errors building SandyBridge support. Both these options can
 also be used simultaneously. ***\033[0m
 > make[1]: ***
 [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
 Error 1
 > make: *** [julia-deps] Error 2
 > --
 >
 > On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes 
 wrote:
 > Hi Viral,
 >
 > uname -a is:
 > > Linux abc.com 3.10.0-327.18.2.el7.ppc64le #1 SMP Fri Apr 8
 05:10:45 EDT 2016 ppc64le ppc64le ppc64le GNU/Linux
 >
 > and using Power8: Red Hat Enterprise Linux Server release 7.2 (Maipo)
 >
 >
 > Can you send me the tarball image of 

Re: [julia-users] IBM Power port

[Paulito Palmes]

Here's the error using Power8: same error which happens during linking.

Can you send me the tarballs of successfully compiled image in Power8?

-

LINK usr/lib/libjulia.so.0.5.0
make[1]: warning:  Clock skew detected.  Your build may be incomplete.
make[1]: Warning: File `../src/julia_version.h' has modification time 228 s
in the future
CC ui/repl.o
LINK usr/bin/julia
make[1]: warning:  Clock skew detected.  Your build may be incomplete.
PERL base/pcre_h.jl
PERL base/errno_h.jl
PERL base/build_h.jl.phony
PERL base/fenv_constants.jl
PERL base/file_constants.jl
PERL base/uv_constants.jl
PERL base/version_git.jl.phony
JULIA usr/lib/julia/inference.ji
LLVM ERROR: unable to evaluate offset to undefined symbol ''
make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji] Error
1
make: *** [julia-inference] Error 2


On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes  wrote:

> It caused a core-dump during linking ;( in Power7
>
> ...
> CC src/cgmemmgr.o
> LINK usr/lib/libjulia.so.0.5.0
> CC ui/repl.o
> LINK usr/bin/julia
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> /bin/sh: line 1: 28699 Segmentation fault  (core dumped)
> /home/paulpalm/julia/usr/bin/julia -C native --output-ji
> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
> make: *** [julia-inference] Error 2
>
>
> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes  wrote:
>
>> I'm compiling in both Power7 and Power8 and not yet finished. I started
>> with make -j 20 but after some time, it had errors. Then I switch to make
>> -j 1 but takes time to finish. I hope it will compile in both power7 and
>> power8.
>>
>> I'll wait and try to check if I can fix some obvious errors. Otherwise,
>> I'll ask the tarball so that I can check the difference from what I have
>> specially which objects were not compiled.
>>
>> thanks.
>>
>> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
>>
>>> Did it go through? I usually build with make -j 20 on the machines that
>>> have enough cores. Let me know if you still want me to create the tarball.
>>> Using ATLAS makes the whole thing a bit nonstandard for creating
>>> distributions, but I’ll see what I can do if needed.
>>>
>>> -viral
>>>
>>> > On Jul 22, 2016, at 10:50 AM, Paulito Palmes 
>>> wrote:
>>> >
>>> > Ah, forgot to update Make.user
>>> >
>>> >
>>> > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
>>> wrote:
>>> > Hi,
>>> >
>>> > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64
>>> #1 SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
>>> >
>>> > Red Hat Enterprise Linux Server release 7.2 (Maipo)
>>> > --
>>> > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/
>>> CC=gcc FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY=
>>> USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1
>>> DYNAMIC_ARCH=1 MAKE_NB_JOBS=0
>>> > dynamic.c: In function ‘support_avx’:
>>> > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
>>> [-Wimplicit-function-declaration]
>>> >cpuid(1, , , , );
>>> >^
>>> > dynamic.c:97:3: error: impossible register constraint in ‘asm’
>>> >__asm__ __volatile__
>>> >^
>>> > make[3]: *** [dynamic.o] Error 1
>>> > make[2]: *** [libs] Error 1
>>> > \033[33;1m*** Clean the OpenBLAS build with 'make -C deps
>>> clean-openblas'. Rebuild with 'make OPENBLAS_USE_THREAD=0' if OpenBLAS had
>>> trouble linking libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM'
>>> if there were errors building SandyBridge support. Both these options can
>>> also be used simultaneously. ***\033[0m
>>> > make[1]: ***
>>> [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
>>> Error 1
>>> > make: *** [julia-deps] Error 2
>>> > --
>>> >
>>> > On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes 
>>> wrote:
>>> > Hi Viral,
>>> >
>>> > uname -a is:
>>> > > Linux abc.com 3.10.0-327.18.2.el7.ppc64le #1 SMP Fri Apr 8 05:10:45
>>> EDT 2016 ppc64le ppc64le ppc64le GNU/Linux
>>> >
>>> > and using Power8: Red Hat Enterprise Linux Server release 7.2 (Maipo)
>>> >
>>> >
>>> > Can you send me the tarball image of Julia compiled in Power8? I would
>>> like to test it if the problem is only during compilation. Since I have no
>>> git access on this machine, I used make -C deps getall to pull the deps
>>> before copying the source files to Power8. It may be possible the deps were
>>> not properly resolved?
>>> >
>>> > On Fri, Jul 22, 2016 at 1:58 PM, 

Re: [julia-users] IBM Power port

[Paulito Palmes]

I'm compiling in both Power7 and Power8 and not yet finished. I started
with make -j 20 but after some time, it had errors. Then I switch to make
-j 1 but takes time to finish. I hope it will compile in both power7 and
power8.

I'll wait and try to check if I can fix some obvious errors. Otherwise,
I'll ask the tarball so that I can check the difference from what I have
specially which objects were not compiled.

thanks.

On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:

> Did it go through? I usually build with make -j 20 on the machines that
> have enough cores. Let me know if you still want me to create the tarball.
> Using ATLAS makes the whole thing a bit nonstandard for creating
> distributions, but I’ll see what I can do if needed.
>
> -viral
>
> > On Jul 22, 2016, at 10:50 AM, Paulito Palmes  wrote:
> >
> > Ah, forgot to update Make.user
> >
> >
> > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
> wrote:
> > Hi,
> >
> > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1
> SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
> >
> > Red Hat Enterprise Linux Server release 7.2 (Maipo)
> > --
> > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc
> FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1
> GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1
> MAKE_NB_JOBS=0
> > dynamic.c: In function ‘support_avx’:
> > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
> [-Wimplicit-function-declaration]
> >cpuid(1, , , , );
> >^
> > dynamic.c:97:3: error: impossible register constraint in ‘asm’
> >__asm__ __volatile__
> >^
> > make[3]: *** [dynamic.o] Error 1
> > make[2]: *** [libs] Error 1
> > \033[33;1m*** Clean the OpenBLAS build with 'make -C deps
> clean-openblas'. Rebuild with 'make OPENBLAS_USE_THREAD=0' if OpenBLAS had
> trouble linking libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM'
> if there were errors building SandyBridge support. Both these options can
> also be used simultaneously. ***\033[0m
> > make[1]: ***
> [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
> Error 1
> > make: *** [julia-deps] Error 2
> > --
> >
> > On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes 
> wrote:
> > Hi Viral,
> >
> > uname -a is:
> > > Linux abc.com 3.10.0-327.18.2.el7.ppc64le #1 SMP Fri Apr 8 05:10:45
> EDT 2016 ppc64le ppc64le ppc64le GNU/Linux
> >
> > and using Power8: Red Hat Enterprise Linux Server release 7.2 (Maipo)
> >
> >
> > Can you send me the tarball image of Julia compiled in Power8? I would
> like to test it if the problem is only during compilation. Since I have no
> git access on this machine, I used make -C deps getall to pull the deps
> before copying the source files to Power8. It may be possible the deps were
> not properly resolved?
> >
> > On Fri, Jul 22, 2016 at 1:58 PM, Viral Shah  wrote:
> > Not sure what to do here. Is the filesystem NFS or something? Perhaps
> just try building again with make -j 1.
> >
> > What is uname -a?
> >
> > -viral
> >
> >
> > On Jul 22, 2016 8:52 AM, "Paulito Palmes"  wrote:
> > Hi,
> >
> > I'm compiling using Red Hat Enterprise Linux Server release 7.2 in
> Power8 and I got this error:
> >
> > ./julia/usr/lib64/libunwind*.a: No such file or directory
> >
> >
> > the make process didn't create usr/lib64 and the libunwind*.a are in
> usr/lib
> >
> > I created the links of libunwind*.a in usr/lib64
> >
> > but got these errors during compile:
> >
> > make[2]: Warning: File
> `/home/paulpalm/julia/deps/srccache/patchelf-0.9/aclocal.m4' has
> modification time 293 s in the future
> >
> >  cd /home/paulpalm/julia/deps/srccache/patchelf-0.9 && /bin/sh
> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing
> automake-1.15 --foreign
> >
> > /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing: line
> 81: automake-1.15: command not found
> >
> > WARNING: 'automake-1.15' is missing on your system.
> >
> >  You should only need it if you modified 'Makefile.am' or
> >
> >  'configure.ac' or m4 files included by 'configure.ac'.
> >
> >  The 'automake' program is part of the GNU Automake package:
> >
> >  
> >
> >  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
> >
> >  
> >
> >  
> >
> >  
> >
> > make[2]: *** [julia/deps/srccache/patchelf-0.9/Makefile.in] Error 1
> >
> > make[1]: *** [build/patchelf-0.9/src/patchelf] Error 2
> >
> > make: *** [julia-deps] Error 2
> >
> >
> > I have automake-1.13 while it looks for automake-1.15.
> >
> > On Wednesday, 20 July 2016 20:57:36 UTC+1, Viral Shah wrote:
> > Just a heads up, there is a 

[julia-users] Re: A workaround to use "." to access class member functions - is it unJulian?

[Zhong Pan]

OK, I admit, it's ugly. :-) 

Now I realize it's also wrong. In the example, the 
inner-constructor-created member function split() cannot see member 
variable "N"; it can only see parameter "n" that is passed in from outside. 
If the code changes N later on, the split() function will be using a stale 
value. 

Re: [julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

['Bill Hart' via julia-users]

What's totally bizarre about this, apart from the lack of traceback
information, is that this is precisely the same as the code used in Julia
itself in gmp.jl.

Bill.

On 22 July 2016 at 20:09, 'Bill Hart' via julia-users <
julia-users@googlegroups.com> wrote:

> I've narrowed it down to an issue in the following snippet of code which
> is in __init__ in our package:
>
>ccall((:__gmp_set_memory_functions, libgmp), Void,
>   (Ptr{Void},Ptr{Void},Ptr{Void}),
>   cglobal(:jl_gc_counted_malloc),
>   cglobal(:jl_gc_counted_realloc_with_old_size),
>   cglobal(:jl_gc_counted_free))
>
> Can anyone see what could possibly be wrong with this? It works just fine
> on Linux, but not Windows 64.
>
> Note, we define libgmp as follows (which I am sure is correct):
>
> const pkgdir = realpath(joinpath(dirname(@__FILE__), ".."))
> const libdir = joinpath(pkgdir, "local", "lib")
> const libgmp = joinpath(pkgdir, "local", "lib", "libgmp")
>
> Bill.
>

[julia-users] Re: Strange performance issue in filling in a matrix column

[Michael Prange]

Gunnar,

Thank you for your explanation of the extra allocations and the tip about 
sub. I implemented a version with sub as fill_W3!:

function fill_W3!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
ishift::Int)
@assert(size(W,1) == length(w), "Dimension mismatch between W and w")
W[(ishift+1):end,icol] = sub(w, 1:(length(w)-ishift))
W[1:ishift,icol] = sub(w, (length(w)-ishift+1):length(w))
return
end

Is this what you had in mind? I reran the tests above (with new random 
numbers) and had the following results:

fill_W!: 0.003234 seconds (4 allocations: 160 bytes) 
fill_W1!: 0.005898 seconds (9 allocations: 7.630 MB) 
fill_W2!: 0.005904 seconds (7 allocations: 7.630 MB) 
fill_W3!: 0.002347 seconds (8 allocations: 352 bytes)

Using sub consistently achieves better times that fill_W!, even through it uses 
twice the number of allocations than fill_W!. This seems to be the way to go.


Michael


On Thursday, July 21, 2016 at 5:35:47 PM UTC-4, Gunnar Farnebäck wrote:
>
> fill_W1! allocates memory because it makes copies when constructing the 
> right hand sides. fill_W2 allocates memory in order to construct the 
> comprehensions (that you then discard). In both cases memory allocation 
> could plausibly be avoided by a sufficiently smart compiler, but until 
> Julia becomes that smart, have a look at the sub function to provide views 
> instead of copies for the right hand sides of fill_W1!.
>
> On Thursday, July 21, 2016 at 5:07:34 PM UTC+2, Michael Prange wrote:
>>
>> I'm a new user, so have mercy in your responses. 
>>
>> I've written a method that takes a matrix and vector as input and then 
>> fills in column icol of that matrix with the vector of given values that 
>> have been shifted upward by ishift indices with periodic boundary 
>> conditions. To make this clear, given the matrix
>>
>> W = [1  2
>> 3  4
>> 5  6]
>>
>> the vector w = [7  8  9], icol = 2 and ishift = 1, the new value of W is 
>> given by
>>
>> W = [1  8
>> 3  9
>> 5  7]
>>
>> I need a fast way of doing this for large matrices. I wrote three methods 
>> that should (In my naive mind) give the same performance results, but @time 
>> reports otherwise.  The method definitions and the performance results are 
>> given below. Can someone teach me why the results are so different? The 
>> method fill_W! is too wordy for my tastes, but the more compact notation in 
>> fill_W1! and fill_W2! achieve poorer results. Any why do these latter two 
>> methods allocate so much memory when the whole point of these methods is to 
>> use already-allocated memory.
>>
>> Michael
>>
>> ### Definitions
>>
>>
>> function fill_W1!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
>> ishift::Int)
>> @assert(size(W,1) == length(w), "Dimension mismatch between W and w")
>> W[1:(end-ishift),icol] = w[(ishift+1):end]
>> W[(end-(ishift-1)):end,icol] = w[1:ishift]
>> return
>> end
>>
>>
>> function fill_W2!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
>> ishift::Int)
>> @assert(size(W,1) == length(w), "Dimension mismatch between W and w")
>> [W[i,icol] = w[i+ishift] for i in 1:(length(w)-ishift)]
>> [W[end-ishift+i,icol] = w[i] for i in 1:ishift]
>> return
>> end
>>
>>
>> function fill_W!{TF}(W::Matrix{TF}, icol::Int, w::Vector{TF}, 
>> ishift::Int)
>> @assert(size(W,1) == length(w), "Dimension mismatch between W and w")
>> n = length(w)
>> for j in 1:(n-ishift)
>> W[j,icol] = w[j+ishift]
>> end
>> for j in (n-(ishift-1)):n
>> W[j,icol] = w[j-(n-ishift)]
>> end
>> end
>>
>>
>> # Performance Results
>> julia>
>> W = rand(100,2)
>> w = rand(100)
>> println("fill_W!:")
>> println(@time fill_W!(W, 2, w, 2))
>> println("fill_W1!:")
>> println(@time fill_W1!(W, 2, w, 2))
>> println("fill_W2!:")
>> println(@time fill_W2!(W, 2, w, 2))
>>
>>
>> Out>
>> fill_W!:
>>  0.002801 seconds (4 allocations: 160 bytes)
>> nothing
>> fill_W1!:
>>  0.007427 seconds (9 allocations: 7.630 MB)
>> [0.152463397611579,0.6314166578356002]
>> fill_W2!:
>>  0.005587 seconds (7 allocations: 7.630 MB)
>> [0.152463397611579,0.6314166578356002]
>>
>>
>>

Re: [julia-users] Pipeline interoperability with IOStream and IOBuffer

[William Wong]

To add to that, this discussion had actually initially started out on 
Julia-Users
https://groups.google.com/forum/#!searchin/julia-users/pipeline$20iostream/julia-users/-66VWszB-mM/b9wno137BgAJ

I was also hoping that someone could help me with this question here:

> In either case, it seems that I need an IOStream to pipe data into a 
> pipeline command. How can I turn data into a stream that is not a file?
> https://groups.google.com/forum/#!msg/julia-users/R-F3F97leh4/o4zKINZbbvUJ 
> asks 
> a similar question but readall produces a string, I still need to stream it 
> into a pipeline command.
>

On Friday, July 22, 2016 at 8:55:44 AM UTC-4, Tom Breloff wrote:
>
> To be fair, he was told, in that issue, that julia-users was a more 
> appropriate place to ask this type of question. 
>
> On Friday, July 22, 2016, Steven G. Johnson  > wrote:
>
>>
>>
>> On Thursday, July 21, 2016 at 6:09:12 PM UTC-4, William Wong wrote:
>>>
>>> I'm trying to continue the discussion of 
>>> https://github.com/JuliaLang/julia/issues/15479
>>>
>>
>> The github issue is the appropriate place for discussion; it's not 
>> helpful to split the discussion into two separate forums. 
>>
>> (If you want to see progress on an issue, the most effective way is to 
>> submit a pull request attempting to fix the issue.)
>>
>

[julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

['Bill Hart' via julia-users]

I've narrowed it down to an issue in the following snippet of code which is 
in __init__ in our package:

   ccall((:__gmp_set_memory_functions, libgmp), Void,
  (Ptr{Void},Ptr{Void},Ptr{Void}),
  cglobal(:jl_gc_counted_malloc),
  cglobal(:jl_gc_counted_realloc_with_old_size),
  cglobal(:jl_gc_counted_free))

Can anyone see what could possibly be wrong with this? It works just fine 
on Linux, but not Windows 64.

Note, we define libgmp as follows (which I am sure is correct):

const pkgdir = realpath(joinpath(dirname(@__FILE__), ".."))
const libdir = joinpath(pkgdir, "local", "lib")
const libgmp = joinpath(pkgdir, "local", "lib", "libgmp")

Bill.

Re: [julia-users] Re: A workaround to use "." to access class member functions - is it unJulian?

[Tom Breloff]

In julia 0.4, I think this would be considered both slow and ugly.  Since
the improvements to anonymous functions in 0.5, it's now only ugly.  :)

I think you'll find a lot of benefit if you forget about OO-programming,
and use multiple dispatch.  "You must unlearn what you have learned!"

On Fri, Jul 22, 2016 at 1:19 PM, Jeffrey Sarnoff 
wrote:

> Too much riffle-raffle for the gain you mention (imo).
>
>
> On Friday, July 22, 2016 at 1:01:42 PM UTC-4, Zhong Pan wrote:
>>
>> Most people coming from the object-oriented programming (OOP) world are
>> used to using "." to access member methods/functions of a class. Consider
>> the following simple example in Python that defines a class AA which has
>> two members: an integer variable N to store the number of people attended,
>> and a split(cost) function to calculate the cost split evenly among all
>> attendees.
>> class AA:
>> def __init__(self, n):
>> self.N = n
>>
>> def split(self, cost):
>> return float(cost) / self.N
>>
>> groupdinner = AA(20)
>> totalcost = 500.00
>> print("{:d} people attended the group dinner, and each should pay
>> ${:.2f}".format(groupdinner.N,
>>
>> groupdinner.split(totalcost)))
>>
>> Running the above code gives:
>> 20 people attended the group dinner, and each should pay $25.00
>>
>> In Julia, with multiple dispatch and functions as first-class objects,
>> the code would usually be written this way:
>> type AA
>>   N :: Int
>> end
>>
>> split(event::AA, x::Number) = x/event.N
>>
>> groupdinner = AA(20)
>> totalcost = 500.00
>> @printf("%d people attended the group dinner, and each should pay
>> \$%.2f\n", groupdinner.N, split(groupdinner, totalcost))
>>
>> However, if someone insists that a class (or type in Julia) should "own"
>> the member functions, I do see a workaround using inner constructor, like
>> this:
>> type AA
>>   N :: Int
>>   split :: Function
>>
>>   AA(n::Int) = new(n, (x::Number) -> x/n)
>> end
>>
>> groupdinner = AA(20)
>> totalcost = 500.00
>> @printf("%d people attended the group dinner, and each should pay
>> \$%.2f\n", groupdinner.N, groupdinner.split(totalcost))
>>
>> This approach treats member functions as Function objects owned by a
>> type, and the implementations of member functions are actually written in
>> an inner constructor.
>>
>> Obviously this is a workaround and workarounds are awkward. However, I do
>> see one potential practical use: modern IDEs often provide intellisense
>> which will display an object's members once "." is typed after an object
>> name. It's quite handy when I want to use a mature 3rd party module that I
>> don't have time to learn by reading documentation; instead I just want to
>> quickly try and use it by exploring the class hierarchy. It also saves a
>> lot of memorizing/typing when I can be constantly reminded/auto-completed
>> of matching variable/function names filtered by the object before the "."
>> and the first few letters I typed in after the ".".
>>
>> In Julia one can use methods(AA) to display all functions that take AA
>> object(s) as input(s). However, the list produced is often quite long and
>> hard to read, since multiple dispatch will create many versions of the same
>> function, with each differing only in the parameter types, and "methods"
>> will show all of them with parameter types but no meaningful names. Also
>> not sure how intellisense can help here. So the only way to explore for now
>> is to know the function name (or at least a significant leading part of the
>> name) and read its documentation by using "?" in a terminal, separate from
>> the source code editor.
>>
>> With the "." workaround shown above intellisense should be able to prompt
>> the name "split" alongside with "N".
>>
>> I just wonder if this workaround would be considered way too "unJulian"
>> that it ought to be denounced. :-)
>>
>> Thanks,
>> -Zhong
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

Re: [julia-users] Composite Type Array

[maxent219]

Thanks Stefan!

I thought it would be like declaring a struct array in c/c++ i.e. something 
like ExampleEvent events[2][1000]; Then set each field in the events array 
as I encounter the required value in my algo: e.g. events[1][1].fld1 = 
"ABC";  events[1][1].fld2 = 123;   etc

How do I access elements in the events Vector since ndims(events) = 1? I 
don't see anything in the docs about indexing into a preallocated Vector 
data structure. I see methods like push! splice! etc but not anything that 
will let me use the elements of my preallocation on the fly. 


On Thursday, July 21, 2016 at 3:21:54 PM UTC-4, Stefan Karpinski wrote:
>
> It's a little unclear what you want to do that you can't figure out how to 
> accomplish. You can allocate an uninitialized vector of ExampleEvent 
> objects:
>
> julia> type ExampleEvent
>fld1::ASCIIString
>fld2::Int16
>fld3::Int64
>fld4::Int64
>fld5::Int64
>fld6::Int64
>fld7::Int64
>end
>
> julia> events = Vector{ExampleEvent}(1000)
> 1000-element Array{ExampleEvent,1}:
>  #undef
>  #undef
>  #undef
>⋮
>  #undef
>  #undef
>  #undef
>
>
>
>
> On Thu, Jul 21, 2016 at 2:51 PM,  wrote:
>
>>
>> Hi 
>>
>> I was working on processing large data sets & historically I've used 
>> structs in C++ & other languages for this type of task. I attempted to use 
>> a Composite Type in Julia & preallocate a large array before filling it 
>> w/values as my algo processes the data. 
>>
>> My example was:
>>
>> type ExampleEvent
>>
>> fld1::ASCIIString
>> fld2::Int16
>> fld3::Int64
>> fld4::Int64
>> fld5::Int64
>> fld6::Int64
>> fld7::Int64
>>
>> end
>>
>> I googled around & from what I found, & all the docs examples I tried 
>> out, there isn't an obvious way to declare an array of composite type 
>> without having to do some work arounds. 
>>
>> I liked the language in several other respects but it seems to be missing 
>> helpful tools to make the programmer's life easy. Am I missing something? 
>> If not, why is a data structure like this not easily available? 
>>
>> thanks in advance
>>
>> best,
>> A 
>>
>
>

[julia-users] Re: A workaround to use "." to access class member functions - is it unJulian?

[Jeffrey Sarnoff]

Too much riffle-raffle for the gain you mention (imo).

On Friday, July 22, 2016 at 1:01:42 PM UTC-4, Zhong Pan wrote:
>
> Most people coming from the object-oriented programming (OOP) world are 
> used to using "." to access member methods/functions of a class. Consider 
> the following simple example in Python that defines a class AA which has 
> two members: an integer variable N to store the number of people attended, 
> and a split(cost) function to calculate the cost split evenly among all 
> attendees.
> class AA:
> def __init__(self, n):
> self.N = n
>
> def split(self, cost):
> return float(cost) / self.N
>
> groupdinner = AA(20)
> totalcost = 500.00
> print("{:d} people attended the group dinner, and each should pay 
> ${:.2f}".format(groupdinner.N,
>   
> groupdinner.split(totalcost)))
>
> Running the above code gives:
> 20 people attended the group dinner, and each should pay $25.00
>
> In Julia, with multiple dispatch and functions as first-class objects, the 
> code would usually be written this way:
> type AA
>   N :: Int
> end
>
> split(event::AA, x::Number) = x/event.N
>
> groupdinner = AA(20)
> totalcost = 500.00
> @printf("%d people attended the group dinner, and each should pay 
> \$%.2f\n", groupdinner.N, split(groupdinner, totalcost))
>
> However, if someone insists that a class (or type in Julia) should "own" 
> the member functions, I do see a workaround using inner constructor, like 
> this:
> type AA
>   N :: Int
>   split :: Function
>
>   AA(n::Int) = new(n, (x::Number) -> x/n)
> end
>
> groupdinner = AA(20)
> totalcost = 500.00
> @printf("%d people attended the group dinner, and each should pay 
> \$%.2f\n", groupdinner.N, groupdinner.split(totalcost))
>
> This approach treats member functions as Function objects owned by a type, 
> and the implementations of member functions are actually written in an 
> inner constructor. 
>
> Obviously this is a workaround and workarounds are awkward. However, I do 
> see one potential practical use: modern IDEs often provide intellisense 
> which will display an object's members once "." is typed after an object 
> name. It's quite handy when I want to use a mature 3rd party module that I 
> don't have time to learn by reading documentation; instead I just want to 
> quickly try and use it by exploring the class hierarchy. It also saves a 
> lot of memorizing/typing when I can be constantly reminded/auto-completed 
> of matching variable/function names filtered by the object before the "." 
> and the first few letters I typed in after the ".".
>
> In Julia one can use methods(AA) to display all functions that take AA 
> object(s) as input(s). However, the list produced is often quite long and 
> hard to read, since multiple dispatch will create many versions of the same 
> function, with each differing only in the parameter types, and "methods" 
> will show all of them with parameter types but no meaningful names. Also 
> not sure how intellisense can help here. So the only way to explore for now 
> is to know the function name (or at least a significant leading part of the 
> name) and read its documentation by using "?" in a terminal, separate from 
> the source code editor. 
>
> With the "." workaround shown above intellisense should be able to prompt 
> the name "split" alongside with "N".
>
> I just wonder if this workaround would be considered way too "unJulian" 
> that it ought to be denounced. :-)
>
> Thanks,
> -Zhong
>
>
>
>
>
>
>
>
>
>
>
>
>

[julia-users] A workaround to use "." to access class member functions - is it unJulian?

[Zhong Pan]

Most people coming from the object-oriented programming (OOP) world are 
used to using "." to access member methods/functions of a class. Consider 
the following simple example in Python that defines a class AA which has 
two members: an integer variable N to store the number of people attended, 
and a split(cost) function to calculate the cost split evenly among all 
attendees.
class AA:
def __init__(self, n):
self.N = n

def split(self, cost):
return float(cost) / self.N

groupdinner = AA(20)
totalcost = 500.00
print("{:d} people attended the group dinner, and each should pay 
${:.2f}".format(groupdinner.N,

  groupdinner.split(totalcost)))

Running the above code gives:
20 people attended the group dinner, and each should pay $25.00

In Julia, with multiple dispatch and functions as first-class objects, the 
code would usually be written this way:
type AA
  N :: Int
end

split(event::AA, x::Number) = x/event.N

groupdinner = AA(20)
totalcost = 500.00
@printf("%d people attended the group dinner, and each should pay 
\$%.2f\n", groupdinner.N, split(groupdinner, totalcost))

However, if someone insists that a class (or type in Julia) should "own" 
the member functions, I do see a workaround using inner constructor, like 
this:
type AA
  N :: Int
  split :: Function

  AA(n::Int) = new(n, (x::Number) -> x/n)
end

groupdinner = AA(20)
totalcost = 500.00
@printf("%d people attended the group dinner, and each should pay 
\$%.2f\n", groupdinner.N, groupdinner.split(totalcost))

This approach treats member functions as Function objects owned by a type, 
and the implementations of member functions are actually written in an 
inner constructor. 

Obviously this is a workaround and workarounds are awkward. However, I do 
see one potential practical use: modern IDEs often provide intellisense 
which will display an object's members once "." is typed after an object 
name. It's quite handy when I want to use a mature 3rd party module that I 
don't have time to learn by reading documentation; instead I just want to 
quickly try and use it by exploring the class hierarchy. It also saves a 
lot of memorizing/typing when I can be constantly reminded/auto-completed 
of matching variable/function names filtered by the object before the "." 
and the first few letters I typed in after the ".".

In Julia one can use methods(AA) to display all functions that take AA 
object(s) as input(s). However, the list produced is often quite long and 
hard to read, since multiple dispatch will create many versions of the same 
function, with each differing only in the parameter types, and "methods" 
will show all of them with parameter types but no meaningful names. Also 
not sure how intellisense can help here. So the only way to explore for now 
is to know the function name (or at least a significant leading part of the 
name) and read its documentation by using "?" in a terminal, separate from 
the source code editor. 

With the "." workaround shown above intellisense should be able to prompt 
the name "split" alongside with "N".

I just wonder if this workaround would be considered way too "unJulian" 
that it ought to be denounced. :-)

Thanks,
-Zhong

[julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

['Bill Hart' via julia-users]

I think there is a access violation occurring in one of the dlls we are 
loading in __init__. However, these are precisely the same dlls we used in 
the old version of Nemo, so I'm quite puzzled how they are causing an 
access violation just because we are using a later version of Nemo.

I'll have to check all the julia code we use to load the dlls and see what 
we changed. I know that we are setting some memory functions now that we 
didn't use to set, so Julia can do counted_malloc.

This is a real head scratcher, because I can't think of a plausible 
explanation for the problem. If I remove all the code to set the memory 
functions except the one to set the GMP memory functions, it complains that 
it can't find the GMP dll. That's despite the fact that we use this dll 
without problems in the old version of Nemo.

Bill.

[julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

[Daniel Høegh]

You could try to run Julia with the `--inline=no` flag to see if you get more 
debug information.

[julia-users] Re: Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

['Bill Hart' via julia-users]

Here are some other things I tried:

1) Run Julia as administrator : no change

2) turn off precompilation : still doesn't work, error message below [2]

That's the entire error message. There's no useful diagnostic information 
to suggest what might have gone wrong at all.

Bill.

[2] [ ERROR: Nemo 
]=

failed process: 
Process(`'C:\Users\User\AppData\Local\Julia-0.4.6\bin\julia' 
--check-bounds=yes --code-coverage=none --color=yes 
'C:\Users\User\.julia\v0.4\Nemo\test\runtests.jl'`, 
ProcessExited(3221225477)) [3221225477]


ERROR: Nemo had test errors
 in error at error.jl:21

Re: [julia-users] IBM Power port

[Viral Shah]

Did it go through? I usually build with make -j 20 on the machines that have 
enough cores. Let me know if you still want me to create the tarball. Using 
ATLAS makes the whole thing a bit nonstandard for creating distributions, but 
I’ll see what I can do if needed.

-viral

> On Jul 22, 2016, at 10:50 AM, Paulito Palmes  wrote:
> 
> Ah, forgot to update Make.user
> 
> 
> On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes  wrote:
> Hi, 
> 
> Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1 SMP 
> Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
> 
> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> --
> make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc 
> FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1 
> GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1 
> MAKE_NB_JOBS=0
> dynamic.c: In function ‘support_avx’:
> dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’ 
> [-Wimplicit-function-declaration]
>cpuid(1, , , , );
>^
> dynamic.c:97:3: error: impossible register constraint in ‘asm’
>__asm__ __volatile__
>^
> make[3]: *** [dynamic.o] Error 1
> make[2]: *** [libs] Error 1
> \033[33;1m*** Clean the OpenBLAS build with 'make -C deps clean-openblas'. 
> Rebuild with 'make OPENBLAS_USE_THREAD=0' if OpenBLAS had trouble linking 
> libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were 
> errors building SandyBridge support. Both these options can also be used 
> simultaneously. ***\033[0m
> make[1]: *** 
> [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so] 
> Error 1
> make: *** [julia-deps] Error 2
> --
> 
> On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes  wrote:
> Hi Viral,
> 
> uname -a is:
> > Linux abc.com 3.10.0-327.18.2.el7.ppc64le #1 SMP Fri Apr 8 05:10:45 EDT 
> > 2016 ppc64le ppc64le ppc64le GNU/Linux
> 
> and using Power8: Red Hat Enterprise Linux Server release 7.2 (Maipo)
> 
> 
> Can you send me the tarball image of Julia compiled in Power8? I would like 
> to test it if the problem is only during compilation. Since I have no git 
> access on this machine, I used make -C deps getall to pull the deps before 
> copying the source files to Power8. It may be possible the deps were not 
> properly resolved?
> 
> On Fri, Jul 22, 2016 at 1:58 PM, Viral Shah  wrote:
> Not sure what to do here. Is the filesystem NFS or something? Perhaps just 
> try building again with make -j 1.
> 
> What is uname -a?
> 
> -viral
> 
> 
> On Jul 22, 2016 8:52 AM, "Paulito Palmes"  wrote:
> Hi,
> 
> I'm compiling using Red Hat Enterprise Linux Server release 7.2 in Power8 and 
> I got this error:
> 
> ./julia/usr/lib64/libunwind*.a: No such file or directory
> 
> 
> the make process didn't create usr/lib64 and the libunwind*.a are in usr/lib
> 
> I created the links of libunwind*.a in usr/lib64
> 
> but got these errors during compile:
> 
> make[2]: Warning: File 
> `/home/paulpalm/julia/deps/srccache/patchelf-0.9/aclocal.m4' has modification 
> time 293 s in the future
> 
>  cd /home/paulpalm/julia/deps/srccache/patchelf-0.9 && /bin/sh 
> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing 
> automake-1.15 --foreign
> 
> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing: line 81: 
> automake-1.15: command not found
> 
> WARNING: 'automake-1.15' is missing on your system.
> 
>  You should only need it if you modified 'Makefile.am' or
> 
>  'configure.ac' or m4 files included by 'configure.ac'.
> 
>  The 'automake' program is part of the GNU Automake package:
> 
>  
> 
>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
> 
>  
> 
>  
> 
>  
> 
> make[2]: *** [julia/deps/srccache/patchelf-0.9/Makefile.in] Error 1
> 
> make[1]: *** [build/patchelf-0.9/src/patchelf] Error 2
> 
> make: *** [julia-deps] Error 2
> 
> 
> I have automake-1.13 while it looks for automake-1.15. 
> 
> On Wednesday, 20 July 2016 20:57:36 UTC+1, Viral Shah wrote:
> Just a heads up, there is a bug in atlas that causes the linalg/lq test to 
> fail (thanks Andreas for finding!). The bugfix is going to be in the next 
> atlas release - 3.10.3 
> 
>  https://sourceforge.net/p/math-atlas/bugs/254/#64f2 
> 
> Turns out at this moment, both atlas and openblas are not passing julia’s 
> tests on power. 
> 
> -viral 
> 
> 
> 
> > On Jul 20, 2016, at 3:11 PM, James Fairbanks  wrote: 
> > 
> > Updating to master and using that Make.user worked for me. 
> > 
> > Success! 
> > [jpf@power8 julia-dev]$ ./julia 
> >_ 
> >_   _ _(_)_ |  A fresh approach to technical computing 
> >   (_) 

[julia-users] Re: FFT, PSD and Windowing functions

[Islam Badreldin]

Hi Yared,

Please see below,,

On Thursday, July 21, 2016 at 11:19:44 AM UTC-4, Yared Melese wrote:

> Hi Islam, 
>
> Thanks for your input 
>
>  I was able to find all windowing functions; however, there is nothing 
> about PSD ( power spectral density). In python and matlab, there is 
> function pwelch which does both windowing and FFT and wondering if there is 
> the same function in Julia.
>

Did you take a look at `welch_pgram` function?
http://dspjl.readthedocs.io/en/latest/periodograms.html#welch_pgram 


> Here is simple trial I had but it is complaining about type mismatch
>
> fb= fb[:]*hamming(length(fb))
> fb = fft(fb) # take FFT of signal 
>
> LoadError: MethodError: `*` has no method matching 
> *(::Array{Complex{Float64},1}, ::Array{Float64,1})
> Closest candidates are:
>   *(::Any, ::Any, !Matched::Any, !Matched::Any...)
>   
> *{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},S}(!Matched::Union{DenseArray{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},2},SubArray{T<:Union{Complex{Float32},Complex{Float64},Float32,Float64},2,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD}},
>  
> ::Union{DenseArray{S,1},SubArray{S,1,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD}})
>   
> *{TA,TB}(!Matched::Base.LinAlg.AbstractTriangular{TA,S<:AbstractArray{T,2}}, 
> ::Union{DenseArray{TB,1},DenseArray{TB,2},SubArray{TB,1,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD},SubArray{TB,2,A<:DenseArray{T,N},I<:Tuple{Vararg{Union{Colon,Int64,Range{Int64,LD}})
>   ...
> in include_string at loading.jl:282
> in include_string at C:\Users\melese\.julia\v0.4\CodeTools\src\eval.jl:32
> in anonymous at C:\Users\melese\.julia\v0.4\Atom\src\eval.jl:84
> in withpath at C:\Users\melese\.julia\v0.4\Requires\src\require.jl:37
> in withpath at C:\Users\melese\.julia\v0.4\Atom\src\eval.jl:53
> [inlined code] from C:\Users\melese\.julia\v0.4\Atom\src\eval.jl:83
> in anonymous at task.jl:58
> while loading D:\userdata\melese\Desktop\fft.jl, in expression starting on 
> line 23
>
>
This particular error seems to be occurring at the `fb= 
fb[:]*hamming(length(fb))` line. It looks like you are multiplying an 
_vector_ of complex doubles with a _vector_ of doubles, which is not 
mathematically defined because of the dimension mismatch, since both 
vectors are of dimension Nx1. Instead, my guess is that you meant 
element-wise multiplication using `.*`. But again, I think the 
`welch_pgram` function should meet your needs.

  -Islam
 

>
> On Wednesday, July 20, 2016 at 9:15:40 AM UTC-5, Yared Melese wrote:
>
>> Hello 
>>
>> Would you please let me know the package available to do windowing, FFT 
>> and PSD? 
>>
>> Currently, I have bin file that I have processed in Julia and need to 
>> window it and take preferably PSD but FFT work as well
>>
>> Thanks 
>> Yared
>>
>>  
>>
>>

[julia-users] Error precompiling on Windows 64 (julia 0.4.0 and 0.4.6)

['Bill Hart' via julia-users]

I just tried to run the latest (master) version of our Nemo package on 
Windows 64 using Julia 0.4.6 and after many ambiguity warnings (which are 
harmless) it bombs out with the message below [1].

What we have tried:

1) Building the old version of Nemo with Julia 0.4.6 : works OK

2) Building the new version of Nemo with Julia 0.4.0 : same failure

3) Building the old version of Nemo with Julia 0.4.0 : works OK

This suggests that we've changed something in the latest version of Nemo 
that screws up precompilation on Windows 64. But we haven't any idea what 
it might be. It works just fine under Linux.

Does anyone have any idea what might be going wrong on Windows 64?

Bill.

[1] 

ERROR: Failed to precompile Nemo to C:\Users\User\.julia\lib\v0.4\Nemo.ji
 in error at error.jl:21

[julia-users] help with integrating websockets and protobuf

[Jon Norberg]

just to check that there is no problem in the formats, the following does send 
a ljulia-protobuf formatted message to the html-client but somewhat 
indirectly

msg = read(client)
iob = PipeBuffer();
write(iob,msg)
test = readproto(iob,com())
println("got MESSAGE: $test.id")  #i.e. works!
writeproto(iob,com(id=[1],val=[0.2]))
msg=read(iob)
write(client,msg)#the new value 
turns up at the client, so no issues with the formatting, just to get the web 
socket to talk via readproto and writeproto

[julia-users] help with integrating websockets and protobuf

[Jon Norberg]

Dear julia community. 

I can't figure out whats wrong here. I have a web socket implementation that 
works just fine without using protobuf on the julsa/websocket side (in fact, 
the html-client does send a protobuf array which just gets sent back without 
unpacking and packing on the julia web socket side, i.e. echo server.

the relevant lines in the web socket server are:

msg = read(client) # This receives messages
write(client,msg)   # This sends it back

I can then unpack it on the html-client side again just fine.

I have defined a protobuf type as 

type com
id::Array{Int32,1}
val::Array{Float32,1}
com(; kwargs...) = (o=new(); fillunset(o); isempty(kwargs) || 
ProtoBuf._protobuild(o, kwargs); o)
end #type com
hash(v::com) = ProtoBuf.protohash(v)
isequal(v1::com, v2::com) = ProtoBuf.protoisequal(v1, v2)
==(v1::com, v2::com) = ProtoBuf.protoeq(v1, v2)

and the following works as it should:

iob = PipeBuffer();
writeproto(iob,com(id=[1],val=[0.2]))
msg = readproto(iob,com())
println(msg)

But when I change the relevant lines in the web socket code on the server side 
to:

msg = readproto(client.socket,com())
writeproto(client.socket,com(id=[1],val=[0.2]))

it does not work.

 I did figure out that client is a composite type and that client.socket is of 
type TCPSocket which I assume is the right variable to pass to the protobuf 
functions.

Can anyone spot what I am missing? 

the protofile is:

message com {
  repeated int32 id = 1;
  repeated float val =2;
}

Re: [julia-users] IBM Power port

[Paulito Palmes]

Ah, forgot to update Make.user


On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes  wrote:

> Hi,
>
> Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1
> SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
>
> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> --
> make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc
> FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1
> GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1
> MAKE_NB_JOBS=0
> dynamic.c: In function ‘support_avx’:
> dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
> [-Wimplicit-function-declaration]
>cpuid(1, , , , );
>^
> dynamic.c:97:3: error: impossible register constraint in ‘asm’
>__asm__ __volatile__
>^
> make[3]: *** [dynamic.o] Error 1
> make[2]: *** [libs] Error 1
> \033[33;1m*** Clean the OpenBLAS build with 'make -C deps clean-openblas'.
> Rebuild with 'make OPENBLAS_USE_THREAD=0' if OpenBLAS had trouble linking
> libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were
> errors building SandyBridge support. Both these options can also be used
> simultaneously. ***\033[0m
> make[1]: ***
> [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
> Error 1
> make: *** [julia-deps] Error 2
> --
>
> On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes  wrote:
>
>> Hi Viral,
>>
>> uname -a is:
>> > Linux abc.com 3.10.0-327.18.2.el7.ppc64le #1 SMP Fri Apr 8 05:10:45
>> EDT 2016 ppc64le ppc64le ppc64le GNU/Linux
>>
>> and using Power8: Red Hat Enterprise Linux Server release 7.2 (Maipo)
>>
>>
>> Can you send me the tarball image of Julia compiled in Power8? I would
>> like to test it if the problem is only during compilation. Since I have no
>> git access on this machine, I used make -C deps getall to pull the deps
>> before copying the source files to Power8. It may be possible the deps were
>> not properly resolved?
>>
>> On Fri, Jul 22, 2016 at 1:58 PM, Viral Shah  wrote:
>>
>>> Not sure what to do here. Is the filesystem NFS or something? Perhaps
>>> just try building again with make -j 1.
>>>
>>> What is uname -a?
>>>
>>> -viral
>>>
>>> On Jul 22, 2016 8:52 AM, "Paulito Palmes"  wrote:
>>>
 Hi,

 I'm compiling using Red Hat Enterprise Linux Server release 7.2 in
 Power8 and I got this error:

 ./julia/usr/lib64/libunwind*.a: No such file or directory

 the make process didn't create usr/lib64 and the libunwind*.a are in
 usr/lib

 I created the links of libunwind*.a in usr/lib64

 but got these errors during compile:

 make[2]: Warning: File
 `/home/paulpalm/julia/deps/srccache/patchelf-0.9/aclocal.m4' has
 modification time 293 s in the future

  cd /home/paulpalm/julia/deps/srccache/patchelf-0.9 && /bin/sh
 /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing
 automake-1.15 --foreign

 /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing: line
 81: automake-1.15: command not found

 WARNING: 'automake-1.15' is missing on your system.

  You should only need it if you modified 'Makefile.am' or

  'configure.ac' or m4 files included by 'configure.ac'.

  The 'automake' program is part of the GNU Automake package:

  

  It also requires GNU Autoconf, GNU m4 and Perl in order to run:

  

  

  

 make[2]: *** [julia/deps/srccache/patchelf-0.9/Makefile.in] Error 1

 make[1]: *** [build/patchelf-0.9/src/patchelf] Error 2

 make: *** [julia-deps] Error 2

 I have automake-1.13 while it looks for automake-1.15.

 On Wednesday, 20 July 2016 20:57:36 UTC+1, Viral Shah wrote:
>
> Just a heads up, there is a bug in atlas that causes the linalg/lq
> test to fail (thanks Andreas for finding!). The bugfix is going to be in
> the next atlas release - 3.10.3
>
>  https://sourceforge.net/p/math-atlas/bugs/254/#64f2
>
> Turns out at this moment, both atlas and openblas are not passing
> julia’s tests on power.
>
> -viral
>
>
>
> > On Jul 20, 2016, at 3:11 PM, James Fairbanks 
> wrote:
> >
> > Updating to master and using that Make.user worked for me.
> >
> > Success!
> > [jpf@power8 julia-dev]$ ./julia
> >_
> >_   _ _(_)_ |  A fresh approach to technical computing
> >   (_) | (_) (_)|  Documentation: http://docs.julialang.org
> >_ _   _| |_  __ _   |  Type "?help" for help.
> >   | | | | | | |/ _` |  |

Re: [julia-users] IBM Power port

[Paulito Palmes]

Hi Viral,

uname -a is:
> Linux abc.com 3.10.0-327.18.2.el7.ppc64le #1 SMP Fri Apr 8 05:10:45 EDT
2016 ppc64le ppc64le ppc64le GNU/Linux

and using Power8: Red Hat Enterprise Linux Server release 7.2 (Maipo)


Can you send me the tarball image of Julia compiled in Power8? I would like
to test it if the problem is only during compilation. Since I have no git
access on this machine, I used make -C deps getall to pull the deps before
copying the source files to Power8. It may be possible the deps were not
properly resolved?

On Fri, Jul 22, 2016 at 1:58 PM, Viral Shah  wrote:

> Not sure what to do here. Is the filesystem NFS or something? Perhaps just
> try building again with make -j 1.
>
> What is uname -a?
>
> -viral
>
> On Jul 22, 2016 8:52 AM, "Paulito Palmes"  wrote:
>
>> Hi,
>>
>> I'm compiling using Red Hat Enterprise Linux Server release 7.2 in Power8
>> and I got this error:
>>
>> ./julia/usr/lib64/libunwind*.a: No such file or directory
>>
>> the make process didn't create usr/lib64 and the libunwind*.a are in
>> usr/lib
>>
>> I created the links of libunwind*.a in usr/lib64
>>
>> but got these errors during compile:
>>
>> make[2]: Warning: File
>> `/home/paulpalm/julia/deps/srccache/patchelf-0.9/aclocal.m4' has
>> modification time 293 s in the future
>>
>>  cd /home/paulpalm/julia/deps/srccache/patchelf-0.9 && /bin/sh
>> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing
>> automake-1.15 --foreign
>>
>> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing: line
>> 81: automake-1.15: command not found
>>
>> WARNING: 'automake-1.15' is missing on your system.
>>
>>  You should only need it if you modified 'Makefile.am' or
>>
>>  'configure.ac' or m4 files included by 'configure.ac'.
>>
>>  The 'automake' program is part of the GNU Automake package:
>>
>>  
>>
>>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>>
>>  
>>
>>  
>>
>>  
>>
>> make[2]: *** [julia/deps/srccache/patchelf-0.9/Makefile.in] Error 1
>>
>> make[1]: *** [build/patchelf-0.9/src/patchelf] Error 2
>>
>> make: *** [julia-deps] Error 2
>>
>> I have automake-1.13 while it looks for automake-1.15.
>>
>> On Wednesday, 20 July 2016 20:57:36 UTC+1, Viral Shah wrote:
>>>
>>> Just a heads up, there is a bug in atlas that causes the linalg/lq test
>>> to fail (thanks Andreas for finding!). The bugfix is going to be in the
>>> next atlas release - 3.10.3
>>>
>>>  https://sourceforge.net/p/math-atlas/bugs/254/#64f2
>>>
>>> Turns out at this moment, both atlas and openblas are not passing
>>> julia’s tests on power.
>>>
>>> -viral
>>>
>>>
>>>
>>> > On Jul 20, 2016, at 3:11 PM, James Fairbanks 
>>> wrote:
>>> >
>>> > Updating to master and using that Make.user worked for me.
>>> >
>>> > Success!
>>> > [jpf@power8 julia-dev]$ ./julia
>>> >_
>>> >_   _ _(_)_ |  A fresh approach to technical computing
>>> >   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>>> >_ _   _| |_  __ _   |  Type "?help" for help.
>>> >   | | | | | | |/ _` |  |
>>> >   | | |_| | | | (_| |  |  Version 0.5.0-dev+5549 (2016-07-20 15:47
>>> UTC)
>>> >  _/ |\__'_|_|_|\__'_|  |  Commit 80fcb57 (0 days old master)
>>> > |__/   |  ppc64le-redhat-linux
>>> >
>>> > Thanks for going through this with me. Hopefully it will be easier for
>>> the next person.
>>> >
>>> > On Wednesday, July 20, 2016 at 10:27:27 AM UTC-4, Viral Shah wrote:
>>> >
>>> > Julia now  builds on master. No longer need to disable threading.
>>> Make.user for me is now:
>>> >
>>> > override USE_SYSTEM_BLAS = 1
>>> > override LIBBLAS = -L/usr/lib64/atlas -lsatlas
>>> > override LIBBLASNAME = libsatlas
>>> > override USE_BLAS64 = 0
>>> >
>>> > -viral
>>> >
>>> >
>>> > > On Jul 19, 2016, at 7:00 PM, Viral Shah 
>>> wrote:
>>> > >
>>> > > I am testing on CentOS Linux release 7.2.1511 (AltArch)
>>> > >
>>> > > This is the line I am using:
>>> > > export LD_LIBRARY_PATH=/usr/lib64/atlas:$LD_LIBRARY_PATH
>>> > >
>>> > > Our README says LAPACK >= 3.5, so I suspect the system lapack won’t
>>> work out. Assuming that symbol is present in the libsatlas file, perhaps
>>> try also copying it in julia’s usr/lib.
>>> > >
>>> > > The other thing is to run make again to make sure that all the rpath
>>> and linking stuff has gone through fine. Or perhaps make cleanall and make.
>>> > >
>>> > > -viral
>>> > >
>>> > >
>>> > >
>>> > >> On Jul 19, 2016, at 6:55 PM, James Fairbanks 
>>> wrote:
>>> > >>
>>> > >> For completeness I should say that the julia executable appears not
>>> to have the libjulia.so correctly linked.
>>> > >>
>>> > >> $ ./julia
>>> > >> ./julia: symbol lookup error:
>>> /home/jpf/julia/usr/bin/../lib/liblapack.so: 

Re: [julia-users] IBM Power port

[Paulito Palmes]

Hi,

Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1 SMP
Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux

Red Hat Enterprise Linux Server release 7.2 (Maipo)
--
make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc
FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1
GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1
MAKE_NB_JOBS=0
dynamic.c: In function ‘support_avx’:
dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
[-Wimplicit-function-declaration]
   cpuid(1, , , , );
   ^
dynamic.c:97:3: error: impossible register constraint in ‘asm’
   __asm__ __volatile__
   ^
make[3]: *** [dynamic.o] Error 1
make[2]: *** [libs] Error 1
\033[33;1m*** Clean the OpenBLAS build with 'make -C deps clean-openblas'.
Rebuild with 'make OPENBLAS_USE_THREAD=0' if OpenBLAS had trouble linking
libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were
errors building SandyBridge support. Both these options can also be used
simultaneously. ***\033[0m
make[1]: ***
[build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
Error 1
make: *** [julia-deps] Error 2
--

On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes  wrote:

> Hi Viral,
>
> uname -a is:
> > Linux abc.com 3.10.0-327.18.2.el7.ppc64le #1 SMP Fri Apr 8 05:10:45 EDT
> 2016 ppc64le ppc64le ppc64le GNU/Linux
>
> and using Power8: Red Hat Enterprise Linux Server release 7.2 (Maipo)
>
>
> Can you send me the tarball image of Julia compiled in Power8? I would
> like to test it if the problem is only during compilation. Since I have no
> git access on this machine, I used make -C deps getall to pull the deps
> before copying the source files to Power8. It may be possible the deps were
> not properly resolved?
>
> On Fri, Jul 22, 2016 at 1:58 PM, Viral Shah  wrote:
>
>> Not sure what to do here. Is the filesystem NFS or something? Perhaps
>> just try building again with make -j 1.
>>
>> What is uname -a?
>>
>> -viral
>>
>> On Jul 22, 2016 8:52 AM, "Paulito Palmes"  wrote:
>>
>>> Hi,
>>>
>>> I'm compiling using Red Hat Enterprise Linux Server release 7.2 in
>>> Power8 and I got this error:
>>>
>>> ./julia/usr/lib64/libunwind*.a: No such file or directory
>>>
>>> the make process didn't create usr/lib64 and the libunwind*.a are in
>>> usr/lib
>>>
>>> I created the links of libunwind*.a in usr/lib64
>>>
>>> but got these errors during compile:
>>>
>>> make[2]: Warning: File
>>> `/home/paulpalm/julia/deps/srccache/patchelf-0.9/aclocal.m4' has
>>> modification time 293 s in the future
>>>
>>>  cd /home/paulpalm/julia/deps/srccache/patchelf-0.9 && /bin/sh
>>> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing
>>> automake-1.15 --foreign
>>>
>>> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing: line
>>> 81: automake-1.15: command not found
>>>
>>> WARNING: 'automake-1.15' is missing on your system.
>>>
>>>  You should only need it if you modified 'Makefile.am' or
>>>
>>>  'configure.ac' or m4 files included by 'configure.ac'.
>>>
>>>  The 'automake' program is part of the GNU Automake package:
>>>
>>>  
>>>
>>>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> make[2]: *** [julia/deps/srccache/patchelf-0.9/Makefile.in] Error 1
>>>
>>> make[1]: *** [build/patchelf-0.9/src/patchelf] Error 2
>>>
>>> make: *** [julia-deps] Error 2
>>>
>>> I have automake-1.13 while it looks for automake-1.15.
>>>
>>> On Wednesday, 20 July 2016 20:57:36 UTC+1, Viral Shah wrote:

 Just a heads up, there is a bug in atlas that causes the linalg/lq test
 to fail (thanks Andreas for finding!). The bugfix is going to be in the
 next atlas release - 3.10.3

  https://sourceforge.net/p/math-atlas/bugs/254/#64f2

 Turns out at this moment, both atlas and openblas are not passing
 julia’s tests on power.

 -viral



 > On Jul 20, 2016, at 3:11 PM, James Fairbanks 
 wrote:
 >
 > Updating to master and using that Make.user worked for me.
 >
 > Success!
 > [jpf@power8 julia-dev]$ ./julia
 >_
 >_   _ _(_)_ |  A fresh approach to technical computing
 >   (_) | (_) (_)|  Documentation: http://docs.julialang.org
 >_ _   _| |_  __ _   |  Type "?help" for help.
 >   | | | | | | |/ _` |  |
 >   | | |_| | | | (_| |  |  Version 0.5.0-dev+5549 (2016-07-20 15:47
 UTC)
 >  _/ |\__'_|_|_|\__'_|  |  Commit 80fcb57 (0 days old master)
 > |__/   |  ppc64le-redhat-linux
 >
 > Thanks for going through this with me. Hopefully it will be 

[julia-users] Re: Working with DataFrame columns types that are Nullable

[Evan Fields]

As far as I know, DataFrames are only backed by DataArrays. (I believe 
there's current work being done to upgrade the speed and type stability of 
DataFrames, in part by using Nullables.)

It might be helpful to write a little convenience function like

f(n) = isnull(n) ? NA : get(n)

I will say I've found DataArrays to be super finicky when inferring types. 
YMMV.

[julia-users] Re: accessing an expression's global scope from macro

[Fábio Cardeal]

Clearly the ingredient missing here is some evil type magic... Hint:


  immutable SelfFunction
f::Function
  end

  selfcall(f::SelfFunction, t::MyType, args...) = f(t, args...)
  selfcall(f, t::MyType, args...) = f(args...)

  const inc2 = SelfFunction((t::MyType) -> begin
selfcall(inc, t)
selfcall(inc, t)
  end)

Re: [julia-users] IBM Power port

[Viral Shah]

Not sure what to do here. Is the filesystem NFS or something? Perhaps just
try building again with make -j 1.

What is uname -a?

-viral

On Jul 22, 2016 8:52 AM, "Paulito Palmes"  wrote:

> Hi,
>
> I'm compiling using Red Hat Enterprise Linux Server release 7.2 in Power8
> and I got this error:
>
> ./julia/usr/lib64/libunwind*.a: No such file or directory
>
> the make process didn't create usr/lib64 and the libunwind*.a are in
> usr/lib
>
> I created the links of libunwind*.a in usr/lib64
>
> but got these errors during compile:
>
> make[2]: Warning: File
> `/home/paulpalm/julia/deps/srccache/patchelf-0.9/aclocal.m4' has
> modification time 293 s in the future
>
>  cd /home/paulpalm/julia/deps/srccache/patchelf-0.9 && /bin/sh
> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing
> automake-1.15 --foreign
>
> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing: line
> 81: automake-1.15: command not found
>
> WARNING: 'automake-1.15' is missing on your system.
>
>  You should only need it if you modified 'Makefile.am' or
>
>  'configure.ac' or m4 files included by 'configure.ac'.
>
>  The 'automake' program is part of the GNU Automake package:
>
>  
>
>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>
>  
>
>  
>
>  
>
> make[2]: *** [julia/deps/srccache/patchelf-0.9/Makefile.in] Error 1
>
> make[1]: *** [build/patchelf-0.9/src/patchelf] Error 2
>
> make: *** [julia-deps] Error 2
>
> I have automake-1.13 while it looks for automake-1.15.
>
> On Wednesday, 20 July 2016 20:57:36 UTC+1, Viral Shah wrote:
>>
>> Just a heads up, there is a bug in atlas that causes the linalg/lq test
>> to fail (thanks Andreas for finding!). The bugfix is going to be in the
>> next atlas release - 3.10.3
>>
>>  https://sourceforge.net/p/math-atlas/bugs/254/#64f2
>>
>> Turns out at this moment, both atlas and openblas are not passing julia’s
>> tests on power.
>>
>> -viral
>>
>>
>>
>> > On Jul 20, 2016, at 3:11 PM, James Fairbanks 
>> wrote:
>> >
>> > Updating to master and using that Make.user worked for me.
>> >
>> > Success!
>> > [jpf@power8 julia-dev]$ ./julia
>> >_
>> >_   _ _(_)_ |  A fresh approach to technical computing
>> >   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>> >_ _   _| |_  __ _   |  Type "?help" for help.
>> >   | | | | | | |/ _` |  |
>> >   | | |_| | | | (_| |  |  Version 0.5.0-dev+5549 (2016-07-20 15:47 UTC)
>> >  _/ |\__'_|_|_|\__'_|  |  Commit 80fcb57 (0 days old master)
>> > |__/   |  ppc64le-redhat-linux
>> >
>> > Thanks for going through this with me. Hopefully it will be easier for
>> the next person.
>> >
>> > On Wednesday, July 20, 2016 at 10:27:27 AM UTC-4, Viral Shah wrote:
>> >
>> > Julia now  builds on master. No longer need to disable threading.
>> Make.user for me is now:
>> >
>> > override USE_SYSTEM_BLAS = 1
>> > override LIBBLAS = -L/usr/lib64/atlas -lsatlas
>> > override LIBBLASNAME = libsatlas
>> > override USE_BLAS64 = 0
>> >
>> > -viral
>> >
>> >
>> > > On Jul 19, 2016, at 7:00 PM, Viral Shah  wrote:
>> > >
>> > > I am testing on CentOS Linux release 7.2.1511 (AltArch)
>> > >
>> > > This is the line I am using:
>> > > export LD_LIBRARY_PATH=/usr/lib64/atlas:$LD_LIBRARY_PATH
>> > >
>> > > Our README says LAPACK >= 3.5, so I suspect the system lapack won’t
>> work out. Assuming that symbol is present in the libsatlas file, perhaps
>> try also copying it in julia’s usr/lib.
>> > >
>> > > The other thing is to run make again to make sure that all the rpath
>> and linking stuff has gone through fine. Or perhaps make cleanall and make.
>> > >
>> > > -viral
>> > >
>> > >
>> > >
>> > >> On Jul 19, 2016, at 6:55 PM, James Fairbanks 
>> wrote:
>> > >>
>> > >> For completeness I should say that the julia executable appears not
>> to have the libjulia.so correctly linked.
>> > >>
>> > >> $ ./julia
>> > >> ./julia: symbol lookup error:
>> /home/jpf/julia/usr/bin/../lib/liblapack.so: undefined symbol: lsame_
>> > >> $ ldd ./julia
>> > >>linux-vdso64.so.1 =>  (0x3fff9d14)
>> > >>libjulia.so.0.5 => not found
>> > >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10)
>> > >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d)
>> > >>libpthread.so.0 => /lib64/power8/libpthread.so.0
>> (0x3fff9d09)
>> > >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb)
>> > >>/lib64/ld64.so.2 (0x251e)
>> > >>
>> > >> $ ldd ./usr/lib/libjulia.so
>> > >>linux-vdso64.so.1 =>  (0x3fff9968)
>> > >>libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so
>> (0x3fff97d8)
>> > >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4)
>> > >>

Re: [julia-users] Pipeline interoperability with IOStream and IOBuffer

[Tom Breloff]

To be fair, he was told, in that issue, that julia-users was a more
appropriate place to ask this type of question.

On Friday, July 22, 2016, Steven G. Johnson  wrote:

>
>
> On Thursday, July 21, 2016 at 6:09:12 PM UTC-4, William Wong wrote:
>>
>> I'm trying to continue the discussion of
>> https://github.com/JuliaLang/julia/issues/15479
>>
>
> The github issue is the appropriate place for discussion; it's not helpful
> to split the discussion into two separate forums.
>
> (If you want to see progress on an issue, the most effective way is to
> submit a pull request attempting to fix the issue.)
>

Re: [julia-users] IBM Power port

[Paulito Palmes]

Hi,

I'm compiling using Red Hat Enterprise Linux Server release 7.2 in Power8 
and I got this error:

./julia/usr/lib64/libunwind*.a: No such file or directory

the make process didn't create usr/lib64 and the libunwind*.a are in usr/lib

I created the links of libunwind*.a in usr/lib64

but got these errors during compile:

make[2]: Warning: File 
`/home/paulpalm/julia/deps/srccache/patchelf-0.9/aclocal.m4' has 
modification time 293 s in the future

 cd /home/paulpalm/julia/deps/srccache/patchelf-0.9 && /bin/sh 
/home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing 
automake-1.15 --foreign

/home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing: line 81: 
automake-1.15: command not found

WARNING: 'automake-1.15' is missing on your system.

 You should only need it if you modified 'Makefile.am' or

 'configure.ac' or m4 files included by 'configure.ac'.

 The 'automake' program is part of the GNU Automake package:

 

 It also requires GNU Autoconf, GNU m4 and Perl in order to run:

 

 

 

make[2]: *** [julia/deps/srccache/patchelf-0.9/Makefile.in] Error 1

make[1]: *** [build/patchelf-0.9/src/patchelf] Error 2

make: *** [julia-deps] Error 2

I have automake-1.13 while it looks for automake-1.15. 

On Wednesday, 20 July 2016 20:57:36 UTC+1, Viral Shah wrote:
>
> Just a heads up, there is a bug in atlas that causes the linalg/lq test to 
> fail (thanks Andreas for finding!). The bugfix is going to be in the next 
> atlas release - 3.10.3 
>
>  https://sourceforge.net/p/math-atlas/bugs/254/#64f2 
>
> Turns out at this moment, both atlas and openblas are not passing julia’s 
> tests on power. 
>
> -viral 
>
>
>
> > On Jul 20, 2016, at 3:11 PM, James Fairbanks  > wrote: 
> > 
> > Updating to master and using that Make.user worked for me. 
> > 
> > Success! 
> > [jpf@power8 julia-dev]$ ./julia 
> >_ 
> >_   _ _(_)_ |  A fresh approach to technical computing 
> >   (_) | (_) (_)|  Documentation: http://docs.julialang.org 
> >_ _   _| |_  __ _   |  Type "?help" for help. 
> >   | | | | | | |/ _` |  | 
> >   | | |_| | | | (_| |  |  Version 0.5.0-dev+5549 (2016-07-20 15:47 UTC) 
> >  _/ |\__'_|_|_|\__'_|  |  Commit 80fcb57 (0 days old master) 
> > |__/   |  ppc64le-redhat-linux 
> > 
> > Thanks for going through this with me. Hopefully it will be easier for 
> the next person. 
> > 
> > On Wednesday, July 20, 2016 at 10:27:27 AM UTC-4, Viral Shah wrote: 
> > 
> > Julia now  builds on master. No longer need to disable threading. 
> Make.user for me is now: 
> > 
> > override USE_SYSTEM_BLAS = 1 
> > override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
> > override LIBBLASNAME = libsatlas 
> > override USE_BLAS64 = 0 
> > 
> > -viral 
> > 
> > 
> > > On Jul 19, 2016, at 7:00 PM, Viral Shah  wrote: 
> > > 
> > > I am testing on CentOS Linux release 7.2.1511 (AltArch) 
> > > 
> > > This is the line I am using: 
> > > export LD_LIBRARY_PATH=/usr/lib64/atlas:$LD_LIBRARY_PATH 
> > > 
> > > Our README says LAPACK >= 3.5, so I suspect the system lapack won’t 
> work out. Assuming that symbol is present in the libsatlas file, perhaps 
> try also copying it in julia’s usr/lib. 
> > > 
> > > The other thing is to run make again to make sure that all the rpath 
> and linking stuff has gone through fine. Or perhaps make cleanall and make. 
> > > 
> > > -viral 
> > > 
> > > 
> > > 
> > >> On Jul 19, 2016, at 6:55 PM, James Fairbanks  
> wrote: 
> > >> 
> > >> For completeness I should say that the julia executable appears not 
> to have the libjulia.so correctly linked. 
> > >> 
> > >> $ ./julia 
> > >> ./julia: symbol lookup error: 
> /home/jpf/julia/usr/bin/../lib/liblapack.so: undefined symbol: lsame_ 
> > >> $ ldd ./julia 
> > >>linux-vdso64.so.1 =>  (0x3fff9d14) 
> > >>libjulia.so.0.5 => not found 
> > >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10) 
> > >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d) 
> > >>libpthread.so.0 => /lib64/power8/libpthread.so.0 
> (0x3fff9d09) 
> > >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb) 
> > >>/lib64/ld64.so.2 (0x251e) 
> > >> 
> > >> $ ldd ./usr/lib/libjulia.so 
> > >>linux-vdso64.so.1 =>  (0x3fff9968) 
> > >>libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so 
> (0x3fff97d8) 
> > >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4) 
> > >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff97d1) 
> > >>libpthread.so.0 => /lib64/power8/libpthread.so.0 
> (0x3fff97cd) 
> > >>libstdc++.so.6 => /lib64/libstdc++.so.6 (0x3fff97b5) 
> > >>libm.so.6 => /lib64/power8/libm.so.6 (0x3fff97a6) 
> > >> 

[julia-users] Re: I can't believe this spped-up !

[Roger Whitney]

Instead of using tic toc use @time to time your loops. You will find that in 
your sequential loop you are allocating a lot of memory, while the @parallel 
loop does not. The difference in time is due to the memory allocation. One of 
my students ran into this earlier this week and that was the cause  in his 
case.  My understanding is that the compiler does not optimize for loops done 
at the top level.  When you put the sequential loop in a function the excessive 
memory goes away, which makes the sequential loop faster.  

You need to be careful using @parallel with no worker process.  With no workers 
the @parallel loop can modify globals and you will get the correct result 
because it is all done in the same process. When you add workers the globals 
will be copied to each worker and the changes will be done on the workers copy 
and the result is not copied back to the master process. So code that works 
with no workers will break when using drugs workers.

[julia-users] Re: Array of vectors in type definition

[Jussi Piitulainen]

type croc
  teeth :: Int64
  legs :: Int64
  sons :: Vector{Matrix{Float64}}
  croc() = new(0,0, Vector{Matrix{Float64}}())
  croc(th, gs) = new(th, gs, Vector{Matrix{Float64}}())
  croc(th, gs, ns) = new(th, gs, ns)
end

reptile = croc()
reptile.teeth = 4
reptile.legs = 80
push!(reptile.sons, [[3.0 1.0];[4.0 1.0]])

another = croc(80, 4)

sons = Vector{Matrix{Float64}}()
push!(sons, rand(3,1))
push!(sons, rand(4,1))
onemore = croc(80, 4, sons)

@show reptile
@show another
@show onemore

[julia-users] Re: Pipeline interoperability with IOStream and IOBuffer

[Steven G. Johnson]

On Thursday, July 21, 2016 at 6:09:12 PM UTC-4, William Wong wrote:
>
> I'm trying to continue the discussion of 
> https://github.com/JuliaLang/julia/issues/15479
>

The github issue is the appropriate place for discussion; it's not helpful 
to split the discussion into two separate forums. 

(If you want to see progress on an issue, the most effective way is to 
submit a pull request attempting to fix the issue.)

[julia-users] Re: Array of vectors in type definition

[Ferran Mazzanti]

Ok all tests seem to fail, sorry. Jossi doing what you say directly works, 
but trying to wrap up things in a type deffinition either fails, or fails 
when I try to push!() things. Could you please be so kind to fill the whole 
example? Something like:

type croc()
  teeth :: Int64
  legs :: Int64
  sons :: <== here comes the Vector of Arrays definition
  croc() = new(0,0, something here to initialize the vector of 
arrays...)
end

such that I can initialize it like

reptile = croc()

and I can set up things like

reptile.teeth = 80
reptile.legs = 4
push!(reptile.sons,[[1.0 2.0];[3.0 4.0]])

...this is essentially what I'm looking for :)

Best regards and thanks for your kind help again,

Ferran.

[julia-users] Re: Array of vectors in type definition

[Ferran Mazzanti]

Thanks Jussi for being so helpful :)
I'll try that and check. Then I'll carefully think about all this to see 
what can I learn from here :)
Best regards,
Ferran.

Re: [julia-users] Re: accessing an expression's global scope from macro

[Mauro]

On Fri, 2016-07-22 at 10:18, Marius Millea  wrote:
> Yea, thats a good point. Granted for my purpose I'm never going to be
> redefining these types mid program. I suppose one might extend your @unpack
> to work on an expression and do the substitution recursively like my thing
> does, then you could write,
>
> @unpack aa: a function(x,aa:A)
>   sin(2pi/a*x)
>   a = 3 #can also assign without repacking
> end

For functions and loops, it seems much better to have the `@unpack`
inside, no?  For begin-end blocks, you could just use a let instead:

  let
@unpack aa: a
sin(2pi/a*x)
  end

(Or are you worried about performance?  The extra bindings introduced
are optimized away (I think).)

> which seems slightly less hacky than what I'm doing but serves a similar
> purpose.
>
> Marius
>
>
> On Fri, Jul 22, 2016 at 9:01 AM, Mauro  wrote:
>
>>
>> On Fri, 2016-07-22 at 01:02, Marius Millea  wrote:
>> >> FYI Mauro's package has something similar
>> >> .
>> >>
>> >
>> > Some interesting stuff in there, thanks!
>>
>> The problem with your `@self` and with Parameters.jl's
>> `@unpack_SomeType` macros is that it is easy to introduce bugs.
>> Consider:
>>
>>   type A # and register it with @self
>>  a
>>   end
>>   @self f(x,aa:A) = sin(2pi/a*x)
>>
>> Sometime later you refactor type A:
>>
>>   type A
>>  a
>>  pi
>>   end
>>
>> now your function f is broken.  So, for every change in type A you need
>> to check all functions which use `@self`.
>>
>> Instead I now use the @unpack macro (and its companion @pack), also part
>> of Paramters.jl.  Then above f becomes
>>
>>   function f(x,aa::A)
>> @unpack aa: a
>> sin(2pi/a*x)
>>   end
>>
>> This is still much more compact than writing out all the aa.a, etc. (if
>> there are lots of field accesses) but safe.  Also, it clearly states, at
>> the top of the function, which fields of a type are actually used.
>>

Re: [julia-users] accessing an expression's global scope from macro

[Yichao Yu]

>> You should not do this. It is possible to access the current module
>> but you don't have any scope information.
>
>
> Do you mean that its possible to get the module where the expression (not
> the macro) is defined? If so, how do I do that?
>

`current_module()` is the module the expression is being expanded in
but it is completely the wrong scope to resolve the symbols in. It's
fine to implement something that sort of works for yourself but this
should not be used in general.

>
>
>>
>>
>> >
>
>

Re: [julia-users] A foolproof question about ylim

[chobbes158]

Terrific! As a stranger to python, I've never thought that get and set 
methods are using the same keyword. Thanks!

On Friday, July 22, 2016 at 12:09:17 AM UTC+1, Yichao Yu wrote:
>
> On Thu, Jul 21, 2016 at 7:03 PM,   
> wrote: 
> > 
> > 
> > How can I get ylim when using PyPlot? I tried all the suggestions I 
> found on 
> > stackoverflow. None of them works, e.g. get_ylim(). Here is the error: 
> > 
> > ERROR: LoadError: UndefVarError: get_ylim not defined 
> > 
> > Can anyone give me an example of getting the current ylim? Thanks!! 
>
>
> Err, `ylim()`? I believe this is how you do that in python too. 
>

[julia-users] Re: Array of vectors in type definition

[Jussi Piitulainen]

perjantai 22. heinäkuuta 2016 12.26.58 UTC+3 Jussi Piitulainen kirjoitti:

>
> I'm not sure how the square brackets would be used if you wanted a matrix 
> of matrices, but you could at least start with an empty one by writing 
> Matrix{Matrix{Float64}}(). And for an empty vector of matrices, as said, 
> Vector{Matrix{Float64}}. And Julia will show these types as Array{T,1} and 
> Array{T,2} instead of Vector and Matrix.
>
> Sorry, Vector{Matrix{Float64}}() to make a Vector{Matrix{Float64}}. 

[julia-users] Re: Array of vectors in type definition

[Jussi Piitulainen]

perjantai 22. heinäkuuta 2016 11.28.58 UTC+3 Ferran Mazzanti kirjoitti:
>
> Sorry for being so noob once again, but I'm getting close without getting 
> actually to it.
> Could somebody tell me please how should I change the previous definition 
> of caw() as given by Jussi to make room
> for a Vector of Arrays (I can fix them to dimension 2) instead of a Vector 
> of Vector?  I'd like to be able to define it simllarly,
> so that instances of caw() are initially empty and I push!() 2-dimensional 
> arrays into it...
>

 My hobby: empty things.

Array type has two parameters: element type and number of dimensions. 
Vector{Float64} is shorthand for Array{Float64,1}, and Matrix{Float64} is 
similar shorthand for Array{Float64,2}. A vector can be made by listing the 
elements in square brackets after the element type:
julia> Matrix{Float64}[]
0-element Array{Array{Float64,2},1}

Or as Stefan did using the type of the vector:
julia> Vector{Matrix{Float64}}()
0-element Array{Array{Float64,2},1}

There is no Matrix there but you can push! a Matrix there. Or you can start 
with a non-empty Vector that contains an empty Matrix:
julia> Matrix{Float64}[Matrix{Float64}()]
1-element Array{Array{Float64,2},1}:
 0x0 Array{Float64,2}

The expression inside the square brackets makes an empty Matrix. I think 
they are changing this, but in the current release the type name before the 
square brackets makes a big difference when the element is an Array.

I'm not sure how the square brackets would be used if you wanted a matrix 
of matrices, but you could at least start with an empty one by writing 
Matrix{Matrix{Float64}}(). And for an empty vector of matrices, as said, 
Vector{Matrix{Float64}}. And Julia will show these types as Array{T,1} and 
Array{T,2} instead of Vector and Matrix.

[julia-users] Re: Array of vectors in type definition

[Ferran Mazzanti]

Sorry for being so noob once again, but I'm getting close without getting 
actually to it.
Could somebody tell me please how should I change the previous definition 
of caw() as given by Jussi to make room
for a Vector of Arrays (I can fix them to dimension 2) instead of a Vector 
of Vector?  I'd like to be able to define it simllarly,
so that instances of caw() are initially empty and I push!() 2-dimensional 
arrays into it...

Thanks and sorry again,

Ferran.

On Wednesday, July 20, 2016 at 6:37:25 PM UTC+2, Jussi Piitulainen wrote:
>
> keskiviikko 20. heinäkuuta 2016 18.57.13 UTC+3 Ferran Mazzanti kirjoitti:
>>
>> Sorry guys again,
>>
>> I said it works as I tried it out and seemed to work. Now I'm not even 
>> sure it does work, don't ask me why. I try now this
>>
>> type caw
>>legs :: Int64
>>spots :: Vector{Vector{Float64}}
>>caw() = new()
>> end
>>
>> then I can do things like
>> z = caw()
>> which produce
>>
>> caw(4587026064,#undef)
>>
>>
>> Now the question is: how do I start adding vectors to z.spots?
>>
>> I've tried things like
>>
>>
>> push!(z.spots,[1.0])
>>
>>
>> but then I get 
>>
>>
>> LoadError: UndefRefError: access to undefined reference
>> while loading In[30], in expression starting on line 1
>>
>>
>> Thanks for your help,
>>
>>
>> Ferran.
>>
>>
>> and now it does not complain
>>
>> On Monday, July 18, 2016 at 5:13:23 PM UTC+2, Ferran Mazzanti wrote:
>>>
>>> Guys,
>>>
>>> today I've tried to include a vector of vectors as part of atype 
>>> definition, something like
>>>
>>> type caw
>>>legs :: Int64
>>>spots :: Array{Float64}[]
>>> end
>>>
>>> but that fails. Shall I understand that it is not possible to define 
>>> that in a type definition? I just wanted to include a structrure that could 
>>> grow
>>> by adding more data dynamically...
>>>
>>> Any hint about this?
>>>
>>> Thanks for your kind help,
>>>
>>> Ferran.
>>>
>>
>  
> julia> type caw
>  legs :: Int64
>  spots :: Vector{Vector{Float64}}
>  caw() = new(4587026064, Vector{Float64}[])
>end
>
> julia> z = caw()
> caw(4587026064,Array{Float64,1}[])
>
> julia> push!(z.spots, [1.0])
> 1-element Array{Array{Float64,1},1}:
>  [1.0]
>
> julia> z
> caw(4587026064,[[1.0]])
>
>
>
>

Re: [julia-users] Re: accessing an expression's global scope from macro

[Marius Millea]

Yea, thats a good point. Granted for my purpose I'm never going to be
redefining these types mid program. I suppose one might extend your @unpack
to work on an expression and do the substitution recursively like my thing
does, then you could write,

@unpack aa: a function(x,aa:A)
  sin(2pi/a*x)
  a = 3 #can also assign without repacking
end

which seems slightly less hacky than what I'm doing but serves a similar
purpose.

Marius


On Fri, Jul 22, 2016 at 9:01 AM, Mauro  wrote:

>
> On Fri, 2016-07-22 at 01:02, Marius Millea  wrote:
> >> FYI Mauro's package has something similar
> >> .
> >>
> >
> > Some interesting stuff in there, thanks!
>
> The problem with your `@self` and with Parameters.jl's
> `@unpack_SomeType` macros is that it is easy to introduce bugs.
> Consider:
>
>   type A # and register it with @self
>  a
>   end
>   @self f(x,aa:A) = sin(2pi/a*x)
>
> Sometime later you refactor type A:
>
>   type A
>  a
>  pi
>   end
>
> now your function f is broken.  So, for every change in type A you need
> to check all functions which use `@self`.
>
> Instead I now use the @unpack macro (and its companion @pack), also part
> of Paramters.jl.  Then above f becomes
>
>   function f(x,aa::A)
> @unpack aa: a
> sin(2pi/a*x)
>   end
>
> This is still much more compact than writing out all the aa.a, etc. (if
> there are lots of field accesses) but safe.  Also, it clearly states, at
> the top of the function, which fields of a type are actually used.
>

Re: [julia-users] Re: accessing an expression's global scope from macro

[Mauro]

On Fri, 2016-07-22 at 01:02, Marius Millea  wrote:
>> FYI Mauro's package has something similar
>> .
>>
>
> Some interesting stuff in there, thanks!

The problem with your `@self` and with Parameters.jl's
`@unpack_SomeType` macros is that it is easy to introduce bugs.
Consider:

  type A # and register it with @self
 a
  end
  @self f(x,aa:A) = sin(2pi/a*x)

Sometime later you refactor type A:

  type A
 a
 pi
  end

now your function f is broken.  So, for every change in type A you need
to check all functions which use `@self`.

Instead I now use the @unpack macro (and its companion @pack), also part
of Paramters.jl.  Then above f becomes

  function f(x,aa::A)
@unpack aa: a
sin(2pi/a*x)
  end

This is still much more compact than writing out all the aa.a, etc. (if
there are lots of field accesses) but safe.  Also, it clearly states, at
the top of the function, which fields of a type are actually used.

Re: [julia-users] accessing an expression's global scope from macro

[Marius Millea]

On Thu, Jul 21, 2016 at 10:33 PM, Yichao Yu  wrote:

> On Thu, Jul 21, 2016 at 4:01 PM, Marius Millea 
> wrote:
> > In an attempt to make some numerical code (ie something thats basically
> just
> > a bunch of equations) more readable, I am trying to write a macro that
> lets
> > me write the code more succinctly. The code uses parameters from some
> data
> > structure, call it "mytype", so its littered with "t.a", "t.b", etc..
> where
> > t::mytype. My macro basically splices in the the "t." part for me. Its
> kind
> > of like how C++ member functions automatically access the class's
> fields, as
> > an example. To my amazement / growing love of Julia, I actually managed
> to
> > hack it together without too much difficulty, it looks like this,
> >
> >
> > macro self(func)
> > @assert func.head == :function
> >
> > # add "self" as a first function argument
> > insert!(func.args[1].args,2,:(self::mytype))
> >
> >
> > # recurse through AST and rename X to self.X if
> > # its a fieldname of mytype
> > function visit(ex)
> > if typeof(ex) == Expr
> > ex.args = map(visit,ex.args)
> > elseif (typeof(ex) == Symbol) & (ex in fieldnames(mytype))
> > return :(self.$ex)
> > end
> > ex
> > end
> > func.args[2] = visit(func.args[2])
> >
> > show(func) # print the edited function so we can see it in action
> >
> > :($(esc(func)))
> > end
> >
> >
> >
> >
> > Here it is in action:
> >
> >> @self function inc()
> > x = x + 1
> > end
> >
> >
> > :(function inc(self::mytype)
> > self.x = self.x + 1
> > end)
> >
> >
> > inc (generic function with 1 method)
> >
> >
> >
> >
> >> inc(mytype(0))
> > 1
> >
> >
> >
> > where I'm assuming I've defined mytype as
> >
> > type mytype
> > x
> > end
> >
> >
> >
> > As you can see, all it did was add self::mytype as an arg and replace x
> with
> > self.x everywhere it found it. This is also super nice because there is
> zero
> > run-time overhead vs. having written the "self." myself, everything
> happens
> > compile time.
> >
> > Now for the question. I'd like to also to be able automatically pass the
> > "self" argument to functions, so that I could write something like,
> >
> > @self function inc2()
> > inc()
> > inc()
> > end
> >
> >
> >
> > and it would produce
> >
> > function inc2(self::mytype)
> > inc(self)
> > inc(self)
> > end
> >
> >
> >
> > For this though, my macro needs to somehow figure out that "inc" was also
> > defined with @self (since it shouldn't blindly add self as a first arg so
> > other non-@self'ed function calls). Is this possible in Julia? I suppose
> > somehow the macro must access the global scope where the expression is
> being
> > evaluated? I'm not entirely sure that's doable. I'm happy to take any
> tips
> > how to achieve this though, especially ones incurring minimal overhead
> for
> > the rewritten function. Thanks!
>
> You should not do this. It is possible to access the current module
> but you don't have any scope information.
>

Do you mean that its possible to get the module where the expression (not
the macro) is defined? If so, how do I do that?




>
> >
>