Re: [julia-users] Memory allocation issue when using external packages in module

[Jan]

Thanks for the hint. That seems to be the reason!

I have a couple of follow up questions so that I learn more about Julia. 
Would be nice if someone takes a couple of minutes to educate me.

I found a simple example reproducing my issue:

module FooBar

# Including BlackBoxOptim causes type instability for exponents

using BlackBoxOptim

# Multiplying instead of exponentiating works fine, even when using 
BlackBoxOptim

f(a::Float64, b::Float64) = a^b

end

If I run @code_warntype with and without BlackBoxOptim for the code above, 
it is clear that it causes the type instability.

With BlackBoxOptim:

<https://lh3.googleusercontent.com/-nMINsUdVczQ/WACQBV0dbKI/AbM/tjGkVdRnZyokgT437RE36epcLaXko6zBgCLcB/s1600/type_instable.PNG>


Without BlackBoxOptim:


<https://lh3.googleusercontent.com/-22PONOOPYAk/WACQIi_fZOI/AbQ/WHDojaNHKPk-6u3fmeIOERTntO74eo0jQCLcB/s1600/type_stable.PNG>


For my real code, the @code_warntype macro produces identical results 
whether I use BlackBoxOptim or not even though one is type unstable.

*Question 1 + related ones :) :* Is there an alternative way to check type 
instability which is more detailed but still halfway easily readable? Would 
it be possible to detect the issue with @code_llvm or similar? I tried to 
write @code_llvm to a file since the output is very long, but never 
succeeded. Is this possible?

*Question 2:* When the issue 18465 is fixed, will that end up in Julia 
0.5.1 or is a fixed version available already before that somewhere?

Many thanks for any help. I really like to work with Julia so some input 
would be highly appreciated.

Jan

[julia-users] Memory allocation issue when using external packages in module

[Jan]

Hi!

I´ve tried to reduce my problem to a smaller one, but I didn´t succeed. 
However, I hope someone can help me even though the problem description is 
a bit long and involves github. To summerize my problem: when I include one 
external package (BlackBoxOptim) in my module one of my functions starts to 
allocate much more memory than when omitting BlackBoxOptim.

I´ve started to develop a small package for hydrological modelling:

https://github.com/jmgnve/Vann

I use a couple of other packages in my module (BlackBoxOptim and 
Distributions). I have simply added them like this:

module Vann

using BlackBoxOptim
using Distributions

other stuff

end

I have one function in my package called "hydro_model" which I test using 
this script:

https://github.com/jmgnve/Vann/blob/master/test/hbv_tests.jl

The function allocates this much memory:

<https://lh3.googleusercontent.com/-5aRvVXgsgLU/V_-kavMciVI/Aa0/yU8HOY3FPzYIu9faz4Fd6Ehh_mdqNymYwCLcB/s1600/much_memory.PNG>


If I do not include the BlackBoxOptim package in my main module (Vann.jl), 
the same function call allocates this much memory:


<https://lh3.googleusercontent.com/-bcrxgXn4310/V_-l8SKE9fI/Aa8/ExxY7PSGP-cJyeyXZUmE86vr5Koi_KbhACLcB/s1600/little_memory.PNG>


The "hydro_model"-function does not use any of the BlackBoxOptim stuff, at 
least not intentionally. The "hydro_model"-function is stored here:


https://github.com/jmgnve/Vann/blob/master/src/hydro_hbv.jl


Perhaps someone directly spots the issue. Am I using some name in the 
"hydro_model"-function that also exist in the BlackBoxOptim package? How 
can I analyze these kind of memory problems efficiently? The output from 
@profile is hard to understand.


Thanks for any help.
Jan


*Version info:*


*Julia Version 0.5.0*

*Commit 3c9d753 (2016-09-19 18:14 UTC)*

*Platform Info:*

*  System: NT (x86_64-w64-mingw32)*

*  CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz*

*  WORD_SIZE: 64*

*  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH N*

*  LAPACK: libopenblas64_*

*  LIBM: libopenlibm*

*  LLVM: libLLVM-3.7.1 (ORCJIT, sandybridge)*

[julia-users] Re: Does Julia always need internet access when loading a package?

[Jan Hlavacek]

On Wednesday, August 17, 2016 at 12:37:58 AM UTC-4, Andreas Lobinger wrote:
>
>
> http://docs.julialang.org/en/release-0.4/stdlib/pkg/#Base.Pkg.dir 
>
> For improving the documentation it would be interesting, what information 
> you (or your admin, the 'they') had used for the setup.
>

One thing that is not clear to me is: what happens when I have several 
package directories:  a readonly global one where only root can install new 
packages, and a local user one where the user can install.  Which one 
should Pkg.dir() return?  How will Julia know about the other one? 

I know now about Base.LOAD_PATH and Base.LOAD_CACHE_PATH, and know that 
each of them can have  multiple paths in them.  Their contents does not 
seem to have any effect at all on Pkg.dir(), though.

Is it possible to have some packages in a system wide global directory, say 
/usr/local/share/julia/site/... and some user installed packages in a user 
directory, say ~/.julia/...?  How would such setup be achieved?

[julia-users] What exactly triggers a package recompile?

[Jan Hlavacek]

I am working on a system that has a number of packages installed system 
wide in /usr/local/share/julia/site/.  The problem is, when trying to load 
a package, Julia tries to recompile it, and cannot do so since 
/usr/local/share/julia/site/lib/v0.4/ 
is not writable. I would not expect the recompile, since the cached ji 
files should have the same version as the installed jl files, so as far as 
I can tell, no recompilation should be necessary.  I am trying to figure 
out if there is any version mismatch, or if there is any other reason for 
the recompile.  Also, is there any way to find out the version of an 
installed package and the version of the cache?

[julia-users] Re: Does Julia always need internet access when loading a package?

[Jan Hlavacek]

On Wednesday, August 17, 2016 at 12:37:58 AM UTC-4, Andreas Lobinger wrote:
>
>
> http://docs.julialang.org/en/release-0.4/stdlib/pkg/#Base.Pkg.dir 
>
> For improving the documentation it would be interesting, what information 
> you (or your admin, the 'they') had used for the setup.
>
>
The documentation seems good, it seems that the problem was caused by 
missing JULIA_PKGDIR environment variable.  Thanks for your help! 

[julia-users] Re: Does Julia always need internet access when loading a package?

[Jan Hlavacek]

On Tuesday, August 16, 2016 at 3:26:44 PM UTC-4, Andreas Lobinger wrote:
>
> Hello colleague,
>
> Looks like the local julia installation has identified a missing package 
> repository and then tried to get METADATA into that. The place where julia 
> expects a package repository can be configured. In your case the setup was 
> incorrect.
>
>
Thank you.  Would you be able to provide some pointers to documents that 
describe what the correct setup should be?  When I was trying to find that 
information on the web I got what seemed to me like conflicting pieces of 
information.

[julia-users] Does Julia always need internet access when loading a package?

[Jan Hlavacek]

I am trying to use Julia on SageMathCloud.  They have recently installed a 
whole bunch of packages system wide, so that they are available in all 
projects without having to install them locally.  However, when I try to 
use a package from one of their free projects, there is a problem. Free 
projects by default do not have internet access.  When loading a Julia 
package, for example 

using Gadfly

the package will be recompiled, and then Julia tries to go to github and 
download METADATA.jl,  which takes for ever before it times out.  Then, 
probably because of the missing metadata, some other errors are reported.  
Finally, the package gets loaded and can be used.  The messages are as 
follows:


INFO: Precompiling module Gadfly...
INFO: Initializing package repository 
/projects/41eb44d2-462c-4af8-80a5-ac0c9cad99dd/.julia/v0.4
INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
fatal: unable to connect to github.com:
github.com[0: 192.30.253.112]: errno=Connection timed out

INFO: Initializing package repository 
/projects/41eb44d2-462c-4af8-80a5-ac0c9cad99dd/.julia/v0.4
INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
fatal: unable to connect to github.com:
github.com[0: 192.30.253.112]: errno=Connection timed out

WARNING: could not import LinAlg._chol! into FixedSizeArrays
WARNING: New definition 
+(AbstractArray{T<:Any, 2}, WoodburyMatrices.SymWoodbury) at 
/usr/local/share/julia/site/v0.4/WoodburyMatrices/src/SymWoodburyMatrices.jl:106
is ambiguous with: 
+(DataArrays.DataArray, AbstractArray) at 
/usr/local/share/julia/site/v0.4/DataArrays/src/operators.jl:276.
To fix, define 
+(DataArrays.DataArray{T<:Any, 2}, WoodburyMatrices.SymWoodbury)
before the new definition.
WARNING: New definition 
+(AbstractArray{T<:Any, 2}, WoodburyMatrices.SymWoodbury) at 
/usr/local/share/julia/site/v0.4/WoodburyMatrices/src/SymWoodburyMatrices.jl:106
is ambiguous with: 
+(DataArrays.AbstractDataArray, AbstractArray) at 
/usr/local/share/julia/site/v0.4/DataArrays/src/operators.jl:300.
To fix, define 
+(DataArrays.AbstractDataArray{T<:Any, 2}, WoodburyMatrices.SymWoodbury)
before the new definition.
WARNING: New definition 
+(AbstractArray{T<:Any, 2}, WoodburyMatrices.SymWoodbury) at 
/usr/local/share/julia/site/v0.4/WoodburyMatrices/src/SymWoodburyMatrices.jl:106
is ambiguous with: 
+(DataArrays.DataArray, AbstractArray) at 
/usr/local/share/julia/site/v0.4/DataArrays/src/operators.jl:276.
To fix, define 
+(DataArrays.DataArray{T<:Any, 2}, WoodburyMatrices.SymWoodbury)
before the new definition.
WARNING: New definition 
+(AbstractArray{T<:Any, 2}, WoodburyMatrices.SymWoodbury) at 
/usr/local/share/julia/site/v0.4/WoodburyMatrices/src/SymWoodburyMatrices.jl:106
is ambiguous with: 
+(DataArrays.AbstractDataArray, AbstractArray) at 
/usr/local/share/julia/site/v0.4/DataArrays/src/operators.jl:300.
To fix, define 
+(DataArrays.AbstractDataArray{T<:Any, 2}, WoodburyMatrices.SymWoodbury)
before the new definition.

 
Does Julia really need internet access just to load a package?  Is there 
any way to work around it?

[julia-users] Arrays of user defined types, indexing and copying.

[Jan]

I have a beginner question for which I cannot find the answer after quite 
some searching. 


type MyType
  a::Array{Float64,1}
end

# Fill an array with "independent" instances of MyType. (By the way, is 
there a shorter way to do this?)

MyType_Vec = Array(MyType, 3);

for i in eachindex(MyType_Vec)

  MyType_Vec[i] = MyType([0.0]);
 
end

MyType_Vec

# Change the value of MyType_Vec[1].a[1] to 2.

MyType_Vec[1].a[1] = 2;

MyType_Vec

# Shuffle the vector but with repeated elements

MyType_Vec = MyType_Vec[[1,3,1]];

# Change the value of MyType_Vec[1].a[1] to 4.

MyType_Vec[1].a[1] = 4;

MyType_Vec

# The value of MyType_Vec[3].a[1] also changed to 4.


How can I avoid this reference behaviour? I want that, after the shuffling 
step, the 3 elements of MyType_Vec should be "independent" so that if I 
change MyType_Vec[1].a[1] nothing else is affected. I have tried copy and 
deepcopy without success.

I would be very happy if someone could help me out. I'm stuck...

Many thanks in advance.

[julia-users] Re: Cxx.jl: Creating a templated class

[Jan Strube]

Edit: The cxx line is not valid C++.
   cxx"""UTIL::CellIDDecoder($(collection.coll)) x;
should of course read:
   cxx"""UTIL::CellIDDecoder x($(collection.coll));

Nevertheless, the icxx call seems valid, so I still don't understand why 
this isn't working.
Any insight is greatly appreciated.

