[julia-users] Re: How to install JuMP without SSL errors?

[Jonathan Goldfarb]

FYI: https://github.com/JuliaLang/julia/issues/18871

On Sunday, October 16, 2016 at 11:55:07 AM UTC-4, Rick Graham wrote:
>
> Ref:  https://github.com/JuliaOpt/JuMP.jl/issues/864
>
> I can't seem to add package JuMP.  Other packages seem to be added fine.
>
> How can I fix this?
>
> OS: Fedora 24
>
> julia> versioninfo()
> Julia Version 0.6.0-dev.986
> Commit 6c9f5af (2016-10-16 05:19 UTC)
> Platform Info:
>   OS: Linux (x86_64-redhat-linux)
>   CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.7.1 (ORCJIT, broadwell)
>
>
>
> julia> Pkg.add("JuMP")
> INFO: Cloning cache of Calculus from 
> https://github.com/johnmyleswhite/Calculus.jl.git
> INFO: Cloning cache of DataStructures from 
> https://github.com/JuliaLang/DataStructures.jl.git
> INFO: Cloning cache of ForwardDiff from 
> https://github.com/JuliaDiff/ForwardDiff.jl.git
> INFO: Cloning cache of JuMP from https://github.com/JuliaOpt/JuMP.jl.git
> ERROR: Cannot clone JuMP from https://github.com/JuliaOpt/JuMP.jl.git. SSL 
> error:  - UNKNOWN ERROR CODE (0001)
>  in prefetch(::String, ::String, ::Array{String,1}) at ./pkg/cache.jl:56
>  in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, 
> ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, 
> ::Dict{String,Tuple{VersionNumber,Bool}}, 
> ::Dict{String,Base.Pkg.Types.Fixed}, ::Dict{String,VersionNumber}, 
> ::Set{String}) at ./pkg/entry.jl:512
>  in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, 
> ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, 
> ::Dict{String,Tuple{VersionNumber,Bool}}, 
> ::Dict{String,Base.Pkg.Types.Fixed}) at ./pkg/entry.jl:476
>  in edit(::Function, ::String, ::Base.Pkg.Types.VersionSet, 
> ::Vararg{Base.Pkg.Types.VersionSet,N}) at ./pkg/entry.jl:30
>  in (::Base.Pkg.Entry.##2#5{String,Base.Pkg.Types.VersionSet})() at 
> ./task.jl:363
>  in sync_end() at ./task.jl:314
>  in macro expansion at ./task.jl:330 [inlined]
>  in add(::String, ::Base.Pkg.Types.VersionSet) at ./pkg/entry.jl:50
>  in (::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}})() 
> at ./pkg/dir.jl:31
>  in cd(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}}, 
> ::String) at ./file.jl:69
>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, ::Vararg{Any,N}) 
> at ./pkg/dir.jl:31
>  in add(::String) at ./pkg/pkg.jl:100
>
>

Re: [julia-users] Does anyone have a fork/branch of Sundials.jl that works on 0.4/0.5?

[Jonathan Goldfarb]

For anyone following along at home, the branch in question is now updated 
with wrapper functions recreated so the tests should now pass.

Regards,

Max

