Re: [julia-users] Re: isdefined with local variables

[Yichao Yu]

On Tue, Jul 19, 2016 at 11:54 PM, Isaiah Norton  wrote:
> Creating variables dynamically at local scope is not possible (if you are
> calling `eval` inside a function: it does not work like that!)
>
>> Since the runtime can determine that the local variable is undefined as
>> evidenced by an appropriate error
>
>
> All compile-time undefined bindings become a runtime lookup from the
> enclosing (i.e. module) scope. The undefined error means that this lookup
> failed.

We do have local only variables that can be undefined.

>
>
> On Tue, Jul 19, 2016 at 10:43 PM, Christopher Rinderspacher
>  wrote:
>>
>> I, too, would like to be able to check whether local variables are
>> defined. In my case, I am parsing a file that doesn't allow redefinition of
>> a field. The natural way to do this is to check whether I've previously
>> assigned a variable with the content.
>>
>> The fact that isdefined only looks at the module scope is really
>> irrelevant to my use case. Since the runtime can determine that the local
>> variable is undefined as evidenced by an appropriate error, I wish I could
>> do the same within my function without some clunky try ... catch mehcanism.

A separate bool flag or a Nullable should work equally well.

>>
>>
>> On Monday, May 11, 2015 at 7:31:06 PM UTC-4, Juha Heiskala wrote:
>>>
>>>  Hello,
>>>
>>> Am I missing something or doesn't isdefined detect local variables of a
>>> function?
>>>
>>>
>>> julia> foo()= begin bar=1; isdefined(current_module(), :bar); end
>>> foo (generic function with 1 method)
>>>
>>> julia> foo()
>>> false
>>>
>>> Best Regards,
>>>
>>> Juha
>>>
>>> julia version 0.3.5
>>>
>>> julia> versioninfo()
>>> Julia Version 0.3.5
>>> Commit a05f87b* (2015-01-08 22:33 UTC)
>>> Platform Info:
>>>   System: Linux (x86_64-linux-gnu)
>>>   CPU: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY)
>>>   LAPACK: liblapack.so.3
>>>   LIBM: libopenlibm
>>>   LLVM: libLLVM-3.3
>
>

Re: [julia-users] Call Julia from a c++ shared lib

[Yichao Yu]

On Tue, Jul 19, 2016 at 8:00 PM, jqian via julia-users
 wrote:
>
> I am trying to call Julia from C++ shared library.  From the log, it seems
> the call to jl_eval_string("sqrt(2.0)") return correct value.
> The problem is that the function  CPPCallJulia::gssqrt( ) never return to
> caller ( If I remove Julia function, it works fine).

What do you get if you run it in gdb.

>
>
> g++ -c -W -O3 -m64 -fPIC CPPCallJulia.cpp  -I$JULIA_DIR/include/julia
> g++ -O3 -shared -m64 -WI  -fPIC -o./libCPPCallJulia.so CPPCallJulia.o
> -L$JULIA_DIR/lib/julia -lm -ljulia
>
>
> Thanks for the help.
> Jason
> string CPPCallJulia::gssqrt(const vector & args)
> {
> ofstream f("/home/ju_log.txt",ios::out);
> stringstream s;
> double result=1000;
>
> jl_init("/home/Julia/julia-2e358ce975/bin");
> jl_value_t *ret = (jl_value_t*)jl_eval_string("sqrt(2.0)");
> if (jl_is_float64(ret)) {
> result = jl_unbox_float64(ret);
> }
>
> jl_atexit_hook(0);

FYI, you will never able to reinitialize julia again without restart
your process after this call..

>
> s << result;
>
>   if(f.is_open()){
>f<<"=== result ";
>f<f.close();
>   }
> return s.str();
> }

Re: [julia-users] Re: isdefined with local variables

[Isaiah Norton]

Creating variables dynamically at local scope is not possible (if you are
calling `eval` inside a function: it does not work like that!)

Since the runtime can determine that the local variable is undefined as
> evidenced by an appropriate error


All compile-time undefined bindings become a runtime lookup from the
enclosing (i.e. module) scope. The undefined error means that this lookup
failed.