On Monday, July 4, 2016 at 10:09:34 PM UTC-7, Jan Strube wrote:
>
> What's the right way to create a templated class on the C++ side with Cxx?
>
> I have an LCCollection 
> <http://lcio.desy.de/v02-07/doc/doxygen_api/html/classEVENT_1_1LCCollection.html>,
>  
> and I would like to create a CellIDDecoder 
> <http://lcio.desy.de/v02-07/doc/doxygen_api/html/classUTIL_1_1CellIDDecoder.html>,
>  
> which needs a template argument.
>
> A simple 
>cxx"""UTIL::CellIDDecoder($(collection.coll)) x;
>   std::cout << x << std::endl;
> results in 
>
> ERROR: LoadError: Creating LLVM constants for type `T` not implemented yet
>  in llvmconst(::Any) at /home/stru821/.julia/v0.5/Cxx/src/cxxstr.jl:22
>  in ArgCleanup(::Cxx.ClangCompiler, ::Cxx.CppPtr{Cxx.CxxQualType{Cxx.
> CppBaseType{Symbol("EVENT::LCCollection")},(false,false,false)},(false,
> false,false)}, ::Cxx.CppPtr{Cxx.CxxQualType{Cxx.CppBaseType{Symbol(
> "clang::VarDecl")},(false,false,false)},(false,false,false)}) at /home/
> stru821/.julia/v0.5/Cxx/src/cxxstr.jl:192
>  in macro expansion at /home/stru821/.julia/v0.5/Cxx/src/cxxstr.jl:634 [
> inlined]
>  in getCellIDDecoder(::LCIO.LCCollection{Cxx.CppPtr{Cxx.CxxQualType{Cxx.
> CppBaseType{Symbol("EVENT::SimCalorimeterHit")},(false,false,false)},(
> false,false,false)}}) at /home/stru821/.julia/v0.5/LCIO/src/CaloHit.jl:29
>  in testReader(::String) at /home/stru821/.julia/v0.5/LCIO/examples/
> testLCIOCxx.jl:14
>  in include_from_node1(::String) at ./loading.jl:426
>  in process_options(::Base.JLOptions) at ./client.jl:266
>  in _start() at ./client.jl:322
> while loading /home/stru821/.julia/v0.5/LCIO/examples/testLCIOCxx.jl, in 
> expression starting on line 22
>
> I have also tried to return the result of 
> icxx"""UTIL::CellIDDecoder($(collection.coll));
>
> But that replies with an even stranger message:
> :2:45: error: no matching constructor for initialization of 
> 'UTIL::CellIDDecoder'
> UTIL::CellIDDecoder < SimCalorimeterHit > ( __juliavar1 ) ;
> ^
> /scratch/software/lcio-test/include/UTIL/CellIDDecoder.h:36:3: note: 
> candidate constructor not viable: requires single argument 'encoder_str', 
> but no arguments were provided
>   CellIDDecoder( const std::string& encoder_str ) : _oldHit(0) {
>   ^
> /scratch/software/lcio-test/include/UTIL/CellIDDecoder.h:47:5: note: 
> candidate constructor not viable: requires single argument 'col', but no 
> arguments were provided
> CellIDDecoder( const EVENT::LCCollection* col ) : _oldHit(0) {
> ^
>
> The code clearly has a constructor argument, so I don't understand why the 
> compiler things it doesn't...
>
> If somebody knows how to construct such a templated class, please share.
> Many thanks.
>

[julia-users] Re: Cxx.jl: Creating a templated class

[Jan Strube]

Is this in any way related to https://github.com/Keno/Cxx.jl/issues/212 ?
Any pointer what this means?
ERROR: LoadError: Creating LLVM constants for type `T` not implemented yet


On Monday, July 4, 2016 at 10:09:34 PM UTC-7, Jan Strube wrote:
>
> What's the right way to create a templated class on the C++ side with Cxx?
>
> I have an LCCollection 
> <http://lcio.desy.de/v02-07/doc/doxygen_api/html/classEVENT_1_1LCCollection.html>,
>  
> and I would like to create a CellIDDecoder 
> <http://lcio.desy.de/v02-07/doc/doxygen_api/html/classUTIL_1_1CellIDDecoder.html>,
>  
> which needs a template argument.
>
> A simple 
>cxx"""UTIL::CellIDDecoder($(collection.coll)) x;
>   std::cout << x << std::endl;
> results in 
>
> ERROR: LoadError: Creating LLVM constants for type `T` not implemented yet
>  in llvmconst(::Any) at /home/stru821/.julia/v0.5/Cxx/src/cxxstr.jl:22
>  in ArgCleanup(::Cxx.ClangCompiler, ::Cxx.CppPtr{Cxx.CxxQualType{Cxx.
> CppBaseType{Symbol("EVENT::LCCollection")},(false,false,false)},(false,
> false,false)}, ::Cxx.CppPtr{Cxx.CxxQualType{Cxx.CppBaseType{Symbol(
> "clang::VarDecl")},(false,false,false)},(false,false,false)}) at /home/
> stru821/.julia/v0.5/Cxx/src/cxxstr.jl:192
>  in macro expansion at /home/stru821/.julia/v0.5/Cxx/src/cxxstr.jl:634 [
> inlined]
>  in getCellIDDecoder(::LCIO.LCCollection{Cxx.CppPtr{Cxx.CxxQualType{Cxx.
> CppBaseType{Symbol("EVENT::SimCalorimeterHit")},(false,false,false)},(
> false,false,false)}}) at /home/stru821/.julia/v0.5/LCIO/src/CaloHit.jl:29
>  in testReader(::String) at /home/stru821/.julia/v0.5/LCIO/examples/
> testLCIOCxx.jl:14
>  in include_from_node1(::String) at ./loading.jl:426
>  in process_options(::Base.JLOptions) at ./client.jl:266
>  in _start() at ./client.jl:322
> while loading /home/stru821/.julia/v0.5/LCIO/examples/testLCIOCxx.jl, in 
> expression starting on line 22
>
> I have also tried to return the result of 
> icxx"""UTIL::CellIDDecoder($(collection.coll));
>
> But that replies with an even stranger message:
> :2:45: error: no matching constructor for initialization of 
> 'UTIL::CellIDDecoder'
> UTIL::CellIDDecoder < SimCalorimeterHit > ( __juliavar1 ) ;
> ^
> /scratch/software/lcio-test/include/UTIL/CellIDDecoder.h:36:3: note: 
> candidate constructor not viable: requires single argument 'encoder_str', 
> but no arguments were provided
>   CellIDDecoder( const std::string& encoder_str ) : _oldHit(0) {
>   ^
> /scratch/software/lcio-test/include/UTIL/CellIDDecoder.h:47:5: note: 
> candidate constructor not viable: requires single argument 'col', but no 
> arguments were provided
> CellIDDecoder( const EVENT::LCCollection* col ) : _oldHit(0) {
> ^
>
> The code clearly has a constructor argument, so I don't understand why the 
> compiler things it doesn't...
>
> If somebody knows how to construct such a templated class, please share.
> Many thanks.
>

[julia-users] Re: Cxx.jl: Creating a templated class

[Jan Strube]

things --> thinks... Obviously, I didn't

On Monday, July 4, 2016 at 10:09:34 PM UTC-7, Jan Strube wrote:
>
> What's the right way to create a templated class on the C++ side with Cxx?
>
> I have an LCCollection 
> <http://lcio.desy.de/v02-07/doc/doxygen_api/html/classEVENT_1_1LCCollection.html>,
>  
> and I would like to create a CellIDDecoder 
> <http://lcio.desy.de/v02-07/doc/doxygen_api/html/classUTIL_1_1CellIDDecoder.html>,
>  
> which needs a template argument.
>
> A simple 
>cxx"""UTIL::CellIDDecoder($(collection.coll)) x;
>   std::cout << x << std::endl;
> results in 
>
> ERROR: LoadError: Creating LLVM constants for type `T` not implemented yet
>  in llvmconst(::Any) at /home/stru821/.julia/v0.5/Cxx/src/cxxstr.jl:22
>  in ArgCleanup(::Cxx.ClangCompiler, ::Cxx.CppPtr{Cxx.CxxQualType{Cxx.
> CppBaseType{Symbol("EVENT::LCCollection")},(false,false,false)},(false,
> false,false)}, ::Cxx.CppPtr{Cxx.CxxQualType{Cxx.CppBaseType{Symbol(
> "clang::VarDecl")},(false,false,false)},(false,false,false)}) at /home/
> stru821/.julia/v0.5/Cxx/src/cxxstr.jl:192
>  in macro expansion at /home/stru821/.julia/v0.5/Cxx/src/cxxstr.jl:634 [
> inlined]
>  in getCellIDDecoder(::LCIO.LCCollection{Cxx.CppPtr{Cxx.CxxQualType{Cxx.
> CppBaseType{Symbol("EVENT::SimCalorimeterHit")},(false,false,false)},(
> false,false,false)}}) at /home/stru821/.julia/v0.5/LCIO/src/CaloHit.jl:29
>  in testReader(::String) at /home/stru821/.julia/v0.5/LCIO/examples/
> testLCIOCxx.jl:14
>  in include_from_node1(::String) at ./loading.jl:426
>  in process_options(::Base.JLOptions) at ./client.jl:266
>  in _start() at ./client.jl:322
> while loading /home/stru821/.julia/v0.5/LCIO/examples/testLCIOCxx.jl, in 
> expression starting on line 22
>
> I have also tried to return the result of 
> icxx"""UTIL::CellIDDecoder($(collection.coll));
>
> But that replies with an even stranger message:
> :2:45: error: no matching constructor for initialization of 
> 'UTIL::CellIDDecoder'
> UTIL::CellIDDecoder < SimCalorimeterHit > ( __juliavar1 ) ;
> ^
> /scratch/software/lcio-test/include/UTIL/CellIDDecoder.h:36:3: note: 
> candidate constructor not viable: requires single argument 'encoder_str', 
> but no arguments were provided
>   CellIDDecoder( const std::string& encoder_str ) : _oldHit(0) {
>   ^
> /scratch/software/lcio-test/include/UTIL/CellIDDecoder.h:47:5: note: 
> candidate constructor not viable: requires single argument 'col', but no 
> arguments were provided
> CellIDDecoder( const EVENT::LCCollection* col ) : _oldHit(0) {
> ^
>
> The code clearly has a constructor argument, so I don't understand why the 
> compiler things it doesn't...
>
> If somebody knows how to construct such a templated class, please share.
> Many thanks.
>

[julia-users] Cxx.jl: Creating a templated class

[Jan Strube]

What's the right way to create a templated class on the C++ side with Cxx?

I have an LCCollection 
,
 
and I would like to create a CellIDDecoder 
,
 
which needs a template argument.

A simple 
   cxx"""UTIL::CellIDDecoder($(collection.coll)) x;
  std::cout << x << std::endl;
results in 

ERROR: LoadError: Creating LLVM constants for type `T` not implemented yet
 in llvmconst(::Any) at /home/stru821/.julia/v0.5/Cxx/src/cxxstr.jl:22
 in ArgCleanup(::Cxx.ClangCompiler, ::Cxx.CppPtr{Cxx.CxxQualType{Cxx.
CppBaseType{Symbol("EVENT::LCCollection")},(false,false,false)},(false,false
,false)}, ::Cxx.CppPtr{Cxx.CxxQualType{Cxx.CppBaseType{Symbol(
"clang::VarDecl")},(false,false,false)},(false,false,false)}) at /home/
stru821/.julia/v0.5/Cxx/src/cxxstr.jl:192
 in macro expansion at /home/stru821/.julia/v0.5/Cxx/src/cxxstr.jl:634 [
inlined]
 in getCellIDDecoder(::LCIO.LCCollection{Cxx.CppPtr{Cxx.CxxQualType{Cxx.
CppBaseType{Symbol("EVENT::SimCalorimeterHit")},(false,false,false)},(false,
false,false)}}) at /home/stru821/.julia/v0.5/LCIO/src/CaloHit.jl:29
 in testReader(::String) at /home/stru821/.julia/v0.5/LCIO/examples/
testLCIOCxx.jl:14
 in include_from_node1(::String) at ./loading.jl:426
 in process_options(::Base.JLOptions) at ./client.jl:266
 in _start() at ./client.jl:322
while loading /home/stru821/.julia/v0.5/LCIO/examples/testLCIOCxx.jl, in 
expression starting on line 22

I have also tried to return the result of 
icxx"""UTIL::CellIDDecoder($(collection.coll));

But that replies with an even stranger message:
:2:45: error: no matching constructor for initialization of 
'UTIL::CellIDDecoder'
UTIL::CellIDDecoder < SimCalorimeterHit > ( __juliavar1 ) ;
^
/scratch/software/lcio-test/include/UTIL/CellIDDecoder.h:36:3: note: 
candidate constructor not viable: requires single argument 'encoder_str', 
but no arguments were provided
  CellIDDecoder( const std::string& encoder_str ) : _oldHit(0) {
  ^
/scratch/software/lcio-test/include/UTIL/CellIDDecoder.h:47:5: note: 
candidate constructor not viable: requires single argument 'col', but no 
arguments were provided
CellIDDecoder( const EVENT::LCCollection* col ) : _oldHit(0) {
^

The code clearly has a constructor argument, so I don't understand why the 
compiler things it doesn't...

If somebody knows how to construct such a templated class, please share.
Many thanks.

[julia-users] Re: Any up-to-date Julia package for nonlinear regression?

[Jan Drugowitsch]

Thanks, this is what I was looking for. I didn't know that it went into 
LsqFit.jl once it was separated out from Optim.jl.

Thanks,
Jan

On Friday, 27 May 2016 03:29:43 UTC-4, Josef Heinen wrote:
>
> What about LsqFit? Here is an example for a similar model (Lorentz fit):
>
> using LsqFit
>
> x = -16:0.5:35
> y = 19.4./((x - 7).^2 + 15.8) + randn(size(x))./10;  
>
> model(x, p) = p[1]./((x-p[2]).^2+p[3]) 
>
> fit = curve_fit(model, x, y, [25.,10.,10.]) 
> p = fit.param 
> f = p[1]./((x-p[2]).^2+p[3]) 
>
> using GR 
> plot(x, y, "d", x, f, "-", linewidth=2)
>
>
> ... and the result:
>
>
>
> <https://lh3.googleusercontent.com/-5ur05FWaa4k/V0f3PEe0kFI/ACo/z9wRKvLomWQAEM-8IPXTBxOLTk9AKSGvQCLcB/s1600/lorentzfit.png>
>
>
>
> On Friday, May 27, 2016 at 12:18:16 AM UTC+2, Jan Drugowitsch wrote:
>>
>> Hi all,
>>
>> I have some nonlinear regression problems that I'd like to solve. 
>> Unfortunately, NLreg.jl doesn't seem to work on my Julia 0.4.5 
>> installation, but instead fails on the README example code with
>>
>> julia> const sd1 = readtable(Pkg.dir("NLreg","data","sd1.csv.gz"));
>>
>>
>> julia> nl = fit(BolusSD1(CONC ~ TIME, sd1))
>> WARNING: [a,b] concatenation is deprecated; use [a;b] instead
>>  in depwarn at deprecated.jl:73
>>  in oldstyle_vcat_warning at /Applications/Julia-0.4.5.app/Contents/
>> Resources/julia/lib/julia/sys.dylib
>>  in call at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:119
>>  in fit at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:204
>> while loading no file, in expression starting on line 0
>> ERROR: type Array has no field data
>>  in gpinc at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:143
>>  in gpfit at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:159
>>  in fit at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:204
>>
>>
>> In general, NLreg.jl hasn't been updated since 2014. Are there any more 
>> up-to-date Julia packages for nonlinear regression?
>>
>> I know that I could always use optimizers, but then I won't get all the 
>> extra statistics that I would need.
>>
>> Thanks,
>> Jan
>>
>

Re: [julia-users] Any up-to-date Julia package for nonlinear regression?

[Jan Drugowitsch]

I'm looking for statistical rather than machine learning packages, in the 
sense that I'd need standard errors and covariates of the regressors, and 
various other standard statistics (similar to GLMs). The model I'm looking 
at is fairly simple, and almost a GLM:

p(y = 1 | x) = (1-pl) Phi((x - mu)/sig) + pl pb

where Phi is the standard cumulative Gaussian. I want to fit the above by 
least squares regression. I could code the whole thing myself, but as 
nonlinear regression is such a standard problem, I was wondering if a 
package exists that saves me from having to do so.

Thanks,
Jan

On Thursday, 26 May 2016 18:44:09 UTC-4, Tom Breloff wrote:
>
> There's lots of potential options. Can you specify your problem a little 
> more? What type of data? How non-linear? Are we fitting a polynomial? SVM? 
> ANN? Online vs batch? How much noise? What sort of stats do you want?
>
> On Thursday, May 26, 2016, Jan Drugowitsch <jdr...@gmail.com > 
> wrote:
>
>> Hi all,
>>
>> I have some nonlinear regression problems that I'd like to solve. 
>> Unfortunately, NLreg.jl doesn't seem to work on my Julia 0.4.5 
>> installation, but instead fails on the README example code with
>>
>> julia> const sd1 = readtable(Pkg.dir("NLreg","data","sd1.csv.gz"));
>>
>>
>> julia> nl = fit(BolusSD1(CONC ~ TIME, sd1))
>> WARNING: [a,b] concatenation is deprecated; use [a;b] instead
>>  in depwarn at deprecated.jl:73
>>  in oldstyle_vcat_warning at /Applications/Julia-0.4.5.app/Contents/
>> Resources/julia/lib/julia/sys.dylib
>>  in call at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:119
>>  in fit at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:204
>> while loading no file, in expression starting on line 0
>> ERROR: type Array has no field data
>>  in gpinc at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:143
>>  in gpfit at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:159
>>  in fit at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:204
>>
>>
>> In general, NLreg.jl hasn't been updated since 2014. Are there any more 
>> up-to-date Julia packages for nonlinear regression?
>>
>> I know that I could always use optimizers, but then I won't get all the 
>> extra statistics that I would need.
>>
>> Thanks,
>> Jan
>>
>

[julia-users] Any up-to-date Julia package for nonlinear regression?

[Jan Drugowitsch]

Hi all,

I have some nonlinear regression problems that I'd like to solve. 
Unfortunately, NLreg.jl doesn't seem to work on my Julia 0.4.5 
installation, but instead fails on the README example code with

julia> const sd1 = readtable(Pkg.dir("NLreg","data","sd1.csv.gz"));


julia> nl = fit(BolusSD1(CONC ~ TIME, sd1))
WARNING: [a,b] concatenation is deprecated; use [a;b] instead
 in depwarn at deprecated.jl:73
 in oldstyle_vcat_warning at /Applications/Julia-0.4.5.app/Contents/
Resources/julia/lib/julia/sys.dylib
 in call at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:119
 in fit at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:204
while loading no file, in expression starting on line 0
ERROR: type Array has no field data
 in gpinc at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:143
 in gpfit at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:159
 in fit at /Users/jandrugowitsch/.julia/v0.4/NLreg/src/plreg.jl:204


In general, NLreg.jl hasn't been updated since 2014. Are there any more 
up-to-date Julia packages for nonlinear regression?

I know that I could always use optimizers, but then I won't get all the 
extra statistics that I would need.

Thanks,
Jan

Re: [julia-users] Stumbling on first steps with Cxx

[Jan Strube]

Hi Keno,

Got it, thanks. I can work with that.

Cheers,
Jan


On Wednesday, May 25, 2016 at 6:37:51 PM UTC-7, Keno Fischer wrote:
>
> Hi Jan,
>
> first of, I recommend using the string macros icxx and cxx over the @cxx 
> syntax. That should make it a lot clearer what's happening. To answer your 
> question,
>
> @cxx reader, is the equivalent of icxx"reader;",
> however @cxx reader->stuff is the equivalent of icxx"$reader->stuff", so 
> reader is searched for in julia scope rather than C++ scope. Hope that 
> makes sense.
>
> Keno
>
> On Wed, May 25, 2016 at 7:54 PM, Jan Strube <jan.s...@gmail.com 
> > wrote:
>
>> I've created a rudimentary set of bindings to the LCIO file format 
>> <http://lcio.desy.de/v02-07/doc/>.
>> It's an event data model and file format for detector and physics studies 
>> of future linear collider concepts.
>> The code is over on github https://github.com/jstrube/LCIO.jl
>> The purpose of this post isn't to announce this code, however, since at 
>> the moment it's rather fugly and jumping through extern "C" {} stubs.
>>
>> I would like to improve the usability a little and thought that Cxx.jl 
>> could help with that, but I'm struggling with the first steps.
>> I have Cxx installed, but I'm confused about how to use it.
>> I'm using the following to set it up.
>>
>> using Cxx
>> addHeaderDir(joinpath(ENV["LCIO"], "include"), kind=C_User)
>> Libdl.dlopen(joinpath(ENV["LCIO"], "lib", "liblcio.so.2.7.1"), 
>> Libdl.RTLD_GLOBAL)
>> cxxinclude("lcio.h")
>> cxxinclude("IO/LCReader.h")
>> cxxinclude("IOIMPL/LCFactory.h")
>> cxx"IO::LCReader* reader = 
>> IOIMPL::LCFactory::getInstance()->createLCReader();"
>>
>> This works fine.
>> However, I would prefer this as the last line instead:
>> reader = @cxx IOIMPL::LCFactory::getInstance()->createLCReader()
>>
>> Unfortunately, this gives me "IOIMPL not defined."
>> Similarly, 
>> julia> @cxx reader
>> (class IO::LCReader *) @0x02fb0b70
>>
>> julia> @cxx reader->open(pointer("gev250ee_higgs_ZZ_001_tracking.slcio"))
>> ERROR: UndefVarError: reader not defined
>>  in eval(::Module, ::Any) at ./boot.jl:225
>>  in macro expansion at ./REPL.jl:92 [inlined]
>>  in (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:46
>>
>> So "reader" is found and has the right type, but when trying to access 
>> member functions, it's no longer found???
>> I'd file a bug report, but I'm not at all sure I'm actually using this 
>> correctly.
>>
>> If you can think of a reason why this behavior is expected, and what I 
>> could do to remedy, please let me know.
>>
>>
>

[julia-users] Stumbling on first steps with Cxx

[Jan Strube]

I've created a rudimentary set of bindings to the LCIO file format 
.
It's an event data model and file format for detector and physics studies 
of future linear collider concepts.
The code is over on github https://github.com/jstrube/LCIO.jl
The purpose of this post isn't to announce this code, however, since at the 
moment it's rather fugly and jumping through extern "C" {} stubs.

I would like to improve the usability a little and thought that Cxx.jl 
could help with that, but I'm struggling with the first steps.
I have Cxx installed, but I'm confused about how to use it.
I'm using the following to set it up.

using Cxx
addHeaderDir(joinpath(ENV["LCIO"], "include"), kind=C_User)
Libdl.dlopen(joinpath(ENV["LCIO"], "lib", "liblcio.so.2.7.1"), 
Libdl.RTLD_GLOBAL)
cxxinclude("lcio.h")
cxxinclude("IO/LCReader.h")
cxxinclude("IOIMPL/LCFactory.h")
cxx"IO::LCReader* reader = 
IOIMPL::LCFactory::getInstance()->createLCReader();"

This works fine.
However, I would prefer this as the last line instead:
reader = @cxx IOIMPL::LCFactory::getInstance()->createLCReader()

Unfortunately, this gives me "IOIMPL not defined."
Similarly, 
julia> @cxx reader
(class IO::LCReader *) @0x02fb0b70

julia> @cxx reader->open(pointer("gev250ee_higgs_ZZ_001_tracking.slcio"))
ERROR: UndefVarError: reader not defined
 in eval(::Module, ::Any) at ./boot.jl:225
 in macro expansion at ./REPL.jl:92 [inlined]
 in (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:46

So "reader" is found and has the right type, but when trying to access 
member functions, it's no longer found???
I'd file a bug report, but I'm not at all sure I'm actually using this 
correctly.

If you can think of a reason why this behavior is expected, and what I 
could do to remedy, please let me know.

Re: [julia-users] compiling with Intel compiler fails

[Jan Strube]

Keno,

Thanks. The command you suggested doesn't quite work. It's -libuv, not -uv.

I was on a new clone. Ran 'make -C deps distclean-libuv'  anyway, but no 
go. 
Neither on release-0.4 nor on master.

However, your comment made me look further.
Somewhere the variables aren't set properly in the Makefile.
'CC=icc make' does indeed work, but the resulting libuv still has a gcc 
dependency. Not sure yet if that causes a problem.

$ ldd julia 

linux-vdso.so.1 =>  (0x7fff4eb61000)

libjulia.so => not found

libdl.so.2 => /lib64/libdl.so.2 (0x7f9545f31000)

librt.so.1 => /lib64/librt.so.1 (0x7f9545d29000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x7f9545b0d000)

libm.so.6 => /lib64/libm.so.6 (0x7f954580a000)

libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f9545503000)

libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f95452ed000)

libc.so.6 => /lib64/libc.so.6 (0x7f9544f2b000)

/lib64/ld-linux-x86-64.so.2 (0x7f9546143000)



On Wednesday, December 30, 2015 at 12:56:09 PM UTC-8, Keno Fischer wrote:
>
> Hi Jan,
>
> looks like Intel options are being passed to gcc. Perhaps your libuv 
> configuration is stale? You could try `make -C deps distclean-uv`
>
> Keno
>
> On Tue, Dec 29, 2015 at 11:02 PM, Jan Strube <jan.s...@gmail.com 
> > wrote:
>
>> I'm trying to install julia from source using the Intel compilers.
>>
>> icc --version
>>
>> icc (ICC) 16.0.1 20151021
>>
>> Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.
>>
>>
>> Unfortunately, I don't get very far :
>>
>>
>>   CC   src/unix/libuv_la-proctitle.lo
>>
>>   GEN  src/unix/uv-dtrace.o
>>
>> gcc: error: unrecognized command line option ‘-static-intel’
>>
>> "gcc /tmp/tmpKDA11o.c" failed
>>
>>
>> I'm on 'release-0.4'
>>
>> Has anybody else encountered this?
>>
>>
>>
>

Re: [julia-users] compiling with Intel compiler fails

[Jan Strube]

Sorry, should have mentioned I had followed the instructions on the github 
page and this in my Make.user

USEICC = 1

USEIFC = 1

USE_INTEL_MKL = 1

USE_INTEL_MKL_FFT = 1

USE_INTEL_LIBM = 1


Still needed the CC=icc for things to work.

On Friday, January 1, 2016 at 12:39:30 PM UTC-8, Keno Fischer wrote:
>
> You also need to set the USEICC Makefile variable.
>
> On Fri, Jan 1, 2016 at 9:35 PM, Jan Strube <jan.s...@gmail.com 
> > wrote:
>
>> Keno,
>>
>> Thanks. The command you suggested doesn't quite work. It's -libuv, not 
>> -uv.
>>
>> I was on a new clone. Ran 'make -C deps distclean-libuv'  anyway, but no 
>> go. 
>> Neither on release-0.4 nor on master.
>>
>> However, your comment made me look further.
>> Somewhere the variables aren't set properly in the Makefile.
>> 'CC=icc make' does indeed work, but the resulting libuv still has a gcc 
>> dependency. Not sure yet if that causes a problem.
>>
>> $ ldd julia 
>>
>> linux-vdso.so.1 =>  (0x7fff4eb61000)
>>
>> libjulia.so => not found
>>
>> libdl.so.2 => /lib64/libdl.so.2 (0x7f9545f31000)
>>
>> librt.so.1 => /lib64/librt.so.1 (0x7f9545d29000)
>>
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f9545b0d000)
>>
>> libm.so.6 => /lib64/libm.so.6 (0x7f954580a000)
>>
>> libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f9545503000)
>>
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f95452ed000)
>>
>> libc.so.6 => /lib64/libc.so.6 (0x7f9544f2b000)
>>
>> /lib64/ld-linux-x86-64.so.2 (0x7f9546143000)
>>
>>
>>
>> On Wednesday, December 30, 2015 at 12:56:09 PM UTC-8, Keno Fischer wrote:
>>>
>>> Hi Jan,
>>>
>>> looks like Intel options are being passed to gcc. Perhaps your libuv 
>>> configuration is stale? You could try `make -C deps distclean-uv`
>>>
>>> Keno
>>>
>>> On Tue, Dec 29, 2015 at 11:02 PM, Jan Strube <jan.s...@gmail.com> wrote:
>>>
>>>> I'm trying to install julia from source using the Intel compilers.
>>>>
>>>> icc --version
>>>>
>>>> icc (ICC) 16.0.1 20151021
>>>>
>>>> Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.
>>>>
>>>>
>>>> Unfortunately, I don't get very far :
>>>>
>>>>
>>>>   CC   src/unix/libuv_la-proctitle.lo
>>>>
>>>>   GEN  src/unix/uv-dtrace.o
>>>>
>>>> gcc: error: unrecognized command line option ‘-static-intel’
>>>>
>>>> "gcc /tmp/tmpKDA11o.c" failed
>>>>
>>>>
>>>> I'm on 'release-0.4'
>>>>
>>>> Has anybody else encountered this?
>>>>
>>>>
>>>>
>>>
>

[julia-users] Re: advent of code -- day 3

[Jan Strube]

Hmm interesting.
Thanks for all replies. That was very educational.


On Wednesday, December 16, 2015 at 3:33:32 PM UTC-8, ele...@gmail.com wrote:
>
>
>
> On Thursday, December 17, 2015 at 4:07:37 AM UTC+10, Josh Langsfeld wrote:
>>
>> Using mutables in a Set or as keys in a Dict is not necessarily bad; it's 
>> changing them after they've been inserted that causes the chaos. Your 1785 
>> "distinct" elements are all references to a single array object that is 
>> being continually mutated by the santa function.
>>
>> I'm not sure why there would be randomness in the number of elements, but 
>> would guess that something is being hashed on its memory location instead 
>> of its contents. I don't know what that would be though since hashes on 
>> arrays are a function of their values only.
>>
>
> The Set contains only references to the array values, not copies, thats 
> why mutating them after adding them to the set screws things up.  You can 
> see that by printing your resulting set, all the entries will have the same 
> value, the last one.  So any new value compared to the value of an entry 
> with == will always succeed, its comparing the same array after all. 
>  Therefore a value will only be added to the set if the hash of the new 
> value happens to fall on an empty slot in the underlying array, if it falls 
> on a used slot it will always compare equal and not be added.
>
> So the "randomness" depending on input just shows that hash is doing a 
> good job :)
>  
>
>>
>> On Wednesday, December 16, 2015 at 12:22:06 AM UTC-5, Jan Strube wrote:
>>>
>>> So now we have Tomas saying that two arrays are not equal, even though 
>>> their contents are equal.
>>> Kristoffer is saying that changing a mutable doesn't update the hash.
>>> It looks like these two effects are competing when inserting into a Set.
>>> In the game the input was 8192 directions.
>>> Of those 2592 were distinct - the result of the string solution.
>>> The version with arrays gave 1785 distinct elements in the Set.
>>>
>>> So sometimes, the hash definitely did get updated (most of the time in 
>>> fact).
>>> I'm fine with the lesson that using mutables in a Set (or Dict) is a bad 
>>> idea, but I'd still like to understand what's going on here. In fact, the 
>>> array solution is not reproducible on my machine. Two runs give two 
>>> different numbers.
>>> Where does this randomness come from?
>>>
>>>
>>>
>>> On Tuesday, December 15, 2015 at 1:09:54 PM UTC-8, Kristoffer Carlsson 
>>> wrote:
>>>>
>>>> The set is built as a number of key-value pairs of the hash and the 
>>>> object. When you modify the object the key that contains the hash does not 
>>>> get updated. A good reason not to put mutables in sets.
>>>>
>>>> On Tuesday, December 15, 2015 at 5:17:00 PM UTC+1, Josh Langsfeld wrote:
>>>>>
>>>>> I played with it a bit more and am seeing some unexpected behavior. If 
>>>>> you add a mutable element, change it, and then add another equal one, the 
>>>>> set gets two elements. But if you don't mutate the element, it stays at 
>>>>> one. 
>>>>>
>>>>> julia> s = Set{Vector{Int}}()
>>>>> Set{Array{Int64,1}}()
>>>>>
>>>>> julia> el = [1,2,3]; push!(s, el)
>>>>> Set([[1,2,3]])
>>>>>
>>>>> julia> push!(s, [1,2,3]) #Pushing a new array object, but the length 
>>>>> stays at 1.
>>>>> Set([[1,2,3]])
>>>>>
>>>>> julia> s = Set{Vector{Int}}()
>>>>> Set{Array{Int64,1}}()
>>>>>
>>>>> julia> el = [1,2,3]; push!(s, el)
>>>>> Set([[1,2,3]])
>>>>>
>>>>> julia> el[1] = 10; @show s; #Mutate the set element from the outside
>>>>> s = Set([[10,2,3]])
>>>>>
>>>>> julia> push!(s, [10,2,3])
>>>>> Set([[10,2,3],[10,2,3]])
>>>>>
>>>>> julia> length(s)
>>>>> 2
>>>>>
>>>>> julia> els = collect(s); els[1] == els[2]
>>>>> true
>>>>>
>>>>> Is something buggy going on here?
>>>>>
>>>>> On Tuesday, December 15, 2015 at 10:57:31 AM UTC-5, Josh Langsfeld 
>>>>> wrote:
>>>>>>
>>>>>> It's not array equality that's the issue here. Arrays with

[julia-users] Re: advent of code -- day 3

[Jan Strube]

So now we have Tomas saying that two arrays are not equal, even though 
their contents are equal.
Kristoffer is saying that changing a mutable doesn't update the hash.
It looks like these two effects are competing when inserting into a Set.
In the game the input was 8192 directions.
Of those 2592 were distinct - the result of the string solution.
The version with arrays gave 1785 distinct elements in the Set.

So sometimes, the hash definitely did get updated (most of the time in 
fact).
I'm fine with the lesson that using mutables in a Set (or Dict) is a bad 
idea, but I'd still like to understand what's going on here. In fact, the 
array solution is not reproducible on my machine. Two runs give two 
different numbers.
Where does this randomness come from?



On Tuesday, December 15, 2015 at 1:09:54 PM UTC-8, Kristoffer Carlsson 
wrote:
>
> The set is built as a number of key-value pairs of the hash and the 
> object. When you modify the object the key that contains the hash does not 
> get updated. A good reason not to put mutables in sets.
>
> On Tuesday, December 15, 2015 at 5:17:00 PM UTC+1, Josh Langsfeld wrote:
>>
>> I played with it a bit more and am seeing some unexpected behavior. If 
>> you add a mutable element, change it, and then add another equal one, the 
>> set gets two elements. But if you don't mutate the element, it stays at 
>> one. 
>>
>> julia> s = Set{Vector{Int}}()
>> Set{Array{Int64,1}}()
>>
>> julia> el = [1,2,3]; push!(s, el)
>> Set([[1,2,3]])
>>
>> julia> push!(s, [1,2,3]) #Pushing a new array object, but the length 
>> stays at 1.
>> Set([[1,2,3]])
>>
>> julia> s = Set{Vector{Int}}()
>> Set{Array{Int64,1}}()
>>
>> julia> el = [1,2,3]; push!(s, el)
>> Set([[1,2,3]])
>>
>> julia> el[1] = 10; @show s; #Mutate the set element from the outside
>> s = Set([[10,2,3]])
>>
>> julia> push!(s, [10,2,3])
>> Set([[10,2,3],[10,2,3]])
>>
>> julia> length(s)
>> 2
>>
>> julia> els = collect(s); els[1] == els[2]
>> true
>>
>> Is something buggy going on here?
>>
>> On Tuesday, December 15, 2015 at 10:57:31 AM UTC-5, Josh Langsfeld wrote:
>>>
>>> It's not array equality that's the issue here. Arrays with the same 
>>> elements are '==' (but not '==='). If you manually test pushing the same 
>>> array to a Set you'll see it works fine.
>>>
>>> Jan, what happened is that your 'santa' function modifies and returns 
>>> the same array that was passed in instead of creating a new one. So the 
>>> only array that ever gets created is the first 'start = [0 0]' and it just 
>>> gets continually modified, both in the santa function and in the set. 
>>> Switching to a tuple works because you are forced to create a new tuple to 
>>> change one of the elements.
>>>
>>> On Tuesday, December 15, 2015 at 3:32:40 AM UTC-5, Tomas Lycken wrote:
>>>>
>>>> Probably because the arrays will not be equal even if their contents 
>>>> are equal (this is true of most mutable types in Julia).
>>>>
>>>> If you try representing a position as a tuple `(0,0)` instead of as an 
>>>> array `[0,0]`, you'll find that it works as expected.
>>>>
>>>> // T
>>>>
>>>> On Tuesday, December 15, 2015 at 8:28:36 AM UTC+1, Jan Strube wrote:
>>>>>
>>>>> That's not a problem at all. In fact that's the very reason why I'm 
>>>>> using a Set in the first place.
>>>>>
>>>>> My question is: Why is the number of entries in the set different when 
>>>>> I add Arrays vs. adding ASCIIStrings?
>>>>>
>>>>>
>>>>> On Monday, December 14, 2015 at 10:57:57 PM UTC-8, ele...@gmail.com 
>>>>> wrote:
>>>>>>
>>>>>> I think your problem is that Sets cannot contain duplicate entries, 
>>>>>> so if Santa ever passes the same point twice it won't be added.
>>>>>>
>>>>>> Cheers
>>>>>> Lex
>>>>>>
>>>>>> On Tuesday, December 15, 2015 at 4:23:19 PM UTC+10, Jan Strube wrote:
>>>>>>>
>>>>>>> I'm trying to learn a bit more Julia by solving the puzzles over on 
>>>>>>> http://adventofcode.com
>>>>>>> On day 3, the problem is to follow a number of directions and figure 
>>>>>>> out how many new places you end up.
>>>>>>> http://adventofcode.com/day/3
>>>>>>>
>>>>>>> I thought I can solve this simply by defining a set of [x y] 
>>>>>>> positions, each time adding a new grid position to the set, so I'd end 
>>>>>>> up 
>>>>>>> with a Set{ Array{Int64,2}} of the right length.
>>>>>>> However, this doesn't work as expected. I get the wrong number (it's 
>>>>>>> too low).
>>>>>>>
>>>>>>> Wrapping each grid position into a string() call, however, gives me 
>>>>>>> the right answer. 
>>>>>>> The explanation is a bit convoluted. To avoid spoilers I've put the 
>>>>>>> code up at https://gist.github.com/jstrube/3d54e15f7d051b72032b
>>>>>>>
>>>>>>> I don't quite understand this. Is this expected?
>>>>>>>
>>>>>>>

[julia-users] advent of code -- day 3

[Jan Strube]

I'm trying to learn a bit more Julia by solving the puzzles over 
on http://adventofcode.com
On day 3, the problem is to follow a number of directions and figure out 
how many new places you end up.
http://adventofcode.com/day/3

I thought I can solve this simply by defining a set of [x y] positions, 
each time adding a new grid position to the set, so I'd end up with a Set{ 
Array{Int64,2}} of the right length.
However, this doesn't work as expected. I get the wrong number (it's too 
low).

Wrapping each grid position into a string() call, however, gives me the 
right answer. 
The explanation is a bit convoluted. To avoid spoilers I've put the code up 
at https://gist.github.com/jstrube/3d54e15f7d051b72032b

I don't quite understand this. Is this expected?

[julia-users] Re: advent of code -- day 3

[Jan Strube]

That's not a problem at all. In fact that's the very reason why I'm using a 
Set in the first place.

My question is: Why is the number of entries in the set different when I 
add Arrays vs. adding ASCIIStrings?


On Monday, December 14, 2015 at 10:57:57 PM UTC-8, ele...@gmail.com wrote:
>
> I think your problem is that Sets cannot contain duplicate entries, so if 
> Santa ever passes the same point twice it won't be added.
>
> Cheers
> Lex
>
> On Tuesday, December 15, 2015 at 4:23:19 PM UTC+10, Jan Strube wrote:
>>
>> I'm trying to learn a bit more Julia by solving the puzzles over on 
>> http://adventofcode.com
>> On day 3, the problem is to follow a number of directions and figure out 
>> how many new places you end up.
>> http://adventofcode.com/day/3
>>
>> I thought I can solve this simply by defining a set of [x y] positions, 
>> each time adding a new grid position to the set, so I'd end up with a Set{ 
>> Array{Int64,2}} of the right length.
>> However, this doesn't work as expected. I get the wrong number (it's too 
>> low).
>>
>> Wrapping each grid position into a string() call, however, gives me the 
>> right answer. 
>> The explanation is a bit convoluted. To avoid spoilers I've put the code 
>> up at https://gist.github.com/jstrube/3d54e15f7d051b72032b
>>
>> I don't quite understand this. Is this expected?
>>
>>