On Wednesday, October 28, 2015 at 8:30:09 AM UTC-4, Alex wrote:
>
> Hi Simon,
>
> Christian Haargaard just created a PR (
> https://github.com/JuliaLang/Sundials.jl/pull/56), which means that there 
> is now (or should be) a working branch.
>
> May I ask what you mean by "minor API differences"? 
>
> Best,
>
> Alex.
>
> On Saturday, 17 October 2015 10:58:10 UTC+2, Simon Frost wrote:
>
>> Dear Mauro,
>>
>> I think the fixes, at least for cvode, have already been done in one of 
>> the branches, but there isn't a PR yet. Apart from some minor API 
>> differences, which hopefully will be ironed out in the future, cvode in 
>> Sundials.jl is a lot faster than ode23s in ODE.jl.
>>
>> Best
>> Simon
>>
>

[julia-users] Re: Dimension mismatch error in Julia!​

[Jonathan Goldfarb]

Looks like a couple things going on here:

- The error is due to a mix of hcat and vcat in the definition of f; 
replacing it with either 
*f(x,y)= [y;-w^2*sin(x)-u*w^2*cos(x); -2γ*y];*
or
*f(x,y)= [y, -w^2*sin(x)-u*w^2*cos(x), -2γ*y];*
will fix this error.
I predict 
other errors down the line:
- f is a function of two arguments, but it is passed to ode45 with three. 
ode45 expects a function f=f(x,y) where y is a vector of length (in this 
case) 3, I guess. You could define f as a function of 3 arguments, then 
pass the anonymous function (x,y)->f(x,y,u) to ode4
- if U is a vector of length sizeU, you may get a BoundsError calling U[i] 
rather than U[j]


On Tuesday, March 10, 2015 at 8:33:10 AM UTC-4, Kacem HARIZ wrote:
>
>
>
> I got stuck by an error in Julia! please I need help!
>
> *here is the code:*
>
>  
> *w=1;*
> *γ=0.01;*
> *f(x,y)= [y;-w^2*sin(x)-u*w^2*cos(x) -2γ*y];*
>
> *for i=1 : numberOfStates*
> *x0=Sx[i+2];*
> *y0=Sy[i+2];*
> *for j=1:sizeU*
> *u=U[i];*
> *t,NX=ODE.ode45(f(x,y,u),[0,0.1],[x0,y0])*
> *end*
> *end*
>
> with Sx and Sy two vectors of the same size, and U is a vector of size 
> sizeU.
>
> *and here is the error message:*
>
> mismatch in dimension 1
> while loading In[94], in expression starting on line 5
>
>  in cat at abstractarray.jl:631
>  in hcat at abstractarray.jl:671
>  in hvcat at abstractarray.jl:966
>  in f at In[90]:3
>  in oderkf at /home/juser/.julia/v0.3/ODE/src/ODE.jl:208
>  in ode45_dp at /home/juser/.julia/v0.3/ODE/src/ODE.jl:303
>  in anonymous at no file:10
>
>
> Best regards,
> Kacem
>

[julia-users] ANN/RFC: Termbox.jl

[Jonathan Goldfarb]

Termbox.jl (https://github.com/jgoldfar/Termbox.jl) is a wrapper 
for Termbox, a lightweight text-based user interface library. OSX and Linux 
are currently supported, and the low-level interface is complete enough to 
re-implement the demo from the original package (see test/outputexample.jl.)

I wrote this up yesterday for use in another project I'm working on 
(reporting results of a long-running computation in a nicer way,) but I'd 
be interested in feedback, ideas for a higher-level interface and how to 
effectively unit-test the package, etc.

Regards,
Max Goldfarb

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

[Jonathan Goldfarb]

Many thanks for the package; particularly interesting that Yeppp! is faster 
than devectorized Julia code as well, when it is able to outperform Julia.

In case anyone else finds it useful, I added a small benchmark here at this 
gist: https://gist.github.com/jgoldfar/7cb34d8469f92d36fb47

-Max

On Saturday, April 11, 2015 at 3:36:21 AM UTC-4, Viral Shah wrote:
>
> I have cleaned up the old Yeppp.jl repository a bit, and also added 
> release versions to METADATA.
>
> http://www.yeppp.info/
> https://github.com/JuliaLang/Yeppp.jl
>
> In my benchmarks, I have found the vectorized log and exp routines from 
> Yeppp to be 8x faster than the ones in Base, and sin/cos/tan are also 
> faster. I have not found the other routines to be much faster, but I have 
> wrapped a few more anyways.
>
> I think the other useful routine to wrap may be evalpoly.
>
> -viral
>
>

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

[Jonathan Goldfarb]

I agree with this if the idea is to keep Julia scripts easily 
comprehensible/readable, but not if speed is the only goal. Yeppp add! 
beats the devectorized code by ~1.2x (on my machine, running the same 
tests)I posted earlier, with trivial added benchmark.)  While this is 
nothing to phone home about, it is something.
At least for me, on the principle that code is read more often than it is 
written, it makes sense to give up <2x performance for expressive nature of 
Julia. This seems also in keeping with the goal of being within 2x of 
equivalent C code speed.
By the way, I submitted a PR to add evalpoly! to Yeppp.jl; this carries 
more than a 2x speedup compared to the equivalent in pure Julia. Let me 
know if it can be improved in some way.
Thanks
-Max

On Sunday, April 12, 2015 at 12:02:42 AM UTC-4, Viral Shah wrote:
>
> I am wondering if I should just remove the add/multiply/max/min/negate 
> methods. Those don't seem to be useful from a julia performance standpoint 
> at all. They just add clutter to the library, and I will eventually have to 
> write more tests.
>
> I wonder if we can find cases in which these outperform the obvious 
> devectorized julia versions.
>
> -viral
>
> On Sunday, April 12, 2015 at 9:08:36 AM UTC+5:30, Viral Shah wrote:
>>
>> It would be interesting to compare the results of Yeppp with VML. 
>>
>> https://github.com/simonster/VML.jl 
>>
>> Kevin, thanks, I knew someone had done it, but couldn’t locate the 
>> package. I doubt things can be faster, since Yeppp is effectively giving 
>> you a log every 5 cycles or something like that. There’s this: 
>>
>> http://www.yeppp.info/benchmarks.html 
>>
>> -viral 
>>
>>
>>
>> > On 11-Apr-2015, at 11:06 pm, Kevin Squire > > wrote: 
>> > 
>> > Relevant previous discussions/issues 
>> > 
>> > 
>> https://groups.google.com/forum/#!searchin/julia-dev/Yeppp/julia-dev/fixVZON0S8o/ChD5R1T-G0kJ
>>  
>> > https://groups.google.com/forum/#!topic/julia-users/o3Tbjh2eA9c 
>> > https://github.com/JuliaLang/julia/issues/8450 
>> > 
>> > Cheers, 
>> >Kevin 
>> > 
>> > 
>> > On Sat, Apr 11, 2015 at 7:10 AM, Jonathan Goldfarb > > wrote: 
>> > Many thanks for the package; particularly interesting that Yeppp! is 
>> faster than devectorized Julia code as well, when it is able to outperform 
>> Julia. 
>> > 
>> > In case anyone else finds it useful, I added a small benchmark here at 
>> this gist: https://gist.github.com/jgoldfar/7cb34d8469f92d36fb47 
>> > 
>> > -Max 
>> > 
>> > On Saturday, April 11, 2015 at 3:36:21 AM UTC-4, Viral Shah wrote: 
>> > I have cleaned up the old Yeppp.jl repository a bit, and also added 
>> release versions to METADATA. 
>> > 
>> > http://www.yeppp.info/ 
>> > https://github.com/JuliaLang/Yeppp.jl 
>> > 
>> > In my benchmarks, I have found the vectorized log and exp routines from 
>> Yeppp to be 8x faster than the ones in Base, and sin/cos/tan are also 
>> faster. I have not found the other routines to be much faster, but I have 
>> wrapped a few more anyways. 
>> > 
>> > I think the other useful routine to wrap may be evalpoly. 
>> > 
>> > -viral 
>> > 
>> > 
>>
>>

Re: [julia-users] Re: Ubuntu bug? Executing .jl files via shebang does nothing on Ubuntu 16.04 x64

[Jonathan Goldfarb]

Yes [1] I've been bitten by this before as well; it's unfortunate. Is there 
perhaps some way to change some command line arguments after starting Julia?

[1] 
http://unix.stackexchange.com/questions/14887/the-way-to-use-usr-bin-env-sed-f-in-shebang/14892#14892

On Thursday, May 19, 2016 at 2:35:27 PM UTC-4, Yichao Yu wrote:
>
>
> On May 19, 2016 1:54 PM, "Adrian Salceanu"  > wrote:
> >
> > OK, I figured out what causes the problem. 
> >
> > It seems that on linux it does not like the --color=yes 
> >
> > Removed that and it works as expected. 
>
> Cmdline parseing for shebang is wierd. I believe linux only split at the 
> first space
>
> >
> > Cheers! 
> >
> >
> > joi, 19 mai 2016, 19:48:04 UTC+2, Adrian Salceanu a scris:
> >>
> >> Hi, 
> >>
> >> There seems to be a problem with executing .jl scripts on Ubuntu 16.04 
> x64 
> >>
> >> Take this simple program in exec_text.jl
> >>
> >> #!/usr/bin/env julia --color=yes
> >> println("all good!")
> >>
> >>
> >> On Mac OS: 
> >> $ ./exec_test.jl
> >> all good!
> >>
> >>
> >> On Ubuntu it just hangs
> >> $ ./exec_test.jl
> >>
> >> [=> never returns, does nothing]
> >>
> >> This works as expected: 
> >> $ julia exec_test.jl
> >> all good!
> >>
> >> But this is not an acceptable solution as I need to execute my program 
> in order to pass command line args to it. Otherwise julia would just gobble 
> up the command line args intended for my script. 
> >>
> >> Thanks,
> >> Adrian
>

[julia-users] Re: Want: "Deprecation" badge for Github

[Jonathan Goldfarb]

Perhaps related: https://dependencyci.com/
I like the other suggestions in the thread.

On Tuesday, July 12, 2016 at 1:15:24 PM UTC-4, Erik Schnetter wrote:
>
> Our Julia projects live on Github, and many projects proudly present 
> badges for Travis, Appveyor, Codecov, and probably a few more. TL;DR: There 
> should be a badge for "no compatibility warnings" as well.
>
> In the past weeks, Julia 0.5 deprecated a certain number of features. 
> These continue to work fine, but lead to long trails of "WARNING: XYZ is 
> deprecated". Usually, some package depends on some other packages, and one 
> of these isn't using Compat in the right way yet, and the result is a long 
> string of "Base.OS_NAME is deprecated in deps/build.jl:21", repeated 27 
> times, in some package for which you have only a tangential interest.
>
> I've occasionally began to fix this for packages where I contribute (HDF5, 
> MPI), and for packages they use (BinDeps, Compat), but truth be told, 
> there's a lot of these warnings, and it's not always easy to figure out 
> where they come from, or whether they are already fixed on the package's 
> master branch, which just hasn't been tagged yet.
>
> So -- here is my idea: Create a badge for "my project doesn't show any 
> compatibility warnings for the Julia master branch". I'd happily add it to 
> all my projects.
>
> -erik
>
> -- 
> Erik Schnetter > 
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