On Tue, Jul 19, 2016 at 10:43 PM, Christopher Rinderspacher <
crind...@gmail.com> wrote:

> I, too, would like to be able to check whether local variables are
> defined. In my case, I am parsing a file that doesn't allow redefinition of
> a field. The natural way to do this is to check whether I've previously
> assigned a variable with the content.
>
> The fact that isdefined only looks at the module scope is really
> irrelevant to my use case. Since the runtime can determine that the local
> variable is undefined as evidenced by an appropriate error, I wish I could
> do the same within my function without some clunky try ... catch mehcanism.
>
>
> On Monday, May 11, 2015 at 7:31:06 PM UTC-4, Juha Heiskala wrote:
>>
>>  Hello,
>>
>> Am I missing something or doesn't isdefined detect local variables of a
>> function?
>>
>>
>> julia> foo()= begin bar=1; isdefined(current_module(), :bar); end
>> foo (generic function with 1 method)
>>
>> julia> foo()
>> false
>>
>> Best Regards,
>>
>> Juha
>>
>> julia version 0.3.5
>>
>> julia> versioninfo()
>> Julia Version 0.3.5
>> Commit a05f87b* (2015-01-08 22:33 UTC)
>> Platform Info:
>>   System: Linux (x86_64-linux-gnu)
>>   CPU: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY)
>>   LAPACK: liblapack.so.3
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.3
>>
>

[julia-users] Call Julia from a c++ shared lib

[jqian via julia-users]

I am trying to call Julia from C++ shared library.  From the log, it seems 
the call to jl_eval_string("sqrt(2.0)") return correct value.
The problem is that the function  CPPCallJulia::gssqrt( ) never return to 
caller ( If I remove Julia function, it works fine).


g++ -c -W -O3 -m64 -fPIC CPPCallJulia.cpp  -I$JULIA_DIR/include/julia
g++ -O3 -shared -m64 -WI  -fPIC -o./libCPPCallJulia.so CPPCallJulia.o 
-L$JULIA_DIR/lib/julia -lm -ljulia


Thanks for the help.
Jason
string CPPCallJulia::gssqrt(const vector & args)
{
ofstream f("/home/ju_log.txt",ios::out);
stringstream s;
double result=1000;

jl_init("/home/Julia/julia-2e358ce975/bin");
jl_value_t *ret = (jl_value_t*)jl_eval_string("sqrt(2.0)");
if (jl_is_float64(ret)) {
result = jl_unbox_float64(ret);
}

jl_atexit_hook(0);

s << result;

  if(f.is_open()){
   f<<"=== result ";
   f<

[julia-users] Re: isdefined with local variables

[Christopher Rinderspacher]

I, too, would like to be able to check whether local variables are 
defined. In my case, I am parsing a file that doesn't allow redefinition of 
a field. The natural way to do this is to check whether I've previously 
assigned a variable with the content.

The fact that isdefined only looks at the module scope is really irrelevant 
to my use case. Since the runtime can determine that the local variable is 
undefined as evidenced by an appropriate error, I wish I could do the same 
within my function without some clunky try ... catch mehcanism.


On Monday, May 11, 2015 at 7:31:06 PM UTC-4, Juha Heiskala wrote:
>
>  Hello,
>
> Am I missing something or doesn't isdefined detect local variables of a 
> function?
>
>
> julia> foo()= begin bar=1; isdefined(current_module(), :bar); end
> foo (generic function with 1 method)
>
> julia> foo()
> false
>
> Best Regards,
>
> Juha
>
> julia version 0.3.5
>
> julia> versioninfo()
> Julia Version 0.3.5
> Commit a05f87b* (2015-01-08 22:33 UTC)
> Platform Info:
>   System: Linux (x86_64-linux-gnu)
>   CPU: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY)
>   LAPACK: liblapack.so.3
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>

Re: [julia-users] IBM Power port

[James Fairbanks]

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)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x3fff97a2)
libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9784)
libz.so.1 => /lib64/libz.so.1 (0x3fff9780)
/lib64/ld64.so.2 (0x35a0)

