[julia-users] Re: Unitful.jl for physical units

[Andrew Keller]

Hi Yousef, 

Yes, I anticipate that there will be a simpler way to add units sometime, 
probably via a macro. However, my concern first and foremost is to make 
sure that operations involving units do not fail unexpectedly, particularly 
where ranges, arrays, and matrices are involved. This is really key for 
widespread adoption, I think, as well as for my own application. I'd also 
like to make it so that exact conversions are preserved where possible (see 
issue #3 on the Github page). In the meantime, you're welcome to submit a 
pull request for the units you need, or just modify your local copy.

Thanks to everyone for the positive feedback! It looks like there was a 
recent commit to Julia master that may introduce some breakage—I'll 
prioritize fixing that once the Mac OS X binary for Julia is updated. I may 
fix it sooner since I was able to build master.

Best
Andrew

On Tuesday, February 16, 2016 at 6:11:52 AM UTC-8, yousef.k...@gmail.com 
wrote:
>
> Hello Andrew,
>
> Your work is very promising. If you have ever dealt with oil field 
> equations, then you'll know that units are a headache to deal with.
> Your package should make life much easier.
>
> I'm curious, however, as if you'll implement an easier means of defining 
> new units.
> Something like a function that takes a unit, its base factor, and its 
> conversion to SI units, then gets it working in Unitful.
>
> Thanks again for your work,
> Yousef
>

Re: [julia-users] Cxx.jl object address stability?

[Keno Fischer]

Sorry, didn't see this before.

The answer is that anything of type CppValue will be owned by julia and
destructed upon GC. Right now that should be stable, but I will not
guarantee that given future possible directions of the language, so for use
cases like this I would recommend keeping the object on the C++ heap so you
have explicit control over addresses.

On Thu, Feb 11, 2016 at 7:09 AM, Oliver Schulz  wrote:

> Hi,
>
> is the memory address (seen from C++) of objects created via `@cxx
> SomeClass()` (or similar) stable over time (GC cycles)?
>
> I need to use a container class whose elements keep a pointer to the
> container itself. I want Julia to own the container, so it should be
> subject to garbage collection. The container owns it's elements and deletes
> them on destruction, so they can't outlive the container object. But
> obviously, the address of the container object must not change over time,
> else things will break. So is it safe to do
>
> container = @cxx Container()
>
> or
>
> container = icxx""" Container(); """
>
> Or do I need to do something like
>
> container = icxx""" std::unique_ptr(new Container); """
>
> I would assume that "container.data" moves around during GC cycles, so
> that `icxx""" &$container """` wouldn't be stable over GC cycles. But
> this little test seems to indicate that it actually may be stable:
>
> cxx"""
> struct MyContainer {
> MyContainer* m_origAddr;
> MyContainer* origAddr() { return m_origAddr; }
> MyContainer* currAddr() { return this; }
> bool checkAddr() { return currAddr() == origAddr(); }
> MyContainer() { m_origAddr = this; }
> };
> """
>
> typealias MyContainer
> cxxt"MyContainer"{Int(icxx"""sizeof(MyContainer);""")}
>
> rndarray = rand(1000,1000,100)
>
> containers = Vector{MyContainer}()
> for i in 1:2000 push!(containers, @cxx MyContainer()) end
> assert(all(x -> icxx""" $x.checkAddr(); """, containers))
>
> rndarray = rand(10,10,10)
> gc()
>
> assert(all(x -> icxx""" $x.checkAddr(); """, containers))
>
> Keno, help ... ? ;-)
>
>
> Cheers,
>
> Oliver
>
>

Re: [julia-users] Re: Cxx.jl object address stability?

[Oliver Schulz]

Thanks, Yichao!

