[julia-users] Re: release-0.5 build failed while building libgit2

[Jinliang Wei]

My apologizes. The problem has been resolved.

On Wednesday, September 14, 2016 at 11:27:42 PM UTC-4, Jinliang Wei wrote:
>
> Any suggestions please?
>
> *Commit: *
>
> commit 9c76c3e89a8c384f324c2e0b84ad28ceef9ab69d
>
> Author: Tony Kelman <...>
>
> Date:   Thu Sep 8 18:43:44 2016 -0700
>
>
> Tag v0.5.0-rc4
>
> *Console output:*
>
> -- Configuring incomplete, errors occurred!
>
> See also 
> "/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeOutput.log".
>
> See also 
> "/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeError.log".
>
> /home/jinliang/julia.git/deps/libgit2.mk:58: recipe for target 
> 'build/libgit2-211e117a0590583a720c53172406f34186c543bd/Makefile' failed
>
> make[1]: *** 
> [build/libgit2-211e117a0590583a720c53172406f34186c543bd/Makefile] Error 1
>
> Makefile:81: recipe for target 'julia-deps' failed
>
> make: *** [julia-deps] Error 2
>
> *CMakeError.log:*
>
> Performing C SOURCE FILE Test HAVE_STRUCT_STAT_ST_MTIMESPEC failed with 
> the following output:
>
> Change Dir: 
> /home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c5317
> 2406f34186c543bd/CMakeFiles/CMakeTmp
>
>
> Run Build Command:"/usr/bin/make" "cmTC_2aea8/fast"
>
> make[2]: Entering directory 
> '/home/jinliang/julia.git/deps/build/libgit2-211e117
> a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'
>
> /usr/bin/make -f CMakeFiles/cmTC_2aea8.dir/build.make 
> CMakeFiles/cmTC_2aea8.dir/build
>
> make[3]: Entering directory 
> '/home/jinliang/julia.git/deps/build/libgit2-211e117
> a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'
>
> Building C object CMakeFiles/cmTC_2aea8.dir/src.c.o
>
> /usr/bin/gcc -m64   -DHAVE_STRUCT_STAT_ST_MTIMESPEC   -o 
> CMakeFiles/cmTC_2aea8.dir/src.c.o   -c 
> /home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c
>
>
> /home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c:
>  
> In function ‘main’:
>
>
> /home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c:7:35:
>  
> error: ‘struct stat’ has no member named ‘st_mtimespec’
>
> (void)sizeof(((struct stat *)0)->st_mtimespec);
>
>^
>
> CMakeFiles/cmTC_2aea8.dir/build.make:65: recipe for target 
> 'CMakeFiles/cmTC_2aea8.dir/src.c.o' failed
>
> make[3]: *** [CMakeFiles/cmTC_2aea8.dir/src.c.o] Error 1
>
> make[3]: Leaving directory 
> '/home/jinliang/julia.git/deps/build/libgit2-211e117a
> 0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'
>
> Makefile:126: recipe for target 'cmTC_2aea8/fast' failed
>
> make[2]: *** [cmTC_2aea8/fast] Error 2
>
> make[2]: Leaving directory 
> '/home/jinliang/julia.git/deps/build/libgit2-211e117a
> 0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'
>
>
> Source file was:
>
>
> #include 
>
> #include 
>
>
> int main()
>
> {  
>
>(void)sizeof(((struct stat *)0)->st_mtimespec);
>
>return 0;
>
> }
>
>
> Performing C SOURCE FILE Test HAVE_STRUCT_STAT_MTIME_NSEC failed with the 
> following output:
>
> Change Dir: 
> /home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c5317
> 2406f34186c543bd/CMakeFiles/CMakeTmp
>
>
> Run Build Command:"/usr/bin/make" "cmTC_e6835/fast"
>
> make[2]: Entering directory 
> '/home/jinliang/julia.git/deps/build/libgit2-211e117
> a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'
>
> /usr/bin/make -f CMakeFiles/cmTC_e6835.dir/build.make 
> CMakeFiles/cmTC_e6835.dir/build
>
> make[3]: Entering directory 
> '/home/jinliang/julia.git/deps/build/libgit2-211e117
> a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'
>
> Building C object CMakeFiles/cmTC_e6835.dir/src.c.o
>
> /usr/bin/gcc -m64   -DHAVE_STRUCT_STAT_MTIME_NSEC   -o 
> CMakeFiles/cmTC_e6835.dir/src.c.o   -c 
> /home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c
>
>
> /home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c:
>  
> In function ‘main’:
>
>
> /home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c:6:35:
>  
> error: ‘struct stat’ has no member named ‘st_mtime_nsec’
>
> (void)sizeof(((struct stat *)0)->st_mtime_nsec);
>
>^
>
> CMakeFiles/cmTC_e6835.dir/build.make:65: recipe for target 
> 'CMakeFiles/cmTC_e6835.dir/src.c.o' failed
>
> make[3]: *** [CMakeFiles/cmTC_e6835.dir/src.c.o] Error 1
>
> make[3]: Leaving directory 
> '/home/jinliang/julia.git/deps/build/libgit2-211e117a
> 0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'
>
> Makefile:126: recipe for target 'cmTC_e6835/fast' failed
>
> make[2]: *** [cmTC_e6835/fast] Error 2
>
> make[2]: Leaving directory 
> '/home/jinliang/julia.git/deps/build/libgit2-211e117a
> 

[julia-users] release-0.5 build failed while building libgit2

[Jinliang Wei]

Any suggestions please?

*Commit: *

commit 9c76c3e89a8c384f324c2e0b84ad28ceef9ab69d

Author: Tony Kelman <...>

Date:   Thu Sep 8 18:43:44 2016 -0700


Tag v0.5.0-rc4

*Console output:*

-- Configuring incomplete, errors occurred!

See also 
"/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeOutput.log".

See also 
"/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeError.log".

/home/jinliang/julia.git/deps/libgit2.mk:58: recipe for target 
'build/libgit2-211e117a0590583a720c53172406f34186c543bd/Makefile' failed

make[1]: *** 
[build/libgit2-211e117a0590583a720c53172406f34186c543bd/Makefile] Error 1

Makefile:81: recipe for target 'julia-deps' failed

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

*CMakeError.log:*

Performing C SOURCE FILE Test HAVE_STRUCT_STAT_ST_MTIMESPEC failed with the 
following output:

Change Dir: 
/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c5317
2406f34186c543bd/CMakeFiles/CMakeTmp


Run Build Command:"/usr/bin/make" "cmTC_2aea8/fast"

make[2]: Entering directory 
'/home/jinliang/julia.git/deps/build/libgit2-211e117
a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'

/usr/bin/make -f CMakeFiles/cmTC_2aea8.dir/build.make 
CMakeFiles/cmTC_2aea8.dir/build

make[3]: Entering directory 
'/home/jinliang/julia.git/deps/build/libgit2-211e117
a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'

Building C object CMakeFiles/cmTC_2aea8.dir/src.c.o

/usr/bin/gcc -m64   -DHAVE_STRUCT_STAT_ST_MTIMESPEC   -o 
CMakeFiles/cmTC_2aea8.dir/src.c.o   -c 
/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c

/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c:
 
In function ‘main’:

/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c:7:35:
 
error: ‘struct stat’ has no member named ‘st_mtimespec’

(void)sizeof(((struct stat *)0)->st_mtimespec);

   ^

CMakeFiles/cmTC_2aea8.dir/build.make:65: recipe for target 
'CMakeFiles/cmTC_2aea8.dir/src.c.o' failed

make[3]: *** [CMakeFiles/cmTC_2aea8.dir/src.c.o] Error 1

make[3]: Leaving directory 
'/home/jinliang/julia.git/deps/build/libgit2-211e117a
0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'

Makefile:126: recipe for target 'cmTC_2aea8/fast' failed

make[2]: *** [cmTC_2aea8/fast] Error 2

make[2]: Leaving directory 
'/home/jinliang/julia.git/deps/build/libgit2-211e117a
0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'


Source file was:


#include 

#include 


int main()

{  

   (void)sizeof(((struct stat *)0)->st_mtimespec);

   return 0;

}


Performing C SOURCE FILE Test HAVE_STRUCT_STAT_MTIME_NSEC failed with the 
following output:

Change Dir: 
/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c5317
2406f34186c543bd/CMakeFiles/CMakeTmp


Run Build Command:"/usr/bin/make" "cmTC_e6835/fast"

make[2]: Entering directory 
'/home/jinliang/julia.git/deps/build/libgit2-211e117
a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'

/usr/bin/make -f CMakeFiles/cmTC_e6835.dir/build.make 
CMakeFiles/cmTC_e6835.dir/build

make[3]: Entering directory 
'/home/jinliang/julia.git/deps/build/libgit2-211e117
a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'

Building C object CMakeFiles/cmTC_e6835.dir/src.c.o

/usr/bin/gcc -m64   -DHAVE_STRUCT_STAT_MTIME_NSEC   -o 
CMakeFiles/cmTC_e6835.dir/src.c.o   -c 
/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c

/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c:
 
In function ‘main’:

/home/jinliang/julia.git/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp/src.c:6:35:
 
error: ‘struct stat’ has no member named ‘st_mtime_nsec’

(void)sizeof(((struct stat *)0)->st_mtime_nsec);

   ^

CMakeFiles/cmTC_e6835.dir/build.make:65: recipe for target 
'CMakeFiles/cmTC_e6835.dir/src.c.o' failed

make[3]: *** [CMakeFiles/cmTC_e6835.dir/src.c.o] Error 1

make[3]: Leaving directory 
'/home/jinliang/julia.git/deps/build/libgit2-211e117a
0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'

Makefile:126: recipe for target 'cmTC_e6835/fast' failed

make[2]: *** [cmTC_e6835/fast] Error 2

make[2]: Leaving directory 
'/home/jinliang/julia.git/deps/build/libgit2-211e117a
0590583a720c53172406f34186c543bd/CMakeFiles/CMakeTmp'


Source file was:


#include 


int main()

{  

   (void)sizeof(((struct stat *)0)->st_mtime_nsec);

   return 0;

}

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

[Tony Kelman]

Something's broken, you'll probably have to run that in gdb and try to get 
a backtrace. I don't think the .lib files are full-fledged static libraries 
(how big are they?), I suspect they are import libraries that go along with 
the corresponding dll's. So the mingw naming convention from them would be 
libmkl_rt.dll.a for mkl_rt.lib. The main thing you want to do is make sure 
the blas and lapack library ccall's are getting pointed to the mkl_rt.dll.


On Wednesday, September 14, 2016 at 3:14:52 PM UTC-7, Zhong Pan wrote:
>
> Thanks, Tony, with your help I think I am pretty close.
>
> Yes you are right, I searched for *.dll and found them in a folder that I 
> didn't notice before.
>
> Here's what I did last based on your comments to move things forward a few 
> steps more:
>
> (1) Copied all the 17 .lib files from "C:\Program Files 
> (x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\mkl\lib\intel64_win"
>  
> to 
> "C:\Users\zpan\Documents\GitHub\julia\usr\x86_64-w64-mingw32\sys-root\mingw\lib".
>  
> Changed them from .lib files to .a files and added prefix "lib". So now the 
> 17 files look like:
>
> libmkl_blas95_ilp64.a
> libmkl_blas95_lp64.a
> libmkl_core.a
> libmkl_core_dll.a
> libmkl_intel_ilp64.a
> libmkl_intel_ilp64_dll.a
> libmkl_intel_lp64.a
> libmkl_intel_lp64_dll.a
> libmkl_intel_thread.a
> libmkl_intel_thread_dll.a
> libmkl_lapack95_ilp64.a
> libmkl_lapack95_lp64.a
> libmkl_rt.a
> libmkl_sequential.a
> libmkl_sequential_dll.a
> libmkl_tbb_thread.a
> libmkl_tbb_thread_dll.a
>
>
>
> (2) Copied all the .dll files from "C:\Program Files 
> (x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\redist\intel64_win\mkl"
>  
> to 
> "C:\Users\zpan\Documents\GitHub\julia\usr\x86_64-w64-mingw32\sys-root\mingw\bin".
>  
> This includes the folder "33". Here are all the files that got copied:
>
> 1033/mkl_msg.dll
> libimalloc.dll
> mkl_avx.dll
> mkl_avx2.dll
> mkl_avx512.dll
> mkl_avx512_mic.dll
> mkl_core.dll
> mkl_def.dll
> mkl_intel_thread.dll
> mkl_mc.dll
> mkl_mc3.dll
> mkl_rt.dll
> mkl_sequential.dll
> mkl_tbb_thread.dll
> mkl_vml_avx.dll
> mkl_vml_avx2.dll
> mkl_vml_avx512.dll
> mkl_vml_avx512_mic.dll
> mkl_vml_cmpt.dll
> mkl_vml_def.dll
> mkl_vml_mc.dll
> mkl_vml_mc2.dll
> mkl_vml_mc3.dll
>
>
> (3) "make -j 4" again. This time, there was no "Cannot find BLAS 
> libraries" error anymore. The build went on for a while until here:
>
> floatfuncs.jl
>
> Please submit a bug report with steps to reproduce this fault, and any 
> error messages that follow (in their entirety). Thanks.
> Exception: EXCEPTION_ACCESS_VIOLATION at 0x0 -- unknown function (ip: 
> )
> unknown function (ip: )
> *** This error is usually fixed by running `make clean`. If the error 
> persists, try `make cleanall`. ***
> make[1]: *** [Makefile:200: 
> /c/users/zpan/Documents/GitHub/julia/usr/lib/julia/sys.o] Error 1
> make: *** [Makefile:69: julia-sysimg-release] Error 2
>
>
> I tried both "make clean" and "make cleanall", and the same problem 
> persisted. I also tried renaming the .dll and .a files in a couple ways in 
> vain. 
>
> Again, any help appreciated!! Hope I am close to success. When I am done I 
> will repeat the process and document it here for others to see.
>
>
>
>
> On Wednesday, September 14, 2016 at 3:02:40 PM UTC-5, Tony Kelman wrote:
>>
>> Which configure file was this from? Julia doesn't need the .lib files, it 
>> needs the dll, and I assure you there are dlls in MKL. However some of the 
>> dependencies may need the .lib files, and/or you can try copying them to a 
>> .dll.a file name if that helps libtool or configure work better.
>>
>>

[julia-users] building a package without rebuilding a REQUIRES pkg

[Jeffrey Sarnoff]

If I have a package MainPkg with a  REQUIRE file that holds "HelperPkg", 
and I do
Pkg.add("HelperPkg");Pkg.build("HelperPkg");
is there a way to 
Pkg.add("MainPkg")
without automatically rebuilding (the already current) HelperPkg?

[julia-users] Re: ANN: SimpleTraits.jl

[Jeffrey Sarnoff]

Thanks for updating your work.
If there is a form that allows a function to be defined that has 
multidispatch over trait and also over type, please provide an example.
(If it is already there, please direct me to that example).

On Wednesday, September 14, 2016 at 6:04:04 AM UTC-4, Mauro wrote:
>
> There is --at times-- some interest on this list about traits, enough 
> that I thought the noise to announce the registration of this traits 
> package is warranted.  In brief, traits group types into sets 
> independent of the type hierarchy and let functions dispatch on those 
> traits instead of on types. 
>
> The package can be found here: 
>   https://github.com/mauro3/SimpleTraits.jl 
>
> SimpleTraits.jl provides macros to automate *Tim's trait trick*.  A 
> brief example (more can be found in the README): 
>
>   using SimpleTraits 
>   # define a trait: 
>   @traitdef IsNice{X} 
>
>   # add some types to the trait: 
>   @traitimpl IsNice{Int} 
>   @traitimpl IsNice{String} 
>
>   # define a function dispatching on this trait and its negation: 
>   @traitfn f{X;  IsNice{X}}(x::X) = "Very nice!" 
>   @traitfn f{X; !IsNice{X}}(x::X) = "Not so nice!" 
>
>   # use that function like any other function 
>   f(5) # => "Very nice!" 
>   f("a") # => "Very nice!" 
>   f(6.0) # => "Not so nice!" 
>
>
> Tim Holy, indeed the inventor of the trick named after him, uses 
> SimpleTraits in the overhaul of his Images.jl package [1,2] (and was who 
> prodded me to register SimpleTraits.jl).  The "blurb" in my README is: 
>
>   Tim Holy endorses SimpleTraits, a bit: "I'd say that compared to 
>   manually writing out the trait-dispatch, the "win" is not enormous, 
>   but it is a little nicer." I suspect that — if you don't write 
>   Holy-traits before breakfast — your "win" should be greater ;-) 
>
> [1] https://github.com/timholy/Images.jl/issues/542 
> [2] https://github.com/JuliaImages/ImageAxes.jl 
>

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

[Yichao Yu]

On Wed, Sep 14, 2016 at 4:12 PM, Harald Held  wrote:
> I'm playing around with embedding Julia in a C application and figured out
> how to create and set scalars, arrays, and tuples from C successfully.
>
> What's missing for what I'm trying to do is to create a dictionary in C that
> is then set to a Julia variable and used in a Julia script. However, I
> couldn't find any information on how to achieve that. Is that even possible?
> If so, what is the appropriate type in C to allocate?

Dict is not a builtin type. It's just a normal julia type that doesn't
have a good mapping in C so there's no builtin API for it.
When dealing with such types for embedding, your options are,

1. If you want to rely on the internal implementation detail of the
type, you can declare type in C with the same field as they appear in
julia code and manipulate the fields. (You probably don't want to use
Dict this way)
2. Call julia functions to create/manipulate the object. This can
either be done by getting the function object and calling them with
`jl_apply` or `jl_call*` functions, or by getting a C callable
function pointer with `cfunction` julia function or `jl_function_ptr`
C API. This is the preferred option for handling complex objects like
dict.

> I guess I could just create two arrays (one holding the keys, the other the
> values), zip them, and create a Dict from that result (in Julia code!) --
> but that would not be a pure C solution which I would prefer.

It's hard to say what counts as "pure C solution" since the object you
want to handle is implemented in pure julia. Unless you want to
reimplement it in pure C there's no pure C solution.

>
> Thanks for any hints and advice on that issue!

Re: [julia-users] Re: dependent types in julia?

[Isaiah Norton]

See https://github.com/JuliaLang/julia/issues/18466#issuecomment-246713799

On Wed, Sep 14, 2016 at 6:13 PM, Dan  wrote:

> Maybe the following is the form you are looking for:
>
> julia> decomplexify{T}(::Type{Complex{T}}) = T
> decomplexify (generic function with 1 method)
>
>
> julia> type bar{S,T}
>sum::S
>sumsqr::T
>function bar(s,ss)
>if typeof(ss) != decomplexify(typeof(s))
>error("Yaiks")
>end
>new(s,ss)
>end
>end
>
>
> julia> bar{Complex{Float64},Float64}(1.5+2.0im,1.0)
> bar{Complex{Float64},Float64}(1.5 + 2.0im,1.0)
>
>
> julia> bar{S,T}(x::S,y::T) = bar{S,T}(x,y)
> bar{S,T}
>
>
> julia> bar(1.5+2.0im,1.0)
> bar{Complex{Float64},Float64}(1.5 + 2.0im,1.0)
>
>
> The outer constructor is necessary to get the last line working. The inner
> constructor basically maintains the constraint between S and T of: T ==
> Complex{S}.
>
> On Wednesday, September 14, 2016 at 3:38:53 PM UTC-4, Neal Becker wrote:
>>
>> Evan Fields wrote:
>>
>> > How about something like the following?
>> >
>> > type CT{T}
>> > ctsum::Complex{T}
>> > ctsumsq::T
>> > end
>> >
>>
>> I'm aware that it's easier to make the type parameter the scalar type,
>> allowing writing as you show, but as a learning exercise I'd like to know
>> how Julia would go the other way.
>>
>> In c++ this would be done with template metaprogramming, but as Julia
>> claims
>> to have types as 1st class objects, I thought there should be some
>> elegant
>> way to do this.
>>
>> That is, given T is Complex{U}, I need the type U so I can write
>> ctsumsq::U
>>
>>

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

[Mosè Giordano]

2016-09-15 0:10 GMT+02:00 Chris Rackauckas:
> If you use Reexport.jl's @reexport in the top-scope of a module for such a
> metapackage it will actually export all of the functions from inside:
>
> module MyMetapackage # Setup t
>   using Reexport
>   @reexport using DifferentialEquations
>   @reexport using Plots
> end
>
>
>
> using MyMetapackage # Imports both packages
> plot # 3 methods
> solve # 7 methods

Nice!  Then I'd vote in favor of meta-packages, rather than distributions.

It seems we basically came to something already proposed almost two
years ago: https://github.com/JuliaLang/julia/issues/1986#issuecomment-67957609
:-)