On Tuesday, July 19, 2016 at 6:30:34 PM UTC-4, James Fairbanks wrote:
>
> Adding /usr/lib64/atlas was insufficient so I created a symlink in ln -s 
> /usr/lib/atlas/libsatlas.so.3 /usr/lib/atlas/libsatlas.so
> This allowed the build process to complete but leads to an error when 
> running the julia executable.
>
> The error is:
> /home/jpf/julia/usr/bin/julia: symbol lookup error: 
> /home/jpf/julia/usr/bin/../lib/liblapack.so: undefined symbol: lsame_
>
> Is it a good idea to go with the RHEL ppc64le system lapack instead of 
> having julia build lapack against system blas?
> I have this version of lapack available from the system.
>
> Available Packages
> Name: lapack
> Arch: ppc64le
> Version : 3.4.2
> Release : 5.el7
> Size: 4.9 M
> Repo: rhel-7-for-power-le-rpms/7Server/ppc64le
>
>
> Thanks,
>   James
> On Tuesday, July 19, 2016 at 4:46:22 PM UTC-4, Viral Shah wrote:
>>
>>
>> Yes - I forgot to mention that. On the machine I am using, I had to add 
>> /usr/lib64/atlas or something like that to LD_LIBRARY_PATH. I can’t login 
>> at the moment for some reason, or else I could have retrieved the exact 
>> line. 
>>
>>
>> -viral 
>>
>>
>>
>> > On Jul 19, 2016, at 4:12 PM, James Fairbanks  
>> wrote: 
>> > 
>> > I set it up like you said and got the following error 
>> > 
>> > $ make 
>> > ... a bunch of stuff successfully building ... 
>> > /usr/bin/ld: cannot find -lsatlas 
>> > collect2: error: ld returned 1 exit status 
>> > make[1]: *** [build/lapack-3.5.0/liblapack.so] Error 1 
>> > make: *** [julia-deps] Error 2 
>> > 
>> > Do I need to add something to LD_LIBRARY_PATH in the makefile or bash 
>> environment? 
>> > 
>> > On Tuesday, July 19, 2016 at 3:59:55 PM UTC-4, Viral Shah wrote: 
>> > There is some old ATLAS stuff in there to build atlas that hasn’t been 
>> used for a very long time. We are going to delete it. If we find this atlas 
>> stuff to be generally useful, we can bring it into the Makefile - but I 
>> definitely don’t want to support a source build. 
>> > 
>> > override USE_SYSTEM_BLAS = 1 
>> > override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
>> > override LIBBLASNAME = libsatlas 
>> > override USE_BLAS64 = 0 
>> > override JULIA_THREADS := 0 
>> > 
>> > Use the vs/ccall-ppc branch that I just pushed, with the above 
>> Make.user.  Master still doesn’t work. 
>> > 
>> > -viral 
>> > 
>> > 
>> > > On Jul 19, 2016, at 3:49 PM, James Fairbanks  
>> wrote: 
>> > > 
>> > > You are overriding the SYSTEM_BLAS with ATLAS. There is a USE_ATLAS 
>> option. Sould that work? 
>> > > 
>> > > the relevant part from Make.inc is 
>> > > 
>> > > USE_ATLAS := 0 
>> > > ATLAS_LIBDIR := $(build_libdir) 
>> > > # or ATLAS_LIBDIR := /path/to/atlas 
>> > > 
>> > > 
>> > > 
>> > > On Saturday, July 9, 2016 at 2:07:38 AM UTC-4, Viral Shah wrote: 
>> > > The current master now seems to be in good shape for Power, for those 
>> interested in trying it out. OpenBLAS is still working out a few bugs, but 
>> in the meanwhile, I was able to successfully link against Atlas using the 
>> following Make.user: 
>> > > 
>> > > override USE_SYSTEM_BLAS = 1 
>> > > override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
>> > > override LIBBLASNAME = libsatlas 
>> > > override USE_BLAS64 = 0 
>> > > 
>> > > Apart from multi-threading, all the other tests passed. 
>> > > 
>> > > -viral 
>> > > 
>> > 
>>
>>

Re: [julia-users] IBM Power port

[James Fairbanks]