On Tuesday, February 16, 2016 at 8:55:29 PM UTC+1, Yichao Yu wrote:
>
>
> On Feb 16, 2016 2:38 PM, "Oliver Schulz"  > wrote:
> >
> > Hello,
> >
> > I realized that this question is probably not specific to Cxx.jl, but 
> concerns Julia's garbage collection in general: Is it save to keep a 
> pointer to a Julia-owned object in an FFI environment (e.g. from C), as 
> long as the object is not GC'ed? From what I saw, the current Julia garbage 
> collector is non-moving. Should I be prepared for Julia to switch to a 
> moving/compacting GC in the foreseeable future, or is a next-generation GC 
> for Julia likely to be non-moving as well?
>
> We'd like to try out moving but even if it is implemented, we will 
> definitely have a relatively easy way to pin the object.
>
> >
> >
> > Cheers,
> >
> > Oliver
> >
> >
> > On Thursday, February 11, 2016 at 1:09:44 PM UTC+1, Oliver Schulz wrote:
> >>
> >> Hi,
> >>
> >> is the memory address (seen from C++) of objects created via `@cxx 
> SomeClass()` (or similar) stable over time (GC cycles)?
> >>
> >> I need to use a container class whose elements keep a pointer to the 
> container itself. I want Julia to own the container, so it should be 
> subject to garbage collection. The container owns it's elements and deletes 
> them on destruction, so they can't outlive the container object. But 
> obviously, the address of the container object must not change over time, 
> else things will break. So is it safe to do
> >>
> >> container = @cxx Container()
> >>
> >> or
> >>
> >> container = icxx""" Container(); """
> >>
> >> Or do I need to do something like
> >>
> >> container = icxx""" std::unique_ptr(new Container); """
> >>
> >> I would assume that "container.data" moves around during GC cycles, so 
> that `icxx""" &$container """` wouldn't be stable over GC cycles. But this 
> little test seems to indicate that it actually may be stable:
> >>
> >> cxx"""
> >> struct MyContainer {
> >> MyContainer* m_origAddr;
> >> MyContainer* origAddr() { return m_origAddr; }
> >> MyContainer* currAddr() { return this; }
> >> bool checkAddr() { return currAddr() == origAddr(); }
> >> MyContainer() { m_origAddr = this; }
> >> };
> >> """
> >>
> >> typealias MyContainer 
> cxxt"MyContainer"{Int(icxx"""sizeof(MyContainer);""")}
> >>
> >> rndarray = rand(1000,1000,100)
> >>
> >> containers = Vector{MyContainer}()
> >> for i in 1:2000 push!(containers, @cxx MyContainer()) end
> >> assert(all(x -> icxx""" $x.checkAddr(); """, containers))
> >>
> >> rndarray = rand(10,10,10)
> >> gc()
> >>
> >> assert(all(x -> icxx""" $x.checkAddr(); """, containers))
> >>
> >> Keno, help ... ? ;-)
> >>
> >>
> >> Cheers,
> >>
> >> Oliver
> >>
>

[julia-users] Re: Implicit constructor for custom types through Base.convert

[Cedric St-Jean]

That looks like a bug to me. I couldn't find any github issue covering it, 
maybe you should submit one? 