[julia-users] Re: Segfault when using SharedArray on OS X

[Jan Drugowitsch]

Now issue #14295 <https://github.com/JuliaLang/julia/issues/14295>.

On Friday, 27 November 2015 11:33:24 UTC+1, Jan Drugowitsch wrote:
>
> Hi all,
>
> when working on an parallel implementation of a particle filter, Julia 
> started segfault'ing under heavy workload. A minimal example to reproduce 
> this behavior is
>
> @everywhere begin
> type A
> x::SharedArray{Float64,1}
> A(N) = new(SharedArray(Float64, N))
> end
> localf(x::SharedArray) = nothing
> function f(a::A)
> map(fetch, Any[(@spawnat i localf(a.x)) for i in workers()])
> end
> end
>
>
> a = A(1000)
> for n = 1:10^8
> f(a)
> end
>
> This results on my MacBook Pro under OS X El Capitan in
>
> Jans-MacBook-Pro:~ jdrugo$ /Applications/Julia-0.4.1.app/Contents/
> Resources/julia/bin/julia -p 7 ./crash_example.jl
>
> signal (11): Segmentation fault: 11
> __pool_alloc at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc
> .c:1053
> _new_array_ at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/
> array.c:84
> _new_array at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/
> array.c:333
> call at /Applications/Julia-0.4.1.app/Contents/Resources/julia/lib/julia/
> sys.dylib (unknown line)
> def_rv_channel at multi.jl:619
> jlcall_def_rv_channel_21329 at  (unknown line)
> jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./
> julia.h:1325
> lookup_ref at multi.jl:513
> remotecall_fetch at multi.jl:727
> jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./
> julia.h:1325
> call_on_owner at multi.jl:778
> fetch at multi.jl:796
> jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./
> julia.h:1325
> map at /Applications/Julia-0.4.1.app/Contents/Resources/julia/lib/julia/
> sys.dylib (unknown line)
> f at /Users/jdrugo/crash_example.jl:9
> jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./
> julia.h:1325
> anonymous at /Users/jdrugo/crash_example.jl:15
> jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./
> julia.h:1325
> jl_parse_eval_all at /Users/osx/buildbot/slave/package_osx10_9-x64/build/
> src/toplevel.c:577
> jl_load at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/
> toplevel.c:620
> include at /Applications/Julia-0.4.1.app/Contents/Resources/julia/lib/
> julia/sys.dylib (unknown line)
> jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./
> julia.h:1325
> include_from_node1 at /Applications/Julia-0.4.1.app/Contents/Resources/
> julia/lib/julia/sys.dylib (unknown line)
> jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./
> julia.h:1325
> process_options at /Applications/Julia-0.4.1.app/Contents/Resources/julia/
> lib/julia/sys.dylib (unknown line)
> _start at /Applications/Julia-0.4.1.app/Contents/Resources/jul
> ...