Adding /usr/lib64/atlas was insufficient so I created a symlink in ln -s 
/usr/lib/atlas/libsatlas.so.3 /usr/lib/atlas/libsatlas.so
This allowed the build process to complete but leads to an error when 
running the julia executable.

The error is:
/home/jpf/julia/usr/bin/julia: symbol lookup error: 
/home/jpf/julia/usr/bin/../lib/liblapack.so: undefined symbol: lsame_

Is it a good idea to go with the RHEL ppc64le system lapack instead of 
having julia build lapack against system blas?
I have this version of lapack available from the system.

Available Packages
Name: lapack
Arch: ppc64le
Version : 3.4.2
Release : 5.el7
Size: 4.9 M
Repo: rhel-7-for-power-le-rpms/7Server/ppc64le


Thanks,
  James
On Tuesday, July 19, 2016 at 4:46:22 PM UTC-4, Viral Shah wrote:
>
>
> Yes - I forgot to mention that. On the machine I am using, I had to add 
> /usr/lib64/atlas or something like that to LD_LIBRARY_PATH. I can’t login 
> at the moment for some reason, or else I could have retrieved the exact 
> line. 
>
>
> -viral 
>
>
>
> > On Jul 19, 2016, at 4:12 PM, James Fairbanks  > wrote: 
> > 
> > I set it up like you said and got the following error 
> > 
> > $ make 
> > ... a bunch of stuff successfully building ... 
> > /usr/bin/ld: cannot find -lsatlas 
> > collect2: error: ld returned 1 exit status 
> > make[1]: *** [build/lapack-3.5.0/liblapack.so] Error 1 
> > make: *** [julia-deps] Error 2 
> > 
> > Do I need to add something to LD_LIBRARY_PATH in the makefile or bash 
> environment? 
> > 
> > On Tuesday, July 19, 2016 at 3:59:55 PM UTC-4, Viral Shah wrote: 
> > There is some old ATLAS stuff in there to build atlas that hasn’t been 
> used for a very long time. We are going to delete it. If we find this atlas 
> stuff to be generally useful, we can bring it into the Makefile - but I 
> definitely don’t want to support a source build. 
> > 
> > override USE_SYSTEM_BLAS = 1 
> > override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
> > override LIBBLASNAME = libsatlas 
> > override USE_BLAS64 = 0 
> > override JULIA_THREADS := 0 
> > 
> > Use the vs/ccall-ppc branch that I just pushed, with the above 
> Make.user.  Master still doesn’t work. 
> > 
> > -viral 
> > 
> > 
> > > On Jul 19, 2016, at 3:49 PM, James Fairbanks  
> wrote: 
> > > 
> > > You are overriding the SYSTEM_BLAS with ATLAS. There is a USE_ATLAS 
> option. Sould that work? 
> > > 
> > > the relevant part from Make.inc is 
> > > 
> > > USE_ATLAS := 0 
> > > ATLAS_LIBDIR := $(build_libdir) 
> > > # or ATLAS_LIBDIR := /path/to/atlas 
> > > 
> > > 
> > > 
> > > On Saturday, July 9, 2016 at 2:07:38 AM UTC-4, Viral Shah wrote: 
> > > The current master now seems to be in good shape for Power, for those 
> interested in trying it out. OpenBLAS is still working out a few bugs, but 
> in the meanwhile, I was able to successfully link against Atlas using the 
> following Make.user: 
> > > 
> > > override USE_SYSTEM_BLAS = 1 
> > > override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
> > > override LIBBLASNAME = libsatlas 
> > > override USE_BLAS64 = 0 
> > > 
> > > Apart from multi-threading, all the other tests passed. 
> > > 
> > > -viral 
> > > 
> > 
>
>

Re: [julia-users] IBM Power port

[Viral Shah]

Yes - I forgot to mention that. On the machine I am using, I had to add 
/usr/lib64/atlas or something like that to LD_LIBRARY_PATH. I can’t login at 
the moment for some reason, or else I could have retrieved the exact line.


-viral