Bye,
Mosè

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

[Zhong Pan]

Thanks, Tony, with your help I think I am pretty close.

Yes you are right, I searched for *.dll and found them in a folder that I 
didn't notice before.

Here's what I did last based on your comments to move things forward a few 
steps more:

(1) Copied all the 17 .lib files from "C:\Program Files 
(x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\mkl\lib\intel64_win"
 
to 
"C:\Users\zpan\Documents\GitHub\julia\usr\x86_64-w64-mingw32\sys-root\mingw\lib".
 
Changed them from .lib files to .a files and added prefix "lib". So now the 
17 files look like:

libmkl_blas95_ilp64.a
libmkl_blas95_lp64.a
libmkl_core.a
libmkl_core_dll.a
libmkl_intel_ilp64.a
libmkl_intel_ilp64_dll.a
libmkl_intel_lp64.a
libmkl_intel_lp64_dll.a
libmkl_intel_thread.a
libmkl_intel_thread_dll.a
libmkl_lapack95_ilp64.a
libmkl_lapack95_lp64.a
libmkl_rt.a
libmkl_sequential.a
libmkl_sequential_dll.a
libmkl_tbb_thread.a
libmkl_tbb_thread_dll.a



(2) Copied all the .dll files from "C:\Program Files 
(x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\redist\intel64_win\mkl"
 
to 
"C:\Users\zpan\Documents\GitHub\julia\usr\x86_64-w64-mingw32\sys-root\mingw\bin".
 
This includes the folder "33". Here are all the files that got copied:

1033/mkl_msg.dll
libimalloc.dll
mkl_avx.dll
mkl_avx2.dll
mkl_avx512.dll
mkl_avx512_mic.dll
mkl_core.dll
mkl_def.dll
mkl_intel_thread.dll
mkl_mc.dll
mkl_mc3.dll
mkl_rt.dll
mkl_sequential.dll
mkl_tbb_thread.dll
mkl_vml_avx.dll
mkl_vml_avx2.dll
mkl_vml_avx512.dll
mkl_vml_avx512_mic.dll
mkl_vml_cmpt.dll
mkl_vml_def.dll
mkl_vml_mc.dll
mkl_vml_mc2.dll
mkl_vml_mc3.dll


(3) "make -j 4" again. This time, there was no "Cannot find BLAS libraries" 
error anymore. The build went on for a while until here:

floatfuncs.jl

Please submit a bug report with steps to reproduce this fault, and any 
error messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x0 -- unknown function (ip: 
)
unknown function (ip: )
*** This error is usually fixed by running `make clean`. If the error 
persists, try `make cleanall`. ***
make[1]: *** [Makefile:200: 
/c/users/zpan/Documents/GitHub/julia/usr/lib/julia/sys.o] Error 1
make: *** [Makefile:69: julia-sysimg-release] Error 2


I tried both "make clean" and "make cleanall", and the same problem 
persisted. I also tried renaming the .dll and .a files in a couple ways in 
vain. 

Again, any help appreciated!! Hope I am close to success. When I am done I 
will repeat the process and document it here for others to see.




On Wednesday, September 14, 2016 at 3:02:40 PM UTC-5, Tony Kelman wrote:
>
> Which configure file was this from? Julia doesn't need the .lib files, it 
> needs the dll, and I assure you there are dlls in MKL. However some of the 
> dependencies may need the .lib files, and/or you can try copying them to a 
> .dll.a file name if that helps libtool or configure work better.
>
>
>>>

[julia-users] Re: dependent types in julia?

[Dan]

Maybe the following is the form you are looking for:

julia> decomplexify{T}(::Type{Complex{T}}) = T
decomplexify (generic function with 1 method)


julia> type bar{S,T} 
   sum::S 
   sumsqr::T
   function bar(s,ss)
   if typeof(ss) != decomplexify(typeof(s))
   error("Yaiks")
   end
   new(s,ss)
   end
   end


julia> bar{Complex{Float64},Float64}(1.5+2.0im,1.0)
bar{Complex{Float64},Float64}(1.5 + 2.0im,1.0)


julia> bar{S,T}(x::S,y::T) = bar{S,T}(x,y)
bar{S,T}


julia> bar(1.5+2.0im,1.0)
bar{Complex{Float64},Float64}(1.5 + 2.0im,1.0)


The outer constructor is necessary to get the last line working. The inner 
constructor basically maintains the constraint between S and T of: T == 
Complex{S}.

On Wednesday, September 14, 2016 at 3:38:53 PM UTC-4, Neal Becker wrote:
>
> Evan Fields wrote: 
>
> > How about something like the following? 
> > 
> > type CT{T} 
> > ctsum::Complex{T} 
> > ctsumsq::T 
> > end 
> > 
>
> I'm aware that it's easier to make the type parameter the scalar type, 
> allowing writing as you show, but as a learning exercise I'd like to know 
> how Julia would go the other way. 
>
> In c++ this would be done with template metaprogramming, but as Julia 
> claims 
> to have types as 1st class objects, I thought there should be some elegant 
> way to do this. 
>
> That is, given T is Complex{U}, I need the type U so I can write 
> ctsumsq::U 
>
>

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

[Chris Rackauckas]

If you use Reexport.jl's @reexport in the top-scope of a module for such a 
metapackage it will actually export all of the functions from inside:

module MyMetapackage # Setup t
  using Reexport
  @reexport using DifferentialEquations
  @reexport using Plots
end



using MyMetapackage # Imports both packages
plot # 3 methods
solve # 7 methods


On Wednesday, September 14, 2016 at 3:01:34 PM UTC-7, Mosè Giordano wrote:
>
> 2016-09-14 23:46 GMT+02:00 Chris Rackauckas: 
> > I too am weary about how different distributions would play together. 
> I'd 
> > assume you'd just install with one and that would be it. 
>
> There are many people working in many fields that may want to install 
> different distributions.  I don't think that preventing them to 
> install all of them, or forcing them to choose only one, is a good 
> idea.  Creating many cross-field distributions is not viable.  Some 
> people may discard the idea of installing a distribution just for 
> these reasons. 
>
> > And yes, not 
> > putting "using" in code that you share can lead to some issues, so maybe 
> > "using MyMetapackage" and having the repo online so people can see all 
> of 
> > your packages (at that date/time) would be helpful? 
>
> I think this works better with a meta-package, doesn't it?  The 
> problem is that functions are not exported. 
>
> Bye, 
> Mosè 
>

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

[Harald Held]

I'm playing around with embedding Julia in a C application and figured out 
how to create and set scalars, arrays, and tuples from C successfully.

What's missing for what I'm trying to do is to create a dictionary in C 
that is then set to a Julia variable and used in a Julia script. However, I 
couldn't find any information on how to achieve that. Is that even 
possible? If so, what is the appropriate type in C to allocate?

I guess I could just create two arrays (one holding the keys, the other the 
values), zip them, and create a Dict from that result (in Julia code!) -- 
but that would not be a pure C solution which I would prefer.

Thanks for any hints and advice on that issue!

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

[Mosè Giordano]

2016-09-14 23:46 GMT+02:00 Chris Rackauckas:
> I too am weary about how different distributions would play together. I'd
> assume you'd just install with one and that would be it.

There are many people working in many fields that may want to install
different distributions.  I don't think that preventing them to
install all of them, or forcing them to choose only one, is a good
idea.  Creating many cross-field distributions is not viable.  Some
people may discard the idea of installing a distribution just for
these reasons.

> And yes, not
> putting "using" in code that you share can lead to some issues, so maybe
> "using MyMetapackage" and having the repo online so people can see all of
> your packages (at that date/time) would be helpful?

I think this works better with a meta-package, doesn't it?  The
problem is that functions are not exported.

Bye,
Mosè

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

[Chris Rackauckas]

I didn't think about using metapackages instead to do "distributions" (with 
Reexport.jl to make using Metapackage import all of the packages). That 
seems like an interesting idea.

I too am weary about how different distributions would play together. I'd 
assume you'd just install with one and that would be it. And yes, not 
putting "using" in code that you share can lead to some issues, so maybe 
"using MyMetapackage" and having the repo online so people can see all of 
your packages (at that date/time) would be helpful?

It really is an interplay between: things keep moving out of Base (like the 
most recent talk is for LinSpace), so the list of "how many usings I need 
for what I am doing" grows. This is both a good thing because Base is 
leaner, but a bad thing because needing to be too explicit about every 
function you want to use is a PITA. Maybe "distributions" is overkill and 
metapackages + a standard library would be better. g's suggestion of 
ways to exclude the StandardLibrary would be helpful, though I don't know 
if an exclude command is possible (though if it was setup to import some 
standard library, julia --barebones seems possible. I don't know if exclude 
is possible because I don't think there's an easy way to remove a package 
after it's been imported).

On Wednesday, September 14, 2016 at 2:03:17 PM UTC-7, Mosè Giordano wrote:
>
> Hi Chris,
>
> what would be the difference between a distribution and a meta-package 
> like those used, for example, in Debian and derivatives: a package without 
> code, that only requires other packages?  In this sense you can create 
> right now a meta-package: just create a repository for a Julia package and 
> populate the REQUIRE file as you wish.  You can specify a Julia version and 
> provide a build script.
>
> I'm above all worried about the interplay between different 
> distributions.  There would be clashing .juliarc's?  Why providing a 
> .juliarc at all?  Automatically running at startup some "using"s & co. is 
> definitely useful, but can lead in the long run to bad habits, like 
> forgetting to put "using" commands in code shared with people not using the 
> same distribution.
>
> Bye,
> Mosè
>
> I think one major point of contention when talking about what should be 
>> included in Base due to competing factors:
>>
>>
>>1. Some people would like a "lean Base" for things like embedded 
>>installs or other low memory applications
>>2. Some people want a MATLAB-like "bells and whistles" approach. This 
>>way all the functions they use are just there: no extra packages to 
>>find/import.
>>3. Some people like having things in Base because it "standardizes" 
>>things. 
>>4. Putting things in Base constrains their release schedule. 
>>5. Putting things in packages outside of JuliaLang helps free up 
>>Travis.
>>
>>
>> The last two concerns have been why things like JuliaMath have sprung up 
>> to move things out of Base. However, I think there is some credibility to 
>> having some form of standardization. I think this can be achieved through 
>> some kind of standard library. This would entail a set of packages which 
>> are installed when Julia is installed, and a set of packages which add 
>> their using statement to the .juliarc. To most users this would be 
>> seamless: they would install automatically, and every time you open Julia, 
>> they would import automatically. There are a few issues there:
>>
>>
>>1.  This wouldn't work with building from source. This idea works 
>>better for binaries (this is no biggie since these users are likely more 
>>experienced anyways)
>>2. Julia would have to pick winners and losers.
>>
>> That second part is big: what goes into the standard library? Would all 
>> of the MATLAB functions like linspace, find, etc. go there? Would the 
>> sparse matrix library be included?
>>
>> I think one way to circumvent the second issue would be to allow for 
>> Julia Distributions. A distribution would be defined by:
>>
>>
>>1. A Julia version
>>2. A List of packages to install (with versions?)
>>3. A build script
>>4. A .juliarc
>>
>> The ideal would be for one to be able to make an executable from those 
>> parts which would install the Julia version with the specified packages, 
>> build the packages (and maybe modify some environment variables / 
>> defaults), and add a .juliarc that would automatically import some packages 
>> / maybe define some constants or checkout branches. JuliaLang could then 
>> provide a lean distribution and a "standard distribution" where the 
>> standard distribution is a more curated library which people can fight 
>> about, but it's not as big of a deal if anyone can make their own. This has 
>> many upsides:
>>
>>
>>1. Julia wouldn't have to come with what you don't want.
>>2. Other than some edge cases where the advantages of Base come into 
>>play (I don't know of a good example, but I 

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

[ggggg]

One could imagine a metapackage where 

using StandardLibrary

imports all the goodies (as Gabriel put it), and that wouldn't be too 
painful. Would it be possible to have it the other way around though, where 
all the goodies are imported unless you do something else like

exclude StandardLibrary

or 

julia --barebones

That way the extra work falls to the presumably more experienced users who 
want more control, rather than the potential ex-MATLAB user who just wants 
to take an fft. Of course this only makes sense for the StandardLibrary, 
not for a world with many distributions.

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

[Mosè Giordano]

Hi Chris,

what would be the difference between a distribution and a meta-package like 
those used, for example, in Debian and derivatives: a package without code, 
that only requires other packages?  In this sense you can create right now 
a meta-package: just create a repository for a Julia package and populate 
the REQUIRE file as you wish.  You can specify a Julia version and provide 
a build script.

I'm above all worried about the interplay between different distributions.  
There would be clashing .juliarc's?  Why providing a .juliarc at all?  
Automatically running at startup some "using"s & co. is definitely useful, 
but can lead in the long run to bad habits, like forgetting to put "using" 
commands in code shared with people not using the same distribution.

Bye,
Mosè

I think one major point of contention when talking about what should be 
> included in Base due to competing factors:
>
>
>1. Some people would like a "lean Base" for things like embedded 
>installs or other low memory applications
>2. Some people want a MATLAB-like "bells and whistles" approach. This 
>way all the functions they use are just there: no extra packages to 
>find/import.
>3. Some people like having things in Base because it "standardizes" 
>things. 
>4. Putting things in Base constrains their release schedule. 
>5. Putting things in packages outside of JuliaLang helps free up 
>Travis.
>
>
> The last two concerns have been why things like JuliaMath have sprung up 
> to move things out of Base. However, I think there is some credibility to 
> having some form of standardization. I think this can be achieved through 
> some kind of standard library. This would entail a set of packages which 
> are installed when Julia is installed, and a set of packages which add 
> their using statement to the .juliarc. To most users this would be 
> seamless: they would install automatically, and every time you open Julia, 
> they would import automatically. There are a few issues there:
>
>
>1.  This wouldn't work with building from source. This idea works 
>better for binaries (this is no biggie since these users are likely more 
>experienced anyways)
>2. Julia would have to pick winners and losers.
>
> That second part is big: what goes into the standard library? Would all of 
> the MATLAB functions like linspace, find, etc. go there? Would the sparse 
> matrix library be included?
>
> I think one way to circumvent the second issue would be to allow for Julia 
> Distributions. A distribution would be defined by:
>
>
>1. A Julia version
>2. A List of packages to install (with versions?)
>3. A build script
>4. A .juliarc
>
> The ideal would be for one to be able to make an executable from those 
> parts which would install the Julia version with the specified packages, 
> build the packages (and maybe modify some environment variables / 
> defaults), and add a .juliarc that would automatically import some packages 
> / maybe define some constants or checkout branches. JuliaLang could then 
> provide a lean distribution and a "standard distribution" where the 
> standard distribution is a more curated library which people can fight 
> about, but it's not as big of a deal if anyone can make their own. This has 
> many upsides:
>
>
>1. Julia wouldn't have to come with what you don't want.
>2. Other than some edge cases where the advantages of Base come into 
>play (I don't know of a good example, but I know there are some things 
>which can't be defined outside of Base really well, like BigFloats? I'm 
> not 
>the expert on this.), most things could spawn out to packages without the 
>standard user ever noticing.
>3. There would still be a large set of standard functions you can 
>assume most people will have.
>4. You can share Julia setups: for example, with my lab I would share 
>a distribution that would have all of the JuliaDiffEq packages installed, 
>along with Plots.jl and some backends, so that way it would be "in the box 
>solve differential equations and plot" setup like what MATLAB provides. I 
>could pick packages/versions that I know work well together, 
>and guarantee their install will work. 
>5. You could write tutorials / run workshops which use a distribution, 
>knowing that a given set of packages will be available.
>6. Anyone could make their setup match yours by looking at the 
>distribution setup scripts (maybe just make a base function which runs 
> that 
>install since it would all be in Julia). This would be nice for some work 
>in progress projects which require checking out master on 3 different 
>packages, and getting some weird branch for another 5. I would give you a 
>succinct and standardized way to specify an install to get there.
>
>
> Side notes:
>
> [An interesting distribution would be that JuliaGPU could provide a full 
> distribution for 

Re: [julia-users] ls()?

[Tony Kelman]

Julia supports Windows, which is not a posix platform. So while Julia uses 
posix-inspired names in some places, that's not universally the case, and 
they're often jargony and confusing if you're not a Unix user.


On Wednesday, September 14, 2016 at 1:30:25 PM UTC-7, Evan Fields wrote:
>
> Which can get gnarly on Windows, depending how you launched Julia. E.g. 
> just launching from the Julia executable:
>
>
> shell> ls
> ERROR: could not spawn `ls`: no such file or directory (ENOENT)
>  in _jl_spawn(::String, ::Array{String,1}, ::Ptr{Void}, ::Base.Process, 
> ::RawFD, ::RawFD, ::RawFD) at .\process.jl:321
>  in #414 at .\process.jl:478 [inlined]
>  in setup_stdio(::Base.##414#415{Cmd,Ptr{Void},Base.Process}, 
> ::Tuple{RawFD,RawFD,RawFD}) at .\process.jl:466
>  in #spawn#413(::Nullable{Base.ProcessChain}, ::Function, ::Cmd, 
> ::Tuple{RawFD,RawFD,RawFD}, ::Bool, ::Bool) at .\process.jl:477
>  in run(::Cmd) at .\process.jl:591
>  in repl_cmd(::Cmd, ::Base.Terminals.TTYTerminal) at .\client.jl:91
>
> julia>
>
> (It works fine if launched from Git bash)
>

Re: [julia-users] Advice on (perhaps) chunking to HDF5

[Anandaroop Ray]

Works beautifully, thanks.

On 14 September 2016 at 12:21, Erik Schnetter  wrote:

> On Tue, Sep 13, 2016 at 9:36 PM, Anandaroop Ray 
> wrote:
>
>> Cool! The colons approach makes sense to me, followed by splatting.
>>
>> I'm unfamiliar with the syntax here but when I try to create a tuple in
>> the REPL using
>>
>> inds = ((:) for i in 1:3)
>>
>> I get
>> ERROR: syntax: missing separator in tuple
>>
>
> That's a feature that will be available in Julia 0.5. You can instead write
>
> inds = [(:) for i in 1:3]
>
> which defines an array instead of a generator. (The "fill" syntax
> mentioned below works as well, and is even shorter.)
>
> -erik
>
> --
> Erik Schnetter  http://www.perimeterinstitute.
> ca/personal/eschnetter/
>

Re: [julia-users] ls()?

[Evan Fields]

Which can get gnarly on Windows, depending how you launched Julia. E.g. 
just launching from the Julia executable:


shell> ls
ERROR: could not spawn `ls`: no such file or directory (ENOENT)
 in _jl_spawn(::String, ::Array{String,1}, ::Ptr{Void}, ::Base.Process, 
::RawFD, ::RawFD, ::RawFD) at .\process.jl:321
 in #414 at .\process.jl:478 [inlined]
 in setup_stdio(::Base.##414#415{Cmd,Ptr{Void},Base.Process}, 
::Tuple{RawFD,RawFD,RawFD}) at .\process.jl:466
 in #spawn#413(::Nullable{Base.ProcessChain}, ::Function, ::Cmd, 
::Tuple{RawFD,RawFD,RawFD}, ::Bool, ::Bool) at .\process.jl:477
 in run(::Cmd) at .\process.jl:591
 in repl_cmd(::Cmd, ::Base.Terminals.TTYTerminal) at .\client.jl:91

julia>

(It works fine if launched from Git bash)

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

[Tony Kelman]

Which configure file was this from? Julia doesn't need the .lib files, it 
needs the dll, and I assure you there are dlls in MKL. However some of the 
dependencies may need the .lib files, and/or you can try copying them to a 
.dll.a file name if that helps libtool or configure work better.

On Wednesday, September 14, 2016 at 12:28:16 PM UTC-7, Zhong Pan wrote:
>
> BTW I did try Tony's idea of adding "lib" as prefix to each .lib filename. 
> That didn't solve the problem.
>
> On Wednesday, September 14, 2016 at 2:07:14 PM UTC-5, Zhong Pan wrote:
>>
>> Just to report my progress and ask for help again if anybody succeeded in 
>> building Julia 0.4 or 0.5 on Windows with MKL.
>>
>> I backed off a little and tried building release-0.5 on Windows following 
>> the standard instructions below. That is, without any MKL related 
>> configurations.
>> https://github.com/JuliaLang/julia/blob/master/README.windows.md 
>> 
>> But the build failed with Error 2 (some dependency failed to build). 
>>
>> Since my main focus is to get MKL to work rather than trying out 0.5, I 
>> tried building release-0.4 first following the same instructions (no MKL). 
>> And that was a success!
>> Encouraged, I added the following lines to Make.user and copied the 17 
>> .lib files from the MKL library to julia/usr/bin and julia/usr/lib and 
>> C:\mkllib
>> USE_INTEL_MKL = 1
>> USE_INTEL_MKL_FFT = 1
>> USE_INTEL_LIBM = 1
>>
>> I also did this, though I know it probably won't matter:
>> export MKLLIB=/c/mkllib
>>
>> "make -j 4" failed with the expected error:
>>
>> ...
>> configure: error: Cannot find BLAS libraries
>> ...
>> make: *** [Makefile:51: julia-deps] Error 2
>>
>> I know CMake probably won't be able to figure out Windows style libraries 
>> by itself, but I don't know how to make this work. Could anyone help? 
>>
>> P.S. the 17 MKL .lib files are listed below:
>>
>> mkl_blas95_ilp64.lib
>> mkl_blas95_lp64.lib
>> mkl_core.lib
>> mkl_core_dll.lib
>> mkl_intel_ilp64.lib
>> mkl_intel_ilp64_dll.lib
>> mkl_intel_lp64.lib
>> mkl_intel_lp64_dll.lib
>> mkl_intel_thread.lib
>> mkl_intel_thread_dll.lib
>> mkl_lapack95_ilp64.lib
>> mkl_lapack95_lp64.lib
>> mkl_rt.lib
>> mkl_sequential.lib
>> mkl_sequential_dll.lib
>> mkl_tbb_thread.lib
>> mkl_tbb_thread_dll.lib
>>
>>
>>
>>
>>
>>

[julia-users] Re: dependent types in julia?

[Evan Fields]

I'm not sure then, but hopefully someone here can help you out! Naively 
perhaps it feels like this makes the type inference impossible. Your 
function decomplexify always produces the same output for the same input, 
but what if you had a function that returned a different output (always of 
type DataType) based on a random number generated inside the function? Then 
using that function to annotate field types would be super hairy, right?

[julia-users] Re: dependent types in julia?

[Neal Becker]

Evan Fields wrote:

> How about something like the following?
> 
> type CT{T}
> ctsum::Complex{T}
> ctsumsq::T
> end
> 

I'm aware that it's easier to make the type parameter the scalar type, 
allowing writing as you show, but as a learning exercise I'd like to know 
how Julia would go the other way.

In c++ this would be done with template metaprogramming, but as Julia claims 
to have types as 1st class objects, I thought there should be some elegant 
way to do this.

That is, given T is Complex{U}, I need the type U so I can write
ctsumsq::U

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

[Zhong Pan]

BTW I did try Tony's idea of adding "lib" as prefix to each .lib filename. 
That didn't solve the problem.

On Wednesday, September 14, 2016 at 2:07:14 PM UTC-5, Zhong Pan wrote:
>
> Just to report my progress and ask for help again if anybody succeeded in 
> building Julia 0.4 or 0.5 on Windows with MKL.
>
> I backed off a little and tried building release-0.5 on Windows following 
> the standard instructions below. That is, without any MKL related 
> configurations.
> https://github.com/JuliaLang/julia/blob/master/README.windows.md 
> 
> But the build failed with Error 2 (some dependency failed to build). 
>
> Since my main focus is to get MKL to work rather than trying out 0.5, I 
> tried building release-0.4 first following the same instructions (no MKL). 
> And that was a success!
> Encouraged, I added the following lines to Make.user and copied the 17 
> .lib files from the MKL library to julia/usr/bin and julia/usr/lib and 
> C:\mkllib
> USE_INTEL_MKL = 1
> USE_INTEL_MKL_FFT = 1
> USE_INTEL_LIBM = 1
>
> I also did this, though I know it probably won't matter:
> export MKLLIB=/c/mkllib
>
> "make -j 4" failed with the expected error:
>
> ...
> configure: error: Cannot find BLAS libraries
> ...
> make: *** [Makefile:51: julia-deps] Error 2
>
> I know CMake probably won't be able to figure out Windows style libraries 
> by itself, but I don't know how to make this work. Could anyone help? 
>
> P.S. the 17 MKL .lib files are listed below:
>
> mkl_blas95_ilp64.lib
> mkl_blas95_lp64.lib
> mkl_core.lib
> mkl_core_dll.lib
> mkl_intel_ilp64.lib
> mkl_intel_ilp64_dll.lib
> mkl_intel_lp64.lib
> mkl_intel_lp64_dll.lib
> mkl_intel_thread.lib
> mkl_intel_thread_dll.lib
> mkl_lapack95_ilp64.lib
> mkl_lapack95_lp64.lib
> mkl_rt.lib
> mkl_sequential.lib
> mkl_sequential_dll.lib
> mkl_tbb_thread.lib
> mkl_tbb_thread_dll.lib
>
>
>
>
>
>

[julia-users] Re: dependent types in julia?

[Evan Fields]

How about something like the following?

type CT{T}
ctsum::Complex{T}
ctsumsq::T
end

x = 1 + 2im

ctx = CT(x, convert(decomplexify(typeof(x)), x * conj(x))

You could also make a convenience function so you don't have to do the 
converts yourself for the second argument.
Have you seen the standard docs on parametric 
types? 
http://docs.julialang.org/en/release-0.5/manual/types/#man-parametric-types

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

[Zhong Pan]

Just to report my progress and ask for help again if anybody succeeded in 
building Julia 0.4 or 0.5 on Windows with MKL.

I backed off a little and tried building release-0.5 on Windows following 
the standard instructions below. That is, without any MKL related 
configurations.
https://github.com/JuliaLang/julia/blob/master/README.windows.md 

But the build failed with Error 2 (some dependency failed to build). 

Since my main focus is to get MKL to work rather than trying out 0.5, I 
tried building release-0.4 first following the same instructions (no MKL). 
And that was a success!
Encouraged, I added the following lines to Make.user and copied the 17 .lib 
files from the MKL library to julia/usr/bin and julia/usr/lib and C:\mkllib
USE_INTEL_MKL = 1
USE_INTEL_MKL_FFT = 1
USE_INTEL_LIBM = 1

I also did this, though I know it probably won't matter:
export MKLLIB=/c/mkllib

"make -j 4" failed with the expected error:

...
configure: error: Cannot find BLAS libraries
...
make: *** [Makefile:51: julia-deps] Error 2

I know CMake probably won't be able to figure out Windows style libraries 
by itself, but I don't know how to make this work. Could anyone help? 

P.S. the 17 MKL .lib files are listed below:

mkl_blas95_ilp64.lib
mkl_blas95_lp64.lib
mkl_core.lib
mkl_core_dll.lib
mkl_intel_ilp64.lib
mkl_intel_ilp64_dll.lib
mkl_intel_lp64.lib
mkl_intel_lp64_dll.lib
mkl_intel_thread.lib
mkl_intel_thread_dll.lib
mkl_lapack95_ilp64.lib
mkl_lapack95_lp64.lib
mkl_rt.lib
mkl_sequential.lib
mkl_sequential_dll.lib
mkl_tbb_thread.lib
mkl_tbb_thread_dll.lib

[julia-users] dependent types in julia?

[Neal Becker]

As a toy example, I'm trying to write something that computes 2nd order 
statistics of complex variables.

give a type T :: Complex{FLT}, I need to get the scalar type associated with 
it.  For example, Complex{Float64} -> Float64

The decomplexify metafunction seems to do it:

decomplexify{T}(::Type{Complex{T}}) = T

julia> decomplexify(Complex{Float64})
Float64

But I don't know how to get this to work:

type var{T}
sum::T
sumsqr::Type{decomplexify{T}}
end

It's trying to say that sum has type e.g., Complex{Float64}, while
sumsqr has type Float64 (here, T would have type Complex{Float64})

Any documents I can read to help?

[julia-users] Re: Pkg.add() works fine while Pkg.update() doesn't over https instead of git

[Tony Kelman]

Better to go into METADATA and check with git status exactly what happened 
before completely deleting it. Otherwise we'll never know what happened. At 
least move it to a different name so it's not gone.


On Wednesday, September 14, 2016 at 10:07:43 AM UTC-7, Chris Rackauckas 
wrote:
>
> +1000 for the REQUIRE hack. Never knew about that. Be careful to save the 
> packages you've been working on (or just commit and push somewhere) if you 
> do this though.
>
> On Wednesday, September 14, 2016 at 10:02:22 AM UTC-7, David P. Sanders 
> wrote:
>>
>>
>> I am a fan of deleting the entire .julia directory in your home directory 
>> and reinstalling your packages.
>>
>> You can also just keep the REQUIRE file from .julia/v0.4 somewhere, do 
>> Pkg.init(), then copy the REQUIRE file back and do
>> Pkg.resolve()  to reinstall everything you previously had installed.
>>
>> El martes, 13 de septiembre de 2016, 10:54:43 (UTC-4), Rahul Mourya 
>> escribió:
>>>
>>> Hi,
>>> I'm using Julia-0.4.6. My machine is behind a firewall, thus configured 
>>> git to use https: git config --global url."https://".insteadOf git://.
>>> Under this setting, I'm able to install packages using Pkg.add(), 
>>> however, when I use Pkg.update(), I get following error:
>>>
>>> INFO: Updating METADATA...
>>> Cannot pull with rebase: You have unstaged changes.
>>> Please commit or stash them.
>>> ERROR: failed process: Process(`git pull --rebase -q`, ProcessExited(1)) 
>>> [1]
>>>  in pipeline_error at process.jl:555
>>>  in run at process.jl:531
>>>  in anonymous at pkg/entry.jl:283
>>>  in withenv at env.jl:160
>>>  in anonymous at pkg/entry.jl:282
>>>  in cd at ./file.jl:22
>>>  in update at ./pkg/entry.jl:272
>>>  in anonymous at pkg/dir.jl:31
>>>  in cd at file.jl:22
>>>  in cd at pkg/dir.jl:31
>>>  in update at ./pkg.jl:45
>>>
>>> what could be the reason? Any workaround this?
>>>
>>> Thanks!
>>>
>>

[julia-users] Re: [ANN]New package RFlavor.jl provides R-like functions

[Lanfeng Pan]

Glad to see a similar effort! I agree the name is not very descriptive. I 
didn't even find it in google.
Right now we are not sure about the ultimate goal yet. 
One of our plan is implementing R fundamental functions so that we can 
easily translate an R package (such as those plotting packages) to Julia.
Right now we are considering implementing a similar S3 methods with the 
`list` type.
 


On Wednesday, September 14, 2016 at 11:39:59 AM UTC-5, Chris Rackauckas 
wrote:
>
> We may want to combine efforts. I have VectorizedRoutines.jl 
>  for this with 
> a slightly larger scope (I don't know if it's the right name though).
>
> On Wednesday, September 14, 2016 at 8:12:21 AM UTC-7, Lanfeng Pan wrote:
>>
>> Hi all,
>>
>> To help R users get used to Julia soon, this package provide some handy 
>> functions from R in Julia, such as 
>>
>> list
>> matrix
>> rep, seq
>> table
>> expand_grid, outer
>> sweep
>> duplicated
>> findinterval
>> ...
>>
>> More to come and all contributions and comments are welcome.
>> The package address is https://github.com/panlanfeng/RFlavor.jl
>> See our work list at https://github.com/panlanfeng/RFlavor.jl/issues/2
>>
>>
>> Best,
>> Lanfeng
>>
>

Re: [julia-users] Advice on (perhaps) chunking to HDF5

[Erik Schnetter]

On Tue, Sep 13, 2016 at 9:36 PM, Anandaroop Ray 
wrote:

> Cool! The colons approach makes sense to me, followed by splatting.
>
> I'm unfamiliar with the syntax here but when I try to create a tuple in
> the REPL using
>
> inds = ((:) for i in 1:3)
>
> I get
> ERROR: syntax: missing separator in tuple
>

That's a feature that will be available in Julia 0.5. You can instead write

inds = [(:) for i in 1:3]

which defines an array instead of a generator. (The "fill" syntax mentioned
below works as well, and is even shorter.)

-erik

-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

[julia-users] Re: Pkg.add() works fine while Pkg.update() doesn't over https instead of git

[Chris Rackauckas]

+1000 for the REQUIRE hack. Never knew about that. Be careful to save the 
packages you've been working on (or just commit and push somewhere) if you 
do this though.

On Wednesday, September 14, 2016 at 10:02:22 AM UTC-7, David P. Sanders 
wrote:
>
>
> I am a fan of deleting the entire .julia directory in your home directory 
> and reinstalling your packages.
>
> You can also just keep the REQUIRE file from .julia/v0.4 somewhere, do 
> Pkg.init(), then copy the REQUIRE file back and do
> Pkg.resolve()  to reinstall everything you previously had installed.
>
> El martes, 13 de septiembre de 2016, 10:54:43 (UTC-4), Rahul Mourya 
> escribió:
>>
>> Hi,
>> I'm using Julia-0.4.6. My machine is behind a firewall, thus configured 
>> git to use https: git config --global url."https://".insteadOf git://.
>> Under this setting, I'm able to install packages using Pkg.add(), 
>> however, when I use Pkg.update(), I get following error:
>>
>> INFO: Updating METADATA...
>> Cannot pull with rebase: You have unstaged changes.
>> Please commit or stash them.
>> ERROR: failed process: Process(`git pull --rebase -q`, ProcessExited(1)) 
>> [1]
>>  in pipeline_error at process.jl:555
>>  in run at process.jl:531
>>  in anonymous at pkg/entry.jl:283
>>  in withenv at env.jl:160
>>  in anonymous at pkg/entry.jl:282
>>  in cd at ./file.jl:22
>>  in update at ./pkg/entry.jl:272
>>  in anonymous at pkg/dir.jl:31
>>  in cd at file.jl:22
>>  in cd at pkg/dir.jl:31
>>  in update at ./pkg.jl:45
>>
>> what could be the reason? Any workaround this?
>>
>> Thanks!
>>
>

Re: [julia-users] Re: Curious parsing behavior

[Chris Rackauckas]

Some are unavoidable: [1 -2] vs [1 - 2] (though I think there should be a 
row-concatenation operator, like ; does column-concatenation. That would 
stop this problem).



On Wednesday, September 14, 2016 at 10:01:07 AM UTC-7, Erik Schnetter wrote:
>
> There was a talk at JuliaCon suggesting that parsing ambiguities are often 
> best resolved by throwing an error: "Fortress: Features and Lessons 
> Learned".
>
> -erik
>
> On Wed, Sep 14, 2016 at 12:01 PM, David P. Sanders  > wrote:
>
>>
>>
>> El miércoles, 14 de septiembre de 2016, 11:12:52 (UTC-4), David Gleich 
>> escribió:
>>>
>>> Ahah! That explains it.
>>>
>>> Is there a better way to create floating point literals that avoid this?
>>>
>>
>> I think using 1782.0 instead of 1782. (without the 0) will solve this?
>> I seem to remember there was an issue to deprecate the style without the 
>> 0.
>>  
>>
>>>
>>> David
>>>
>>> On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson 
>>> wrote:



 On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich 
 wrote:
>
> Can anyone give me a quick explanation for why these statements seem 
> to parse differently?
>
> julia> 1782.^12. + 1841.^12.
>

 .^ and .+ are (elementwise/broadcasting) operators in Julia, and there 
 is a parsing ambiguity here because it is not clear whether the . goes 
 with 
 the operator or the number.

 See also the discussion at

  https://github.com/JuliaLang/julia/issues/15731
  https://github.com/JuliaLang/julia/pull/11529

 for possible ways that this might be made less surprising in the future.

>>>
>
>
> -- 
> Erik Schnetter  
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

Re: [julia-users] Re: Curious parsing behavior

[Stefan Karpinski]

It's a really appealing idea.

On Wed, Sep 14, 2016 at 1:01 PM, Erik Schnetter  wrote:

> There was a talk at JuliaCon suggesting that parsing ambiguities are often
> best resolved by throwing an error: "Fortress: Features and Lessons
> Learned".
>
> -erik
>
> On Wed, Sep 14, 2016 at 12:01 PM, David P. Sanders 
> wrote:
>
>>
>>
>> El miércoles, 14 de septiembre de 2016, 11:12:52 (UTC-4), David Gleich
>> escribió:
>>>
>>> Ahah! That explains it.
>>>
>>> Is there a better way to create floating point literals that avoid this?
>>>
>>
>> I think using 1782.0 instead of 1782. (without the 0) will solve this?
>> I seem to remember there was an issue to deprecate the style without the
>> 0.
>>
>>
>>>
>>> David
>>>
>>> On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson
>>> wrote:



 On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich
 wrote:
>
> Can anyone give me a quick explanation for why these statements seem
> to parse differently?
>
> julia> 1782.^12. + 1841.^12.
>

 .^ and .+ are (elementwise/broadcasting) operators in Julia, and there
 is a parsing ambiguity here because it is not clear whether the . goes with
 the operator or the number.

 See also the discussion at

  https://github.com/JuliaLang/julia/issues/15731
  https://github.com/JuliaLang/julia/pull/11529

 for possible ways that this might be made less surprising in the future.

>>>
>
>
> --
> Erik Schnetter  http://www.perimeterinstitute.
> ca/personal/eschnetter/
>

[julia-users] Re: electron framework / javascript / LLVM / Julia numerics?

[Páll Haraldsson]

"would it be possible to somehow create numeric libraries /  code in Julia, 
and "export" (emscripten?)  asm.js "pure" javascript numerical code"

Yes, in theory, but someone would have to do it/finish (I recall some small 
demo). As Emscripten "is an LLVM 
-to-JavaScript 
compiler. It takes LLVM bitcode - which can be generated from C/C++". 
There's an issue on Github on it, that was stalled, last I checked.

However, some dependencies, e.g. BLAS, are in Fortran and assembly (that 
Emscripten doesn't support), so the unofficial Julia-lite branch (without 
those) should be doable.

JavaScript would also not support Threads (only experimental in 0.5 anyway) 
etc.

I guess you where really after BLAS, linear algebra etc. and then 
WebAssembly would be a better target than asm.js. Or you could reimplement, 
what of BLAS etc. you need.. in pure Julia..

-- 
Palli.

On Tuesday, September 13, 2016 at 5:25:46 PM UTC, Perrin Meyer wrote:
>
> The github "electron" cross platform app framework looks pretty slick upon 
> first inspection (chrome / v8 / node.js /  javascript, llvm)  
>
> However, last time I checked, the javascript numerical libraries i've 
> looked at are alpha quality at best.  
>
> Since julia is also LLVM based, would it be possible to somehow create 
> numeric libraries /  code in Julia, and "export" (emscripten?)  asm.js 
> "pure" javascript numerical code that could be "linked" to code in the 
> electron framework, since that would be a possibly easy way to create cross 
> platform apps (linux, mac, windows, android) with high quality numerics?  I 
> would be more interested in correctness than raw speed, although I've been 
> impressed by V8 / asm.js benchmarks I've seen. 
>
> Thanks
>
> perrin
>
>

[julia-users] Re: Pkg.add() works fine while Pkg.update() doesn't over https instead of git

[David P. Sanders]

I am a fan of deleting the entire .julia directory in your home directory 
and reinstalling your packages.

You can also just keep the REQUIRE file from .julia/v0.4 somewhere, do 
Pkg.init(), then copy the REQUIRE file back and do
Pkg.resolve()  to reinstall everything you previously had installed.

El martes, 13 de septiembre de 2016, 10:54:43 (UTC-4), Rahul Mourya 
escribió:
>
> Hi,
> I'm using Julia-0.4.6. My machine is behind a firewall, thus configured 
> git to use https: git config --global url."https://".insteadOf git://.
> Under this setting, I'm able to install packages using Pkg.add(), however, 
> when I use Pkg.update(), I get following error:
>
> INFO: Updating METADATA...
> Cannot pull with rebase: You have unstaged changes.
> Please commit or stash them.
> ERROR: failed process: Process(`git pull --rebase -q`, ProcessExited(1)) 
> [1]
>  in pipeline_error at process.jl:555
>  in run at process.jl:531
>  in anonymous at pkg/entry.jl:283
>  in withenv at env.jl:160
>  in anonymous at pkg/entry.jl:282
>  in cd at ./file.jl:22
>  in update at ./pkg/entry.jl:272
>  in anonymous at pkg/dir.jl:31
>  in cd at file.jl:22
>  in cd at pkg/dir.jl:31
>  in update at ./pkg.jl:45
>
> what could be the reason? Any workaround this?
>
> Thanks!
>

Re: [julia-users] Re: Curious parsing behavior

[Erik Schnetter]

There was a talk at JuliaCon suggesting that parsing ambiguities are often
best resolved by throwing an error: "Fortress: Features and Lessons
Learned".

-erik

On Wed, Sep 14, 2016 at 12:01 PM, David P. Sanders 
wrote:

>
>
> El miércoles, 14 de septiembre de 2016, 11:12:52 (UTC-4), David Gleich
> escribió:
>>
>> Ahah! That explains it.
>>
>> Is there a better way to create floating point literals that avoid this?
>>
>
> I think using 1782.0 instead of 1782. (without the 0) will solve this?
> I seem to remember there was an issue to deprecate the style without the 0.
>
>
>>
>> David
>>
>> On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich wrote:

 Can anyone give me a quick explanation for why these statements seem to
 parse differently?

 julia> 1782.^12. + 1841.^12.

>>>
>>> .^ and .+ are (elementwise/broadcasting) operators in Julia, and there
>>> is a parsing ambiguity here because it is not clear whether the . goes with
>>> the operator or the number.
>>>
>>> See also the discussion at
>>>
>>>  https://github.com/JuliaLang/julia/issues/15731
>>>  https://github.com/JuliaLang/julia/pull/11529
>>>
>>> for possible ways that this might be made less surprising in the future.
>>>
>>


-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] ls()?

[Stefan Karpinski]

There's already shell mode:

;cd projects
;ls


in the REPL.

On Wed, Sep 14, 2016 at 12:56 PM,  wrote:

> > There are POSIX standards for new programming language function names?
>
> No, but you've implemented functions with POSIX names
>
> > yes, ls() could be a better name
>
> In the REPL, I might
>
> julia> cd("projects")
>
> And want to
>
> julia> ls()
>
> to see what's there
>
> But, I probably wouldn't want to do that in Julia file
>
> rd = readdir(pwd())  # ls() doesn't make sense here
>
> So, maybe alias them?
>
> Aidy
>
> On 9/14/2016 at 5:41 PM, "Stefan Karpinski"  wrote:
> >
> >There are POSIX standards for new programming language function
> >names? But
> >yes, ls() could be a better name.
> >
> >On Wed, Sep 14, 2016 at 12:04 PM, Adrian Lewis
> >
> >wrote:
> >
> >> > You can find a thread/issue where this is discussed. Some
> >group decided
> >> to call it readdir() and like it more. I just got used to it. I
> >think it's
> >> silly, but it's just syntax.
> >>
> >> I thought it might be an idea to stick with POSIX standards.
> >>
> >> On Wednesday, September 14, 2016 at 4:40:03 PM UTC+1, Chris
> >Rackauckas
> >> wrote:
> >>>
> >>>
> >>>
> >>> On Wednesday, September 14, 2016 at 7:36:18 AM UTC-7, Jacob
> >Quinn wrote:
> 
>  readdir()
> 
>  On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis
> >
>  wrote:
> 
> > In the filesystem package, if we have pwd() and cd(), why do
> >we not
> > have ls()?
> >
> > Aidy
> >
> 
> 
>
>

[julia-users] Re: Pkg.add() works fine while Pkg.update() doesn't over https instead of git

[Chris Rackauckas]

If git stash doesn't work, you can always go nuclear and delete your 
METADATA folder, along with META_BRANCH and REQUIRE. Then when you 
Pkg.update() it will install a new METADATA and basically try again, but I 
think this will delete all of your installed packages so it really is a 
heavy-handed fix. Maybe Tony has a more refined solution.

On Wednesday, September 14, 2016 at 2:04:05 AM UTC-7, Rahul Mourya wrote:
>
> Well I didn't make any intentional change my own. I guess it's the Pkg 
> manager, which was not successful ! I did git stash, however it didn't 
> solve the problem, I'm still getting same error msg when using Pkg.update() 
> .
>
> On Tuesday, 13 September 2016 16:54:43 UTC+2, Rahul Mourya wrote:
>>
>> Hi,
>> I'm using Julia-0.4.6. My machine is behind a firewall, thus configured 
>> git to use https: git config --global url."https://".insteadOf git://.
>> Under this setting, I'm able to install packages using Pkg.add(), 
>> however, when I use Pkg.update(), I get following error:
>>
>> INFO: Updating METADATA...
>> Cannot pull with rebase: You have unstaged changes.
>> Please commit or stash them.
>> ERROR: failed process: Process(`git pull --rebase -q`, ProcessExited(1)) 
>> [1]
>>  in pipeline_error at process.jl:555
>>  in run at process.jl:531
>>  in anonymous at pkg/entry.jl:283
>>  in withenv at env.jl:160
>>  in anonymous at pkg/entry.jl:282
>>  in cd at ./file.jl:22
>>  in update at ./pkg/entry.jl:272
>>  in anonymous at pkg/dir.jl:31
>>  in cd at file.jl:22
>>  in cd at pkg/dir.jl:31
>>  in update at ./pkg.jl:45
>>
>> what could be the reason? Any workaround this?
>>
>> Thanks!
>>
>

Re: [julia-users] ls()?

[adrian_lewis]

> There are POSIX standards for new programming language function names?

No, but you've implemented functions with POSIX names

> yes, ls() could be a better name

In the REPL, I might

julia> cd("projects")

And want to 

julia> ls()

to see what's there

But, I probably wouldn't want to do that in Julia file

rd = readdir(pwd())  # ls() doesn't make sense here

So, maybe alias them?

Aidy

On 9/14/2016 at 5:41 PM, "Stefan Karpinski"  wrote:
>
>There are POSIX standards for new programming language function 
>names? But
>yes, ls() could be a better name.
>
>On Wed, Sep 14, 2016 at 12:04 PM, Adrian Lewis 
>
>wrote:
>
>> > You can find a thread/issue where this is discussed. Some 
>group decided
>> to call it readdir() and like it more. I just got used to it. I 
>think it's
>> silly, but it's just syntax.
>>
>> I thought it might be an idea to stick with POSIX standards.
>>
>> On Wednesday, September 14, 2016 at 4:40:03 PM UTC+1, Chris 
>Rackauckas
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, September 14, 2016 at 7:36:18 AM UTC-7, Jacob 
>Quinn wrote:

 readdir()

 On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis 
>
 wrote:

> In the filesystem package, if we have pwd() and cd(), why do 
>we not
> have ls()?
>
> Aidy
>

Re: [julia-users] ls()?

[Keno Fischer]

readdir is POSIX: http://man7.org/linux/man-pages/man3/readdir.3.html

On Wed, Sep 14, 2016 at 12:45 PM, Chris Rackauckas 
wrote:

> Here it is: https://github.com/JuliaLang/julia/issues/3376. Would
> changing to ls be back on the table?
>
> On Wednesday, September 14, 2016 at 9:41:55 AM UTC-7, Stefan Karpinski
> wrote:
>>
>> There are POSIX standards for new programming language function names?
>> But yes, ls() could be a better name.
>>
>> On Wed, Sep 14, 2016 at 12:04 PM, Adrian Lewis 
>> wrote:
>>
>>> > You can find a thread/issue where this is discussed. Some group
>>> decided to call it readdir() and like it more. I just got used to it. I
>>> think it's silly, but it's just syntax.
>>>
>>> I thought it might be an idea to stick with POSIX standards.
>>>
>>> On Wednesday, September 14, 2016 at 4:40:03 PM UTC+1, Chris Rackauckas
>>> wrote:



 On Wednesday, September 14, 2016 at 7:36:18 AM UTC-7, Jacob Quinn wrote:
>
> readdir()
>
> On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis 
> wrote:
>
>> In the filesystem package, if we have pwd() and cd(), why do we not
>> have ls()?
>>
>> Aidy
>>
>
>
>>

Re: [julia-users] ls()?

[Chris Rackauckas]

Here it is: https://github.com/JuliaLang/julia/issues/3376. Would changing 
to ls be back on the table?

On Wednesday, September 14, 2016 at 9:41:55 AM UTC-7, Stefan Karpinski 
wrote:
>
> There are POSIX standards for new programming language function names? But 
> yes, ls() could be a better name.
>
> On Wed, Sep 14, 2016 at 12:04 PM, Adrian Lewis  > wrote:
>
>> > You can find a thread/issue where this is discussed. Some group decided 
>> to call it readdir() and like it more. I just got used to it. I think it's 
>> silly, but it's just syntax.
>>
>> I thought it might be an idea to stick with POSIX standards. 
>>
>> On Wednesday, September 14, 2016 at 4:40:03 PM UTC+1, Chris Rackauckas 
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, September 14, 2016 at 7:36:18 AM UTC-7, Jacob Quinn wrote:

 readdir()

 On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis  
 wrote:

> In the filesystem package, if we have pwd() and cd(), why do we not 
> have ls()?
>
> Aidy
>


>

Re: [julia-users] ls()?

[Stefan Karpinski]

There are POSIX standards for new programming language function names? But
yes, ls() could be a better name.

On Wed, Sep 14, 2016 at 12:04 PM, Adrian Lewis 
wrote:

> > You can find a thread/issue where this is discussed. Some group decided
> to call it readdir() and like it more. I just got used to it. I think it's
> silly, but it's just syntax.
>
> I thought it might be an idea to stick with POSIX standards.
>
> On Wednesday, September 14, 2016 at 4:40:03 PM UTC+1, Chris Rackauckas
> wrote:
>>
>>
>>
>> On Wednesday, September 14, 2016 at 7:36:18 AM UTC-7, Jacob Quinn wrote:
>>>
>>> readdir()
>>>
>>> On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis 
>>> wrote:
>>>
 In the filesystem package, if we have pwd() and cd(), why do we not
 have ls()?

 Aidy

>>>
>>>

[julia-users] Re: [ANN]New package RFlavor.jl provides R-like functions

[Chris Rackauckas]

We may want to combine efforts. I have VectorizedRoutines.jl 
 for this with a 
slightly larger scope (I don't know if it's the right name though).

On Wednesday, September 14, 2016 at 8:12:21 AM UTC-7, Lanfeng Pan wrote:
>
> Hi all,
>
> To help R users get used to Julia soon, this package provide some handy 
> functions from R in Julia, such as 
>
> list
> matrix
> rep, seq
> table
> expand_grid, outer
> sweep
> duplicated
> findinterval
> ...
>
> More to come and all contributions and comments are welcome.
> The package address is https://github.com/panlanfeng/RFlavor.jl
> See our work list at https://github.com/panlanfeng/RFlavor.jl/issues/2
>
>
> Best,
> Lanfeng
>

[julia-users] unexpected mapslice result on 0.5rc3

[Marius Millea]

Is this the expected behavior? 

julia> mapslices(x->tuple(x), [1 2; 3 4], 1)
1×2 Array{Tuple{Array{Int64,1}},2}:
 ([2,4],)  ([2,4],)

julia> mapslices(x->tuple(x...), [1 2; 3 4], 1)
1×2 Array{Tuple{Int64,Int64},2}:
 (1,3)  (2,4)


The first case certainly came as pretty unexpected to me. Does it have 
something to do with copies vs views into the array?

[julia-users] Re: online (streaming) statistics?

[David P. Sanders]

Apparently the problem was using "julialang" instead of just "julia" in the 
search.
julialang will, I guess, mainly pick up things on the Julia language home 
page,
whereas you were looking for an external package.

El miércoles, 14 de septiembre de 2016, 12:12:06 (UTC-4), David P. Sanders 
escribió:
>
>
>
> El miércoles, 14 de septiembre de 2016, 12:02:32 (UTC-4), Neal Becker 
> escribió:
>>
>> David P. Sanders wrote: 
>>
>> > 
>> > 
>> > 
>> > El miércoles, 14 de septiembre de 2016, 11:45:00 (UTC-4), Neal Becker 
>> > escribió: 
>> >> 
>> >> Is there a package for online (streaming) statistics? 
>> >> 
>> > 
>> > Please use Google before posting questions like this. 
>> > Googling "online streaming statistics Julia" gives the answer as the 
>> first 
>> > link. 
>> > 
>>
>> I apologize for the noise, I tried googling "julialang online statistics" 
>> but that produced no useful result (at least on the 1st page) 
>>
>
> OK, fair enough, sorry! 
>

[julia-users] Re: online (streaming) statistics?

[David P. Sanders]

El miércoles, 14 de septiembre de 2016, 12:02:32 (UTC-4), Neal Becker 
escribió:
>
> David P. Sanders wrote: 
>
> > 
> > 
> > 
> > El miércoles, 14 de septiembre de 2016, 11:45:00 (UTC-4), Neal Becker 
> > escribió: 
> >> 
> >> Is there a package for online (streaming) statistics? 
> >> 
> > 
> > Please use Google before posting questions like this. 
> > Googling "online streaming statistics Julia" gives the answer as the 
> first 
> > link. 
> > 
>
> I apologize for the noise, I tried googling "julialang online statistics" 
> but that produced no useful result (at least on the 1st page) 
>

OK, fair enough, sorry! 

Re: [julia-users] ls()?

[Adrian Lewis]

> You can find a thread/issue where this is discussed. Some group decided 
to call it readdir() and like it more. I just got used to it. I think it's 
silly, but it's just syntax.

I thought it might be an idea to stick with POSIX standards. 

On Wednesday, September 14, 2016 at 4:40:03 PM UTC+1, Chris Rackauckas 
wrote:
>
>
>
> On Wednesday, September 14, 2016 at 7:36:18 AM UTC-7, Jacob Quinn wrote:
>>
>> readdir()
>>
>> On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis  
>> wrote:
>>
>>> In the filesystem package, if we have pwd() and cd(), why do we not have 
>>> ls()?
>>>
>>> Aidy
>>>
>>
>>

[julia-users] Re: online (streaming) statistics?

[Neal Becker]

David P. Sanders wrote:

> 
> 
> 
> El miércoles, 14 de septiembre de 2016, 11:45:00 (UTC-4), Neal Becker
> escribió:
>>
>> Is there a package for online (streaming) statistics?
>>
> 
> Please use Google before posting questions like this.
> Googling "online streaming statistics Julia" gives the answer as the first
> link.
> 

I apologize for the noise, I tried googling "julialang online statistics" 
but that produced no useful result (at least on the 1st page)

[julia-users] Re: Curious parsing behavior

[David P. Sanders]

El miércoles, 14 de septiembre de 2016, 11:12:52 (UTC-4), David Gleich 
escribió:
>
> Ahah! That explains it.
>
> Is there a better way to create floating point literals that avoid this?
>

I think using 1782.0 instead of 1782. (without the 0) will solve this?
I seem to remember there was an issue to deprecate the style without the 0.
 

>
> David
>
> On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson 
> wrote:
>>
>>
>>
>> On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich wrote:
>>>
>>> Can anyone give me a quick explanation for why these statements seem to 
>>> parse differently?
>>>
>>> julia> 1782.^12. + 1841.^12.
>>>
>>
>> .^ and .+ are (elementwise/broadcasting) operators in Julia, and there is 
>> a parsing ambiguity here because it is not clear whether the . goes with 
>> the operator or the number.
>>
>> See also the discussion at
>>
>>  https://github.com/JuliaLang/julia/issues/15731
>>  https://github.com/JuliaLang/julia/pull/11529
>>
>> for possible ways that this might be made less surprising in the future.
>>
>

[julia-users] Re: online (streaming) statistics?

[David P. Sanders]

El miércoles, 14 de septiembre de 2016, 11:45:00 (UTC-4), Neal Becker 
escribió:
>
> Is there a package for online (streaming) statistics? 
>

Please use Google before posting questions like this.
Googling "online streaming statistics Julia" gives the answer as the first 
link.



 

>
> This would be an object that could be called repeatedly with new data, and 
> would produce stats on the accumulated results (without actually having to 
> collect all the results at 1 time) 
>
> I have made a package for python which wraps some of 
> http://www.boost.org/doc/libs/1_61_0/doc/html/accumulators.html 
>
> but have no clue how to do this for Julia (hopefully someone else already 
> has) 
>
>

Re: [julia-users] online (streaming) statistics?

[Tom Breloff]

https://github.com/joshday/OnlineStats.jl  (note that StreamStats was
deprecated in favor of this)

On Wed, Sep 14, 2016 at 11:44 AM, Neal Becker  wrote:

> Is there a package for online (streaming) statistics?
>
> This would be an object that could be called repeatedly with new data, and
> would produce stats on the accumulated results (without actually having to
> collect all the results at 1 time)
>
> I have made a package for python which wraps some of
> http://www.boost.org/doc/libs/1_61_0/doc/html/accumulators.html
>
> but have no clue how to do this for Julia (hopefully someone else already
> has)
>
>

Re: [julia-users] online (streaming) statistics?

[Tamas Papp]

See https://github.com/johnmyleswhite/StreamStats.jl

On Wed, Sep 14 2016, Neal Becker wrote:

> Is there a package for online (streaming) statistics?
>
> This would be an object that could be called repeatedly with new data, and
> would produce stats on the accumulated results (without actually having to
> collect all the results at 1 time)
>
> I have made a package for python which wraps some of
> http://www.boost.org/doc/libs/1_61_0/doc/html/accumulators.html
>
> but have no clue how to do this for Julia (hopefully someone else already
> has)

[julia-users] online (streaming) statistics?

[Neal Becker]

Is there a package for online (streaming) statistics?

This would be an object that could be called repeatedly with new data, and 
would produce stats on the accumulated results (without actually having to 
collect all the results at 1 time)

I have made a package for python which wraps some of
http://www.boost.org/doc/libs/1_61_0/doc/html/accumulators.html

but have no clue how to do this for Julia (hopefully someone else already 
has)

Re: [julia-users] ls()?

[Chris Rackauckas]

You can find a thread/issue where this is discussed. Some group decided to 
call it readdir() and like it more. I just got used to it. I think it's 
silly, but it's just syntax.

On Wednesday, September 14, 2016 at 7:36:18 AM UTC-7, Jacob Quinn wrote:
>
> readdir()
>
> On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis  > wrote:
>
>> In the filesystem package, if we have pwd() and cd(), why do we not have 
>> ls()?
>>
>> Aidy
>>
>
>

Re: [julia-users] Re: Telling if code is vectorised.

[Yichao Yu]

On Wed, Sep 14, 2016 at 11:09 AM, Ben Ward  wrote:
>
> Ahah! I completely forgot about warntype! Thanks!
>
> Out of interest, as I've only started to read llvm and native instructions 
> generated by my julia functions, is there a way to tell from the llvm if 
> there's type instability - say one forgets to do a code_warntype, are there 
> llvm instructions that when you see them, you should go "Doh man I need to do 
> @code_warntype as there's something not right here"?
>

Way too many items in the GC frame,

>  %1 = alloca [11 x %jl_value_t*], align 8
>  %.sub = getelementptr inbounds [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, 
> i64 0, i64 0

Boxing/Allocation

>  %27 = call %jl_value_t* @jl_box_uint64(i64 zeroext %26)

Generic calls.

>  %28 = call %jl_value_t* @jl_apply_generic(%jl_value_t** %2, i32 3)

[julia-users] Re: Curious parsing behavior

[David Gleich]

Ahah! That explains it.

Is there a better way to create floating point literals that avoid this?

David

On Wednesday, September 14, 2016 at 9:26:42 AM UTC-4, Steven G. Johnson 
wrote:
>
>
>
> On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich wrote:
>>
>> Can anyone give me a quick explanation for why these statements seem to 
>> parse differently?
>>
>> julia> 1782.^12. + 1841.^12.
>>
>
> .^ and .+ are (elementwise/broadcasting) operators in Julia, and there is 
> a parsing ambiguity here because it is not clear whether the . goes with 
> the operator or the number.
>
> See also the discussion at
>
>  https://github.com/JuliaLang/julia/issues/15731
>  https://github.com/JuliaLang/julia/pull/11529
>
> for possible ways that this might be made less surprising in the future.
>

[julia-users] [ANN]New package RFlavor.jl provides R-like functions

[Lanfeng Pan]

Hi all,

To help R users get used to Julia soon, this package provide some handy 
functions from R in Julia, such as 

list
matrix
rep, seq
table
expand_grid, outer
sweep
duplicated
findinterval
...

More to come and all contributions and comments are welcome.
The package address is https://github.com/panlanfeng/RFlavor.jl
See our work list at https://github.com/panlanfeng/RFlavor.jl/issues/2


Best,
Lanfeng

[julia-users] Re: Telling if code is vectorised.

[Ben Ward]

Ahah! I completely forgot about warntype! Thanks!

Out of interest, as I've only started to read llvm and native instructions 
generated by my julia functions, is there a way to tell from the llvm if 
there's type instability - say one forgets to do a code_warntype, are there 
llvm instructions that when you see them, you should go "Doh man I need to 
do @code_warntype as there's something not right here"?

On Wednesday, September 14, 2016 at 4:04:29 PM UTC+1, Kristoffer Carlsson 
wrote:
>
> Your code is type unstable. Use a = UInt64(0).
>
> On Wednesday, September 14, 2016 at 4:33:39 PM UTC+2, Ben Ward wrote:
>>
>> Hi,
>>
>> I've written a simple function:
>>
>> function testfun2()
>> a = 0
>> @inbounds @simd for i in UInt64(1):UInt64(1000)
>> i = i - ((i >> 1) & 0x)
>> a += ((i & 0x) + ((i >> 2) & 0x))
>> end
>> return a
>> end
>>
>> I applies the same set of bit operations to a series of UInt64's and 
>> accumulates a result.
>>
>> And know from the Intel blog on vectorisation, in the llvm code generated 
>> by julia there is a set of instructions to look out for that indicate 
>> vectorised code: vector.head and vector.ph:
>>
>> I'm wondering why I don't see those instructions in the llvm generated 
>> for this function, I don't think I've violated any of the rules of writing 
>> loops that can be vectorised:
>>
>> *julia> **@code_llvm testfun2()*
>>
>>
>> define %jl_value_t* @julia_testfun2_70900() #0 {
>>
>> top:
>>
>>   %0 = call %jl_value_t*** @jl_get_ptls_states() #1
>>
>>   %1 = alloca [11 x %jl_value_t*], align 8
>>
>>   %.sub = getelementptr inbounds [11 x %jl_value_t*], [11 x 
>> %jl_value_t*]* %1, i64 0, i64 0
>>
>>   %2 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
>> i64 8
>>
>>   %3 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
>> i64 2
>>
>>   %a = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
>> i64 7
>>
>>   %4 = bitcast %jl_value_t** %2 to i8*
>>
>>   call void @llvm.memset.p0i8.i32(i8* %4, i8 0, i32 24, i32 8, i1 false)
>>
>>   %5 = bitcast [11 x %jl_value_t*]* %1 to i64*
>>
>>   %6 = bitcast %jl_value_t** %3 to i8*
>>
>>   call void @llvm.memset.p0i8.i64(i8* %6, i8 0, i64 40, i32 8, i1 false)
>>
>>   store i64 18, i64* %5, align 8
>>
>>   %7 = bitcast %jl_value_t*** %0 to i64*
>>
>>   %8 = load i64, i64* %7, align 8
>>
>>   %9 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
>> i64 1
>>
>>   %10 = bitcast %jl_value_t** %9 to i64*
>>
>>   store i64 %8, i64* %10, align 8
>>
>>   store %jl_value_t** %.sub, %jl_value_t*** %0, align 8
>>
>>   %"r#274" = alloca %UnitRange.6, align 8
>>
>>   store %jl_value_t* inttoptr (i64 4400218208 to %jl_value_t*), 
>> %jl_value_t** %a, align 8
>>
>>   %11 = getelementptr inbounds %UnitRange.6, %UnitRange.6* %"r#274", i64 
>> 0, i32 0
>>
>>   store i64 1, i64* %11, align 8
>>
>>   %12 = getelementptr inbounds %UnitRange.6, %UnitRange.6* %"r#274", i64 
>> 0, i32 1
>>
>>   store i64 1000, i64* %12, align 8
>>
>>   %13 = call i64 @julia_simd_inner_length_70896(%UnitRange.6* nonnull 
>> %"r#274", i64 0) #0
>>
>>   %14 = icmp eq i64 %13, 0
>>
>>   br i1 %14, label %L.backedge, label %if26.lr.ph
>>
>>
>> L8:   ; preds = %if26
>>
>>   %15 = load %jl_value_t*, %jl_value_t** %a, align 8
>>
>>   store %jl_value_t* %15, %jl_value_t** %40, align 8
>>
>>   %16 = getelementptr inbounds %jl_value_t, %jl_value_t* %15, i64 -1, i32 
>> 0
>>
>>   %17 = bitcast %jl_value_t** %16 to i64*
>>
>>   %18 = load i64, i64* %17, align 8
>>
>>   %19 = and i64 %18, -16
>>
>>   %20 = inttoptr i64 %19 to %jl_value_t*
>>
>>   %21 = icmp eq %jl_value_t* %20, inttoptr (i64 4400088496 to 
>> %jl_value_t*)
>>
>>   br i1 %21, label %L11, label %L10
>>
>>
>> L10:  ; preds = %L8
>>
>>   %22 = load i64, i64* %46, align 8
>>
>>   store i64 %22, i64* %47, align 8
>>
>>   %23 = and i64 %53, 3689348814741910323
>>
>>   %24 = lshr i64 %53, 2
>>
>>   %25 = and i64 %24, 3689348814741910323
>>
>>   %26 = add nuw nsw i64 %25, %23
>>
>>   store %jl_value_t* inttoptr (i64 4408276712 to %jl_value_t*), 
>> %jl_value_t** %2, align 8
>>
>>   %27 = call %jl_value_t* @jl_box_uint64(i64 zeroext %26)
>>
>>   store %jl_value_t* %27, %jl_value_t** %44, align 8
>>
>>   %28 = call %jl_value_t* @jl_apply_generic(%jl_value_t** %2, i32 3)
>>
>>   store %jl_value_t* %28, %jl_value_t** %41, align 8
>>
>>   br label %L12
>>
>>
>> L11:  ; preds = %L8, %if26
>>
>>   %"#temp#3.0" = phi %jl_value_t* [ inttoptr (i64 4409008592 to 
>> %jl_value_t*), %if26 ], [ inttoptr (i64 4423075536 to %jl_value_t*), %L8 ]
>>
>>   store %jl_value_t* %"#temp#3.0", %jl_value_t** %42, align 8
>>
>>   %29 = load i64, i64* %46, align 8
>>
>>   store i64 %29, i64* %47, align 8
>>
>>   %30 = and i64 %53, 3689348814741910323
>>
>>   %31 = lshr i64 %53, 

[julia-users] Re: Telling if code is vectorised.

[Kristoffer Carlsson]

Your code is type unstable. Use a = UInt64(0).

On Wednesday, September 14, 2016 at 4:33:39 PM UTC+2, Ben Ward wrote:
>
> Hi,
>
> I've written a simple function:
>
> function testfun2()
> a = 0
> @inbounds @simd for i in UInt64(1):UInt64(1000)
> i = i - ((i >> 1) & 0x)
> a += ((i & 0x) + ((i >> 2) & 0x))
> end
> return a
> end
>
> I applies the same set of bit operations to a series of UInt64's and 
> accumulates a result.
>
> And know from the Intel blog on vectorisation, in the llvm code generated 
> by julia there is a set of instructions to look out for that indicate 
> vectorised code: vector.head and vector.ph:
>
> I'm wondering why I don't see those instructions in the llvm generated for 
> this function, I don't think I've violated any of the rules of writing 
> loops that can be vectorised:
>
> *julia> **@code_llvm testfun2()*
>
>
> define %jl_value_t* @julia_testfun2_70900() #0 {
>
> top:
>
>   %0 = call %jl_value_t*** @jl_get_ptls_states() #1
>
>   %1 = alloca [11 x %jl_value_t*], align 8
>
>   %.sub = getelementptr inbounds [11 x %jl_value_t*], [11 x %jl_value_t*]* 
> %1, i64 0, i64 0
>
>   %2 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
> i64 8
>
>   %3 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
> i64 2
>
>   %a = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
> i64 7
>
>   %4 = bitcast %jl_value_t** %2 to i8*
>
>   call void @llvm.memset.p0i8.i32(i8* %4, i8 0, i32 24, i32 8, i1 false)
>
>   %5 = bitcast [11 x %jl_value_t*]* %1 to i64*
>
>   %6 = bitcast %jl_value_t** %3 to i8*
>
>   call void @llvm.memset.p0i8.i64(i8* %6, i8 0, i64 40, i32 8, i1 false)
>
>   store i64 18, i64* %5, align 8
>
>   %7 = bitcast %jl_value_t*** %0 to i64*
>
>   %8 = load i64, i64* %7, align 8
>
>   %9 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
> i64 1
>
>   %10 = bitcast %jl_value_t** %9 to i64*
>
>   store i64 %8, i64* %10, align 8
>
>   store %jl_value_t** %.sub, %jl_value_t*** %0, align 8
>
>   %"r#274" = alloca %UnitRange.6, align 8
>
>   store %jl_value_t* inttoptr (i64 4400218208 to %jl_value_t*), 
> %jl_value_t** %a, align 8
>
>   %11 = getelementptr inbounds %UnitRange.6, %UnitRange.6* %"r#274", i64 
> 0, i32 0
>
>   store i64 1, i64* %11, align 8
>
>   %12 = getelementptr inbounds %UnitRange.6, %UnitRange.6* %"r#274", i64 
> 0, i32 1
>
>   store i64 1000, i64* %12, align 8
>
>   %13 = call i64 @julia_simd_inner_length_70896(%UnitRange.6* nonnull 
> %"r#274", i64 0) #0
>
>   %14 = icmp eq i64 %13, 0
>
>   br i1 %14, label %L.backedge, label %if26.lr.ph
>
>
> L8:   ; preds = %if26
>
>   %15 = load %jl_value_t*, %jl_value_t** %a, align 8
>
>   store %jl_value_t* %15, %jl_value_t** %40, align 8
>
>   %16 = getelementptr inbounds %jl_value_t, %jl_value_t* %15, i64 -1, i32 0
>
>   %17 = bitcast %jl_value_t** %16 to i64*
>
>   %18 = load i64, i64* %17, align 8
>
>   %19 = and i64 %18, -16
>
>   %20 = inttoptr i64 %19 to %jl_value_t*
>
>   %21 = icmp eq %jl_value_t* %20, inttoptr (i64 4400088496 to %jl_value_t*)
>
>   br i1 %21, label %L11, label %L10
>
>
> L10:  ; preds = %L8
>
>   %22 = load i64, i64* %46, align 8
>
>   store i64 %22, i64* %47, align 8
>
>   %23 = and i64 %53, 3689348814741910323
>
>   %24 = lshr i64 %53, 2
>
>   %25 = and i64 %24, 3689348814741910323
>
>   %26 = add nuw nsw i64 %25, %23
>
>   store %jl_value_t* inttoptr (i64 4408276712 to %jl_value_t*), 
> %jl_value_t** %2, align 8
>
>   %27 = call %jl_value_t* @jl_box_uint64(i64 zeroext %26)
>
>   store %jl_value_t* %27, %jl_value_t** %44, align 8
>
>   %28 = call %jl_value_t* @jl_apply_generic(%jl_value_t** %2, i32 3)
>
>   store %jl_value_t* %28, %jl_value_t** %41, align 8
>
>   br label %L12
>
>
> L11:  ; preds = %L8, %if26
>
>   %"#temp#3.0" = phi %jl_value_t* [ inttoptr (i64 4409008592 to 
> %jl_value_t*), %if26 ], [ inttoptr (i64 4423075536 to %jl_value_t*), %L8 ]
>
>   store %jl_value_t* %"#temp#3.0", %jl_value_t** %42, align 8
>
>   %29 = load i64, i64* %46, align 8
>
>   store i64 %29, i64* %47, align 8
>
>   %30 = and i64 %53, 3689348814741910323
>
>   %31 = lshr i64 %53, 2
>
>   %32 = and i64 %31, 3689348814741910323
>
>   %33 = add nuw nsw i64 %32, %30
>
>   store %jl_value_t* inttoptr (i64 4408276712 to %jl_value_t*), 
> %jl_value_t** %2, align 8
>
>   %34 = call %jl_value_t* @jl_box_uint64(i64 zeroext %33)
>
>   store %jl_value_t* %34, %jl_value_t** %44, align 8
>
>   %35 = call %jl_value_t* @jl_invoke(%jl_value_t* %"#temp#3.0", 
> %jl_value_t** %2, i32 3)
>
>   store %jl_value_t* %35, %jl_value_t** %43, align 8
>
>   br label %L12
>
>
> L12:  ; preds = %L11, %L10
>
>   %storemerge.in.in = phi %jl_value_t* [ %28, %L10 ], [ %35, %L11 ]
>
>   %storemerge.in = bitcast %jl_value_t* 

Re: [julia-users] Telling if code is vectorised.

[Yichao Yu]

On Wed, Sep 14, 2016 at 10:33 AM, Ben Ward  wrote:

> Hi,
>
> I've written a simple function:
>
> function testfun2()
> a = 0
> @inbounds @simd for i in UInt64(1):UInt64(1000)
> i = i - ((i >> 1) & 0x)
> a += ((i & 0x) + ((i >> 2) & 0x))
> end
> return a
> end
>
>

Run your code through code_warntype first


> I applies the same set of bit operations to a series of UInt64's and
> accumulates a result.
>
> And know from the Intel blog on vectorisation, in the llvm code generated
> by julia there is a set of instructions to look out for that indicate
> vectorised code: vector.head and vector.ph:
>
> I'm wondering why I don't see those instructions in the llvm generated for
> this function, I don't think I've violated any of the rules of writing
> loops that can be vectorised:
>
> *julia> **@code_llvm testfun2()*
>
>
> define %jl_value_t* @julia_testfun2_70900() #0 {
>
> top:
>
>   %0 = call %jl_value_t*** @jl_get_ptls_states() #1
>
>   %1 = alloca [11 x %jl_value_t*], align 8
>
>   %.sub = getelementptr inbounds [11 x %jl_value_t*], [11 x %jl_value_t*]*
> %1, i64 0, i64 0
>
>   %2 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0,
> i64 8
>
>   %3 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0,
> i64 2
>
>   %a = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0,
> i64 7
>
>   %4 = bitcast %jl_value_t** %2 to i8*
>
>   call void @llvm.memset.p0i8.i32(i8* %4, i8 0, i32 24, i32 8, i1 false)
>
>   %5 = bitcast [11 x %jl_value_t*]* %1 to i64*
>
>   %6 = bitcast %jl_value_t** %3 to i8*
>
>   call void @llvm.memset.p0i8.i64(i8* %6, i8 0, i64 40, i32 8, i1 false)
>
>   store i64 18, i64* %5, align 8
>
>   %7 = bitcast %jl_value_t*** %0 to i64*
>
>   %8 = load i64, i64* %7, align 8
>
>   %9 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0,
> i64 1
>
>   %10 = bitcast %jl_value_t** %9 to i64*
>
>   store i64 %8, i64* %10, align 8
>
>   store %jl_value_t** %.sub, %jl_value_t*** %0, align 8
>
>   %"r#274" = alloca %UnitRange.6, align 8
>
>   store %jl_value_t* inttoptr (i64 4400218208 to %jl_value_t*),
> %jl_value_t** %a, align 8
>
>   %11 = getelementptr inbounds %UnitRange.6, %UnitRange.6* %"r#274", i64
> 0, i32 0
>
>   store i64 1, i64* %11, align 8
>
>   %12 = getelementptr inbounds %UnitRange.6, %UnitRange.6* %"r#274", i64
> 0, i32 1
>
>   store i64 1000, i64* %12, align 8
>
>   %13 = call i64 @julia_simd_inner_length_70896(%UnitRange.6* nonnull
> %"r#274", i64 0) #0
>
>   %14 = icmp eq i64 %13, 0
>
>   br i1 %14, label %L.backedge, label %if26.lr.ph
>
>
> L8:   ; preds = %if26
>
>   %15 = load %jl_value_t*, %jl_value_t** %a, align 8
>
>   store %jl_value_t* %15, %jl_value_t** %40, align 8
>
>   %16 = getelementptr inbounds %jl_value_t, %jl_value_t* %15, i64 -1, i32 0
>
>   %17 = bitcast %jl_value_t** %16 to i64*
>
>   %18 = load i64, i64* %17, align 8
>
>   %19 = and i64 %18, -16
>
>   %20 = inttoptr i64 %19 to %jl_value_t*
>
>   %21 = icmp eq %jl_value_t* %20, inttoptr (i64 4400088496 to %jl_value_t*)
>
>   br i1 %21, label %L11, label %L10
>
>
> L10:  ; preds = %L8
>
>   %22 = load i64, i64* %46, align 8
>
>   store i64 %22, i64* %47, align 8
>
>   %23 = and i64 %53, 3689348814741910323
>
>   %24 = lshr i64 %53, 2
>
>   %25 = and i64 %24, 3689348814741910323
>
>   %26 = add nuw nsw i64 %25, %23
>
>   store %jl_value_t* inttoptr (i64 4408276712 to %jl_value_t*),
> %jl_value_t** %2, align 8
>
>   %27 = call %jl_value_t* @jl_box_uint64(i64 zeroext %26)
>
>   store %jl_value_t* %27, %jl_value_t** %44, align 8
>
>   %28 = call %jl_value_t* @jl_apply_generic(%jl_value_t** %2, i32 3)
>
>   store %jl_value_t* %28, %jl_value_t** %41, align 8
>
>   br label %L12
>
>
> L11:  ; preds = %L8, %if26
>
>   %"#temp#3.0" = phi %jl_value_t* [ inttoptr (i64 4409008592 to
> %jl_value_t*), %if26 ], [ inttoptr (i64 4423075536 to %jl_value_t*), %L8 ]
>
>   store %jl_value_t* %"#temp#3.0", %jl_value_t** %42, align 8
>
>   %29 = load i64, i64* %46, align 8
>
>   store i64 %29, i64* %47, align 8
>
>   %30 = and i64 %53, 3689348814741910323
>
>   %31 = lshr i64 %53, 2
>
>   %32 = and i64 %31, 3689348814741910323
>
>   %33 = add nuw nsw i64 %32, %30
>
>   store %jl_value_t* inttoptr (i64 4408276712 to %jl_value_t*),
> %jl_value_t** %2, align 8
>
>   %34 = call %jl_value_t* @jl_box_uint64(i64 zeroext %33)
>
>   store %jl_value_t* %34, %jl_value_t** %44, align 8
>
>   %35 = call %jl_value_t* @jl_invoke(%jl_value_t* %"#temp#3.0",
> %jl_value_t** %2, i32 3)
>
>   store %jl_value_t* %35, %jl_value_t** %43, align 8
>
>   br label %L12
>
>
> L12:  ; preds = %L11, %L10
>
>   %storemerge.in.in = phi %jl_value_t* [ %28, %L10 ], [ %35, %L11 ]
>
>   %storemerge.in = bitcast %jl_value_t* 

Re: [julia-users] ls()?

[Jacob Quinn]

readdir()

On Wed, Sep 14, 2016 at 8:34 AM, Adrian Lewis 
wrote:

> In the filesystem package, if we have pwd() and cd(), why do we not have
> ls()?
>
> Aidy
>

[julia-users] ls()?

[Adrian Lewis]

In the filesystem package, if we have pwd() and cd(), why do we not have 
ls()?

Aidy

[julia-users] Telling if code is vectorised.

[Ben Ward]

Hi,

I've written a simple function:

function testfun2()
a = 0
@inbounds @simd for i in UInt64(1):UInt64(1000)
i = i - ((i >> 1) & 0x)
a += ((i & 0x) + ((i >> 2) & 0x))
end
return a
end

I applies the same set of bit operations to a series of UInt64's and 
accumulates a result.

And know from the Intel blog on vectorisation, in the llvm code generated 
by julia there is a set of instructions to look out for that indicate 
vectorised code: vector.head and vector.ph:

I'm wondering why I don't see those instructions in the llvm generated for 
this function, I don't think I've violated any of the rules of writing 
loops that can be vectorised:

*julia> **@code_llvm testfun2()*


define %jl_value_t* @julia_testfun2_70900() #0 {

top:

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

  %1 = alloca [11 x %jl_value_t*], align 8

  %.sub = getelementptr inbounds [11 x %jl_value_t*], [11 x %jl_value_t*]* 
%1, i64 0, i64 0

  %2 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
i64 8

  %3 = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
i64 2

  %a = getelementptr [11 x %jl_value_t*], [11 x %jl_value_t*]* %1, i64 0, 
i64 7

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

  call void @llvm.memset.p0i8.i32(i8* %4, i8 0, i32 24, i32 8, i1 false)

  %5 = bitcast [11 x %jl_value_t*]* %1 to i64*

  %6 = bitcast %jl_value_t** %3 to i8*

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

  store i64 18, i64* %5, align 8

  %7 = bitcast %jl_value_t*** %0 to i64*

  %8 = load i64, i64* %7, align 8

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

  %10 = bitcast %jl_value_t** %9 to i64*

  store i64 %8, i64* %10, align 8

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

  %"r#274" = alloca %UnitRange.6, align 8

  store %jl_value_t* inttoptr (i64 4400218208 to %jl_value_t*), 
%jl_value_t** %a, align 8

  %11 = getelementptr inbounds %UnitRange.6, %UnitRange.6* %"r#274", i64 0, 
i32 0

  store i64 1, i64* %11, align 8

  %12 = getelementptr inbounds %UnitRange.6, %UnitRange.6* %"r#274", i64 0, 
i32 1

  store i64 1000, i64* %12, align 8

  %13 = call i64 @julia_simd_inner_length_70896(%UnitRange.6* nonnull 
%"r#274", i64 0) #0

  %14 = icmp eq i64 %13, 0

  br i1 %14, label %L.backedge, label %if26.lr.ph


L8:   ; preds = %if26

  %15 = load %jl_value_t*, %jl_value_t** %a, align 8

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

  %16 = getelementptr inbounds %jl_value_t, %jl_value_t* %15, i64 -1, i32 0

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

  %18 = load i64, i64* %17, align 8

  %19 = and i64 %18, -16

  %20 = inttoptr i64 %19 to %jl_value_t*

  %21 = icmp eq %jl_value_t* %20, inttoptr (i64 4400088496 to %jl_value_t*)

  br i1 %21, label %L11, label %L10


L10:  ; preds = %L8

  %22 = load i64, i64* %46, align 8

  store i64 %22, i64* %47, align 8

  %23 = and i64 %53, 3689348814741910323

  %24 = lshr i64 %53, 2

  %25 = and i64 %24, 3689348814741910323

  %26 = add nuw nsw i64 %25, %23

  store %jl_value_t* inttoptr (i64 4408276712 to %jl_value_t*), 
%jl_value_t** %2, align 8

  %27 = call %jl_value_t* @jl_box_uint64(i64 zeroext %26)

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

  %28 = call %jl_value_t* @jl_apply_generic(%jl_value_t** %2, i32 3)

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

  br label %L12


L11:  ; preds = %L8, %if26

  %"#temp#3.0" = phi %jl_value_t* [ inttoptr (i64 4409008592 to 
%jl_value_t*), %if26 ], [ inttoptr (i64 4423075536 to %jl_value_t*), %L8 ]

  store %jl_value_t* %"#temp#3.0", %jl_value_t** %42, align 8

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

  store i64 %29, i64* %47, align 8

  %30 = and i64 %53, 3689348814741910323

  %31 = lshr i64 %53, 2

  %32 = and i64 %31, 3689348814741910323

  %33 = add nuw nsw i64 %32, %30

  store %jl_value_t* inttoptr (i64 4408276712 to %jl_value_t*), 
%jl_value_t** %2, align 8

  %34 = call %jl_value_t* @jl_box_uint64(i64 zeroext %33)

  store %jl_value_t* %34, %jl_value_t** %44, align 8

  %35 = call %jl_value_t* @jl_invoke(%jl_value_t* %"#temp#3.0", 
%jl_value_t** %2, i32 3)

  store %jl_value_t* %35, %jl_value_t** %43, align 8

  br label %L12


L12:  ; preds = %L11, %L10

  %storemerge.in.in = phi %jl_value_t* [ %28, %L10 ], [ %35, %L11 ]

  %storemerge.in = bitcast %jl_value_t* %storemerge.in.in to i64*

  %storemerge = load i64, i64* %storemerge.in, align 1

  %36 = call %jl_value_t* @jl_box_uint64(i64 zeroext %storemerge)

  store %jl_value_t* %36, %jl_value_t** %a, align 8

  %37 = add nuw i64 %"i#277.040", 1

  %exitcond = icmp eq i64 %37, %13

  br i1 %exitcond, label %L.backedge.loopexit, label %if26


L.backedge.loopexit:  ; preds = %L12

  

[julia-users] Re: Curious parsing behavior

[Steven G. Johnson]

On Wednesday, September 14, 2016 at 9:18:11 AM UTC-4, David Gleich wrote:
>
> Can anyone give me a quick explanation for why these statements seem to 
> parse differently?
>
> julia> 1782.^12. + 1841.^12.
>

.^ and .+ are (elementwise/broadcasting) operators in Julia, and there is a 
parsing ambiguity here because it is not clear whether the . goes with the 
operator or the number.

See also the discussion at

 https://github.com/JuliaLang/julia/issues/15731
 https://github.com/JuliaLang/julia/pull/11529

for possible ways that this might be made less surprising in the future.

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

[Steven G. Johnson]

On Wednesday, September 14, 2016 at 7:12:31 AM UTC-4, Neal Becker wrote:
>
> I'd expect it to be called with a large array as input, so hopefully it's 
> performant enough as is, leaving the type of the argument determined at 
> runtime: 


My issue is more with how it is used.   The whole constellation type seems 
oriented towards the "vectorized" style of constantly constructing new 
arrays  [c.C[x+1] for x in xsyms]  (aside: it seems like OOP overkill to 
define a whole type etcetera just to implement this simple one-line 
function), whereas you can usually get better performance by combining this 
kind of trivial array construction with the subsequent computation on the 
data.

[julia-users] Re: Curious parsing behavior

[Kristoffer Carlsson]

Does this answer the question?

julia> Base.parse("1782.^12. + 1841.^12.")
:(1782 .^ 12.0 + 1841 .^ 12.0)

julia> Base.parse("1782.^12.+1841.^12.")
:(1782 .^ 12 .+ 1841 .^ 12.0)


On Wednesday, September 14, 2016 at 3:18:11 PM UTC+2, David Gleich wrote:
>
> Can anyone give me a quick explanation for why these statements seem to 
> parse differently?
>
> julia> 1782.^12. + 1841.^12.
>
> 2.5412102586145895e39
>
>
>
> julia> 1782.^12.+1841.^12.
>
> 1.5158124229919557e39
>
> Thanks!
>
> David Gleich
>

[julia-users] Curious parsing behavior

[David Gleich]

Can anyone give me a quick explanation for why these statements seem to 
parse differently?

julia> 1782.^12. + 1841.^12.

2.5412102586145895e39



julia> 1782.^12.+1841.^12.

1.5158124229919557e39

Thanks!

David Gleich

[julia-users] Re: NumericExtensions not working on julia-0.5?

[Neal Becker]

Kristoffer Carlsson wrote:

> Do
> note:
> 
https://github.com/lindahua/NumericExtensions.jl/commit/16193a86ad0589520f944680a248ad36e3242682
> .
...

Yes, it seems StatsFuns (shouldn't that be spelled StatsFuncs?) has 
logsumexp.

[julia-users] Re: NumericExtensions not working on julia-0.5?

[Kristoffer Carlsson]

Do 
note: 
https://github.com/lindahua/NumericExtensions.jl/commit/16193a86ad0589520f944680a248ad36e3242682
.

The Union()s need to be Union{} to work on 0.5.

On Wednesday, September 14, 2016 at 2:16:11 PM UTC+2, Neal Becker wrote:
>
> julia> using NumericExtensions: logsumexp 
> INFO: Precompiling module ArrayViews. 
> WARNING: Method definition (::Type{ArrayViews.UnsafeContiguousView}) 
> (Ptr{#T<:Any}, Int64, Tuple{Vararg{Int64, #N<:Any}}) in module ArrayViews 
> at 
> /home/nbecker/.julia/v0.5/ArrayViews/src/arrviews.jl:18 overwritten at 
> /home/nbecker/.julia/v0.5/ArrayViews/src/arrviews.jl:26. 
> WARNING: symbol is deprecated, use Symbol instead. 
>  in symbol(::String, ::Vararg{Any,N}) at ./deprecated.jl:30 
>  in default_functorsym(::Symbol) at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:39 
>  in @functor2a(::Any, ::Any) at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:54 
>  in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:64 
>  in macro expansion at ./REPL.jl:95 [inlined] 
>  in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68 
> while loading /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl, in 
> expression starting on line 139 
> WARNING: Method definition 
> (::Type{NumericFuns.BesseliFun})(##335#OT<:Real) 
> in module NumericFuns at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73. 
> WARNING: Method definition 
> (::Type{NumericFuns.BesseljFun})(##340#OT<:Real) 
> in module NumericFuns at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73. 
> WARNING: Method definition 
> (::Type{NumericFuns.BesselkFun})(##345#OT<:Real) 
> in module NumericFuns at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73. 
> WARNING: Method definition 
> (::Type{NumericFuns.BesselyFun})(##350#OT<:Real) 
> in module NumericFuns at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73. 
> WARNING: Method definition 
> (::Type{NumericFuns.Hankelh1Fun})(##355#OT<:Real) 
> in module NumericFuns at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73. 
> WARNING: Method definition 
> (::Type{NumericFuns.Hankelh2Fun})(##360#OT<:Real) 
> in module NumericFuns at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
> /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73. 
> WARNING: could not import Base.add! into NumericExtensions 
> ERROR: LoadError: LoadError: MethodError: no method matching 
> Union(::Type{DenseArray{T,1}}, ::Type{DenseArray{T,2}}) 
> Closest candidates are: 
>   Union{T}(::Any) at sysimg.jl:53 
>  in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:64 
>  in macro expansion at ./REPL.jl:95 [inlined] 
>  in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68 
> while loading /home/nbecker/.julia/v0.5/NumericExtensions/src/common.jl, 
> in 
> expression starting on line 5 
> while loading 
> /home/nbecker/.julia/v0.5/NumericExtensions/src/NumericExtensions.jl, in 
> expression starting on line 116 
>
>
>

[julia-users] NumericExtensions not working on julia-0.5?

[Neal Becker]

julia> using NumericExtensions: logsumexp
INFO: Precompiling module ArrayViews.
WARNING: Method definition (::Type{ArrayViews.UnsafeContiguousView})
(Ptr{#T<:Any}, Int64, Tuple{Vararg{Int64, #N<:Any}}) in module ArrayViews at 
/home/nbecker/.julia/v0.5/ArrayViews/src/arrviews.jl:18 overwritten at 
/home/nbecker/.julia/v0.5/ArrayViews/src/arrviews.jl:26.
WARNING: symbol is deprecated, use Symbol instead.
 in symbol(::String, ::Vararg{Any,N}) at ./deprecated.jl:30
 in default_functorsym(::Symbol) at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:39
 in @functor2a(::Any, ::Any) at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:54
 in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:64
 in macro expansion at ./REPL.jl:95 [inlined]
 in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68
while loading /home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl, in 
expression starting on line 139
WARNING: Method definition (::Type{NumericFuns.BesseliFun})(##335#OT<:Real) 
in module NumericFuns at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73.
WARNING: Method definition (::Type{NumericFuns.BesseljFun})(##340#OT<:Real) 
in module NumericFuns at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73.
WARNING: Method definition (::Type{NumericFuns.BesselkFun})(##345#OT<:Real) 
in module NumericFuns at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73.
WARNING: Method definition (::Type{NumericFuns.BesselyFun})(##350#OT<:Real) 
in module NumericFuns at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73.
WARNING: Method definition (::Type{NumericFuns.Hankelh1Fun})(##355#OT<:Real) 
in module NumericFuns at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73.
WARNING: Method definition (::Type{NumericFuns.Hankelh2Fun})(##360#OT<:Real) 
in module NumericFuns at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:71 overwritten at 
/home/nbecker/.julia/v0.5/NumericFuns/src/functors.jl:73.
WARNING: could not import Base.add! into NumericExtensions
ERROR: LoadError: LoadError: MethodError: no method matching 
Union(::Type{DenseArray{T,1}}, ::Type{DenseArray{T,2}})
Closest candidates are:
  Union{T}(::Any) at sysimg.jl:53
 in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:64
 in macro expansion at ./REPL.jl:95 [inlined]
 in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68
while loading /home/nbecker/.julia/v0.5/NumericExtensions/src/common.jl, in 
expression starting on line 5
while loading 
/home/nbecker/.julia/v0.5/NumericExtensions/src/NumericExtensions.jl, in 
expression starting on line 116

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

[Neal Becker]

Steven G. Johnson wrote:

...
> 
> Note that you have the same problem in several places, e.g. in
> Constellation.jl.
> 
> (I don't really understand what that file is doing, but it seems to be
> constructing lots of little arrays that would be better of constructed
> implicitly as part of other data-processing operations.)
> 
> There are lots of micro-optimizations I can spot in Constellation.jl, e.g.
> let k = 2*pi/N; [cis(k*x) for x in 0:N-1]; end is almost 2x faster than
> [exp(im*2*pi/N*x) for x in 0:N-1] on my machine, but as usual one would
> expect that the biggest benefits would arise by re-arranging you code to
> avoid multiple passes over multiple arrays and instead do a single pass
> over one (or zero) arrays.

Constellation is just a mapping from an Array{Integer} -> 
Array{Complex{Float64}}.

I think I would prefer it to accept an Array{any Integer type}.  It's 
normally constructed only once, so I don't care about performance of the 
construction.

I'd expect it to be called with a large array as input, so hopefully it's 
performant enough as is, leaving the type of the argument determined at 
runtime:

Basically, it is just this:

type constellation{flt}
C::Array{Complex{flt},1}
end

function (c::constellation)(xsyms)
return [c.C[x+1] for x in xsyms]
end

I guess it would be better to write

function (c::constellation}{T}(xsyms::Array{T})
...

?

Re: [julia-users] link time error while running make utility on ppc64le

[Valencia Serrao]

Hello,

@Mahesh
I'm facing similar issue. Any updates on this issue ?  Were you able to 
progress ?

@Isaiah
I'm facing similar issue, I tried to access the links you shared above, 
however, the first link(github link) is not accessible. Could you please 
share the correct URL ? Also, if you can share the URL for the ppc related 
Makefile changes, it'll be great and really helpful.


Thanks,
Valencia

[julia-users] Re: Julia TCP server and connection

[Tanmay K. Mohapatra]

Hi,

I did not find any slowness when I ran the code.

My environment:
Julia Version 0.4.6
Commit 2e358ce (2016-06-19 17:16 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

The only thing I observed when I send messages rapidly is the buildup of 
TCP sockets (in closewait, timewait states).
I'm not sure if that could be causing the slowness you observed.
That is usually addressed by tuning system parameters, primarily 
net.ipv4.ip_local_port_range, net.ipv4.tcp_fin_timeout (ref. 
http://www.linux-admins.net/2010/09/linux-tcp-tuning.html for more details).

I reorganized the code somewhat (here: 
https://gist.github.com/tanmaykm/c2ab61a52cc5afa0e54fe61905a48ef1) to make 
it easier to understand/reuse.
With this it seems possible to merge server1 and server2 into one server 
and not have an additional hop between the two.
You may need them separate though, if you have many server1 and server2 
instances.

Hope this helps.

- Tanmay

On Tuesday, September 13, 2016 at 6:20:55 PM UTC+5:30, Karli Kund wrote:
>
> Hi,
>
> I posted question in stackoverflow with no answers: 
> http://stackoverflow.com/questions/39448808/julia-tcp-server-and-connection 
> Maybe from here. 
>

[julia-users] ANN: SimpleTraits.jl

[Mauro]

There is --at times-- some interest on this list about traits, enough
that I thought the noise to announce the registration of this traits
package is warranted.  In brief, traits group types into sets
independent of the type hierarchy and let functions dispatch on those
traits instead of on types.

The package can be found here:
  https://github.com/mauro3/SimpleTraits.jl

SimpleTraits.jl provides macros to automate *Tim's trait trick*.  A
brief example (more can be found in the README):

  using SimpleTraits
  # define a trait:
  @traitdef IsNice{X}

  # add some types to the trait:
  @traitimpl IsNice{Int}
  @traitimpl IsNice{String}

  # define a function dispatching on this trait and its negation:
  @traitfn f{X;  IsNice{X}}(x::X) = "Very nice!"
  @traitfn f{X; !IsNice{X}}(x::X) = "Not so nice!"

  # use that function like any other function
  f(5) # => "Very nice!"
  f("a") # => "Very nice!"
  f(6.0) # => "Not so nice!"


Tim Holy, indeed the inventor of the trick named after him, uses
SimpleTraits in the overhaul of his Images.jl package [1,2] (and was who
prodded me to register SimpleTraits.jl).  The "blurb" in my README is:

  Tim Holy endorses SimpleTraits, a bit: "I'd say that compared to
  manually writing out the trait-dispatch, the "win" is not enormous,
  but it is a little nicer." I suspect that — if you don't write
  Holy-traits before breakfast — your "win" should be greater ;-)

[1] https://github.com/timholy/Images.jl/issues/542
[2] https://github.com/JuliaImages/ImageAxes.jl

[julia-users] Re: Pkg.add() works fine while Pkg.update() doesn't over https instead of git

[Rahul Mourya]

Well I didn't make any intentional change my own. I guess it's the Pkg 
manager, which was not successful ! I did git stash, however it didn't 
solve the problem, I'm still getting same error msg when using Pkg.update() 
.

On Tuesday, 13 September 2016 16:54:43 UTC+2, Rahul Mourya wrote:
>
> Hi,
> I'm using Julia-0.4.6. My machine is behind a firewall, thus configured 
> git to use https: git config --global url."https://".insteadOf git://.
> Under this setting, I'm able to install packages using Pkg.add(), however, 
> when I use Pkg.update(), I get following error:
>
> INFO: Updating METADATA...
> Cannot pull with rebase: You have unstaged changes.
> Please commit or stash them.
> ERROR: failed process: Process(`git pull --rebase -q`, ProcessExited(1)) 
> [1]
>  in pipeline_error at process.jl:555
>  in run at process.jl:531
>  in anonymous at pkg/entry.jl:283
>  in withenv at env.jl:160
>  in anonymous at pkg/entry.jl:282
>  in cd at ./file.jl:22
>  in update at ./pkg/entry.jl:272
>  in anonymous at pkg/dir.jl:31
>  in cd at file.jl:22
>  in cd at pkg/dir.jl:31
>  in update at ./pkg.jl:45
>
> what could be the reason? Any workaround this?
>
> Thanks!
>

[julia-users] Re: Julia for Data Science book (Technics Publications)

[Ismael Venegas Castelló]

I advice you to add a reference to your book, via a pull request to:

   - https://github.com/JuliaLang/julialang.github.com
   
Which should go in this file:

   - 
   
https://github.com/JuliaLang/julialang.github.com/blob/master/learning/index.md
   

El martes, 13 de septiembre de 2016, 19:58:23 (UTC-5), Zacharias Voulgaris 
escribió:
>
> Hi everyone,
>
>  
>
> I’m fairly new in this group but I’ve been an avid Julia user since Ver. 
> 0.2. About a year ago I decided to take the next step and start using Julia 
> professionally, namely for data science projects (even if at that time I 
> was a PM in Microsoft). Shortly afterwards, I started writing a book about 
> it, focusing on how we can use this wonderful tool for data science 
> projects. My aim was to make it easy for everyone to learn to make use of 
> their Julia know-how for tackling data science project, but also to help 
> more experienced data scientists to do what they usually do but instead of 
> Python / R / Scala, use a more elegant tool (Julia). I’m writing this post 
> because this book is finally a reality.
>
>  
>
> In this book, which is titled Julia for Data Science and published by 
> Technics Publications, I cover various data science topics. These include 
> data engineering, supervised and unsupervised  machine learning, 
> statistics, and some graph analysis. Also, since the focus is on 
> applications rather than digging into the deeper layers of the language, I 
> make use of IJulia instead of Juno, while I also refrain from delving into 
> custom types and meta-programming. Yet, in this book I make use of tools 
> and metrics that are rarely, if ever, mentioned in other data science books 
> (e.g. the T-SNE method, some variants of Jaccard Similarity, some 
> alternative error averages for regression, and more). Also, I try to keep 
> assumptions about the reader’s knowledge to a minimum, so there are plenty 
> of links to references for the various concepts used in the book, from 
> reliable sources. Finally, the book includes plenty of reference sections 
> at the end, so you don’t need to remember all the packages introduced, or 
> all the places where you can learn more about the language. Each chapter is 
> accompanied by a series of questions and some exercises, to help you make 
> sure you comprehend everything you’ve read, while at the end I include a 
> full project for you to practice on (answers to all the exercises and the 
> project itself are at an appendix). All the code used in the book is 
> available on Jupyter files, while the data files are also available in .csv 
> and text format.
>
>  
>
> The book is available in both paperback and eBook format (PDF, Kindle, and 
> Safari) at the publisher’s website: https://technicspub.com/analytics
>
>  
>
> Please note that for some reason the Packt publishing house, which has had 
> the monopoly on Julia books up until now, decided to follow suit, which is 
> why it is releasing a book with the same title next month (clearly, 
> imagination is not their strongest suit!). So, please make sure that you 
> don’t confuse the two books. My goal is not to make a quick buck through 
> this book (which is why I’m not publishing it via Packt); instead, I aim to 
> make Julia more well-known to the data science world while at the same time 
> make data science more accessible to all Julia users. 
>
>  
>
> Thanks,
>
>  
>
> Zack
>

Re: [julia-users] Re: Priority queue - peek versus dequeue!

[Júlio Hoffimann]

Thank you, I'll open an issue.

-Júlio

Re: [julia-users] Julia for Data Science book (Technics Publications)

[Tamas Papp]

On Wed, Sep 14 2016, Zacharias Voulgaris wrote:

> Please note that for some reason the Packt publishing house, which has had
> the monopoly on Julia books up until now, decided to follow suit, which is
> why it is releasing a book with the same title next month (clearly,
> imagination is not their strongest suit!). So, please make sure that you
> don’t confuse the two books. My goal is not to make a quick buck through
> this book (which is why I’m not publishing it via Packt); instead, I aim to
> make Julia more well-known to the data science world while at the same time
> make data science more accessible to all Julia users.

On the one hand I am happy to hear that so many books are coming out
about Julia. On the other hand, given that Julia is under active
development with major changes in the language happening all the time, I
am wondering whether pre-0.5 is the right time in the life cycle of the
language and the package ecosystem for these "walkthrough" style
books. I expect that code would become obsolete very quickly --- it can,
of course, be modified to run with only minor changes, but perhaps the
target audience of these books would be confused by this.

Again, please understand that I am not disparaging your book, or the one
coming out from Packt, just expressing a general opinion.

Best,

Tamas

Re: [julia-users] debugging tips for GC?

[Andreas Lobinger]

Hello,

On Tuesday, September 13, 2016 at 10:17:30 PM UTC+2, Yichao Yu wrote:

>
> On Tue, Sep 13, 2016 at 4:11 PM, Yichao Yu  > wrote:
>
>> I'm able to reproduce it in rr and found the issue.
>> TL;DR the issue is at 
>> https://github.com/JuliaGraphics/Cairo.jl/blame/master/src/Cairo.jl#L625, 
>> where it passes the ownership of a cairo pointer to julia, causing a double 
>> free.
>>
>
> Which comes from your commit a year ago ;-p
>
> https://github.com/JuliaGraphics/Cairo.jl/commit/23681dc1270882c964059d23863a88d4276f6fd8
>

True. Actually Tim recommended this, i had initially a solution with 
unsafe_load on single elements. But we both and subsequent editors never 
recognized the problem. I've filed an PR.