On Tuesday, February 16, 2016 at 10:01:05 AM UTC-5, Helge Eichhorn wrote:
>
> When I run the following code
>
> type A
> v::Float64
> end
>
> type B
> v::Float64
> end
>
> Base.convert(::Type{A}, b::B) = A(b.v/2)
> b = B(12)
> A(b)
>
> it fails with this error message because the implicit constructor is 
> called.
>
> LoadError: MethodError: `convert` has no method matching 
> convert(::Type{Float64}, ::B)
> This may have arisen from a call to the constructor Float64(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   call{T}(::Type{T}, ::Any)
>   convert(::Type{Float64}, !Matched::Int8)
>   convert(::Type{Float64}, !Matched::Int16)
>   ...
> while loading In[1], in expression starting on line 11
>
>  in call at In[1]:2
>
>
> Since the manual said "defining Base.convert(::Type{T}, args...) = 
> ...automatically 
> defines a constructor T(args...) = ", I expected this to work.
> If I define a convert method for a built-in type like Float64, it works. 
> Am I doing something wrong or is this intended? If so, it should be clearly 
> stated in the manual.
>

Re: [julia-users] Julia compilation - forcing architecture

[Tony Kelman]

I think it needs to be MARCH=x86-64 to match the flags gcc wants for -march.


On Tuesday, February 16, 2016 at 6:59:04 AM UTC-8, Milan Bouchet-Valat 
wrote:
>
> Le mardi 16 février 2016 à 06:38 -0800, Ben Ward a écrit : 
> > Hi, 
> > 
> > I'm compiling Julia on a multi node cluster system and whilst I can 
> > get to to compile and install successfully, 
> > it compiles for the incorrect cpu architecture perhaps because I'm 
> > building it from a specific software install node. 
> > Which Makefiles, and their variables, must I edit in order to ensure 
> > that it compiles for x86_64 architecture? 
> > ARCH? MARCH? The README of the repo is slightly unclear on this to 
> > me. 
> You can pass MARCH=x86_64, and it will override JULIA_CPU_TARGET as 
> well. If you want to specify a more recent architecture, you can set 
> the latter to any of the values listed by llc -mattr=help. (If you set 
> MARCH without JULIA_CPU_TARGET, you'll need to find targets supported 
> both by gcc and LLVM.) 
>
> Please make suggestions if you think the README can be improved. 
>
>
> Regards 
>

Re: [julia-users] Inverse of `bits`?

[Sheehan Olver]

Cool!  I think the extra step will be instructive anyways (that strings are not 
bits, and that bits have different interpretations depending on the type).




> On 17 Feb 2016, at 8:14 AM, Jacob Quinn  wrote:
> 
> There is the parse(type, str[, base]) function that will parse *integers* of 
> a given base (link to doc: 
> http://docs.julialang.org/en/release-0.4/stdlib/numbers/?highlight=binary#Base.parse
>  
> ),
>  but floats are always parsed as decimal. But using reinterpret, you could do
> 
> julia> str = bits(1.0f0)
> "00111000"
> 
> julia> int = parse(Int32,str,2)
> 1065353216
> 
> julia> reinterpret(Float32,int)
> 1.0f0
> 
> 
> -Jacob
> 
> On Tue, Feb 16, 2016 at 2:07 PM, Sheehan Olver  > wrote:
> 
> 
> I'm lecturing a course that will include basic machine arithmetic, and the 
> bits function looks very helpful.  But is there a way to go back?  I.e., I 
> want a frombits to do:
> 
> 
> str=bits(1.0f0)# returns "00111000"
> frombits(Float32,str)  # should return 1.0f0
> 
> 
> 

Re: [julia-users] Inverse of `bits`?

[Jacob Quinn]

There is the parse(*type*, *str*[, *base*]) function that will parse
*integers* of a given base (link to doc:
http://docs.julialang.org/en/release-0.4/stdlib/numbers/?highlight=binary#Base.parse),
but floats are always parsed as decimal. But using reinterpret, you could do

julia> str = bits(1.0f0)
"00111000"

julia> int = parse(Int32,str,2)
1065353216

julia> reinterpret(Float32,int)
1.0f0


-Jacob

On Tue, Feb 16, 2016 at 2:07 PM, Sheehan Olver 
wrote:

>
>
> I'm lecturing a course that will include basic machine arithmetic, and the
> bits function looks very helpful.  But is there a way to go back?  I.e., I
> want a frombits to do:
>
>
> str=bits(1.0f0)# returns *"00111000"*
> *frombits(Float32,str)  # should return 1.0f0*
>
>
>

[julia-users] Inverse of `bits`?

[Sheehan Olver]

I'm lecturing a course that will include basic machine arithmetic, and the 
bits function looks very helpful.  But is there a way to go back?  I.e., I 
want a frombits to do:


str=bits(1.0f0)# returns *"00111000"*
*frombits(Float32,str)  # should return 1.0f0*

Re: [julia-users] Re: Cxx.jl object address stability?

[Yichao Yu]

On Feb 16, 2016 2:38 PM, "Oliver Schulz" 
wrote:
>
> Hello,
>
> I realized that this question is probably not specific to Cxx.jl, but
concerns Julia's garbage collection in general: Is it save to keep a
pointer to a Julia-owned object in an FFI environment (e.g. from C), as
long as the object is not GC'ed? From what I saw, the current Julia garbage
collector is non-moving. Should I be prepared for Julia to switch to a
moving/compacting GC in the foreseeable future, or is a next-generation GC
for Julia likely to be non-moving as well?

We'd like to try out moving but even if it is implemented, we will
definitely have a relatively easy way to pin the object.

>
>
> Cheers,
>
> Oliver
>
>
> On Thursday, February 11, 2016 at 1:09:44 PM UTC+1, Oliver Schulz wrote:
>>
>> Hi,
>>
>> is the memory address (seen from C++) of objects created via `@cxx
SomeClass()` (or similar) stable over time (GC cycles)?
>>
>> I need to use a container class whose elements keep a pointer to the
container itself. I want Julia to own the container, so it should be
subject to garbage collection. The container owns it's elements and deletes
them on destruction, so they can't outlive the container object. But
obviously, the address of the container object must not change over time,
else things will break. So is it safe to do
>>
>> container = @cxx Container()
>>
>> or
>>
>> container = icxx""" Container(); """
>>
>> Or do I need to do something like
>>
>> container = icxx""" std::unique_ptr(new Container); """
>>
>> I would assume that "container.data" moves around during GC cycles, so
that `icxx""" &$container """` wouldn't be stable over GC cycles. But this
little test seems to indicate that it actually may be stable:
>>
>> cxx"""
>> struct MyContainer {
>> MyContainer* m_origAddr;
>> MyContainer* origAddr() { return m_origAddr; }
>> MyContainer* currAddr() { return this; }
>> bool checkAddr() { return currAddr() == origAddr(); }
>> MyContainer() { m_origAddr = this; }
>> };
>> """
>>
>> typealias MyContainer
cxxt"MyContainer"{Int(icxx"""sizeof(MyContainer);""")}
>>
>> rndarray = rand(1000,1000,100)
>>
>> containers = Vector{MyContainer}()
>> for i in 1:2000 push!(containers, @cxx MyContainer()) end
>> assert(all(x -> icxx""" $x.checkAddr(); """, containers))
>>
>> rndarray = rand(10,10,10)
>> gc()
>>
>> assert(all(x -> icxx""" $x.checkAddr(); """, containers))
>>
>> Keno, help ... ? ;-)
>>
>>
>> Cheers,
>>
>> Oliver
>>

[julia-users] Re: Cxx.jl object address stability?

[Oliver Schulz]

Hello,

I realized that this question is probably not specific to Cxx.jl, but 
concerns Julia's garbage collection in general: Is it save to keep a 
pointer to a Julia-owned object in an FFI environment (e.g. from C), as 
long as the object is not GC'ed? From what I saw, the current Julia garbage 
collector is non-moving. Should I be prepared for Julia to switch to a 
moving/compacting GC in the foreseeable future, or is a next-generation GC 
for Julia likely to be non-moving as well?


Cheers,

Oliver


On Thursday, February 11, 2016 at 1:09:44 PM UTC+1, Oliver Schulz wrote:
>
> Hi,
>
> is the memory address (seen from C++) of objects created via `@cxx 
> SomeClass()` (or similar) stable over time (GC cycles)?
>
> I need to use a container class whose elements keep a pointer to the 
> container itself. I want Julia to own the container, so it should be 
> subject to garbage collection. The container owns it's elements and deletes 
> them on destruction, so they can't outlive the container object. But 
> obviously, the address of the container object must not change over time, 
> else things will break. So is it safe to do
>
> container = @cxx Container()
>
> or
>
> container = icxx""" Container(); """
>
> Or do I need to do something like
>
> container = icxx""" std::unique_ptr(new Container); """
>
> I would assume that "container.data" moves around during GC cycles, so 
> that `icxx""" &$container """` wouldn't be stable over GC cycles. But 
> this little test seems to indicate that it actually may be stable:
>
> cxx"""
> struct MyContainer {
> MyContainer* m_origAddr;
> MyContainer* origAddr() { return m_origAddr; }
> MyContainer* currAddr() { return this; }
> bool checkAddr() { return currAddr() == origAddr(); }
> MyContainer() { m_origAddr = this; }
> };
> """
>
> typealias MyContainer 
> cxxt"MyContainer"{Int(icxx"""sizeof(MyContainer);""")}
>
> rndarray = rand(1000,1000,100)
>
> containers = Vector{MyContainer}()
> for i in 1:2000 push!(containers, @cxx MyContainer()) end
> assert(all(x -> icxx""" $x.checkAddr(); """, containers))
>
> rndarray = rand(10,10,10)
> gc()
>
> assert(all(x -> icxx""" $x.checkAddr(); """, containers))
>
> Keno, help ... ? ;-)
>
>
> Cheers,
>
> Oliver
>
>