> On Jul 19, 2016, at 4:12 PM, James Fairbanks  wrote:
> 
> I set it up like you said and got the following error
> 
> $ make
> ... a bunch of stuff successfully building ...
> /usr/bin/ld: cannot find -lsatlas
> collect2: error: ld returned 1 exit status
> make[1]: *** [build/lapack-3.5.0/liblapack.so] Error 1
> make: *** [julia-deps] Error 2
> 
> Do I need to add something to LD_LIBRARY_PATH in the makefile or bash 
> environment?
> 
> On Tuesday, July 19, 2016 at 3:59:55 PM UTC-4, Viral Shah wrote:
> There is some old ATLAS stuff in there to build atlas that hasn’t been used 
> for a very long time. We are going to delete it. If we find this atlas stuff 
> to be generally useful, we can bring it into the Makefile - but I definitely 
> don’t want to support a source build. 
> 
> override USE_SYSTEM_BLAS = 1 
> override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
> override LIBBLASNAME = libsatlas 
> override USE_BLAS64 = 0 
> override JULIA_THREADS := 0 
> 
> Use the vs/ccall-ppc branch that I just pushed, with the above Make.user.  
> Master still doesn’t work. 
> 
> -viral 
> 
> 
> > On Jul 19, 2016, at 3:49 PM, James Fairbanks  wrote: 
> > 
> > You are overriding the SYSTEM_BLAS with ATLAS. There is a USE_ATLAS option. 
> > Sould that work? 
> > 
> > the relevant part from Make.inc is 
> > 
> > USE_ATLAS := 0 
> > ATLAS_LIBDIR := $(build_libdir) 
> > # or ATLAS_LIBDIR := /path/to/atlas 
> > 
> > 
> > 
> > On Saturday, July 9, 2016 at 2:07:38 AM UTC-4, Viral Shah wrote: 
> > The current master now seems to be in good shape for Power, for those 
> > interested in trying it out. OpenBLAS is still working out a few bugs, but 
> > in the meanwhile, I was able to successfully link against Atlas using the 
> > following Make.user: 
> > 
> > override USE_SYSTEM_BLAS = 1 
> > override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
> > override LIBBLASNAME = libsatlas 
> > override USE_BLAS64 = 0 
> > 
> > Apart from multi-threading, all the other tests passed. 
> > 
> > -viral 
> > 
> 

Re: [julia-users] IBM Power port

[Viral Shah]

There is some old ATLAS stuff in there to build atlas that hasn’t been used for 
a very long time. We are going to delete it. If we find this atlas stuff to be 
generally useful, we can bring it into the Makefile - but I definitely don’t 
want to support a source build.

override USE_SYSTEM_BLAS = 1
override LIBBLAS = -L/usr/lib64/atlas -lsatlas
override LIBBLASNAME = libsatlas
override USE_BLAS64 = 0
override JULIA_THREADS := 0

Use the vs/ccall-ppc branch that I just pushed, with the above Make.user.  
Master still doesn’t work.

-viral


> On Jul 19, 2016, at 3:49 PM, James Fairbanks  wrote:
> 
> You are overriding the SYSTEM_BLAS with ATLAS. There is a USE_ATLAS option. 
> Sould that work?
> 
> the relevant part from Make.inc is
> 
> USE_ATLAS := 0
> ATLAS_LIBDIR := $(build_libdir)
> # or ATLAS_LIBDIR := /path/to/atlas
> 
> 
> 
> On Saturday, July 9, 2016 at 2:07:38 AM UTC-4, Viral Shah wrote:
> The current master now seems to be in good shape for Power, for those 
> interested in trying it out. OpenBLAS is still working out a few bugs, but in 
> the meanwhile, I was able to successfully link against Atlas using the 
> following Make.user:
> 
> override USE_SYSTEM_BLAS = 1
> override LIBBLAS = -L/usr/lib64/atlas -lsatlas
> override LIBBLASNAME = libsatlas
> override USE_BLAS64 = 0
> 
> Apart from multi-threading, all the other tests passed.
> 
> -viral
> 

Re: [julia-users] IBM Power port

[James Fairbanks]

I set it up like you said and got the following error

$ make
... a bunch of stuff successfully building ...
/usr/bin/ld: cannot find -lsatlas
collect2: error: ld returned 1 exit status
make[1]: *** [build/lapack-3.5.0/liblapack.so] Error 1
make: *** [julia-deps] Error 2