[julia-users] Segfault when using SharedArray on OS X

[Jan Drugowitsch]

Hi all,

when working on an parallel implementation of a particle filter, Julia 
started segfault'ing under heavy workload. A minimal example to reproduce 
this behavior is

@everywhere begin
type A
x::SharedArray{Float64,1}
A(N) = new(SharedArray(Float64, N))
end
localf(x::SharedArray) = nothing
function f(a::A)
map(fetch, Any[(@spawnat i localf(a.x)) for i in workers()])
end
end


a = A(1000)
for n = 1:10^8
f(a)
end

This results on my MacBook Pro under OS X El Capitan in

Jans-MacBook-Pro:~ jdrugo$ /Applications/Julia-0.4.1.app/Contents/Resources/
julia/bin/julia -p 7 ./crash_example.jl

signal (11): Segmentation fault: 11
__pool_alloc at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c
:1053
_new_array_ at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/array
.c:84
_new_array at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/array.
c:333
call at /Applications/Julia-0.4.1.app/Contents/Resources/julia/lib/julia/sys
.dylib (unknown line)
def_rv_channel at multi.jl:619
jlcall_def_rv_channel_21329 at  (unknown line)
jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.
h:1325
lookup_ref at multi.jl:513
remotecall_fetch at multi.jl:727
jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.
h:1325
call_on_owner at multi.jl:778
fetch at multi.jl:796
jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.
h:1325
map at 
/Applications/Julia-0.4.1.app/Contents/Resources/julia/lib/julia/sys.dylib 
(unknown line)
f at /Users/jdrugo/crash_example.jl:9
jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.
h:1325
anonymous at /Users/jdrugo/crash_example.jl:15
jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.
h:1325
jl_parse_eval_all at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src
/toplevel.c:577
jl_load at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.
c:620
include at /Applications/Julia-0.4.1.app/Contents/Resources/julia/lib/julia/
sys.dylib (unknown line)
jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.
h:1325
include_from_node1 at /Applications/Julia-0.4.1.app/Contents/Resources/julia
/lib/julia/sys.dylib (unknown line)
jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.
h:1325
process_options at /Applications/Julia-0.4.1.app/Contents/Resources/julia/
lib/julia/sys.dylib (unknown line)
_start at /Applications/Julia-0.4.1.app/Contents/Resources/julia/lib/julia/
sys.dylib (unknown line)
jlcall__start_18614 at /Applications/Julia-0.4.1.app/Contents/Resources/
julia/lib/julia/sys.dylib (unknown line)
jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.
h:1325
true_main at /Applications/Julia-0.4.1.app/Contents/Resources/julia/bin/julia 
(unknown line)
main at /Applications/Julia-0.4.1.app/Contents/Resources/julia/bin/julia 
(unknown 
line)
Segmentation fault: 11

More info

julia> versioninfo()
Julia Version 0.4.1
Commit cbe1bee* (2015-11-08 10:33 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

Is this a known issue?

Thanks,
Jan

[julia-users] Emacs mode for keyword pair matching or highlighting

[Jan Kybic]

Dear all,

in Julia, blocks of code are delimited by pairs of keywords such as 
module/end, function/end, for/end, quote/end etc.  Sometimes I get the 
pairings between the opening and closing keyword wrong, which leads to at 
least syntax errors, but sometimes other hard to catch errors. 
It would be useful to be able to find at a glance very quickly, where each 
block starts and ends. Emacs already seems to understand Julia syntax, 
 when I do 'indent-region', the results are usually correct. However, in 
longer functions, I still need to verify manually, if what I think is the 
beginning of the block is at the same indentation level as the closing 
'end'. What I would like is something like the 'rainbow-mode', which colors 
parentheses (but only parentheses) with matching colors, which is very 
useful for Lisp-like languages. I also liked the idea of the 'smartparens' 
package, which highlights the matching keyword delimiter if you put a 
cursor over the other one - it however seems to be confused by 'end' being 
a universal closing keyword, so it just finds the first 'end', even if it 
is not on the right level.

Would you have any other suggestions, what other Emacs package I could use 
to get the desired effect?

Thanks,

Jan

Re: [julia-users] Options fail with Julia 0.4?

[Jan Kybic]

Mauro <mauro...@runbox.com> writes:

>Unless someone else knows a fix, could you to put together a small test
>case and file an issue with Options.jl?

I have looked and it seems that the problem is kind of known but will
not be solved (?), rather the package will be obsoleted.

So for the moment, I will solve the issue by making a local copy of
the Options file, changing the module type and the datatype name, so
that standard "using Options" works.

The test case is as follows, in case somebody is interested.

Jan

-- file a.jl:

module a

require("Options")
using OptionsMod

export myfun

function myfun(opts)
@defaults opts p=0
println("myfun p=$p")
end

function testa()
myfun(@options)
end

end

-- file b.jl:
module b

using a

require("Options")
using OptionsMod

function testb()
myfun(@options)
end

end
--

julia> import a ; a.testa()
WARNING: `require` is deprecated, use `using` or `import` instead

julia> import b ; b.testb()
ERROR: First argument must be an options type





>
>On Wed, 2015-09-30 at 18:33, Jan Kybic <jky...@gmail.com> wrote:
>> Hello,
>>after switching to from Julia 0.3 to Julia 0.4 (release
>> candidate 3),  the Options package stopped working for me. I have several
>> modules, in each I call
>>
>> require("Options")
>> using OptionsMod
>>
>> A function from one module is called either from the same module or from
>> another using a call like "myfunction(a,b,@options)". Inside "myfunction",
>> the type of the last parameter is always
>>  "OptionsMod.Options{OptionsMod.CheckError}". However, the types do not
>> seem to be the same, "isa(opts,OptionsMod.Options)" give true in one case
>> and false in the latter and this leads to all sorts of errors like "method
>> not found".
>>
>> Do you know what is happening and how to avoid it? Perhaps as the module is
>> reloaded, it interferes with the precompilation?
>>
>> Thank you,
>>
>> Jan

-- 
-
Jan Kybic <ky...@fel.cvut.cz>   tel. +420 2 2435 5721 
http://cmp.felk.cvut.cz/~kybic  

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

[Jan Strube]

Just to add my 2 cents:
I posted a question about linspace and collect not too long ago.
Collect wasn't obvious to me at first, and I tried something like linspace 
(0, 1, 10)[:] to get the array first.
I only needed it for PyPlot. As long as PyPlot works with whatever linspace 
returns, I'm happy.


On Wednesday, September 30, 2015 at 11:56:23 AM UTC-7, Steven G. Johnson 
wrote:
>
>
>
> On Wednesday, September 30, 2015 at 1:31:55 PM UTC-4, Alex Ames wrote:\
>>
>>  I ran into errors when trying to plot a function over a linspace of x 
>> values, since plotting libs currently expect vectors as arguments, not 
>> range objects. Easily fixed if you know Julia well, but Matlab/Python 
>> converts may be stymied.
>>
>
> PyPlot works fine with linspace arguments.
>
> In Julia, a Range is a subtype of AbstractVector, and any plotting program 
> should normally work for any AbstractVector type, not just Array.  If not, 
> that is a bug in the plotting program. 
>

[julia-users] Options fail with Julia 0.4?

[Jan Kybic]

Hello,
   after switching to from Julia 0.3 to Julia 0.4 (release 
candidate 3),  the Options package stopped working for me. I have several 
modules, in each I call

require("Options")
using OptionsMod

A function from one module is called either from the same module or from 
another using a call like "myfunction(a,b,@options)". Inside "myfunction", 
the type of the last parameter is always 
 "OptionsMod.Options{OptionsMod.CheckError}". However, the types do not 
seem to be the same, "isa(opts,OptionsMod.Options)" give true in one case 
and false in the latter and this leads to all sorts of errors like "method 
not found".

Do you know what is happening and how to avoid it? Perhaps as the module is 
reloaded, it interferes with the precompilation?

Thank you,

Jan

Re: [julia-users] linspace and HDF5

[Jan Strube]

The julia example doesn't need meshgrid at all.


On Tuesday, September 22, 2015 at 2:37:55 AM UTC-7, Christoph Ortner wrote:
>
> another example why meshgrid should be in Base. :)
> Christoph
>

Re: [julia-users] linspace and HDF5

[Jan Strube]

A small python snippet that does roughly what I want is below.
I'm using asymmetric data to remind myself whether to transpose the matrix 
or not.
Thanks for your help.


from matplotlib import pyplot as plt
from matplotlib.colors import LogNorm 
import numpy as np 
import sys 
xaxis = np.linspace(1, 20, 101) 
yaxis = np.linspace(2, 5, 101) 
data = np.zeros((100, 100)) 

for x in range(100): 
for y in range(100): 
data[x,y] = xaxis[x] + yaxis[y] 
X, Y = np.meshgrid(xaxis, yaxis) 
# I can figure out how to make this figure in Julia
#p = plt.pcolormesh(X, Y, data.T) 

# This is what I would like instead
p = plt.pcolormesh(X, Y, data.T, norm=LogNorm(vmin=np.min(data), vmax=np.max
(data))) 
plt.colorbar(p) 
plt.savefig("test.png")





On Sunday, September 20, 2015 at 8:54:26 PM UTC-7, Tom Breloff wrote:
>
> Yes you should probably use `collect`.
>
> With regards to plotting... can you post the pyplot code that generates 
> the graph that you want?  We may be able to either show you how to do it in 
> julia, or it will help in future development by pinpointing a deficiency.  
> Thanks.
>
> On Sun, Sep 20, 2015 at 11:11 PM, Jan Strube <jan.s...@gmail.com 
> > wrote:
>
>> I'm trying to write some data and axis definitions to HDF5 for later 
>> plotting in pyplot. (Because I haven't figured out how to do lognorm on 
>> pcolormesh in PyPlot.jl)
>> Writing the data - a 2D array - is no problem.
>> Writing the axes - linspace(min, max, 100) - doesn't work, because I just 
>> found out that linspace creates a LinSpace object, not an array, and HDF5 
>> doesn't know how to write that.
>> My question is: What is an idiomatic way to turn LinSpace into an Array? 
>> Is collect the recommended way to do this?
>>
>>
>

Re: [julia-users] linspace and HDF5

[Jan Strube]

@pyimport, nifty.
Thanks!

On Monday, September 21, 2015 at 11:03:35 AM UTC-7, Tom Breloff wrote:
>
> This seemed to match:
>  
>
>> using PyPlot, PyCall
>> @pyimport matplotlib.colors as COL
>> @pyimport numpy as np
>> xaxis = linspace(1, 20, 101)
>> yaxis = linspace(2, 5, 101)
>> data = Float64[x+y for x in xaxis, y in yaxis];
>> X, Y = np.meshgrid(xaxis, yaxis)
>> plt = pcolormesh(X, Y, data', norm = COL.LogNorm(vmin=minimum(data), 
>> vmax=maximum(data)))
>> colorbar()
>> savefig("test.png")
>
>
>  
>
> On Mon, Sep 21, 2015 at 1:34 PM, Jan Strube <jan.s...@gmail.com 
> > wrote:
>
>> A small python snippet that does roughly what I want is below.
>> I'm using asymmetric data to remind myself whether to transpose the 
>> matrix or not.
>> Thanks for your help.
>>
>>
>> from matplotlib import pyplot as plt
>> from matplotlib.colors import LogNorm 
>> import numpy as np 
>> import sys 
>> xaxis = np.linspace(1, 20, 101) 
>> yaxis = np.linspace(2, 5, 101) 
>> data = np.zeros((100, 100)) 
>>
>> for x in range(100): 
>> for y in range(100): 
>> data[x,y] = xaxis[x] + yaxis[y] 
>> X, Y = np.meshgrid(xaxis, yaxis) 
>> # I can figure out how to make this figure in Julia
>> #p = plt.pcolormesh(X, Y, data.T) 
>>
>> # This is what I would like instead
>> p = plt.pcolormesh(X, Y, data.T, norm=LogNorm(vmin=np.min(data), vmax=np.
>> max(data))) 
>> plt.colorbar(p) 
>> plt.savefig("test.png")
>>
>>
>>
>>
>>
>> On Sunday, September 20, 2015 at 8:54:26 PM UTC-7, Tom Breloff wrote:
>>>
>>> Yes you should probably use `collect`.
>>>
>>> With regards to plotting... can you post the pyplot code that generates 
>>> the graph that you want?  We may be able to either show you how to do it in 
>>> julia, or it will help in future development by pinpointing a deficiency.  
>>> Thanks.
>>>
>>> On Sun, Sep 20, 2015 at 11:11 PM, Jan Strube <jan.s...@gmail.com> wrote:
>>>
>>>> I'm trying to write some data and axis definitions to HDF5 for later 
>>>> plotting in pyplot. (Because I haven't figured out how to do lognorm on 
>>>> pcolormesh in PyPlot.jl)
>>>> Writing the data - a 2D array - is no problem.
>>>> Writing the axes - linspace(min, max, 100) - doesn't work, because I 
>>>> just found out that linspace creates a LinSpace object, not an array, and 
>>>> HDF5 doesn't know how to write that.
>>>> My question is: What is an idiomatic way to turn LinSpace into an 
>>>> Array? Is collect the recommended way to do this?
>>>>
>>>>
>>>
>

[julia-users] linspace and HDF5

[Jan Strube]

I'm trying to write some data and axis definitions to HDF5 for later 
plotting in pyplot. (Because I haven't figured out how to do lognorm on 
pcolormesh in PyPlot.jl)
Writing the data - a 2D array - is no problem.
Writing the axes - linspace(min, max, 100) - doesn't work, because I just 
found out that linspace creates a LinSpace object, not an array, and HDF5 
doesn't know how to write that.
My question is: What is an idiomatic way to turn LinSpace into an Array? Is 
collect the recommended way to do this?

Re: [julia-users] CXX.jl installation failure -- bug or user error?

[Jan Strube]

Works!
Thank you. I appreciate the fast reply. Can't wait to play with Pythia.jl 
:-)


On Monday, August 17, 2015 at 2:38:18 PM UTC-7, Keno Fischer wrote:

 I just fixed this on master. The reason this failed is that the 
 recommended configuration for Cxx.jl always pulls in latest LLVM master. 
 This causes problems sometimes when LLVM breaks the API, but it makes it 
 easier for me to make sure everyone has patches I commit upstream. Please 
 try again.

 On Mon, Aug 17, 2015 at 6:59 PM, Jan Strube jan.s...@gmail.com 
 javascript: wrote:

 I am trying to install CXX.jl following the instructions from the README.
 I'm on Mac OS X Yosemite and have installed Xcode.
 The deps compile OK.

 However, julia compilation seems to fail.
 ...

 CC src/codegen.o

 *codegen.cpp:5363:14: **error: **use of undeclared identifier 
 'createTypeBasedAliasAnalysisPass'; did you mean 
 'createBasicAliasAnalysisPass'?*

 FPM-add(createTypeBasedAliasAnalysisPass());

 * ^~~~*

  createBasicAliasAnalysisPass

 */Workdir/JULIA_GIT/usr/include/llvm/Analysis/BasicAliasAnalysis.h:191:16: 
 **note: *'createBasicAliasAnalysisPass' declared here

 ImmutablePass *createBasicAliasAnalysisPass();

 *   ^*

 1 error generated.

 make[1]: *** [codegen.o] Error 1

 make: *** [julia-src-release] Error 2


 I couldn't find a bug posted about this, so I'm wondering if this is 
 something I can fix on my end.

 Has anybody else encountered this?

[julia-users] CXX.jl installation failure -- bug or user error?

[Jan Strube]

I am trying to install CXX.jl following the instructions from the README.
I'm on Mac OS X Yosemite and have installed Xcode.
The deps compile OK.

However, julia compilation seems to fail.
...

CC src/codegen.o

*codegen.cpp:5363:14: **error: **use of undeclared identifier 
'createTypeBasedAliasAnalysisPass'; did you mean 
'createBasicAliasAnalysisPass'?*

FPM-add(createTypeBasedAliasAnalysisPass());

* ^~~~*

 createBasicAliasAnalysisPass

*/Workdir/JULIA_GIT/usr/include/llvm/Analysis/BasicAliasAnalysis.h:191:16: 
**note: 
*'createBasicAliasAnalysisPass' declared here

ImmutablePass *createBasicAliasAnalysisPass();

*   ^*

1 error generated.

make[1]: *** [codegen.o] Error 1

make: *** [julia-src-release] Error 2


I couldn't find a bug posted about this, so I'm wondering if this is 
something I can fix on my end.

Has anybody else encountered this?

Re: [julia-users] Re: Short-circuit evaluation for multiplication

[Jan Drugowitsch]

My aim is to write a Hamiltonian MCMC sampler that samples bound and drift 
parameter posteriors for bounded diffusion models while assuming some 
parametric form for how these bounds and the drift change over time. This 
requires the first and second derivative of the first-passage densities 
that are computed in 
https://github.com/jdrugo/DiffModels.jl/blob/master/src/fpt.jl#L153. For 
certain parametrization of drift and bound, partial derivatives will be one 
or zero, which would make some parts of the code computing the full 
derivatives drop out. To make this have an impact on performance, I thought 
of two approaches:

   - Write specialised functions for different parameterizations. This is 
   the safe approach but would introduce many functions, as there are many 
   possible combinations of drift and bound parameterizations. Also, it would 
   not handle cases that I haven't thought of.
   - Write a generic function that only evaluates the parts of the code 
   that influence the final result. Currently, it seems that macros are the 
   best way to achieve this. The advantages would be that it only requires me 
   to write the function once, avoiding code replication and associated bugs. 
   Also, it should be able to handle cases that I haven't thought of.