[julia-users] Help request wrapping a library with Clang.jl

[Jonathan Goldfarb]

Been working off of the  examples 
 (and the docs, which I 
understand are in flux) but running into an issue I'm not sure is worth 
reporting, or can be fixed. Don't honestly know where to start, if anyone 
has an idea let me know.

The library to be wrapped is Silo 
(https://wci.llnl.gov/simulation/computer-codes/silo); the applicable 
header is attached in case that gives some hint. I made sure to build the 
library itself as a shared library with -shared and -fPIC compiler options. 
The project is open source BTW at https://github.com/jgoldfar/Silo.jl in 
case it ever works and is of use; that version isn't up-to-date (haven't 
pushed for a while, limited internet connection.)

Running the wrap_silo.jl file below:

using Clang.wrap_c

# silo_names = ["silo.h",]

#Clang include path for system clang: /usr/include/clang/3.4/include

JULIAHOME = "/home/jgoldfar/Documents/work/projects/julia"

clang_includes = map(x->joinpath(JULIAHOME, x),[
   "usr/include/clang/",
   "usr/include",
   "usr/include/llvm",
   "usr/include/llvm-c",
   ]
 )

path = "/home/jgoldfar/Documents/work/projects/Silo.jl/deps/usr/include"
check_use_header(path) = true