Do I need to add something to LD_LIBRARY_PATH in the makefile or bash 
environment?

On Tuesday, July 19, 2016 at 3:59:55 PM UTC-4, Viral Shah wrote:
>
> There is some old ATLAS stuff in there to build atlas that hasn’t been 
> used for a very long time. We are going to delete it. If we find this atlas 
> stuff to be generally useful, we can bring it into the Makefile - but I 
> definitely don’t want to support a source build. 
>
> override USE_SYSTEM_BLAS = 1 
> override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
> override LIBBLASNAME = libsatlas 
> override USE_BLAS64 = 0 
> override JULIA_THREADS := 0 
>
> Use the vs/ccall-ppc branch that I just pushed, with the above Make.user. 
>  Master still doesn’t work. 
>
> -viral 
>
>
> > On Jul 19, 2016, at 3:49 PM, James Fairbanks  > wrote: 
> > 
> > You are overriding the SYSTEM_BLAS with ATLAS. There is a USE_ATLAS 
> option. Sould that work? 
> > 
> > the relevant part from Make.inc is 
> > 
> > USE_ATLAS := 0 
> > ATLAS_LIBDIR := $(build_libdir) 
> > # or ATLAS_LIBDIR := /path/to/atlas 
> > 
> > 
> > 
> > On Saturday, July 9, 2016 at 2:07:38 AM UTC-4, Viral Shah wrote: 
> > The current master now seems to be in good shape for Power, for those 
> interested in trying it out. OpenBLAS is still working out a few bugs, but 
> in the meanwhile, I was able to successfully link against Atlas using the 
> following Make.user: 
> > 
> > override USE_SYSTEM_BLAS = 1 
> > override LIBBLAS = -L/usr/lib64/atlas -lsatlas 
> > override LIBBLASNAME = libsatlas 
> > override USE_BLAS64 = 0 
> > 
> > Apart from multi-threading, all the other tests passed. 
> > 
> > -viral 
> > 
>
>

[julia-users] Re: IBM Power port

[James Fairbanks]

You are overriding the SYSTEM_BLAS with ATLAS. There is a USE_ATLAS option. 
Sould that work?

the relevant part from Make.inc is

USE_ATLAS := 0
ATLAS_LIBDIR := $(build_libdir)
# or ATLAS_LIBDIR := /path/to/atlas



On Saturday, July 9, 2016 at 2:07:38 AM UTC-4, Viral Shah wrote:
>
> The current master now seems to be in good shape for Power, for those 
> interested in trying it out. OpenBLAS is still working out a few bugs, but 
> in the meanwhile, I was able to successfully link against Atlas using the 
> following Make.user:
>
> override USE_SYSTEM_BLAS = 1
> override LIBBLAS = -L/usr/lib64/atlas -lsatlas
> override LIBBLASNAME = libsatlas
> override USE_BLAS64 = 0
>
> Apart from multi-threading, all the other tests passed.
>
> -viral
>
>

[julia-users] Re: julia on power8

[James Fairbanks]

On Tuesday, July 19, 2016 at 12:55:25 PM UTC-4, Viral Shah wrote:
>
> I posted my success on power8 here:
>
>
> https://groups.google.com/forum/#!searchin/julia-users/power$20ibm/julia-users/xB0k7XMBNqM/u3eor0IiAwAJ
>
>
Thanks I will see if linking against ATLAS works.
 

> Just curious - is this an HPC system you want to use on? I have a branch 
> on the OSU Power machine that builds that I can push upstream.
>
 
Yes this is an HPC system. I would appreciate that branch.

Re: [julia-users] What does Base.box mean in code_warntype?

[Tim Holy]

They can mean "real" boxing and consequent performance problems, but sometimes 
these get auto-removed during compilation. I see this all the time when 
writing array code, for example this function which takes an input tuple and 
adds 1 to each element:

julia> @inline inc1(a) = _inc1(a...)
inc1 (generic function with 1 method)

julia> @inline _inc1(a1, a...) = (a1+1, _inc1(a...)...)
_inc1 (generic function with 1 method)