Note that the code linked above currently does not compute the derivatives. 
Due to several exp(.), the code that computes the derivatives will be 
significantly longer, such that not evaluating parts of it should lead to 
faster execution (not in the big-O sense, but reducing the constant).

Jan

On Friday, 3 July 2015 01:51:19 UTC+2, Stefan Karpinski wrote:

 Can you elaborate on why that kind of code needs this unusual evaluation? 
 It looks pretty reasonable as is to me.

 On Thu, Jul 2, 2015 at 5:20 PM, Jan Drugowitsch jdr...@gmail.com 
 javascript: wrote:

 Is this a toy reduction of a concept that you want to apply in a much 
 more complex way?


 Yes, it was just meant to illustrate the concept.

 It should be applied to a function that has roughly the complexity of 
 https://github.com/jdrugo/DiffModels.jl/blob/master/src/fpt.jl#L153
 (in fact, it would be the first and second derivative of this function 
 with respect to parameters of drift and bounds).

 Jan 

 On Thu, Jul 2, 2015 at 11:09 AM, Jan Drugowitsch jdr...@gmail.com 
 wrote:

 On Thursday, 2 July 2015 16:55:33 UTC+2, Yichao Yu wrote:

 On Thu, Jul 2, 2015 at 10:48 AM, Tom Breloff t...@breloff.com 
 wrote: 
  Just curious... is there a reason simply checking for non-zero isn't 
 enough? 
  Readability? Performance? 
  
  f(a,b,c) = (Bool(a) ? a * (b + c) : 0.0) 

 I'm guessing he want all code that gets his type automatically gets 
 this behavior? If yes, I don't think there's anyway you can do that. 
 If not, then just writing the branch or having a macro to rewrite that 
 in your own code is probably the best solution. 


 Indeed, the reason why I don't want to check for zeros and ones 
 explicitly is that some of these appear in inner loops and would reduce 
 performance.

 I already thought of macros as a possible solution, but I was wondering 
 if the same could be achieved in a more implicit/elegant way.

 Thanks,
 Jan
  

  On Thursday, July 2, 2015 at 9:47:59 AM UTC-4, Jan Drugowitsch 
 wrote: 
  
  Dear Julia users, 
  
  I am implementing an algorithm to solve a specific type of Volterra 
  integral equation, and that simplifies significantly if some of its 
  parameters are set to zero or one. The function implementing the 
 algorithm 
  takes quite a few arguments, such that writing specific versions 
 for 
  different arguments being zero/one would lead to too many different 
  functions, which I would like to avoid. What I would rather like to 
 do is to 
  write one generic function and let the compiler prune different 
 parts of the 
  function, depending on the argument types. 
  
  A minimal example of what I would like to do is 
  
  immutable Zero : Number; end 
  
  const _zero = Zero() 
  
  Base.promote_rule{T:Number}(::Type{Zero}, ::Type{T}) = T 
  Base.convert{T:Number}(::Type{T}, ::Zero) = zero(T) 
  
  *(::Zero, ::Zero) = _zero 
  *(::Zero, ::Bool) = _zero 
  *(::Bool, ::Zero) = _zero 
  *(::Zero, ::Number) = _zero 
  *(::Number, ::Zero) = _zero 
  
  f(a, b, c) = a * (println(summing b + c); b + c) 
  
  println(Evaluating f(0, 1, 2)) 
  f(0, 1, 2) 
  println(Evaluating f(_zero, 1, 2)) 
  f(_zero, 1, 2) 
  
  (with Zero defined similar to 
  https://groups.google.com/forum/#!topic/julia-users/0ab30bE8q6c) 
  Running the above results in 
  
  Evaluating f(0, 1, 2) 
  summing b + c 
  Evaluating f(_zero, 1, 2) 
  summing b + c 
  
  even though the result of the second summing b + c is discarded, 
 and 
  therefore wouldn't need to be evaluated. This is no surprise, as 
 *(.,.) is a 
  standard function that evaluates its operands before applying the 
 function. 
  Is there any way to change this behavior and turn *(.,.) into a 
 function

[julia-users] Short-circuit evaluation for multiplication

[Jan Drugowitsch]

Dear Julia users,

I am implementing an algorithm to solve a specific type of Volterra 
integral equation, and that simplifies significantly if some of its 
parameters are set to zero or one. The function implementing the algorithm 
takes quite a few arguments, such that writing specific versions for 
different arguments being zero/one would lead to too many different 
functions, which I would like to avoid. What I would rather like to do is 
to write one generic function and let the compiler prune different parts of 
the function, depending on the argument types.

A minimal example of what I would like to do is

immutable Zero : Number; end

const _zero = Zero()

Base.promote_rule{T:Number}(::Type{Zero}, ::Type{T}) = T
Base.convert{T:Number}(::Type{T}, ::Zero) = zero(T)

*(::Zero, ::Zero) = _zero
*(::Zero, ::Bool) = _zero
*(::Bool, ::Zero) = _zero
*(::Zero, ::Number) = _zero
*(::Number, ::Zero) = _zero

f(a, b, c) = a * (println(summing b + c); b + c)

println(Evaluating f(0, 1, 2))
f(0, 1, 2)
println(Evaluating f(_zero, 1, 2))
f(_zero, 1, 2)

(with Zero defined similar 
to https://groups.google.com/forum/#!topic/julia-users/0ab30bE8q6c)
Running the above results in

Evaluating f(0, 1, 2)
summing b + c
Evaluating f(_zero, 1, 2)
summing b + c

even though the result of the second summing b + c is discarded, and 
therefore wouldn't need to be evaluated. This is no surprise, as *(.,.) is 
a standard function that evaluates its operands before applying the 
function. Is there any way to change this behavior and turn *(.,.) into a 
function that performs short-circuit evaluation? If not, is there an 
alternative approach that achieves this without writing tons of specialized 
functions?

Thanks,
Jan

Re: [julia-users] Re: Short-circuit evaluation for multiplication

[Jan Drugowitsch]

On Thursday, 2 July 2015 16:55:33 UTC+2, Yichao Yu wrote:

 On Thu, Jul 2, 2015 at 10:48 AM, Tom Breloff t...@breloff.com 
 javascript: wrote: 
  Just curious... is there a reason simply checking for non-zero isn't 
 enough? 
  Readability? Performance? 
  
  f(a,b,c) = (Bool(a) ? a * (b + c) : 0.0) 

 I'm guessing he want all code that gets his type automatically gets 
 this behavior? If yes, I don't think there's anyway you can do that. 
 If not, then just writing the branch or having a macro to rewrite that 
 in your own code is probably the best solution. 


Indeed, the reason why I don't want to check for zeros and ones explicitly 
is that some of these appear in inner loops and would reduce performance.

I already thought of macros as a possible solution, but I was wondering if 
the same could be achieved in a more implicit/elegant way.

Thanks,
Jan
 

  On Thursday, July 2, 2015 at 9:47:59 AM UTC-4, Jan Drugowitsch wrote: 
  
  Dear Julia users, 
  
  I am implementing an algorithm to solve a specific type of Volterra 
  integral equation, and that simplifies significantly if some of its 
  parameters are set to zero or one. The function implementing the 
 algorithm 
  takes quite a few arguments, such that writing specific versions for 
  different arguments being zero/one would lead to too many different 
  functions, which I would like to avoid. What I would rather like to do 
 is to 
  write one generic function and let the compiler prune different parts 
 of the 
  function, depending on the argument types. 
  
  A minimal example of what I would like to do is 
  
  immutable Zero : Number; end 
  
  const _zero = Zero() 
  
  Base.promote_rule{T:Number}(::Type{Zero}, ::Type{T}) = T 
  Base.convert{T:Number}(::Type{T}, ::Zero) = zero(T) 
  
  *(::Zero, ::Zero) = _zero 
  *(::Zero, ::Bool) = _zero 
  *(::Bool, ::Zero) = _zero 
  *(::Zero, ::Number) = _zero 
  *(::Number, ::Zero) = _zero 
  
  f(a, b, c) = a * (println(summing b + c); b + c) 
  
  println(Evaluating f(0, 1, 2)) 
  f(0, 1, 2) 
  println(Evaluating f(_zero, 1, 2)) 
  f(_zero, 1, 2) 
  
  (with Zero defined similar to 
  https://groups.google.com/forum/#!topic/julia-users/0ab30bE8q6c) 
  Running the above results in 
  
  Evaluating f(0, 1, 2) 
  summing b + c 
  Evaluating f(_zero, 1, 2) 
  summing b + c 
  
  even though the result of the second summing b + c is discarded, and 
  therefore wouldn't need to be evaluated. This is no surprise, as *(.,.) 
 is a 
  standard function that evaluates its operands before applying the 
 function. 
  Is there any way to change this behavior and turn *(.,.) into a 
 function 
  that performs short-circuit evaluation? If not, is there an alternative 
  approach that achieves this without writing tons of specialized 
 functions? 
  
  Thanks, 
  Jan 

Re: [julia-users] Re: Short-circuit evaluation for multiplication

[Jan Drugowitsch]

 Is this a toy reduction of a concept that you want to apply in a much more 
 complex way?


Yes, it was just meant to illustrate the concept.

It should be applied to a function that has roughly the complexity of 
https://github.com/jdrugo/DiffModels.jl/blob/master/src/fpt.jl#L153
(in fact, it would be the first and second derivative of this function with 
respect to parameters of drift and bounds).

Jan 

On Thu, Jul 2, 2015 at 11:09 AM, Jan Drugowitsch jdr...@gmail.com 
 javascript: wrote:

 On Thursday, 2 July 2015 16:55:33 UTC+2, Yichao Yu wrote:

 On Thu, Jul 2, 2015 at 10:48 AM, Tom Breloff t...@breloff.com wrote: 
  Just curious... is there a reason simply checking for non-zero isn't 
 enough? 
  Readability? Performance? 
  
  f(a,b,c) = (Bool(a) ? a * (b + c) : 0.0) 

 I'm guessing he want all code that gets his type automatically gets 
 this behavior? If yes, I don't think there's anyway you can do that. 
 If not, then just writing the branch or having a macro to rewrite that 
 in your own code is probably the best solution. 


 Indeed, the reason why I don't want to check for zeros and ones 
 explicitly is that some of these appear in inner loops and would reduce 
 performance.

 I already thought of macros as a possible solution, but I was wondering 
 if the same could be achieved in a more implicit/elegant way.

 Thanks,
 Jan
  

  On Thursday, July 2, 2015 at 9:47:59 AM UTC-4, Jan Drugowitsch wrote: 
  
  Dear Julia users, 
  
  I am implementing an algorithm to solve a specific type of Volterra 
  integral equation, and that simplifies significantly if some of its 
  parameters are set to zero or one. The function implementing the 
 algorithm 
  takes quite a few arguments, such that writing specific versions for 
  different arguments being zero/one would lead to too many different 
  functions, which I would like to avoid. What I would rather like to 
 do is to 
  write one generic function and let the compiler prune different parts 
 of the 
  function, depending on the argument types. 
  
  A minimal example of what I would like to do is 
  
  immutable Zero : Number; end 
  
  const _zero = Zero() 
  
  Base.promote_rule{T:Number}(::Type{Zero}, ::Type{T}) = T 
  Base.convert{T:Number}(::Type{T}, ::Zero) = zero(T) 
  
  *(::Zero, ::Zero) = _zero 
  *(::Zero, ::Bool) = _zero 
  *(::Bool, ::Zero) = _zero 
  *(::Zero, ::Number) = _zero 
  *(::Number, ::Zero) = _zero 
  
  f(a, b, c) = a * (println(summing b + c); b + c) 
  
  println(Evaluating f(0, 1, 2)) 
  f(0, 1, 2) 
  println(Evaluating f(_zero, 1, 2)) 
  f(_zero, 1, 2) 
  
  (with Zero defined similar to 
  https://groups.google.com/forum/#!topic/julia-users/0ab30bE8q6c) 
  Running the above results in 
  
  Evaluating f(0, 1, 2) 
  summing b + c 
  Evaluating f(_zero, 1, 2) 
  summing b + c 
  
  even though the result of the second summing b + c is discarded, 
 and 
  therefore wouldn't need to be evaluated. This is no surprise, as 
 *(.,.) is a 
  standard function that evaluates its operands before applying the 
 function. 
  Is there any way to change this behavior and turn *(.,.) into a 
 function 
  that performs short-circuit evaluation? If not, is there an 
 alternative 
  approach that achieves this without writing tons of specialized 
 functions? 
  
  Thanks, 
  Jan 

Re: [julia-users] Re: Short-circuit evaluation for multiplication

[Jan Drugowitsch]

On Thursday, 2 July 2015 17:13:50 UTC+2, Yichao Yu wrote:

 On Thu, Jul 2, 2015 at 11:09 AM, Jan Drugowitsch jdr...@gmail.com 
 javascript: wrote: 
  On Thursday, 2 July 2015 16:55:33 UTC+2, Yichao Yu wrote: 
  
  On Thu, Jul 2, 2015 at 10:48 AM, Tom Breloff t...@breloff.com wrote: 
   Just curious... is there a reason simply checking for non-zero isn't 
   enough? 
   Readability? Performance? 
   
   f(a,b,c) = (Bool(a) ? a * (b + c) : 0.0) 
  
  I'm guessing he want all code that gets his type automatically gets 
  this behavior? If yes, I don't think there's anyway you can do that. 
  If not, then just writing the branch or having a macro to rewrite that 
  in your own code is probably the best solution. 
  
  
  Indeed, the reason why I don't want to check for zeros and ones 
 explicitly 
  is that some of these appear in inner loops and would reduce 
 performance. 
  
  I already thought of macros as a possible solution, but I was wondering 
 if 
  the same could be achieved in a more implicit/elegant way. 

 Implicit and elegant sometimes conflict with each other =) 

 If you have control over the code that uses this, using a macro is the 
 way to go. A function can't possibly do this. 

 You could have a look at https://github.com/one-more-minute/Lazy.jl 
 though. 


Thanks, I'll check it out.

Jan 
 

   On Thursday, July 2, 2015 at 9:47:59 AM UTC-4, Jan Drugowitsch wrote: 
   
   Dear Julia users, 
   
   I am implementing an algorithm to solve a specific type of Volterra 
   integral equation, and that simplifies significantly if some of its 
   parameters are set to zero or one. The function implementing the 
   algorithm 
   takes quite a few arguments, such that writing specific versions for 
   different arguments being zero/one would lead to too many different 
   functions, which I would like to avoid. What I would rather like to 
 do 
   is to 
   write one generic function and let the compiler prune different 
 parts 
   of the 
   function, depending on the argument types. 
   
   A minimal example of what I would like to do is 
   
   immutable Zero : Number; end 
   
   const _zero = Zero() 
   
   Base.promote_rule{T:Number}(::Type{Zero}, ::Type{T}) = T 
   Base.convert{T:Number}(::Type{T}, ::Zero) = zero(T) 
   
   *(::Zero, ::Zero) = _zero 
   *(::Zero, ::Bool) = _zero 
   *(::Bool, ::Zero) = _zero 
   *(::Zero, ::Number) = _zero 
   *(::Number, ::Zero) = _zero 
   
   f(a, b, c) = a * (println(summing b + c); b + c) 
   
   println(Evaluating f(0, 1, 2)) 
   f(0, 1, 2) 
   println(Evaluating f(_zero, 1, 2)) 
   f(_zero, 1, 2) 
   
   (with Zero defined similar to 
   https://groups.google.com/forum/#!topic/julia-users/0ab30bE8q6c) 
   Running the above results in 
   
   Evaluating f(0, 1, 2) 
   summing b + c 
   Evaluating f(_zero, 1, 2) 
   summing b + c 
   
   even though the result of the second summing b + c is discarded, 
 and 
   therefore wouldn't need to be evaluated. This is no surprise, as 
 *(.,.) 
   is a 
   standard function that evaluates its operands before applying the 
   function. 
   Is there any way to change this behavior and turn *(.,.) into a 
   function 
   that performs short-circuit evaluation? If not, is there an 
 alternative 
   approach that achieves this without writing tons of specialized 
   functions? 
   
   Thanks, 
   Jan 

[julia-users] Re: Calling C libraries from Julia

[Jan Strube]

Daniel,

I tried your code and could reproduce the problem: I have to suggestions:
-- Julia is 1-based, so drop the 0 in your unsafe_load. The default 
parameter is 1, which is what you want in this case.
-- I can't really understand what your function is supposed to do (and my C 
is a bit rusty), but this simpler version works for me.
I suggest to start there and add the additional functionality of 
particles_add bit by bit.

Good luck.

#include stdio.h
#include stdlib.h

int N= 7;
int Nmax = 9;

struct particle {
double x;
double y;
double z;
};

struct particle* particles = NULL;

void particles_add(struct particle pt){
printf(%.2f\t%.2f\t%.2f\n, pt.x, pt.y, pt.z);
}



On Sunday, June 21, 2015 at 11:42:06 PM UTC+9, Daniel Carrera wrote:

 Hello,

 I'm trying to learn how to call C libraries from Julia. So I wrote a 
 simple C library that does nothing in particular and I am having trouble 
 talking to that library from Julia. Here is my library:

 -
 % cat foo.c
 #include stdio.h
 #include stdlib.h

 int N= 7;
 int Nmax = 9;

 struct particle {
 double x;
 double y;
 double z;
 };

 struct particle* particles = NULL;

 void particles_add(struct particle pt){
 while (Nmax = N){
 Nmax += 128;
 particles = realloc(particles,sizeof(struct particle)*Nmax);
 }
 particles[N] = pt;
 N++;
 }

 -
 % make
 gcc -Wall -std=c99 -Wpointer-arith -c -fPIC foo.c
 gcc -Wall -std=c99 -Wpointer-arith -shared -o libfoo.so foo.o
 -


 So, there are two things I would like to do from Julia: I'd like to read 
 the variable N and I'd like to create a particle struct and pass it to 
 the particles_add() function. I used the documentation on this page:

 http://julia.readthedocs.org/en/latest/manual/calling-c-and-fortran-code/

 Based on what I read, this is what I came up with:

 -
 % cat foo.jl
 const lib = ./libfoo.so

 N()= unsafe_load(cglobal((N   ,lib), Cint), 0)
 Nmax() = unsafe_load(cglobal((Nmax,lib), Cint), 0)

 immutable Particle
 x ::Cdouble
 y ::Cdouble
 z ::Cdouble
 end
 
 function add(pt::Particle)
 ccall((particles_add, lib), Void, (Particle,), pt)
 end
 
 function add(;x=0,y=0,z=0)
 add(Particle(x,y,z))
 end
 -


 However, nothing here works: I cannot read N (I get gibberish) and I 
 cannot call particles_add() (I get a segfault):

 -
 % julia
 ...
 julia include(foo.jl)
 add (generic function with 2 methods)

 julia N()
 32570

 julia Nmax()
 7

 julia add(x=0)

 signal (11): Segmentation fault
 particles_add at ./libfoo.so (unknown line)
 julia_add_20314 at  (unknown line)
 jlcall_add_20314 at  (unknown line)
 unknown function (ip: -490800184)
 unknown function (ip: -490804016)
 unknown function (ip: -490736582)
 jl_f_top_eval at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
 (unknown line)
 eval_user_input at REPL.jl:53
 jlcall_eval_user_input_20278 at  (unknown line)
 jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
 (unknown line)
 anonymous at task.jl:95
 jl_handle_stack_switch at 
 /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so (unknown line)
 julia_trampoline at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
 (unknown line)
 unknown function (ip: 4199613)
 __libc_start_main at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
 unknown function (ip: 4199667)
 unknown function (ip: 0)
 zsh: segmentation fault (core dumped)  julia
 -


 So, at this point I am really stuck. Clearly I have missed a lot of 
 fundamental issues in either my C code, or my Julia code, or both. Can 
 anyone figure out what I'm doing wrong?


 Cheers,
 Daniel.

[julia-users] Re: Calling C libraries from Julia

[Jan Strube]

to suggestions -- two suggestions

On Monday, June 22, 2015 at 12:23:18 AM UTC+9, Jan Strube wrote:

 Daniel,

 I tried your code and could reproduce the problem: I have to suggestions:
 -- Julia is 1-based, so drop the 0 in your unsafe_load. The default 
 parameter is 1, which is what you want in this case.
 -- I can't really understand what your function is supposed to do (and my 
 C is a bit rusty), but this simpler version works for me.
 I suggest to start there and add the additional functionality of 
 particles_add bit by bit.

 Good luck.

 #include stdio.h
 #include stdlib.h

 int N= 7;
 int Nmax = 9;

 struct particle {
 double x;
 double y;
 double z;
 };

 struct particle* particles = NULL;

 void particles_add(struct particle pt){
 printf(%.2f\t%.2f\t%.2f\n, pt.x, pt.y, pt.z);
 }



 On Sunday, June 21, 2015 at 11:42:06 PM UTC+9, Daniel Carrera wrote:

 Hello,

 I'm trying to learn how to call C libraries from Julia. So I wrote a 
 simple C library that does nothing in particular and I am having trouble 
 talking to that library from Julia. Here is my library:

 -
 % cat foo.c
 #include stdio.h
 #include stdlib.h

 int N= 7;
 int Nmax = 9;

 struct particle {
 double x;
 double y;
 double z;
 };

 struct particle* particles = NULL;

 void particles_add(struct particle pt){
 while (Nmax = N){
 Nmax += 128;
 particles = realloc(particles,sizeof(struct particle)*Nmax);
 }
 particles[N] = pt;
 N++;
 }

 -
 % make
 gcc -Wall -std=c99 -Wpointer-arith -c -fPIC foo.c
 gcc -Wall -std=c99 -Wpointer-arith -shared -o libfoo.so foo.o
 -


 So, there are two things I would like to do from Julia: I'd like to read 
 the variable N and I'd like to create a particle struct and pass it to 
 the particles_add() function. I used the documentation on this page:

 http://julia.readthedocs.org/en/latest/manual/calling-c-and-fortran-code/

 Based on what I read, this is what I came up with:

 -
 % cat foo.jl
 const lib = ./libfoo.so

 N()= unsafe_load(cglobal((N   ,lib), Cint), 0)
 Nmax() = unsafe_load(cglobal((Nmax,lib), Cint), 0)

 immutable Particle
 x ::Cdouble
 y ::Cdouble
 z ::Cdouble
 end
 
 function add(pt::Particle)
 ccall((particles_add, lib), Void, (Particle,), pt)
 end
 
 function add(;x=0,y=0,z=0)
 add(Particle(x,y,z))
 end
 -


 However, nothing here works: I cannot read N (I get gibberish) and I 
 cannot call particles_add() (I get a segfault):

 -
 % julia
 ...
 julia include(foo.jl)
 add (generic function with 2 methods)

 julia N()
 32570

 julia Nmax()
 7

 julia add(x=0)

 signal (11): Segmentation fault
 particles_add at ./libfoo.so (unknown line)
 julia_add_20314 at  (unknown line)
 jlcall_add_20314 at  (unknown line)
 unknown function (ip: -490800184)
 unknown function (ip: -490804016)
 unknown function (ip: -490736582)
 jl_f_top_eval at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
 (unknown line)
 eval_user_input at REPL.jl:53
 jlcall_eval_user_input_20278 at  (unknown line)
 jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
 (unknown line)
 anonymous at task.jl:95
 jl_handle_stack_switch at 
 /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so (unknown line)
 julia_trampoline at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
 (unknown line)
 unknown function (ip: 4199613)
 __libc_start_main at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
 unknown function (ip: 4199667)
 unknown function (ip: 0)
 zsh: segmentation fault (core dumped)  julia
 -


 So, at this point I am really stuck. Clearly I have missed a lot of 
 fundamental issues in either my C code, or my Julia code, or both. Can 
 anyone figure out what I'm doing wrong?


 Cheers,
 Daniel.

[julia-users] Re: Calling C libraries from Julia

[Jan Strube]

PS: I'm on Julia-0.4
PPS: Your gcc call can be simplified to gcc -Wall -std=c99 -Wpointer-arith 
-fPIC -shared -o libfoo.so x.c

[julia-users] Re: Calling C libraries from Julia

[Jan Strube]

Make that
gcc -Wall -std=c99 -Wpointer-arith -fPIC -shared -o libfoo.so foo.c
  ^
I didn't copy your example correctly...

On Monday, June 22, 2015 at 12:27:36 AM UTC+9, Jan Strube wrote:

 PS: I'm on Julia-0.4
 PPS: Your gcc call can be simplified to gcc -Wall -std=c99 -Wpointer-arith 
 -fPIC -shared -o libfoo.so x.c

Re: [julia-users] Re: ccall and vectorstring from c++

[Jan Strube]

Thank you for your suggestions.
I haven't tried Cxx.jl, since that apparently requires some effort 
installing a new LLVM, which makes it harder to convince others to use the 
bindings.
Your second suggestion is unfortunately going in the wrong direction, 
taking a Julia array and passing it to C. It may be obvious to everybody 
else, but if the C code returns a Ptr{Ptr{Uint8}}, how can I convert this 
to an Array{String} on the Julia side?
I read the manual back and forth, and I understand how to convert a 
Ptr{Uint8} to a String, using bytestring, but the extension to an Array 
eludes me.




On Sunday, June 14, 2015 at 9:42:46 PM UTC+9, Yichao Yu wrote:



 On Sun, Jun 14, 2015 at 2:04 AM, Jan Strube jan.s...@gmail.com 
 javascript: wrote:

 PPS: Sorry, the segfault actually is unrelated. Nevertheless, I can't 
 figure out the right ccall signature.


 If you are on a new enough version, you can probably try Cxx.jl[1]
 Otherwise, you probably need to do the conversion yourself. Have you tried 
 `Ptr{Ptr{Cchar}}`?[1]

 [1] https://github.com/Keno/Cxx.jl
 [2] 
 http://julia.readthedocs.org/en/latest/manual/calling-c-and-fortran-code/?highlight=char**
  



 On Sunday, June 14, 2015 at 2:56:34 PM UTC+9, Jan Strube wrote:

 PS: My current attempt to return a char** from the vectorstring looks 
 like this:
 I'm converting to a vectorconst char*, then returning the address of 
 the first element.

 const char* convert(const std::string s)
 {
 return s.c_str();
 }

 const char** lcevtgetcollectionnames( void* event ){
   LCEventImpl* evt = static_castLCEventImpl*(event);
   const std::vectorstd::string* nameVec = evt-getCollectionNames();
   std::vectorconst char** names = new std::vectorconst char*;
   std::transform(nameVec-begin(), nameVec-end(), 
 std::back_inserter(*names), convert);
   return (*names)[0];
 }


 On the Julia side I'm trying this signature:
 ccall((:lcevtgetcollectionnames, test.dylib), Ptr{Cstring}, 
 (Ptr{Void},), event)

 But this results in a seg fault 

 signal (11): Segmentation fault: 11

 lcevtgetcollectionnames at /Users/stru821/Workdir/Julia/test.dylib 
 (unknown line)

 anonymous at no file:7

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

 jl_parse_eval_all at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/toplevel.c:573

 jl_load at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/toplevel.c:616

 include at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

 include_from_node1 at loading.jl:133

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/gf.c:1632

 process_options at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 _start at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 jlcall__start_18703 at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

 true_main at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/bin/julia
  
 (unknown line)

 main at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/bin/julia
  
 (unknown line)

 Segmentation fault: 11




 On Sunday, June 14, 2015 at 2:43:24 PM UTC+9, Jan Strube wrote:

 Hi,

 I'm trying to wrap the LCIO file format http://lcio.desy.de/ in Julia.
 I have a proof of principle working and am starting to add more of the 
 API.

 What totally stumps me is this signature:
 virtual const std::vector std::string  * 
 getCollectionNames 
 http://lcio.desy.de/v02-04-03/doc/doxygen_api/html/classEVENT_1_1LCEvent.html#a9128a3f65b8a94629c0cf5e77c0194ac
  () 
 const =0

 http://lcio.desy.de/v02-04-03/doc/doxygen_api/html/classEVENT_1_1LCEvent.html#a9128a3f65b8a94629c0cf5e77c0194ac

 I've created a C library to call from Julia, so I'm happy to convert 
 the return type to char**, but I just cannot figure out how to write a 
 ccall that doesn't segfault.
 I've seen various examples how to convert a Julia array of strings to a 
 char**, but couldn't find anything that converts a char** to Julia types.

 Any help is greatly appreciated.

 Jan

[julia-users] Re: ccall and vectorstring from c++

[Jan Strube]

PPS: Sorry, the segfault actually is unrelated. Nevertheless, I can't 
figure out the right ccall signature.

On Sunday, June 14, 2015 at 2:56:34 PM UTC+9, Jan Strube wrote:

 PS: My current attempt to return a char** from the vectorstring looks 
 like this:
 I'm converting to a vectorconst char*, then returning the address of the 
 first element.

 const char* convert(const std::string s)
 {
 return s.c_str();
 }

 const char** lcevtgetcollectionnames( void* event ){
   LCEventImpl* evt = static_castLCEventImpl*(event);
   const std::vectorstd::string* nameVec = evt-getCollectionNames();
   std::vectorconst char** names = new std::vectorconst char*;
   std::transform(nameVec-begin(), nameVec-end(), 
 std::back_inserter(*names), convert);
   return (*names)[0];
 }


 On the Julia side I'm trying this signature:
 ccall((:lcevtgetcollectionnames, test.dylib), Ptr{Cstring}, 
 (Ptr{Void},), event)

 But this results in a seg fault 

 signal (11): Segmentation fault: 11

 lcevtgetcollectionnames at /Users/stru821/Workdir/Julia/test.dylib 
 (unknown line)

 anonymous at no file:7

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

 jl_parse_eval_all at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/toplevel.c:573

 jl_load at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/toplevel.c:616

 include at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

 include_from_node1 at loading.jl:133

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/gf.c:1632

 process_options at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 _start at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 jlcall__start_18703 at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

 true_main at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/bin/julia
  
 (unknown line)

 main at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/bin/julia
  
 (unknown line)

 Segmentation fault: 11




 On Sunday, June 14, 2015 at 2:43:24 PM UTC+9, Jan Strube wrote:

 Hi,

 I'm trying to wrap the LCIO file format http://lcio.desy.de/ in Julia.
 I have a proof of principle working and am starting to add more of the 
 API.

 What totally stumps me is this signature:
 virtual const std::vector std::string  * 
 getCollectionNames 
 http://lcio.desy.de/v02-04-03/doc/doxygen_api/html/classEVENT_1_1LCEvent.html#a9128a3f65b8a94629c0cf5e77c0194ac
  () 
 const =0

 http://lcio.desy.de/v02-04-03/doc/doxygen_api/html/classEVENT_1_1LCEvent.html#a9128a3f65b8a94629c0cf5e77c0194ac

 I've created a C library to call from Julia, so I'm happy to convert the 
 return type to char**, but I just cannot figure out how to write a ccall 
 that doesn't segfault.
 I've seen various examples how to convert a Julia array of strings to a 
 char**, but couldn't find anything that converts a char** to Julia types.

 Any help is greatly appreciated.

 Jan

Re: [julia-users] Re: ccall and vectorstring from c++

[Jan Strube]

I had tried using this before, but incorrectly, I guess. Now this works for 
me
# returns names for collections in event
function getCollectionNameArray(event::Ptr{Void})
nameArray = String[]
names = ccall((:lcevtgetcollectionnames, libName), Ptr{Ptr{Uint8}}, 
(Ptr{Void},), event)
nNames = ccall((:lcevtgetcollectionnamecount, libName), Cint, (Ptr{Void},), 
event)
for n in 1:nNames
push!(nameArray, bytestring(unsafe_load(names, n)))
end
ccall(:free, Void, (Ptr{Ptr{Uint8}},), names)
return nameArray
end

getcollectionnamecount is just a call to vectorstring::size() on the c 
side.

Not that speed matters in my application, but this is about twice faster 
than calling out to vectorstring::at(i) on the C side for every element 
individually.
Also, it's just prettier, and my mind can stop feeling dirty now. I might 
play with returning the size also in the same call, by passing a Ref{Cint}, 
but that's for another day. 
Thank you very much for your help.


On Sunday, June 14, 2015 at 10:10:00 PM UTC+9, Yichao Yu wrote:



 On Sun, Jun 14, 2015 at 9:00 AM, Jan Strube jan.s...@gmail.com 
 javascript: wrote:

 Thank you for your suggestions.
 I haven't tried Cxx.jl, since that apparently requires some effort 
 installing a new LLVM, which makes it harder to convince others to use the 
 bindings.
 Your second suggestion is unfortunately going in the wrong direction, 
 taking a Julia array and passing it to C. It may be obvious to everybody 
 else, but if the C code returns a Ptr{Ptr{Uint8}}, how can I convert this 
 to an Array{String} on the Julia side?


 That part is just about how to declare types for ccall. After you've got a 
 char**, you can just do the same you do in C to access them.
 In julia, this is done with `unsafe_load`[3]

 [3] 
 http://julia.readthedocs.org/en/latest/stdlib/c/?highlight=unsafe_load#Base.unsafe_load
  

 I read the manual back and forth, and I understand how to convert a 
 Ptr{Uint8} to a String, using bytestring, but the extension to an Array 
 eludes me.




 On Sunday, June 14, 2015 at 9:42:46 PM UTC+9, Yichao Yu wrote:



 On Sun, Jun 14, 2015 at 2:04 AM, Jan Strube jan.s...@gmail.com wrote:

 PPS: Sorry, the segfault actually is unrelated. Nevertheless, I can't 
 figure out the right ccall signature.


 If you are on a new enough version, you can probably try Cxx.jl[1]
 Otherwise, you probably need to do the conversion yourself. Have you 
 tried `Ptr{Ptr{Cchar}}`?[1]

 [1] https://github.com/Keno/Cxx.jl
 [2] 
 http://julia.readthedocs.org/en/latest/manual/calling-c-and-fortran-code/?highlight=char**
  



 On Sunday, June 14, 2015 at 2:56:34 PM UTC+9, Jan Strube wrote:

 PS: My current attempt to return a char** from the vectorstring 
 looks like this:
 I'm converting to a vectorconst char*, then returning the address of 
 the first element.

 const char* convert(const std::string s)
 {
 return s.c_str();
 }

 const char** lcevtgetcollectionnames( void* event ){
   LCEventImpl* evt = static_castLCEventImpl*(event);
   const std::vectorstd::string* nameVec = evt-getCollectionNames();
   std::vectorconst char** names = new std::vectorconst char*;
   std::transform(nameVec-begin(), nameVec-end(), 
 std::back_inserter(*names), convert);
   return (*names)[0];
 }


 On the Julia side I'm trying this signature:
 ccall((:lcevtgetcollectionnames, test.dylib), Ptr{Cstring}, 
 (Ptr{Void},), event)

 But this results in a seg fault 

 signal (11): Segmentation fault: 11

 lcevtgetcollectionnames at /Users/stru821/Workdir/Julia/test.dylib 
 (unknown line)

 anonymous at no file:7

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

 jl_parse_eval_all at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/toplevel.c:573

 jl_load at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/toplevel.c:616

 include at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

 include_from_node1 at loading.jl:133

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/gf.c:1632

 process_options at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 _start at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 jlcall__start_18703 at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
  
 (unknown line)

 jl_apply at 
 /Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

 true_main at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/bin/julia
  
 (unknown line)

 main at 
 /Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/bin/julia
  
 (unknown line)

 Segmentation fault: 11




 On Sunday, June 14, 2015 at 2:43:24 PM UTC+9, Jan Strube wrote:

 Hi,

 I'm trying to wrap

[julia-users] ccall and vectorstring from c++

[Jan Strube]

Hi,

I'm trying to wrap the LCIO file format http://lcio.desy.de/ in Julia.
I have a proof of principle working and am starting to add more of the API.

What totally stumps me is this signature:
virtual const std::vector std::string  * 
getCollectionNames 
http://lcio.desy.de/v02-04-03/doc/doxygen_api/html/classEVENT_1_1LCEvent.html#a9128a3f65b8a94629c0cf5e77c0194ac
 () 
const =0
http://lcio.desy.de/v02-04-03/doc/doxygen_api/html/classEVENT_1_1LCEvent.html#a9128a3f65b8a94629c0cf5e77c0194ac

I've created a C library to call from Julia, so I'm happy to convert the 
return type to char**, but I just cannot figure out how to write a ccall 
that doesn't segfault.
I've seen various examples how to convert a Julia array of strings to a 
char**, but couldn't find anything that converts a char** to Julia types.

Any help is greatly appreciated.

Jan

[julia-users] Re: ccall and vectorstring from c++

[Jan Strube]

PS: My current attempt to return a char** from the vectorstring looks 
like this:
I'm converting to a vectorconst char*, then returning the address of the 
first element.

const char* convert(const std::string s)
{
return s.c_str();
}

const char** lcevtgetcollectionnames( void* event ){
  LCEventImpl* evt = static_castLCEventImpl*(event);
  const std::vectorstd::string* nameVec = evt-getCollectionNames();
  std::vectorconst char** names = new std::vectorconst char*;
  std::transform(nameVec-begin(), nameVec-end(), 
std::back_inserter(*names), convert);
  return (*names)[0];
}


On the Julia side I'm trying this signature:
ccall((:lcevtgetcollectionnames, test.dylib), Ptr{Cstring}, (Ptr{Void},), 
event)

But this results in a seg fault 

signal (11): Segmentation fault: 11

lcevtgetcollectionnames at /Users/stru821/Workdir/Julia/test.dylib (unknown 
line)

anonymous at no file:7

jl_apply at 
/Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

jl_parse_eval_all at 
/Users/vagrant/buildbot/slave/package_osx10_9/build/src/toplevel.c:573

jl_load at 
/Users/vagrant/buildbot/slave/package_osx10_9/build/src/toplevel.c:616

include at 
/Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
 
(unknown line)

jl_apply at 
/Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

include_from_node1 at loading.jl:133

jl_apply at 
/Users/vagrant/buildbot/slave/package_osx10_9/build/src/gf.c:1632

process_options at 
/Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
 
(unknown line)

_start at 
/Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
 
(unknown line)

jlcall__start_18703 at 
/Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/lib/julia/sys.dylib
 
(unknown line)

jl_apply at 
/Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:1299

true_main at 
/Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/bin/julia 
(unknown line)

main at 
/Applications/Julia-0.4.0-dev-539c818c4e.app/Contents/Resources/julia/bin/julia 
(unknown line)

Segmentation fault: 11




On Sunday, June 14, 2015 at 2:43:24 PM UTC+9, Jan Strube wrote:

 Hi,

 I'm trying to wrap the LCIO file format http://lcio.desy.de/ in Julia.
 I have a proof of principle working and am starting to add more of the API.

 What totally stumps me is this signature:
 virtual const std::vector std::string  * 
 getCollectionNames 
 http://lcio.desy.de/v02-04-03/doc/doxygen_api/html/classEVENT_1_1LCEvent.html#a9128a3f65b8a94629c0cf5e77c0194ac
  () 
 const =0

 http://lcio.desy.de/v02-04-03/doc/doxygen_api/html/classEVENT_1_1LCEvent.html#a9128a3f65b8a94629c0cf5e77c0194ac

 I've created a C library to call from Julia, so I'm happy to convert the 
 return type to char**, but I just cannot figure out how to write a ccall 
 that doesn't segfault.
 I've seen various examples how to convert a Julia array of strings to a 
 char**, but couldn't find anything that converts a char** to Julia types.

 Any help is greatly appreciated.

 Jan

Re: [julia-users] Suspending Garbage Collection for Performance...good idea or bad idea?

[Jan Kybic]

On Tuesday, December 16, 2014 at 10:24:08 PM UTC+1, Stefan Karpinski wrote:

 I would love to figure out a way to bring the kind of automatic resource 
 and memory release that Rust has to Julia, but the cost is some fairly 
 finicky static compiler analysis that is ok for Rust's target demographic 
 but fairly clearly unacceptable for Julia general audience. What we'd need 
 is a more dynamic version of something like that. One idea I've had is to 
 indicate ownership and enforce it at run-time rather than compile time – 
 and eliminate run-time checks 

 

 Given these semantics, it would be relatively easy to alloca the actual 
 memory of the array, and only heap allocate the object itself, which could 
 then reference the stack allocated memory. This is tough to implement, 
 especially efficiently, but I have a bit of a suspicion that in Julia 
 mutable objects – and this only makes sense for mutable objects that are 
 inherently associated with a particular place in memory – are rarely 
 performance critical in Julia.




In my own area (image processing and numerical calculations), using 
high-level vector and array operations in the inner loop is very 
detrimental to performance in Julia, especially if allocation of storage 
space for temporary results is needed. In order to get a decent 
performance, I usually need to (i) manually unroll the matrix operactions 
(@devec works but not always) and (ii) preallocate the temporaries and the 
output outside of the loop. The can be done by hand but it is rather 
tedious and leads to ugly code. It would be good if the compiler could 
allocate the temporaries on the stack or in a region, so that they could be 
deallocated quickly. The compiler might need some help, such as annotating 
a particular object as alias-free, which would probably lead to 
rust-like annotations. But if it brings performance, I would not mind.

Yours,

Jan

[julia-users] Re: Default behavior from omitted catch block when a finally block is added.

[Jan van Oort]

 there is something to be said for the explicitness that comes with only 
catching exceptions when there is a catch keyword involved.

Absolutely. Please go that way. It would be even better to make a catch 
mandatory with each try, in order to ( as someone else here said ) ease 
the load on programmers' brains. 

Anything else would veer off into the exotic, IMHO. 




Op dinsdag 7 april 2015 20:54:18 UTC+2 schreef Harry B:

 Hello All,

 I find the following behavior a bit non-intuitive. IMHO, if addition of 
 finally block changes the default behavior provided by the omitted catch 
 block, we should force the user to declare a catch block.

 # Version 0.4.0-dev+4160 (2015-04-06 03:40 UTC)  Commit 8fc5b4e* (1 day 
 old master) x86_64-apple-darwin13.4.0

 julia function f1(x)
try
return x  0 ? x/2 : error(x should be greater than zero)
end # Let us assume user wants to ignore exception...
println(returning normally without exception)
-1
end
 f1 (generic function with 1 method)

 julia f1(1)
 0.5

 julia f1(-1)
 returning normally without exception
 -1

 julia function f2(x)
fp = open(/tmp/unrelated_resource.txt, w)
try
return x  0 ? x/2 : error(x should be greater than zero)
finally
close(fp) # only change is to close the file, no change 
 intended for default on missing-catch-block
end
println(returning normally)
-1
end
 f2 (generic function with 1 method)

 julia f2(1)
 0.5

 julia f2(-1)
 ERROR: x should be greater than zero
  in f2 at none:4

 julia

 Thanks
 --
 Harry

Re: [julia-users] Re: Caching of code generated by macros

[Jan Niklas Hasse]

2015-02-02 4:00 GMT+01:00  julia.eliso...@gmail.com:
 Others will know a lot more about this, but caching of already compiled
 Julia code is a very large issue.  It may be safe to say it is the largest
 current issue for the language now that a new GC has been merged into 0.4.
 So this is to say that you aren't alone in long start up times for Julia.

I see, thanks. I've also tried Speed.jl, but it didn't help. Guess I
will wait for a solution in Julia itself :)