clang_extraargs = ["-D", "__STDC_LIMIT_MACROS", "-D", 
"__STDC_CONSTANT_MACROS", "-v"]
context = wrap_c.init(output_file = "silo.jl",
  header_library=x->"silo",
  clang_args = clang_extraargs,
  clang_includes = clang_includes,
  common_file = "libsilo_h.jl"
  )
context.options.wrap_structs = true

wrap_c.wrap_c_headers(context, [joinpath(path, "silo.h")])
mv("silo.jl", "libsilo.jl")  # avoid a name conflict for case-insensitive 
file systems

gives the following output:

Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 
3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
ignoring nonexistent directory "../lib/clang/3.4/include"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/jgoldfar/Documents/work/projects/julia/usr/include/clang
 /home/jgoldfar/Documents/work/projects/julia/usr/include
 /home/jgoldfar/Documents/work/projects/julia/usr/include/llvm
 /home/jgoldfar/Documents/work/projects/julia/usr/include/llvm-c
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
WARNING: wrap_c_headers: deprecated

WRAPPING HEADER: 
/home/jgoldfar/Documents/work/projects/Silo.jl/deps/usr/include/silo.h 

WARNING: Not wrapping InclusionDirective   stdio.h
ERROR: ParseError("end of input")
 in __parse#8__ at ./string.jl:1259
 in parse at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
 in parse at string.jl:1263
 in wrap at /home/jgoldfar/.julia/v0.3/Clang/src/wrap_c.jl:568
 in wrap_header at /home/jgoldfar/.julia/v0.3/Clang/src/wrap_c.jl:630
 in run at /home/jgoldfar/.julia/v0.3/Clang/src/wrap_c.jl:747
 in wrap_c_headers at /home/jgoldfar/.julia/v0.3/Clang/src/wrap_c.jl:777
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
while loading 
/home/jgoldfar/Documents/work/projects/Silo.jl/gen/wrap_silo.jl, in 
expression starting on line 37