julia> _inc1() = ()
_inc1 (generic function with 2 methods)

julia> inc1((3,5,7))
(4,6,8)

# Let's try using inc1 in another function
julia> foo() = (ret = inc1((3,5,7)); prod(ret))
foo (generic function with 1 method)

julia> foo()
192

julia> @code_warntype inc1((3,5,7))
Variables:
  #self#::#inc1
  a::Tuple{Int64,Int64,Int64}

Body:
  begin 
  SSAValue(1) = (Core.getfield)(a::Tuple{Int64,Int64,Int64},2)::Int64
  SSAValue(2) = (Core.getfield)(a::Tuple{Int64,Int64,Int64},3)::Int64
  return (Core.tuple)((Base.box)(Int64,(Base.add_int)((Core.getfield)
(a::Tuple{Int64,Int64,Int64},1)::Int64,1)),(Base.box)(Int64,(Base.add_int)
(SSAValue(1),1)),(Base.box)(Int64,(Base.add_int)(SSAValue(2),
1)))::Tuple{Int64,Int64,Int64}
  end::Tuple{Int64,Int64,Int64}

julia> @code_llvm inc1((3,5,7))

define void @julia_inc1_67366([3 x i64]* noalias sret, [3 x i64]*) #0 {
top:
  %thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
  %2 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 1
  %3 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 2
  %4 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 0
  %5 = load i64, i64* %4, align 8
  %6 = add i64 %5, 1
  %7 = load i64, i64* %2, align 8
  %8 = add i64 %7, 1
  %9 = load i64, i64* %3, align 8
  %10 = add i64 %9, 1
  %11 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 0
  store i64 %6, i64* %11, align 8
  %12 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 1
  store i64 %8, i64* %12, align 8
  %13 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 2
  store i64 %10, i64* %13, align 8
  ret void
}

julia> @code_llvm foo()

define i64 @julia_foo_67563() #0 {
top:
  %thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
  ret i64 192
}

I think you'd be hard-pressed to complain about inefficiencies in foo() ;-).

--Tim

On Tuesday, July 19, 2016 1:42:46 PM CDT Isaiah Norton wrote:
> On Fri, Jul 15, 2016 at 5:02 PM, David Anthoff  wrote:
> > What do these mean?
> 
> http://stackoverflow.com/questions/13055/what-is-boxing-and-unboxing-and-wha
> t-are-the-trade-offs
> > And should I be worried, i.e. is this an indication that something slow
> > might be going on?
> 
> Boxing requires allocation and can block optimizations, so it can be a
> problem to have box/unbox at points where you might hope to be working with
> contiguous primitive values (such as within a loop). But there's really no
> hard-and-fast rule.
> 
> > --
> > 
> > David Anthoff
> > 
> > University of California, Berkeley
> > 
> > 
> > 
> > http://www.david-anthoff.com

Re: [julia-users] What does Base.box mean in code_warntype?

[Isaiah Norton]

On Fri, Jul 15, 2016 at 5:02 PM, David Anthoff  wrote:

>
> What do these mean?
>

http://stackoverflow.com/questions/13055/what-is-boxing-and-unboxing-and-what-are-the-trade-offs


> And should I be worried, i.e. is this an indication that something slow
> might be going on?
>

Boxing requires allocation and can block optimizations, so it can be a
problem to have box/unbox at points where you might hope to be working with
contiguous primitive values (such as within a loop). But there's really no
hard-and-fast rule.


> --
>
> David Anthoff
>
> University of California, Berkeley
>
>
>
> http://www.david-anthoff.com
>
>
>

RE: [julia-users] What does Base.box mean in code_warntype?

[Kristoffer Carlsson]

Pretty much this https://github.com/JuliaLang/julia/issues/15276

RE: [julia-users] What does Base.box mean in code_warntype?

[David Anthoff]

Bump, does anyone have some info about this? Thanks, David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On
Behalf Of David Anthoff
Sent: Friday, July 15, 2016 2:02 PM
To: julia-users@googlegroups.com
Subject: [julia-users] What does Base.box mean in code_warntype?

 