[julia-users] Caching of code generated by macros

[Jan Niklas Hasse]

Hi!

I've just tried the Match.jl package and it works just as expected. But now 
my program needs 10 extra seconds to start, even if the code using the 
@match macro is untouched. Is there anyway to cache the generated code?

If I understand the docs correctly this only works if I move the code using 
the macro into its own module. Is this correct?

[julia-users] Size of Julia types

[Jan Niklas Hasse]

Hi!

I'm new to Julia and was wondering why

type A
x::Ptr{Void}
y::Ptr{Void}
end

type B
x::A
end

assert(sizeof(A) == sizeof(B))

doesn't work while the C version

#include assert.h

struct A {
void* x;
void* y;
};

struct B {
A x;
};

int main() {
assert(sizeof(A) == sizeof(B));
}

does? This causes a segfault in my FreeType.jl wrapper.

Re: [julia-users] Size of Julia types

[Jan Niklas Hasse]

2015-01-14 11:43 GMT+01:00 Tim Holy tim.h...@gmail.com:
 If you can, use

 immutable B
 x::A
 end

 The type version contains a reference to an A, not the entire A structure
 itself. The C analog of what you were doing would be

 struct B {
 A* x;
 };

 which of course doesn't have the same size as A.

 --Tim

 On Wednesday, January 14, 2015 02:22:19 AM Jan Niklas Hasse wrote:
 Hi!

 I'm new to Julia and was wondering why

 type A
 x::Ptr{Void}
 y::Ptr{Void}
 end

 type B
 x::A
 end

 assert(sizeof(A) == sizeof(B))

 doesn't work while the C version

 #include assert.h

 struct A {
 void* x;
 void* y;
 };

 struct B {
 A x;
 };

 int main() {
 assert(sizeof(A) == sizeof(B));
 }

 does? This causes a segfault in my FreeType.jl wrapper.