[julia-users] Accessing factors in Bunch Kaufman factorization

[Lutfullah Tomak]

Hi,
In Julia, it is usually done for other factorization by indexing with symbols as
Afactored = factoring_func(A)
P=Afactored[:P]
However, searching by

methods(getindex,(Base.LinAlg.BunchKaufman, Symbol))

this factorization isn't available for that indexing.
Also, searching how this factorization type is defined by Julia

?Base.LinAlg.BunchKaufman

No documentation found.
Summary:
immutable Base.LinAlg.BunchKaufman{T,S<:AbstractArray{T,2}} <: Factorization{T}
Fields:
LD:: S<:AbstractArray{T,2}
ipiv  :: Array{Int32,1}
uplo  :: Char
symmetric :: Bool
rook  :: Bool

If you know what these fields refer you can define your getindex method for 
this factorization. You can get help looking up how other factorization defines 
getindex methods. Also, you can open an issue for this at github repo if not 
already done.
Note: I observed this on v0.5 but I guess it is the same for v0.4.
Best,

[julia-users] Re: Accessing factors in Bunch Kaufman factorization

[Steven G. Johnson]

The bkfact routine calls the sytrf routine in LAPACK 
(http://www.netlib.org/lapack/lapack-3.1.1/html/dsytrf.f.html).  As 
described in the LAPACK documentation, its Bunch-Kaufman factorization does 
not actually compute the factors explicitly, but rather expresses them 
implicitly as a product of sparse factors.

Given this implicit representation, however, you can still solve linear 
systems, which is exposed in Julia via \.  That is, you can do:

   B = bkfact(A)
   x = B \ b

to solve Ax = b.   You can also do inv(B) to get the inverse of A, and 
det(B) to get the determinant.

If there are other operations that would be useful to perform with the 
Bunch-Kaufman factorization, patches to Julia would be welcome.  If there 
is a good use-case for explicitly computing the individual factors, this 
could be exposed as well by implementing a computation of the factors from 
their implicit representation.

Re: [julia-users] Julia compilation - forcing architecture

[Milan Bouchet-Valat]

Le mardi 16 février 2016 à 06:38 -0800, Ben Ward a écrit :
> Hi,
> 
> I'm compiling Julia on a multi node cluster system and whilst I can
> get to to compile and install successfully,
> it compiles for the incorrect cpu architecture perhaps because I'm
> building it from a specific software install node.
> Which Makefiles, and their variables, must I edit in order to ensure
> that it compiles for x86_64 architecture?
> ARCH? MARCH? The README of the repo is slightly unclear on this to
> me.
You can pass MARCH=x86_64, and it will override JULIA_CPU_TARGET as
well. If you want to specify a more recent architecture, you can set
the latter to any of the values listed by llc -mattr=help. (If you set
MARCH without JULIA_CPU_TARGET, you'll need to find targets supported
both by gcc and LLVM.)

Please make suggestions if you think the README can be improved.


Regards

[julia-users] Implicit constructor for custom types through Base.convert

[Helge Eichhorn]

When I run the following code

type A
v::Float64
end

type B
v::Float64
end

Base.convert(::Type{A}, b::B) = A(b.v/2)
b = B(12)
A(b)

it fails with this error message because the implicit constructor is called.

LoadError: MethodError: `convert` has no method matching 
convert(::Type{Float64}, ::B)
This may have arisen from a call to the constructor Float64(...),
since type constructors fall back to convert methods.
Closest candidates are:
  call{T}(::Type{T}, ::Any)
  convert(::Type{Float64}, !Matched::Int8)
  convert(::Type{Float64}, !Matched::Int16)
  ...
while loading In[1], in expression starting on line 11

 in call at In[1]:2


Since the manual said "defining Base.convert(::Type{T}, args...) = 
...automatically 
defines a constructor T(args...) = ", I expected this to work.
If I define a convert method for a built-in type like Float64, it works. Am 
I doing something wrong or is this intended? If so, it should be clearly 
stated in the manual.

[julia-users] Julia compilation - forcing architecture

[Ben Ward]

Hi,

I'm compiling Julia on a multi node cluster system and whilst I can get to 
to compile and install successfully,
it compiles for the incorrect cpu architecture perhaps because I'm building 
it from a specific software install node.
Which Makefiles, and their variables, must I edit in order to ensure that 
it compiles for x86_64 architecture?
ARCH? MARCH? The README of the repo is slightly unclear on this to me.

Thanks,
Ben.

[julia-users] accessing factors in bkfact()

[Hyunmin Park]

Hi,

I would like to access the factors in Bunch-Kauffman factorization, i.e.,
when I give A as an input, I would like to get as an output the matrices 
P,L and B that satisfy PAP'=LBL'.
Is there a way of using bkfact() for this purpose? Or, is there any other 
function in julia that does this?

Also, could you explain what exactly a "Bunch-Kauffman object" is that 
bkfact() returns?

Thank you in advance,
Min

[julia-users] Re: julia on ARM for a drone

[Scott Jones]

What do you really need in Julia on the drone?
You might be interested in the branch of Julia I'm maintaining, 
in https://github.com/ScottPJones/julia/tree/spj/lite,
where I've attempted to cut out as much as possible from Base, while still 
having a useful version of Julia.
(I've been building it for my Raspberry Pi 2 (Model B)).
I've made it so that you should be able to select what parts you want 
included, simply by adding flags in Make.user.

It does save a substantial amount of memory / resources.

On Sunday, February 7, 2016 at 1:50:55 AM UTC-5, Jeff Waller wrote:
>
> An update:
>
> It turns out that the default linux client compiled for ARM does work 
> with a few modifications 
> .  It is indeed
> slow to JIT-compile, (on the order of seconds), but is fast after that. 
>  See randomMatrix.txt in the gist, for
> exact measures, but for example rand(100,100) takes 1 second the first 
> time and then 0.0005 seconds subsequently --
> that's quite a speedup.  Likewise, svd of that 100x100 random matrix is 3 
> seconds and then 0.05 seconds
> afterwards. 
>
> Also, of course, I tried using node-julia and that was difficult, but I 
> managed to get that working too.  Firstly, I had
> to add -march=armv7-a to the compile step to allow use of C++ std::thread 
> to be successful; apparently this
> is a known  bug of 
> openembedded , and 
> not an issue with Julia. However, I also had to add -lgfortran and 
> -lopenblas
> to the link step to satisfy the loader which is reminiscent of the error 
> I had 
> 
>  
> when I first tried to get thigs working on 
> linux in 2014.  This is not the same thing but feels possibly related.  I 
> also had to create a symbolic link for gfortran
> as only the specialized version (libgfortran.so.3) existed; ln -s 
> libgfortran.so.3 libgfortran.so; that should probably
> be fixed.
>
> All but 3 of the node-julia regressions worked once I increased the 
> default timeout time.  You can see the relative
> speed differences between an OS/X labtop and the drone in the gist as 
> well.  Some of the timings are comparable,
> some are not.
>
> I believe the large difference in time is due to not only the processor 
> being slower, but the (flash) filesystem as well.
> Exec-ing processes on this drone takes a very large amount of time 
> (relative to normal laptops/desktops).  The memory
> is limited too (512 MB), so you really have to be careful about resources.
>
>

[julia-users] Accessing factors in Bunch Kaufman factorization

[Hyunmin Park]

Hi,

I'm a relatively new user, enthusiastic about learning julia. I would like 
to ask for some help. 

I would like to do a Bunch Kaufman factorization of a matrix and obtain the 
factors.
For instance, if the input matrix is A, I would like to obtain P,B and L 
which satisfy PAP'=LBL'.

Is there a way to implement this in julia? bkfact() seems to return only 
one object.
Also, what exactly is a "Bunch Kaufman object" that bkfact() returns? 

Thank you in advance,

Min

[julia-users] Re: Unitful.jl for physical units

[yousef . k . alhammad]

Hello Andrew,

Your work is very promising. If you have ever dealt with oil field 
equations, then you'll know that units are a headache to deal with.
Your package should make life much easier.

I'm curious, however, as if you'll implement an easier means of defining 
new units.
Something like a function that takes a unit, its base factor, and its 
conversion to SI units, then gets it working in Unitful.

Thanks again for your work,
Yousef

[julia-users] Re: ANN: CppWrapper C++ wrapping package

[Bart Janssens]

Hi Christoph,

It should, yes. I have tested on stock Julia 0.4 on OS X and Linux. The 
only requirement is to have cmake (at least v3.1) in your path when running 
Pkg.build.

Bart

On Tuesday, February 16, 2016 at 12:57:53 PM UTC+1, Christoph Ortner wrote:
>
> Does this work *now* without special compilation tricks?
> Christoph
>
>

[julia-users] Re: ANN: CppWrapper C++ wrapping package

[Christoph Ortner]

Does this work *now* without special compilation tricks?
Christoph

On Sunday, 14 February 2016 23:11:07 UTC, Bart Janssens wrote:
>
> Hi all,
>
> The CppWrapper package is meant to facilitate exposing C++ libraries to 
> Julia, allowing library authors to write the wrapping code in C++ and 
> import to Julia using a one-liner. I think I have now added most of the 
> basic features needed to produce simple type wrappings. The detailed 
> description can be found at:
> https://github.com/barche/CppWrapper
>
> For demonstration and performance-checking purposes, I have also wrapped a 
> very limited part of the Eigen matrix library for some given fixed-size 
> matrices:
> https://github.com/barche/EigenCpp.jl
>
> I'm thinking of submitting a presentation proposal for CppWrapper to 
> JuliaCon, so comments and suggestions are most welcome.
>
> Cheers,
>
> Bart
>