I'm looking for type instabilities in a function with code_warntype, and I'm
seeing lots of ``(Base.box)`` terms there.

 

What do these mean? And should I be worried, i.e. is this an indication that
something slow might be going on?

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

[julia-users] Re: julia on power8

[Viral Shah]

I posted my success on power8 here:

https://groups.google.com/forum/#!searchin/julia-users/power$20ibm/julia-users/xB0k7XMBNqM/u3eor0IiAwAJ

Since then, there are a couple of compiler issues that came in that need 
work on power. We are going to make sure that 0.5 builds on power, since 
the port is almost complete - it passes all but the threading tests.

Just curious - is this an HPC system you want to use on? I have a branch on 
the OSU Power machine that builds that I can push upstream.

-viral

On Tuesday, July 19, 2016 at 11:04:44 AM UTC-4, James Fairbanks wrote:
>
> Hello julia-users,
>
> Has anyone had success using julia on ibm power 8 machines? I see there 
> are some issues on the main repo regarding support but I would like to know 
> if anyone has advice for using julia on power 8.
>
> Thanks,
> James Fairbanks
>

Re: [julia-users] Re: Linear-Equation-System Solver("\") does not work reliably for the "Rational" Type

[Chris Rackauckas]

I wonder if there could be a \! operator for A_ldiv_B!(A,b).

On Tuesday, July 19, 2016 at 8:19:58 AM UTC-7, Andreas Noack wrote:
>
> The UpperTriangular and LinAlg.UnitLowerTriangular parts are not 
> necessary. Julia will detect that but since we already know that they are 
> triangular we can save the costs of the checks.
>
> A_ldiv_B!(A,b) is indeed ugly. It's just A\b where the result is stored in 
> b. That is useful here because it will save us a couple of temporary 
> allocations.
>
> On Tue, Jul 19, 2016 at 11:12 AM, Kurolong  > wrote:
>
>> Thank you, this was very helpful.
>> Just a small question: Are the UpperTriangular and LowerTriangular 
>> commands actually necessary in some case?
>> The other question i have is what A_div_B! actually does in this case, 
>> but i have a feeling that this is hard to explain.
>>
>
>

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

[Tom Breloff]

I think the important thing to know is that Array is an abstract type
unless all parameters have a concrete value. Vector{T} is just a typealias
for Array{T,1}, so Vector{Float64} is a concrete type because
Array{Float64,1} has concrete parameters. However Array{Float64} is NOT
fully specified... It is implicitly the abstract type Array{Float64,N}, and
so you're creating a vector of abstract types, which will hurt performance
in general.

On Tuesday, July 19, 2016, Patrick Kofod Mogensen <
patrick.mogen...@gmail.com> wrote:

> Vector{T} means a vector where the elements are of type T. If T =
> Vector{S} then every element in the original vector is itself a vector with
> elements of type S. In your case, S = Float64 and T = Vector{S} =
> Vector{Float64}. I think it's a pretty good idea to make sure you
> understand this, as the type system is important to understand in order to
> fully exploit multiple dispatch, and to get good performance out of Julia
> programs.
>
> On Tuesday, July 19, 2016 at 12:12:36 AM UTC+2, Ferran Mazzanti wrote:
>>
>> Hi Mauro,
>> your solution seems to work... though I do not understand exactly why :)
>> Even Vector{Array{Float64}} works.
>> Thanks for your kind help :)
>> Ferran.
>>
>

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

[Patrick Kofod Mogensen]

Vector{T} means a vector where the elements are of type T. If T = Vector{S} 
then every element in the original vector is itself a vector with elements 
of type S. In your case, S = Float64 and T = Vector{S} = Vector{Float64}. I 
think it's a pretty good idea to make sure you understand this, as the type 
system is important to understand in order to fully exploit multiple 
dispatch, and to get good performance out of Julia programs.

On Tuesday, July 19, 2016 at 12:12:36 AM UTC+2, Ferran Mazzanti wrote:
>
> Hi Mauro,
> your solution seems to work... though I do not understand exactly why :)
> Even Vector{Array{Float64}} works.
> Thanks for your kind help :)
> Ferran.
>