/*
Copyright (c) 1994 - 2010, Lawrence Livermore National Security, LLC.
LLNL-CODE-425250.
All rights reserved.

This file is part of Silo. For details, see silo.llnl.gov.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

   * Redistributions of source code must retain the above copyright
 notice, this list of conditions and the disclaimer below.
   * Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions and the disclaimer (as noted
 below) in the documentation and/or other materials provided with
 the distribution.
   * Neither the name of the LLNS/LLNL nor the names of its
 contributors may be used to endorse or promote products derived
 from this software without specific prior written permission.

THIS SOFTWARE  IS PROVIDED BY  THE COPYRIGHT HOLDERS  AND CONTRIBUTORS
"AS  IS" AND  ANY EXPRESS  OR IMPLIED  WARRANTIES, INCLUDING,  BUT NOT
LIMITED TO, THE IMPLIED  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A  PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN  NO  EVENT SHALL  LAWRENCE
LIVERMORE  NATIONAL SECURITY, L

[julia-users] Anyone running into a build error on latest master on OSX?

[Jonathan Goldfarb]

Not sure if this is the place for this kind of discussion, but here goes. 
Been building from source from master periodically and enjoying poking 
around in the source, but have run into an issue apparently due to the 
updated LLVM version, and am wondering if anyone else is having similar 
issues. After removing (I think) everything, including "brew rm --force 
$(brew deps --HEAD julia);", I tried the following:

- brew install git gcc 
- clone julia repo to clean directory
- Add 

BUILD_LLVM_CLANG=1
to Make.user as suggested by Clang.jl/Cxx.jl (removing this step does not 
apparently fix the build, but changes the error)

- run make

and have gotten the following: 

llvm[6]: Copying runtime library darwin/eprintf to build dir
cp: 
/Users/jgoldfar/Public/julia/deps/build/llvm-3.7.1/build_Release/tools/clang/runtime/compiler-rt/clang_darwin/eprintf/libcompiler_rt.a:
 
No such file or directory
make[6]: *** 
[/Users/jgoldfar/Public/julia/deps/build/llvm-3.7.1/build_Release/Release/lib/clang/3.7.1/lib/darwin/libclang_rt.eprintf.a]
 
Error 1
make[5]: *** [compiler-rt/.makeall] Error 2
make[4]: *** [all] Error 1
make[3]: *** [clang/.makeall] Error 2
make[2]: *** [all] Error 1
make[1]: *** [build/llvm-3.7.1/build_Release/Release/lib/libLLVMCodeGen.a] 
Error 2
make: *** [julia-deps] Error 2

Searching online suggests that this was an error with an older version of 
clang/LLVM, but it appears here again.

Anybody else running into this?

Regards,
Max

Re: [julia-users] Anyone running into a build error on latest master on OSX?

[Jonathan Goldfarb]

I'd be inclined to agree, but along the way I had tried xcode-select
--install, which has no effect, and gives the error that the command line
tools were already installed. I read somewhere that installing the full
xcode app is necessary (or does this just run some kind of update?)

On Wed, Jan 20, 2016 at 9:21 PM Isaiah Norton 
wrote:

> Probably outdated/mismatched XCode version leading to some error earlier
> in the build. See:
> https://github.com/JuliaLang/julia/issues/14593
> https://github.com/JuliaLang/julia/pull/14605
>
> On Wed, Jan 20, 2016 at 7:59 PM, Jonathan Goldfarb 
> wrote:
>
>> Not sure if this is the place for this kind of discussion, but here goes.
>> Been building from source from master periodically and enjoying poking
>> around in the source, but have run into an issue apparently due to the
>> updated LLVM version, and am wondering if anyone else is having similar
>> issues. After removing (I think) everything, including "brew rm --force
>> $(brew deps --HEAD julia);", I tried the following:
>>
>> - brew install git gcc
>> - clone julia repo to clean directory
>> - Add
>>
>> BUILD_LLVM_CLANG=1
>> to Make.user as suggested by Clang.jl/Cxx.jl (removing this step does not 
>> apparently fix the build, but changes the error)
>>
>> - run make
>>
>> and have gotten the following:
>>
>> llvm[6]: Copying runtime library darwin/eprintf to build dir
>> cp:
>> /Users/jgoldfar/Public/julia/deps/build/llvm-3.7.1/build_Release/tools/clang/runtime/compiler-rt/clang_darwin/eprintf/libcompiler_rt.a:
>> No such file or directory
>> make[6]: ***
>> [/Users/jgoldfar/Public/julia/deps/build/llvm-3.7.1/build_Release/Release/lib/clang/3.7.1/lib/darwin/libclang_rt.eprintf.a]
>> Error 1
>> make[5]: *** [compiler-rt/.makeall] Error 2
>> make[4]: *** [all] Error 1
>> make[3]: *** [clang/.makeall] Error 2
>> make[2]: *** [all] Error 1
>> make[1]: ***
>> [build/llvm-3.7.1/build_Release/Release/lib/libLLVMCodeGen.a] Error 2
>> make: *** [julia-deps] Error 2
>>
>> Searching online suggests that this was an error with an older version of
>> clang/LLVM, but it appears here again.
>>
>> Anybody else running into this?
>>
>> Regards,
>> Max
>>
>
> --
Regards,
Max Goldfarb

[julia-users] Creating closures referencing type parameters recently broken

[Jonathan Goldfarb]

Not sure if anyone else has (perhaps poorly conceived, but used to work) 
code like this:

function dotest{T}(x::T)
subf(x2::T)=println(x, ", ", x2)
subf(one(x))
end
dotest(1.1)


(reduced from a more complicated construction, in which "subf" is mapped 
onto multiple arrays.) Some change in the latest master causes this code to 
give "LoadError: UndefVarError: T not defined" even though e.g.

 function dotest{T}(x::T)
println(T)
end
dotest(1.1)

works fine. Evidently function construction like this should use anonymous 
functions going forward, but does anyone have pointers on how to write 
performant code using this type of pattern that works across Julia versions?
Thanks,
Max

Re: [julia-users] Creating closures referencing type parameters recently broken

[Jonathan Goldfarb]

Ah, I do recall reading that thread but didn't make the connection. I thought 
I'd built a version recent enough that it should have already broken due to 
that, but I guess not. Thanks for your help!

-Max Goldfarb

> On Feb 13, 2016, at 6:33 PM, Kristoffer Carlsson  
> wrote:
> 
> Jeff said this. 
> 
> "NLsolve, SimJulia: These have inner function signatures that depend on 
> static parameters. This is not supported yet, but can be fairly easily."

[julia-users] Updated performance tips?

[Jonathan Goldfarb]

I've really been enjoying writing Julia code as a user, and following the 
language as it develops, but I have noticed that over time, previously fast 
code sometimes gets slower, and (impressively) previously slow code will 
sometimes get faster, with updates to the Julia codebase. No complaint here 
in general; I really appreciate the work all of the Core and package 
developers do, and variations in performance of different codes it to be 
expected.
My question is this: has anyone in the Julia community thought about 
updated performance tips for writing high performance code? Obviously, 
using the profiler, along with many of the tips 
at 
https://github.com/JuliaLang/julia/commits/master/doc/manual/performance-tips.rst
 
still apply, but I am wondering more about general/structural ideas to keep 
in mind in Julia v0.4, as well as guidance on how best to take advantage of 
recent changes on master. I know that document hasn't been stagnant in any 
sense, but relatively "big in any case, I'd be happy to help make some 
updates in a PR if there's anything we come up with.
Best Regards,
Max

Re: [julia-users] Updated performance tips?

[Jonathan Goldfarb]

Yes, understood about difficulty keeping track of regressions. I was 
originally going to send a message relating up to 2x longer test time on 
the same code on Travis, but it appears as though something has changed in 
the nightly build available to CI that now gives significantly faster 
builds, even though the previous poor performance had been dependable... 
Evidently that build is not as up-to-date as I thought. Our code is 
currently not open source, but should be soon after which I can share an 
example.

Thanks for your comments, and thanks again for your work on Julia.

-Max


On Monday, February 22, 2016 at 11:12:58 AM UTC-5, Stefan Karpinski wrote:
>
> Yes, ideally code should not get slower with new releases – unfortunately, 
> keeping track of performance regressions can be a bit of a game of 
> whack-a-mole. Having examples of code whose speed has regressed is very 
> helpful. Thanks to Jarrett Revels excellent work, we now have some great 
> performance regression tracking infrastructure, but of course we always 
> need more things to test!
>
> On Mon, Feb 22, 2016 at 9:58 AM, Milan Bouchet-Valat  > wrote:
>
>> Le lundi 22 février 2016 à 06:27 -0800, Jonathan Goldfarb a écrit :
>> > I've really been enjoying writing Julia code as a user, and following
>> > the language as it develops, but I have noticed that over time,
>> > previously fast code sometimes gets slower, and (impressively)
>> > previously slow code will sometimes get faster, with updates to the
>> > Julia codebase.
>> Code is not supposed to get slower with newer releases. If this
>> happens, please report the problem here or on GitHub (if possible with
>> a reproducible example). This will be very helpful to help avoiding
>> regressions.
>>
>> > No complaint here in general; I really appreciate the work all of the
>> > Core and package developers do, and variations in performance of
>> > different codes it to be expected.
>> > My question is this: has anyone in the Julia community thought about
>> > updated performance tips for writing high performance code?
>> > Obviously, using the profiler, along with many of the tips
>> > at https://github.com/JuliaLang/julia/commits/master/doc/manual/perfo
>> > rmance-tips.rst still apply, but I am wondering more about
>> > general/structural ideas to keep in mind in Julia v0.4, as well as
>> > guidance on how best to take advantage of recent changes on master. I
>> > know that document hasn't been stagnant in any sense, but relatively
>> > "big in any case, I'd be happy to help make some updates in a PR if
>> > there's anything we come up with.
>> I've just skimmed through this page, and I don't think any of the
>> advice given there is outdated. What's new in master is that anonymous
>> functions (and therefore map) are now fast, but that wasn't previously
>> mentioned in the tips as a performance issue anyway.
>>
>> The only small sentence which should likely be removed is "for example,
>> currently it’s not possible to infer the return type of an anonymous
>> function". Type inference seems to work fine now on master with
>> anonymous functions. I'll leave others confirm this.
>>
>> Anyway, do you have any specific points in mind?
>>
>>
>> Regards
>>
>
>

[julia-users] Functions in defined immutables

[Jonathan Goldfarb]

I realize now I may have been misunderstanding 
http://docs.julialang.org/en/release-0.4/manual/performance-tips/#avoid-containers-with-abstract-type-parameters
 
for a long time... Is the recommendation there only related to 
parameterized types, or any user defined type? My specific question, in the 
latter case, is the following

Since Function is an abstract type 
after https://github.com/JuliaLang/julia/pull/13412#issuecomment-17529 
what is the recommended way to have e.g.
immutable J
  a::Function
  b::Function
end
be used in a performant way? Evidently, we should not form e.g. an 
Array{Function, 1}, but would using types like this in code give similarly 
poor performance?

Thanks,
Max

Re: [julia-users] Functions in defined immutables

[Jonathan Goldfarb]

Yes, that's the performance tip I meant. Thanks for your detailed response and 
reference to the issue; that sounds like a good way forward. I'll be looking 
forward to future developments
Regards,
-Max

> On Feb 28, 2016, at 7:26 PM, Yichao Yu  wrote:
> 
> On Sun, Feb 28, 2016 at 7:24 PM, Yichao Yu  wrote:
>> On Sun, Feb 28, 2016 at 6:49 PM, Jonathan Goldfarb  
>> wrote:
>>> I realize now I may have been misunderstanding
>>> http://docs.julialang.org/en/release-0.4/manual/performance-tips/#avoid-containers-with-abstract-type-parameters
> 
> Also note that the reference that's more related to your confusion is
> http://docs.julialang.org/en/release-0.4/manual/performance-tips/#declare-specific-types-for-fields-of-composite-types
> 
>>> for a long time... Is the recommendation there only related to parameterized
>>> types, or any user defined type? My specific question, in the latter case,
>>> is the following
>> 
>> It's about typed slot (i.e. container) in general and has nothing to
>> do with type parameters. using a `TypeA{AbstractType}` won't cause any
>> performance problem as long as you are not using the `AbstractType` as
>> one of the field type. OTOH, having a abstract type field will cause
>> any use of the field to be type unstable, no matter whether the type
>> is parametrized or not.
>> 
>>> 
>>> Since Function is an abstract type after
>>> https://github.com/JuliaLang/julia/pull/13412#issuecomment-17529 what is
>> 
>> The `Function` type is special in the sense that it is always
>> "abstract" since it never has the information for type inference when
>> you want to call the function. (If you are just passing functions
>> around without calling it then yes, `Function` was a leaftype and was
>> type stable)
>> 
>>> the recommended way to have e.g.
>>> immutable J
>>>  a::Function
>>>  b::Function
>>> end
>> 
>> If you want to specialized on the actual function called, use
>> 
>> ```
>> immutable J{F1,F2}
>>a::F1
>>b::F2
>> end
>> ```
>> 
>> Otherwise, keeping it like this shouldn't cause any performance issue
>> compare to 0.3 and 0.4 due to the reason mentioned above.
>> 
>>> be used in a performant way? Evidently, we should not form e.g. an
>>> Array{Function, 1}, but would using types like this in code give similarly
>>> poor performance?
>> 
>> See also my summary in https://github.com/JuliaLang/julia/issues/13984
>> 
>>> 
>>> Thanks,
>>> Max

[julia-users] Change in CLI behavior between v0.4 and v0.5?

[Jonathan Goldfarb]

I'm not sure how often this comes up, but I've found a difference in how 
the Julia CLI parses arguments between v0.4 and v0.5 on Linux and OSX
on v0.4:

julia -O -- script.jl

ERROR: could not open file /path/to/file/--

 in include at ./boot.jl:261

 in include_from_node1 at ./loading.jl:304

 in process_options at ./client.jl:280

 in _start at ./client.jl:378

on v0.5:

julia -O -- script.jl




Leaving out the "--" causes v0.5 to complain, but not v0.4. Is this a known 
issue? It looks like the cause might be that -O takes an argument on v0.5, 
but  it isn't clear that it _must_ be given an argument.
Regards,
-Max