I see. Thanks to you both :)

Now I got it working:
https://github.com/jhasse/FreeType.jl/commit/2297d9c2c93c27466920acba46f9983dac882635

Re: [julia-users] Re: home page content

[Jan Niklas Hasse]

 Am I the only one who thinks these runnable code widgets are totally 
 useless?  I'm curious as to how users interact with them in the real 
 world.  I bet 99% of them either ignore it or just press the button and see 
 the default output.  The ones who probably interact with it the most are 
 going to be the same users that are going to download and run the language 
 anyway.  They displace huge amounts of real estate for basically no 
 practical value.  

 To me the landing page to a programming language is really a nice backdrop 
 for four things, A giant button where I can go download what I want because 
 I'm lazy and just click on the top google hit.  Another prominent link to 
 the Julia package ecosystem because I'm lazy and typing julia AND 
 packages is way too much work (haskell did a survey a while back, if I 
 remember correctly a majority of users to the front page fell under this 
 category). In addition, enough background information to get people to 
 click on the manual and a nice community / development activity section so 
 I can see that things are happening.  Please, please don't make me scroll 
 past a huge useless web 2.0 header to get to what I actually want (again, 
 lazy).  I like the  Racket, Haskell, and OCaml websites as I think they are 
 utilitarian but actually useful. I agree that the Rust site is a bit too 
 minimalist. I absolutely hate the python website.  The R website is just 
 laughably bad.  Altogether, I don't think PL's set a high bar in this 
 regard. 

 -Jake


No you're not the only one ;)
Unfortunately http://forio.com/julia/repl/ doesn't work anymore, in my 
opinion it was excellent and a link to it on the front page would be enough.

For everyone who doesn't already know, I've uploaded a preview of my 
homepage revamp here: http://julialang.herokuapp.com/
If you like I can use that page for a sandbox for ideas that come up during 
this discussion.

[julia-users] Re: Code Optimization Question

[Jan Strube]

Maybe slightly off-topic, but it looks like you're using temp as a (1, 3) 
Array, rather than a (3, 3).


On Wednesday, November 19, 2014 10:09:49 AM UTC+9, Ryan Young wrote:

 Hello,

 I am new to julia and am working on some neuroimaging analysis.  I have a 
 function that calculates the Jacobian of the deformation field at each 
 point in the deformation field.  A qr decomposition is then done on the 
 Jacobian.  The principle eigenvector of the strain portion of the QR 
 decomposition is rotated, stored in an array and returned.

 I was not going to parallelize this function as I think it is easier to do 
 a pmap of this process over all of the samples. Currently, this is taking a 
 few minutes to run on one large deformation field (225,425,225,3).  All the 
 time is being taken up in the last three lines of the for loop.  Any advice 
 is greatly appreciated. 

 Thanks
 Ryan


 function calcJac(deformation::Array{Float32,4})
 temp=Array(Float32,3,3)
 r=Array(Float32,3,3)
 s=Array(Float32,3,3)
 ev=Array(Float32,3,3)
 
 i,j,k=size(deformation)
 final=Array(Float32,i,j,k,3)
   
 for x in 3:i-3
 for y in 3:j-3
 for z in 3:k-3
 
 #compute frist row of jacobain
 
 temp[1,1]=(-deformation[x+2,y,z,1]+8*deformation[x+1,y,z,1]-8*deformation[x-1,y,z,1]+deformation[x-2,y,z,1])/12.0
 
 temp[1,2]=(-deformation[x+2,y,z,2]+8*deformation[x+1,y,z,2]-8*deformation[x-1,y,z,2]+deformation[x-2,y,z,2])/12.0
 
 temp[1,3]=(-deformation[x+2,y,z,3]+8*deformation[x+1,y,z,3]-8*deformation[x-1,y,z,3]+deformation[x-2,y,z,3])/12.0

 #compute 2nd row of jacobian
 
 temp[1,1]=(-deformation[x,y+2,z,1]+8*deformation[x,y+1,z,1]-8*deformation[x,y-1,z,1]+deformation[x,y-2,z,1])/12.0
 
 temp[1,2]=(-deformation[x,y+2,z,2]+8*deformation[x,y+1,z,2]-8*deformation[x,y-1,z,2]+deformation[x,y-2,z,2])/12.0
 
 temp[1,3]=(-deformation[x,y+2,z,3]+8*deformation[x,y+1,z,3]-8*deformation[x,y-1,z,3]+deformation[x,y-2,z,3])/12.0

 #compute third row of jacobian
 
 temp[1,1]=(-deformation[x,y,z+2,1]+8*deformation[x,y,z+1,1]-8*deformation[x,y,z-1,1]+deformation[x,y,z-2,1])/12.0
 
 temp[1,2]=(-deformation[x,y,z+2,2]+8*deformation[x,y,z+1,2]-8*deformation[x,y,z-1,2]+deformation[x,y,z-2,2])/12.0
 
 temp[1,3]=(-deformation[x,y,z+2,3]+8*deformation[x,y,z+1,3]-8*deformation[x,y,z-1,3]+deformation[x,y,z-2,3])/12.0

 r,s=qr(temp)
 ev=eigvecs(s)
 final[x,y,z,:]=r*ev[:,1]

 end
 end
 end

 return final
 end

Re: [julia-users] Re: ANN: revamped Images based on Color, FixedPointNumbers

[Jan Kybic]

If you do Pkg.update(), then

reinterpret(Uint8, separate(img))

should work. If you think this needs to be documented, please add it to the 

It does not currently work for me:

julia img=imread(imgs/simple.png)
RGB Image with:
  data: 320x200 Array{RGB{UfixedBase{Uint8,8}},2}
  properties:
IMcs: sRGB
spatialorder:  x y
pixelspacing:  1 1

julia i=reinterpret(Uint8,separate(img))
ERROR: auto_unbox: unable to determine argument type
 in reinterpret at number.jl:46


Changing the order of both operations works:

   i=separate(reinterpret(Uint8,img))

I will look at the README again when I have more time and better understanding
of what is happening.

One of the advantages of representing as an RGB type is that, for most 
algorithms, you no longer need to worry about this: you can process all 3 
color channels at once, because operations are defined for RGB that allow you 
to add, multiply, etc. But use reinterpret or separate if you still want/need 
to do this.

I understand what you mean and in the new code I will try to take
advantage of this. 

Do you know if there is any performance penalty? I have tried to measure
it but it is hard since the time seems to be dominated by garbage collection.

The most general and efficient way is to use Julia's multiple dispatch: write 
different versions of your algorithm for

Yes but sometimes I would like to write quickly a function that works
for all images, without worrying about different image representation,
and specialize for speed later. 

Well, I guess this is the price to pay for offering different
choices. It hits me now because I have already some code written and
need to adapt it. In the future, I will just stick to one type of image
representation.

Yours,

Jan

-- 
-
Jan Kybic ky...@fel.cvut.cz   tel. +420 2 2435 5721 or 5877
http://cmp.felk.cvut.cz/~kybic  

[julia-users] Re: ANN: revamped Images based on Color, FixedPointNumbers

[Jan Kybic]

On Friday, September 5, 2014 11:07:05 PM UTC+2, Tim Holy wrote:

 I'm pleased to announce a major overhaul of the Images package. The big 
 change 
 is deeper integration with other packages: Color and FixedPointNumbers. 


Thank you very much for your work, I am sure these changes are in the good 
direction. But of course, some of the changes break existing code, as I 
have discovered myself today - after Pkg.update() my code no longer works. 
I am sure I will find the problems and correct them but at the moment I 
just wanted to make some more general comments:

a) The seemingly innocent command 'Pkg.update()' is actually quite 
dangerous. Could it not warn - there are important changes in package XXX, 
you can read about them in YYY, are you sure you want to update now?

b) Backward compatibility is very  important. People will get angry if they 
have to change their code with every new version. I know it is not always 
possible but it would be nice to have the old style and new style live 
together in parallel for some time, while issuing depreciation warnings, 
before actually changing the default behaviour.  

Keep up the good work. Yours,

Jan

Re: [julia-users] Re: ANN: revamped Images based on Color, FixedPointNumbers

[Jan Kybic]

On Fri, Oct 3, 2014 at 6:22 PM, Tim Holy tim.h...@gmail.com wrote:

 Where the problems come in is if your code was exploiting some aspect of the
 raw representation of images. In such cases, there is no way to achieve co-
 existence: the image either uses one representation or another, not both. So
 unfortunately it's not possible for me to maintain compatibility the way you
 seem to be asking for. In general, where possible I recommend trying to use
 the API in Images rather than digging into the internal representation---
 that's your best protection against changes.


Yes, I had to interface with some older Python and C code, so I
converted the Image to Array using

 convert(Array,img)

which used to give me an Uint8 array n x m x 3 (for colour images)
that I could for example directly pass to the Python routine using
pycall.

