[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.

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?
>>
>>

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. 
>

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?

[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

[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

[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