In the new version of Images, this command returns a 2D Array of a new
type, UfixedBase{Uint8,8}.
The README suggests to use separate to get the Matlab color-last
representation, but the element type remains different than before.
Here, the README did not offer much help. I finally came up with

 convert(Array,uint8(integer(255*separate(img

or better

  reinterpret(Uint8,convert(Array,separate(img)))

which seems to work.

My second problem was that I tried to get the color dimension by
size(img,colordim(img)), in order to process each colour channel
separately. This is actually taken from the documentation
(https://github.com/timholy/Images.jl/blob/master/doc/core.md) but it
no longer works, as colordim(img) returns 0. So what is the
recommended way of finding out, whether the image is a color image or
not? Could you update the example in core.md, to show what is the
generic way of processing the color channels one by one?
What I did for the moment was to convert it to Array as above and
counting the number of dimensions but that is obviously not a robust
solution.

This seems to have solved my most problems, although more keep
creeping up as I test some less-often used parts of the code because I
made assumption about the image element type. (I am looking forward to
Julia being able to perform strong typechecking at compile time, this
would find the errors very quickly.) I find it surprisingly difficult
to write a truly generic and type-stable code, especially if it uses
legacy libraries.

Yours,

Jan



-- 
-
Jan Kybic ky...@fel.cvut.cztel. +420 2 2435 5721
http://cmp.felk.cvut.cz/~kybic  ICQ 200569450

Re: [julia-users] Re: Compile-time switchable @assert

[Jan Kybic]

On Tuesday, August 19, 2014 12:11:49 PM UTC+2, Kevin Squire wrote:

 Also check out Logging.jl, which does have macros for enabling/disabling 
 printing/logging at different levels.


Thank you for point out Logging.jl, it seems to do what I was looking for.

Jan 

[julia-users] Re: Incorrect type conversion for ImmutableArrays

[Jan Kybic]

On Friday, August 15, 2014 12:13:42 PM UTC+2, Tobias Knopp wrote:

 This is a bug but I am not sure on which side. The convert function is 
 wrong because it does not create the type that is passed. But maybe Julia 
 should not create the immutable type when seeing this.

 Could you please file a bug on the ImmutableArrays.jl project page? I will 
 file one on the Julia bug tracker.



I have just reported the issue in ImmutableArrays.jl: 
https://github.com/twadleigh/ImmutableArrays.jl/issues/35 

Jan

[julia-users] Incorrect type conversion for ImmutableArrays

[Jan Kybic]

Dear all,

I am seeing an unexpected behaviour when combining ImmutableArrays and 
struct like types (I forgot what the proper name is). In particular, the 
following code:

using ImmutableArrays

immutable Mytype
pos::Vector2{Float32}
end

println(Mytype([4.; 5.]))


incorrectly prints Mytype(Float32[0.0,2.25]) instead of the expected 
Mytype(Float32[4.0,5.0]). This is on the latest Ubuntu, 
Julia 0.3.0-prerelease+3628 (2014-06-11 15:07 UTC).

Both Mytype([4f0; 5f0]) and convert(Vector2{Float32},[4.;5.]) work as 
expected but changing immutable to type does not change the error.

So is there a bug in ImmutableArrays, in Julia, or am I doing something 
wrong? If I am doing something wrong, I would at least expect a warning - 
this error cost me quite some time to find out.

Maybe I do not understand how ImmutableArrays is supposed to work, since

  typeof(convert(Vector2{Float32},[4.;5.]).e1)

gives Float64, not Float32 as expected. So is ImmutableArrays actually an 
efficient way of storing fixed-size vectors? Or do I have to stick to 
Float64 even if I do not need the accuracy?


Thank you for your help. Yours,


Jan

Re: [julia-users] type checking at compile time

[Jan Kybic]

 I've been wondering what, if any kinds of checks or warnings Julia gives 
 at compile time, or if there are any packages that can type check and give 
 you warnings on your code.


Dear Julia developers,

first of all let me thank you for all your hard work. I have started to use 
Julia recently to develop image processing algorithms and I have been very 
pleasantly surprised by the achievable performance of Julia code (although 
it makes the code less elegant), easy parallelisation, relatively low 
penalty for genericity and the breadth of available libraries. 

However, let me vote strongly in favor if incorporating more compile-time 
checks. This is my biggest issue with Julia. Too many errors are discovered 
only when the code is run, which makes the development cycle slow, 
especially if the code takes non-trivial time to execute. I admit I am 
sloppy and I make stupid errors. But languages like Ocaml, C or  Java will 
let me know when compiling, usually in less than a second. [Ocaml used to 
be my favorite language for a long time and if it allowed a little more 
flexibility, had a little better performance and supported multicore, I 
would continue using it. There, when something compiled, it almost always 
also ran and gave results, surprisingly often good results.] With Julia 
(and Matlab and Python), I need to actually run the code to find out. 
Although I obviously try to test my code on small examples first, it is 
still annoying to see most of the code run fine, only to find a typo in the 
last few (recently added) lines. This decreases my productivity.

It seems that most of the errors could be easily detected by compile-time 
static analysis. For example, Julia will happily compile the following:

function test()
unknown_function()
end


function test2()
println(unknown_variable)
end

Lint.lintfile catches the second error but not the first, 
TypeCheck.check_method_calls will not find either. I think I understand the 
reason - Julia expects that perhaps some other code will define 
unknown_function and unknown_variable before test() or test2() are run. 
I understand there might be case for that kind of dynamic code but it 
seems to be a rather unusual (and dangerous) pattern. Could not there be a 
compiler switch  that would say
a) my functions do not use any global variables except when explicitly 
marked; and
b) my functions are not calling any function created on-the-fly, except 
when explicitly marked; or
c) my functions do not use anything not known at this point except when 
explicitly marked (forward references)

Or perhaps the compiler could output a warning (not an error), with a 
possibility to switch it off, if the programmer knows what he/she is doing.

The third kind of common errors I am getting is no method xxx when I get 
the types wrong, as in

function test3()
println(3^[3;2])
end


I would love the compiler to let me know (as in Ocaml or Haskell). I 
understand that this conflicts with some design choices (such as functions 
not having a fixed return type) but in test3(), everything is static and 
known, so the compiler should be able to tell me.

If the compiler could report these problems, it would be in my opinion a 
big step towards increasing the productivity of Julia programmers. 

Keep up the good work. Yours,

Jan

Re: [julia-users] Fast method dispatch depending on constant parameter value

[Jan Drugowitsch]

 I think you should assume you have to perform branching at run-time 
 whenever you want to condition behavior on values (like -1 vs. +1) rather 
 than on types (like Float64 vs. Int64). 

 So I think it’s going to be very difficult to achieve the goal you have in 
 mind. 


Thanks for your reply!

In C++ I do not see any problem implementing this, using virtual methods 
with explicitly specified return types. As in Julia return types are 
inferred rather than specified, I don't see this possibility, but I was 
wondering if I am missing something. I might indeed just go with macros.

Jan

On Jul 30, 2014, at 3:00 AM, Jan Drugowitsch jdr...@gmail.com javascript: 
 wrote: 

  Hi all, 
  
  I've been recently running into a presumably frequently occurring 
 problem, and was wondering what the best way is to solve this in Julia. The 
 problem is how to dynamically choose amongst a set of functions based on 
 some constant parameter value (without the use of macros, which usually 
 make my head hurt). A use case would be the sampler for a probability 
 distribution for which several algorithms exist, and whose choice depends 
 on the parameters of this distribution. Given that this distribution is 
 implemented as an immutable class, one would want to pick the best 
 algorithm at construction of a class instance rather than evaluating it at 
 every time the sampler is called. 
  
  More specifically, an abstract example is to have some function 
 f(a::BaseA, x::Number) that chooses among 
  
  f1(x::Number) = x + 10 
  f2(x::Number) = x - 10 
  
  based on if some parameter y, used to construct BaseA(y), is positive of 
 negative. In addition, we would like to add generic vectorization, akin to 
  
  abstract BaseA 
  f{T : Number}(a::BaseA, x::Vector{T}) = [f(a, xi) for xi in x] 
  
  The fastest approach might be 
  
  immutable A0 : BaseA 
  y::Float64 
  A0(y::Number) = new(float(y)) 
  end 
  f(a::A0, x::Number) = a.y = 0.0 ? f1(x) : f2(x) 
  f{T : Number}(a::A0, x::Vector{T}) = a.y = 0.0 ? [f1(xi) for xi in x] 
 : [f2(xi) for xi in x] 
  
  that is, re-implementing the vectorization, to avoid a.y = 0.0 to be 
 called for every vector element. This seems to defeat the purpose of 
 writing generic methods. A second possibility is to perform the comparison 
 of y at every iteration by 
  
  immutable A1 : BaseA 
  y::Float64 
  A1(y::Number) = new(float(y)) 
  end 
  f(a::A1, x::Number) = a.y = 0.0 ? f1(x) : f2(x) 
  
  For both implementation I find around the same run-time (vector of size 
 10^8, no gc): 
  
  A0: elapsed time: 0.687105729 seconds (160096 bytes allocated) 
  A1: elapsed time: 0.696713456 seconds (160096 bytes allocated) 
  
  However, I don't find either of them particularly satisfactory. A third 
 option would be to choose the function at construction of a: 
  
  immutable A2 : BaseA 
  f::Function 
  A2(y::Number) = new(y = zero(y) ? f1 : f2) 
  end 
  f(a::A2, x::Number) = a.f(x) 
  
  However, this is slow (elapsed time: 25.70402182 seconds (791920 
 bytes allocated)), and defeats type inference (returns Array{Any,10^8}). As 
 last option would be to construct instances of different classes, depending 
 on y: 
  
  immutable _A3f1 : BaseA; end 
  f(a::_A3f1, x::Number) = f1(x) 
  immutable _A3f2 : BaseA; end 
  f(a::_A3f2, x::Number) = f2(x) 
  A3(y::Number) = y = zero(y) ? _A3f1() : _A3f2() 
  
  This is (surprisingly) still slower than A0 and A1 (elapsed time: 
 1.360536247 seconds (160096 bytes allocated)), and just shifts the 
 problem of type inference one level higher. 
  
  Are there any better solutions to tackle this, or are macros the only 
 way? 
  
  Thanks for your helps, 
  Jan 

Re: [julia-users] Fast method dispatch depending on constant parameter value

[Jan Drugowitsch]

The below looks structurally the same as my last example (class A3). Is 
there a crucial difference that I am missing?

Thanks,
Jan

On Wednesday, 30 July 2014 23:20:36 UTC+2, g wrote:

 If the number is available when the type is constructed, you can use it to 
 construct a different type based upon it's value. Does this do what you 
 want?

 abstract BaseA
 immutable AP : BaseA
a
 end
 immutable AN : BaseA
a
 end
 A(x,y) = y0 ? AP(x) : AN(x)
 f(a::AP, x::Number) = x+a.a
 f(a::AN, x::Number) = x-a.a
 f(A(4,2323.2), 4)
 f(A(4,-2), 4)

 f(a::BaseA, x::Vector) = [f(a, xi) for xi in x]
 f(A(4,-2), [1:10])
 f(A(4,2), [1:10])

[julia-users] Fast method dispatch depending on constant parameter value

[Jan Drugowitsch]

Hi all,

I've been recently running into a presumably frequently occurring problem, 
and was wondering what the best way is to solve this in Julia. The problem 
is how to dynamically choose amongst a set of functions based on some 
constant parameter value (without the use of macros, which usually make my 
head hurt). A use case would be the sampler for a probability distribution 
for which several algorithms exist, and whose choice depends on the 
parameters of this distribution. Given that this distribution is 
implemented as an immutable class, one would want to pick the best 
algorithm at construction of a class instance rather than evaluating it at 
every time the sampler is called.

More specifically, an abstract example is to have some function f(a::BaseA, 
x::Number) that chooses among

f1(x::Number) = x + 10
f2(x::Number) = x - 10

based on if some parameter y, used to construct BaseA(y), is positive of 
negative. In addition, we would like to add generic vectorization, akin to

abstract BaseA
f{T : Number}(a::BaseA, x::Vector{T}) = [f(a, xi) for xi in x]

The fastest approach might be

immutable A0 : BaseA
y::Float64
A0(y::Number) = new(float(y))
end
f(a::A0, x::Number) = a.y = 0.0 ? f1(x) : f2(x)
f{T : Number}(a::A0, x::Vector{T}) = a.y = 0.0 ? [f1(xi) for xi in x] : 
[f2(xi) for xi in x]

that is, re-implementing the vectorization, to avoid a.y = 0.0 to be 
called for every vector element. This seems to defeat the purpose of 
writing generic methods. A second possibility is to perform the comparison 
of y at every iteration by

immutable A1 : BaseA
y::Float64
A1(y::Number) = new(float(y))
end
f(a::A1, x::Number) = a.y = 0.0 ? f1(x) : f2(x)

For both implementation I find around the same run-time (vector of size 
10^8, no gc):

A0: elapsed time: 0.687105729 seconds (160096 bytes allocated)
A1: elapsed time: 0.696713456 seconds (160096 bytes allocated)

However, I don't find either of them particularly satisfactory. A third 
option would be to choose the function at construction of a:

immutable A2 : BaseA
f::Function
A2(y::Number) = new(y = zero(y) ? f1 : f2)
end
f(a::A2, x::Number) = a.f(x)

However, this is slow (elapsed time: 25.70402182 seconds (791920 bytes 
allocated)), and defeats type inference (returns Array{Any,10^8}). As last 
option would be to construct instances of different classes, depending on y:

immutable _A3f1 : BaseA; end
f(a::_A3f1, x::Number) = f1(x)
immutable _A3f2 : BaseA; end
f(a::_A3f2, x::Number) = f2(x)
A3(y::Number) = y = zero(y) ? _A3f1() : _A3f2()

This is (surprisingly) still slower than A0 and A1 (elapsed time: 
1.360536247 seconds (160096 bytes allocated)), and just shifts the 
problem of type inference one level higher.

Are there any better solutions to tackle this, or are macros the only way?

Thanks for your helps,
Jan

[julia-users] Append! resulting in #undef elements. Intended behavior?

[Jan Strube]

Hi List!

I'm a particle physicist just getting started with some julia. I've been 
using some python in the past but now I'm trying to use analyzing some lab 
data as an excuse to learn Julia.
So far it looks like I'm going to stick with it for a while.

I've been trying to play with basic image analysis, and I've come across 
the following behavior: append! complains that it doesn't find a suitable 
method for my call signature, but it does append an #undef. Is this 
intended?

Please see below for a session.



   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type help() to list help topics
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.3.0-rc1 (2014-07-14 02:04 UTC)
 _/ |\__'_|_|_|\__'_|  |  
|__/   |  x86_64-apple-darwin13.3.0

julia x = Array[]
0-element Array{Array{T,N},1}

julia append!(x, Array[1])
ERROR: `convert` has no method matching convert(::Type{Array{T,N}}, ::Int64)
 in getindex at array.jl:121

julia x
0-element Array{Array{T,N},1}

julia append!(x, Array[[1]])
1-element Array{Array{T,N},1}:
 [1]

julia append!(x, [1])
ERROR: `convert` has no method matching convert(::Type{Array{T,N}}, ::Int64)
 in copy! at abstractarray.jl:197
 in append! at array.jl:475

julia x
2-element Array{Array{T,N},1}:
[1]
 #undef

Re: [julia-users] Append! resulting in #undef elements. Intended behavior?

[Jan Strube]

Thank you for reporting the issue.
I wasn't sure, but I thought I'd mention this as long as it's still a RC.

Jan


On Friday, July 18, 2014 4:55:36 AM UTC+9, Simon Kornblith wrote:

 The fact that append! grows the array on failure seems like a bug 
 nonetheless. If convert throws it seems preferable to leave the array as 
 is. I'll file an issue.

 Simon

 On Thursday, July 17, 2014 9:34:21 AM UTC-4, Jacob Quinn wrote:

 Hi Jan,

 You have your syntax a little mixed up. The usage of:

 Type[]

 actually declares an empty array with element type of `Type`. So you're 
 first line:

 x = Array[]

 is actually creating an array of arrays.

 Likewise, you're seeing the error in

 Array[1]

 Because you're trying to put an Int[1] array into an array of arrays (and 
 julia doesn't know how to make that conversion).

 The last error is unfortunate, because it seems that the call to 
 `append!` is allocating space for the array you're appending but then fails 
 when actually trying to put the 2nd array into the newly allocated space. 
 Because `append!` is mutating, you're left with your original array mutated 
 with the extra space, with the #undef.

 I think the semantics you're looking for are as follows:

 x = Int[]  # declares an empty 1-d array with element type of `Int`

 y = [1, 2, 3]  # literal syntax for creating an array with elements, (1, 
 2, 3). Type inference figures out that the elements are of type `Int`

 append!(x,y)  # mutates the `x` array by appending all the elements of y 
 to it; this works because they're both of the same type

 push!(x, 5)  # adds a single element, 5,  to the `x` array 

 Feel free to read through the section in teh manual on arrays to get a 
 better feel for what's going on.

 http://docs.julialang.org/en/latest/manual/arrays/

 Cheers,

 -Jacob


 On Thu, Jul 17, 2014 at 8:21 AM, Jan Strube jan.s...@gmail.com wrote:



 Hi List!

 I'm a particle physicist just getting started with some julia. I've been 
 using some python in the past but now I'm trying to use analyzing some lab 
 data as an excuse to learn Julia.
 So far it looks like I'm going to stick with it for a while.

 I've been trying to play with basic image analysis, and I've come across 
 the following behavior: append! complains that it doesn't find a suitable 
 method for my call signature, but it does append an #undef. Is this 
 intended?

 Please see below for a session.



_   _ _(_)_ |  A fresh approach to technical computing
   (_) | (_) (_)|  Documentation: http://docs.julialang.org
_ _   _| |_  __ _   |  Type help() to list help topics
   | | | | | | |/ _` |  |
   | | |_| | | | (_| |  |  Version 0.3.0-rc1 (2014-07-14 02:04 UTC)
  _/ |\__'_|_|_|\__'_|  |  
 |__/   |  x86_64-apple-darwin13.3.0

 julia x = Array[]
 0-element Array{Array{T,N},1}

 julia append!(x, Array[1])
 ERROR: `convert` has no method matching convert(::Type{Array{T,N}}, 
 ::Int64)
  in getindex at array.jl:121

 julia x
 0-element Array{Array{T,N},1}

 julia append!(x, Array[[1]])
 1-element Array{Array{T,N},1}:
  [1]

 julia append!(x, [1])
 ERROR: `convert` has no method matching convert(::Type{Array{T,N}}, 
 ::Int64)
  in copy! at abstractarray.jl:197
  in append! at array.jl:475

 julia x
 2-element Array{Array{T,N},1}:
 [1]
  #undef