Re: [julia-users] Re: ANN: FileIO.jl, for loading and saving formatted files

[David van Leeuwen]

Hello, 

Picking up an old thread... I am looking for a way to trigger a specific 
constructor when loading an object from a JLD file.  

FileIO detects the files are JLD, and that is great, but it would be cool 
if it could trigger my constructor `MyModule.MyType(objectfromjld)` when
 - `MyModule` was specified in the addrequires while writing the file
 - `JLD.exists(io, "MyType")` (namely the object `objectfromjld`)

(The case here is that MyType contains a field that is largish and that can 
be precomputed from another field in the type, which is the want I want to 
store in the file). 

I've tried to write a `detectmytype()` in the spirit of, say, 
`FileIO.detecthdf5()`, but I am kind-of stuck here: 
 - the detect...() interface wants an IO object (I think)
 - I can find out if `MyType` exists from `jldopen(filename)`, but I can't 
find an interface for hdf5/jld for an IO object. 

Does anyone know how I could get this done?

Thanks, 

---david

On Wednesday, September 30, 2015 at 11:35:20 AM UTC+2, Tim Holy wrote:
>
> Probably best as an issue over at FileIO. 
>
> --Tim 
>
> On Wednesday, September 30, 2015 01:24:25 AM David van Leeuwen wrote: 
> > Hello Tim and Simon, 
> > 
> > I'd be very interested in this, for MFCCs.jl and perhaps 
> > GaussianMixtures.jl.  They currently use HDF5 and JLD, respectively, and 
> I 
> > don't think I've put in any magic. 
> > 
> >  - is it wise to put in magic, even with container formats such as HDF5? 
> > 
> >  - do you prefer questions about implementation on this list, the repo, 
> or 
> > some other way (or not at all)? 
> > 
> > Cheers, 
> > 
> > ---david 
> > 
> > On Tuesday, September 29, 2015 at 9:24:13 PM UTC+2, Tim Holy wrote: 
> > > Simon Danisch and I are pleased to introduce FileIO.jl 
> > > (https://github.com/JuliaIO/FileIO.jl), a package for centralizing 
> the 
> > > handling of formatted files. The package contains utilities for 
> querying 
> > > files/filenames by their extensions and/or magic bytes to deduce their 
> > > content. 
> > > It then allows package authors to "register" loaders/savers for 
> detected 
> > > file 
> > > formats. 
> > > 
> > > Some of the advantages of using FileIO are: 
> > > 
> > > - For users, this may reduce the searching required to answer "is 
> there a 
> > > julia package to load file X?" Now you can just try `load("X.ext")` 
> and 
> > > see 
> > > what happens---if the loader has been registered, it will try to find 
> the 
> > > right 
> > > package for you. 
> > > 
> > > - For developers, this allows you to decouple your package from 
> others. If 
> > > you 
> > > want to work with images, you will (once I tag a new release of 
> Images.jl) 
> > > no 
> > > longer need to make the Images package a dependency as long as you use 
> > > FileIO. 
> > > In your package code, you can say `load("myimage.png")` and everything 
> > > should 
> > > Just Work. 
> > > 
> > > - For users and developers, this reduces name conflicts among two 
> > > attractive 
> > > function names, `load` and `save`. If everyone imports those names 
> from 
> > > FileIO, there need be no conflicts. 
> > > 
> > > The package is relatively small and is fairly extensively documented. 
> > > 
> > > While there are not a large number of formats currently registered, 
> the 
> > > architecture already shows a lot of promise. For example, it can 
> recognize 
> > > our 
> > > .jld files as HDF5 files, something that escapes the well-tested (and 
> much 
> > > more 
> > > extensive) Unix `file` command. 
> > > 
> > > Best, 
> > > --Tim & Simon 
>
>

Re: [julia-users] Re: Why these 2 functions generate very different llvm?

['Tobias Knopp' via julia-users]

It would be great if this is resolvable. It took me quite some time to 
determine that this is an issue in my own code. My mental model was that 
type stability is about the return type being statically dependent on the 
input parameter types. That a local binding has changed is quite a 
different thing.

Cheers,

Tobias

Am Dienstag, 31. Mai 2016 02:14:21 UTC+2 schrieb Yichao Yu:
>
> On Mon, May 30, 2016 at 7:54 PM, Erik Schnetter  > wrote: 
> > Yichao 
> > 
> > What is the known bug here: That Julia doesn't handle this more 
> efficiently, 
>
> The bug is that the type instability here is spurious. 
>
> > or that the variable `x` can change its type from Int to Float64? 
> > 
> > In this example, are there two variables `x` (the argument and the 
> > explicitly declared local variable), or should the declaration be an 
> error? 
> > 
> > -erik 
> > 
> > On Mon, May 30, 2016 at 7:47 PM, Yichao Yu  > wrote: 
> >> 
> >> On Mon, May 30, 2016 at 7:23 PM, David P. Sanders  > 
> >> wrote: 
> >> > 
> >> > 
> >> > El lunes, 30 de mayo de 2016, 19:11:47 (UTC-4), FANG Colin escribió: 
> >> >> 
> >> >> function t1(n::Int, x::Int, a::Float64) 
> >> >>x::Float64 = x 
> >> >>for i in 1:n 
> >> >> x += a 
> >> >>end 
> >> >> x 
> >> >> end 
> >> >> @time t1(10^6, 1, 1.0) 
> >> >> 
> >> >> 0.005445 seconds (1.00 M allocations: 15.259 MB) 
> >> > 
> >> > 
> >> > In t1, x changes type during the function, from Int to Float64, so 
> the 
> >> > function is type *un*stable, as shown by @code_warntype, 
> >> > and as suggested by the huge number of allocations. 
> >> > 
> >> > In t2, x is always a Float64, and the function is type stable. 
> >> > 
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >> function t2(n::Int, y::Int, a::Float64) 
> >> >>x::Float64 = y 
> >> >>for i in 1:n 
> >> >> x += a 
> >> >>end 
> >> >> x 
> >> >> end 
> >> >> @time t2(10^6, 1, 1.0) 
> >> >> 
> >> >> 0.001044 seconds (6 allocations: 192 bytes) 
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >> The @code_warntype of the 2 functions are very similar. However, the 
> >> >> llvm 
> >> >> code generated from t2 is a lot simpler. 
> >> > 
> >> > 
> >> > The @code_warntype of the two functions is very *different*. (This is 
> >> > easier 
> >> > to see in the REPL than in the notebook, if 
> >> > that is the problem.) 
> >> > 
> >> >> 
> >> >> 
> >> >> Does it suggest that if we want to change the type of an argument, 
> we'd 
> >> >> better create a new variable? 
> >> 
> >> This is a known bug. Fortunately it's easy to catch with code_warntype. 
> > 
> > 
> > 
> > 
> > -- 
> > Erik Schnetter > 
> > http://www.perimeterinstitute.ca/personal/eschnetter/ 
>

[julia-users] Calculus.hessian result oddities

[Boylan, Ross]

The hessian produced by Calculus.hessian has some properties that seem odd to 
me.  First, the resulting matrix is not symmetric (though it's really close).  
Second, it is not positive definite even though the eigenvalues are all 
positive.  This might partly be the result of the first problem.

Comments?

 julia> @time h6 = Calculus.hessian(RB.mylike, sol6[2])
 206.988247 seconds (2.43 G allocations: 83.830 GB, 15.48% gc time)
 10x10 Array{Float64,2}:

 julia> issym(h6)
 false
 julia> isposdef(h6)
 false
 julia> eigvals(h6)
 10-element Array{Float64,1}:
  3.27548e5
  41407.1
   1873.44
809.515
385.469
336.118
269.82
 64.4228
117.009
122.845
 julia> [det(h6[1:i, 1:i]) for i in 1:10]  # all submatrix determinants are 
positive
 10-element Array{Any,1}:
  583.356
2.93666e5
3.76334e7
4.26776e9
3.17529e12
6.53405e14
1.12477e17
8.54011e21
3.75658e26
6.65866e29

 julia> showall(h6)
 [583.356378500377 -215.9519377704782 42.707753088841706 -12.046905619427504 
100.26418659571075 30.907721733245413 5.1999446295105445 -3522.0797654066855 
4410.401341876791 29.123944464570087
  -215.95193777047822 583.3512842422355 -12.0619061856546 42.69860798380086 
-82.01778794681003 -20.00373356894301 -8.643894790795585 1484.6195212852567 
-3316.905502014349 -2.7622075180025965
  42.7077530888417 -12.061906185654598 131.30467049554812 -44.14799847519552 
16.748039679197223 -10.98960509547607 43.02830286169418 234.68906012694512 
-1258.6622801992237 9.86994636336174
  -12.046905619427504 42.69860798380086 -44.147998475195514 131.35743705036847 
-17.498616283805696 4.724998443749094 -31.481387268916205 -95.390157895702 
209.5245372890838 12.903636963625035
  100.26418659571075 -82.01778794681003 16.748039679197223 -17.498616283805696 
766.6651018177663 -20.766430168130857 -2.164074090378522 610.206909770971 
-6927.858446549729 -200.4409796490271
  30.907721733245413 -20.00373356894301 -10.98960509547607 4.724998443749093 
-20.766430168130857 209.8283757716871 -60.222027409043555 280.3888402431943 
-1638.62573982097 -158.60599205247166
  5.199944629510544 -8.643894790795585 43.02830286169418 -31.4813872689162 
-2.164074090378524 -60.222027409043555 204.34068072875016 -3.631354965653126 
314.50383342119943 30.12788292183477
  -3522.079765406686 1484.6195212852565 234.6890601269451 -95.39015789570199 
610.2069097709712 280.3888402431943 -3.631354965653125 102596.98982032725 
-117630.58331133435 267.23733374838395
  4410.401341876791 -3316.9055020143487 -1258.6622801992235 209.5245372890838 
-6927.858446549729 -1638.62573982097 314.5038334211995 -117630.58331133435 
265600.50878023007 5508.687364627178
  29.123944464570084 -2.762207518002596 9.86994636336174 12.903636963625033 
-200.4409796490271 -158.6059920524717 30.12788292183477 267.23733374838395 
5508.687364627178 2125.8954716959997]

The largest absolute difference between symmetrical entries is < 5e-13.

Ross Boylan

Re: [julia-users] Signal / slot (or publish-subscribe) libraries in Julia

[Steven G. Johnson]

Reactive.jl?

Re: [julia-users] Re: Why these 2 functions generate very different llvm?

[Yichao Yu]

On Mon, May 30, 2016 at 7:54 PM, Erik Schnetter  wrote:
> Yichao
>
> What is the known bug here: That Julia doesn't handle this more efficiently,

The bug is that the type instability here is spurious.

> or that the variable `x` can change its type from Int to Float64?
>
> In this example, are there two variables `x` (the argument and the
> explicitly declared local variable), or should the declaration be an error?
>
> -erik
>
> On Mon, May 30, 2016 at 7:47 PM, Yichao Yu  wrote:
>>
>> On Mon, May 30, 2016 at 7:23 PM, David P. Sanders 
>> wrote:
>> >
>> >
>> > El lunes, 30 de mayo de 2016, 19:11:47 (UTC-4), FANG Colin escribió:
>> >>
>> >> function t1(n::Int, x::Int, a::Float64)
>> >>x::Float64 = x
>> >>for i in 1:n
>> >> x += a
>> >>end
>> >> x
>> >> end
>> >> @time t1(10^6, 1, 1.0)
>> >>
>> >> 0.005445 seconds (1.00 M allocations: 15.259 MB)
>> >
>> >
>> > In t1, x changes type during the function, from Int to Float64, so the
>> > function is type *un*stable, as shown by @code_warntype,
>> > and as suggested by the huge number of allocations.
>> >
>> > In t2, x is always a Float64, and the function is type stable.
>> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> function t2(n::Int, y::Int, a::Float64)
>> >>x::Float64 = y
>> >>for i in 1:n
>> >> x += a
>> >>end
>> >> x
>> >> end
>> >> @time t2(10^6, 1, 1.0)
>> >>
>> >> 0.001044 seconds (6 allocations: 192 bytes)
>> >>
>> >>
>> >>
>> >>
>> >> The @code_warntype of the 2 functions are very similar. However, the
>> >> llvm
>> >> code generated from t2 is a lot simpler.
>> >
>> >
>> > The @code_warntype of the two functions is very *different*. (This is
>> > easier
>> > to see in the REPL than in the notebook, if
>> > that is the problem.)
>> >
>> >>
>> >>
>> >> Does it suggest that if we want to change the type of an argument, we'd
>> >> better create a new variable?
>>
>> This is a known bug. Fortunately it's easy to catch with code_warntype.
>
>
>
>
> --
> Erik Schnetter 
> http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] Re: Why these 2 functions generate very different llvm?

[Erik Schnetter]

Yichao

What is the known bug here: That Julia doesn't handle this more
efficiently, or that the variable `x` can change its type from Int to
Float64?

In this example, are there two variables `x` (the argument and the
explicitly declared local variable), or should the declaration be an error?

-erik

On Mon, May 30, 2016 at 7:47 PM, Yichao Yu  wrote:

> On Mon, May 30, 2016 at 7:23 PM, David P. Sanders 
> wrote:
> >
> >
> > El lunes, 30 de mayo de 2016, 19:11:47 (UTC-4), FANG Colin escribió:
> >>
> >> function t1(n::Int, x::Int, a::Float64)
> >>x::Float64 = x
> >>for i in 1:n
> >> x += a
> >>end
> >> x
> >> end
> >> @time t1(10^6, 1, 1.0)
> >>
> >> 0.005445 seconds (1.00 M allocations: 15.259 MB)
> >
> >
> > In t1, x changes type during the function, from Int to Float64, so the
> > function is type *un*stable, as shown by @code_warntype,
> > and as suggested by the huge number of allocations.
> >
> > In t2, x is always a Float64, and the function is type stable.
> >
> >>
> >>
> >>
> >>
> >>
> >> function t2(n::Int, y::Int, a::Float64)
> >>x::Float64 = y
> >>for i in 1:n
> >> x += a
> >>end
> >> x
> >> end
> >> @time t2(10^6, 1, 1.0)
> >>
> >> 0.001044 seconds (6 allocations: 192 bytes)
> >>
> >>
> >>
> >>
> >> The @code_warntype of the 2 functions are very similar. However, the
> llvm
> >> code generated from t2 is a lot simpler.
> >
> >
> > The @code_warntype of the two functions is very *different*. (This is
> easier
> > to see in the REPL than in the notebook, if
> > that is the problem.)
> >
> >>
> >>
> >> Does it suggest that if we want to change the type of an argument, we'd
> >> better create a new variable?
>
> This is a known bug. Fortunately it's easy to catch with code_warntype.
>



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

Re: [julia-users] Re: Why these 2 functions generate very different llvm?

[Yichao Yu]

On Mon, May 30, 2016 at 7:23 PM, David P. Sanders  wrote:
>
>
> El lunes, 30 de mayo de 2016, 19:11:47 (UTC-4), FANG Colin escribió:
>>
>> function t1(n::Int, x::Int, a::Float64)
>>x::Float64 = x
>>for i in 1:n
>> x += a
>>end
>> x
>> end
>> @time t1(10^6, 1, 1.0)
>>
>> 0.005445 seconds (1.00 M allocations: 15.259 MB)
>
>
> In t1, x changes type during the function, from Int to Float64, so the
> function is type *un*stable, as shown by @code_warntype,
> and as suggested by the huge number of allocations.
>
> In t2, x is always a Float64, and the function is type stable.
>
>>
>>
>>
>>
>>
>> function t2(n::Int, y::Int, a::Float64)
>>x::Float64 = y
>>for i in 1:n
>> x += a
>>end
>> x
>> end
>> @time t2(10^6, 1, 1.0)
>>
>> 0.001044 seconds (6 allocations: 192 bytes)
>>
>>
>>
>>
>> The @code_warntype of the 2 functions are very similar. However, the llvm
>> code generated from t2 is a lot simpler.
>
>
> The @code_warntype of the two functions is very *different*. (This is easier
> to see in the REPL than in the notebook, if
> that is the problem.)
>
>>
>>
>> Does it suggest that if we want to change the type of an argument, we'd
>> better create a new variable?

This is a known bug. Fortunately it's easy to catch with code_warntype.

[julia-users] Re: Why these 2 functions generate very different llvm?

[David P. Sanders]

El lunes, 30 de mayo de 2016, 19:11:47 (UTC-4), FANG Colin escribió:
>
> function t1(n::Int, x::Int, a::Float64)
>x::Float64 = x
>for i in 1:n
> x += a
>end
> x
> end
> @time t1(10^6, 1, 1.0)
>
> 0.005445 seconds (1.00 M allocations: 15.259 MB)
>

In t1, x changes type during the function, from Int to Float64, so the 
function is type *un*stable, as shown by @code_warntype,
and as suggested by the huge number of allocations.

In t2, x is always a Float64, and the function is type stable.
 

>
>
>
>
> function t2(n::Int, y::Int, a::Float64)
>x::Float64 = y
>for i in 1:n
> x += a
>end
> x
> end
> @time t2(10^6, 1, 1.0)
>
> 0.001044 seconds (6 allocations: 192 bytes)
>
>
>
>
> The @code_warntype of the 2 functions are very similar. However, the llvm 
> code generated from t2 is a lot simpler.
>

The @code_warntype of the two functions is very *different*. (This is 
easier to see in the REPL than in the notebook, if
that is the problem.)
 

>
> Does it suggest that if we want to change the type of an argument, we'd 
> better create a new variable?
>

[julia-users] Why these 2 functions generate very different llvm?

[FANG Colin]

function t1(n::Int, x::Int, a::Float64)
   x::Float64 = x
   for i in 1:n
x += a
   end
x
end
@time t1(10^6, 1, 1.0)

0.005445 seconds (1.00 M allocations: 15.259 MB)




function t2(n::Int, y::Int, a::Float64)
   x::Float64 = y
   for i in 1:n
x += a
   end
x
end
@time t2(10^6, 1, 1.0)

0.001044 seconds (6 allocations: 192 bytes)




The @code_warntype of the 2 functions are very similar. However, the llvm 
code generated from t2 is a lot simpler.


Does it suggest that if we want to change the type of an argument, we'd 
better create a new variable?

[julia-users] Re: Grant funding and Julia Computing?

[Sheehan Olver]

Another option might be the "Bountysource" website:

https://www.bountysource.com/teams/julialang

This would get around having to have a contract, and so may be easier to 
use with grant funds.


On Thursday, April 21, 2016 at 1:58:02 PM UTC+10, Sheehan Olver wrote:
>
>
> Has anyone included "Julia Computing" charges in a grant proposal?  Is 
> this something that should be encouraged?
>
>  I'm thinking of including this in my next grant proposal, maybe for some 
> specific goal.  For example, I could include something along the lines of 
> "ApproxFun v0.5 compatibility", and then I could use grant funds to pay 
> Julia Computing  to fix the relevant issue:
>
>   https://github.com/JuliaLang/julia/issues/15464
>
>
> Or it could be something broader: an HPC grant could include "Thread 
> support in Julia" / "OpenCL support in Julia".  
>
>
>
>

[julia-users] Re: Using Julia for real time astronomy

['Tobias Knopp' via julia-users]

If you are prepared to make your code to not perform any heap allocations, 
I don't see a reason why there should be any issue. When I once worked on a 
very first multi-threading version of Julia I wrote exactly such functions 
that won't trigger gc since the later was not thread safe. This can be hard 
work but I would assume that its at least not more work than implementing 
the application in C/C++ (assuming that you have some Julia experience)

Tobi

Am Montag, 30. Mai 2016 12:00:13 UTC+2 schrieb John leger:
>
> Hi everyone,
>
> I am working in astronomy and we are thinking of using Julia for a real 
> time, high performance adaptive optics system on a solar telescope.
>
> This is how the system is supposed to work: 
>1) the image is read from the camera
>2) some correction are applied
>3) the atmospheric turbulence is numerically estimated in order to 
> calculate the command to be sent to the deformable mirror
>
> The overall process should be executed in less than 1ms so that it can be 
> integrated to the chain (closed loop).
>
> Do you think it is possible to do all the computation in Julia or would it 
> be better to code some part in C/C++. What I fear the most is the GC but in 
> our case we can pre-allocate everything, so once we launch the system there 
> will not be any memory allocated during the experiment and it will run for 
> days.
>
> So, what do you think? Considering the current state of Julia will I be 
> able to get the performances I need. Will the garbage collector be an 
> hindrance ?
>
> Thank you.
>

Re: [julia-users] Re: What is the difference between bitwise and logical operators?

[Tamas Papp]

Don't get sidetracked by the implementation. Also, inlining has nothing
to do with it.

& is a function, && is a control flow construct. The only way you could
replicate && and || is with a macro, such that

a && b

would get expanded to something like

if a
b
else
false
end

But of course syntax restricts you from doing that (macros start with
@), so you have them in Julia as primitives.

Best,

Tamas

On Mon, May 30 2016, Ford Ox wrote:

> Yeah I have read it. Multiple times, since I forget things and I still 
> don't remember all the things.
>
> So basically the difference is that bitwise operators are functions. That 
> means its arguments get evaluated before they are passed in. That also 
> means, that if that function would be inlined, && would be same as & 
> because:
>
> &(x::Bool, y::Bool) = box(Bool,and_int(unbox(Bool,x),unbox(Bool,y)))
> I dont really understand that function, since I dont know what box, unbox 
> is, but I guess it is something like 
> &(x::Bool, y::Bool) = x && y
> so if & would be inlined before x, y are evaluated, than && and & would 
> have identical meaning ( for booleans ), right?
>
> I was trying to achieve that with @generated, but it didn't work.
> function x()
> println("x")
> true
> end
> function y()
> println("y")
> false
> end
> @generated and_gen(x::Bool, y::Bool)
> return :(x && y)
> end
>
> and_gen(y(), x())
>
> y
>>
> x
>>
> false
>>
>
> Which is kinda weird, since x and y always returns Bool, so @generated 
> should know types of x() and y() before their evaluation. 
> and_gen(y()::Bool, x()::Bool) # also doesn't work
>
>
>
>
> On Monday, May 30, 2016 at 1:19:05 PM UTC+2, Tamas Papp wrote:
>>
>> See 
>>
>>
>> http://docs.julialang.org/en/release-0.4/manual/control-flow/#man-short-circuit-evaluation
>>  
>>
>> A lot of effort went into writing and improving the language manual, so 
>> that you can find very detailed answers to questions like this one. It 
>> is fine to ask on the list if you can't find it, but giving the whole 
>> manual a read is very useful for new users of Julia. 
>>
>> On Mon, May 30 2016, Ford Ox wrote: 
>>
>> > Ye I know what bitwise operator does. 
>> > I will ask in different way, maybe it will be clearer to you. 
>> > 
>> > Why people use logical operators ( f.e. in conditions ) instead of 
>> bitwise 
>> > operators? Is && <: & ? 
>> > 
>> > 
>> > On Monday, May 30, 2016 at 9:58:02 AM UTC+2, Kaj Wiik wrote: 
>> >> 
>> >> 
>> >> Here's a clue: 
>> >> 
>> >> 
>> >> julia> 0b10010011 & 0b10010011 
>> >> 0x93 
>> >> 
>> >> julia> 0b10010011 && 0b10010011 
>> >> ERROR: TypeError: non-boolean (UInt8) used in boolean context 
>> >> 
>> >> 
>> >> Kaj 
>> >> 
>> >> 
>> >> On Monday, May 30, 2016 at 9:30:22 AM UTC+3, Ford Ox wrote: 
>> >>> 
>> >>> For example 
>> >>> true & false == true && false 
>> >>> 
>> >>> Is it just artifact from c where bool types don't exist? 
>> >>> 
>> >> 
>>

Re: [julia-users] Re: What is the difference between bitwise and logical operators?

[Yichao Yu]

On Mon, May 30, 2016 at 2:25 PM, Ford Ox  wrote:
> Yeah I have read it. Multiple times, since I forget things and I still don't
> remember all the things.
>
> So basically the difference is that bitwise operators are functions. That
> means its arguments get evaluated before they are passed in. That also
> means, that if that function would be inlined, && would be same as &
> because:
>
> &(x::Bool, y::Bool) = box(Bool,and_int(unbox(Bool,x),unbox(Bool,y)))
> I dont really understand that function, since I dont know what box, unbox
> is, but I guess it is something like
> &(x::Bool, y::Bool) = x && y
> so if & would be inlined before x, y are evaluated, than && and & would have
> identical meaning ( for booleans ), right?
>
> Something like
> function x()
> println("x")
> true
> end
> function y()
> println("y")
> false
> end
> @generated_inline and_gen(x::Bool, y::Bool)

FWIW, I think the inline metadata needs to be attached to the return
value, not the function. It doesn't matter for what you want to do
though.

> return :(x && y)
> end
>
> and_gen(y(), x())

[julia-users] Re: What is the difference between bitwise and logical operators?

[Ford Ox]

Yeah I have read it. Multiple times, since I forget things and I still 
don't remember all the things.

So basically the difference is that bitwise operators are functions. That 
means its arguments get evaluated before they are passed in. That also 
means, that if that function would be inlined, && would be same as & 
because:

&(x::Bool, y::Bool) = box(Bool,and_int(unbox(Bool,x),unbox(Bool,y)))
I dont really understand that function, since I dont know what box, unbox 
is, but I guess it is something like 
&(x::Bool, y::Bool) = x && y
so if & would be inlined before x, y are evaluated, than && and & would 
have identical meaning ( for booleans ), right?

Something like
function x()
println("x")
true
end
function y()
println("y")
false
end
@generated_inline and_gen(x::Bool, y::Bool)
return :(x && y)
end

and_gen(y(), x())

Re: [julia-users] Re: What is the difference between bitwise and logical operators?

[Yichao Yu]

On Mon, May 30, 2016 at 2:09 PM, Ford Ox  wrote:
> Yeah I have read it. Multiple times, since I forget things and I still don't
> remember all the things.
>
> So basically the difference is that bitwise operators are functions. That
> means its arguments get evaluated before they are passed in. That also
> means, that if that function would be inlined, && would be same as &
> because:

No. function inlining is a pure optimization that doesn't affect the
schematics of the program at all.

>
> &(x::Bool, y::Bool) = box(Bool,and_int(unbox(Bool,x),unbox(Bool,y)))
> I dont really understand that function, since I dont know what box, unbox
> is, but I guess it is something like
> &(x::Bool, y::Bool) = x && y

They do have similar effect.

> so if & would be inlined before x, y are evaluated, than && and & would have
> identical meaning ( for booleans ), right?

No. inlining is irrelevant.

>
> I was trying to achieve that with @generated, but it didn't work.
> function x()
> println("x")
> true
> end
> function y()
> println("y")
> false
> end
> @generated and_gen(x::Bool, y::Bool)
> return :(x && y)
> end
>
> and_gen(y(), x())
>
>> y
>>
>> x
>>
>> false
>
>
> Which is kinda weird, since x and y always returns Bool, so @generated
> should know types of x() and y() before their evaluation.
> and_gen(y()::Bool, x()::Bool) # also doesn't work
>
>
>
>
> On Monday, May 30, 2016 at 1:19:05 PM UTC+2, Tamas Papp wrote:
>>
>> See
>>
>>
>> http://docs.julialang.org/en/release-0.4/manual/control-flow/#man-short-circuit-evaluation
>>
>> A lot of effort went into writing and improving the language manual, so
>> that you can find very detailed answers to questions like this one. It
>> is fine to ask on the list if you can't find it, but giving the whole
>> manual a read is very useful for new users of Julia.
>>
>> On Mon, May 30 2016, Ford Ox wrote:
>>
>> > Ye I know what bitwise operator does.
>> > I will ask in different way, maybe it will be clearer to you.
>> >
>> > Why people use logical operators ( f.e. in conditions ) instead of
>> > bitwise
>> > operators? Is && <: & ?
>> >
>> >
>> > On Monday, May 30, 2016 at 9:58:02 AM UTC+2, Kaj Wiik wrote:
>> >>
>> >>
>> >> Here's a clue:
>> >>
>> >>
>> >> julia> 0b10010011 & 0b10010011
>> >> 0x93
>> >>
>> >> julia> 0b10010011 && 0b10010011
>> >> ERROR: TypeError: non-boolean (UInt8) used in boolean context
>> >>
>> >>
>> >> Kaj
>> >>
>> >>
>> >> On Monday, May 30, 2016 at 9:30:22 AM UTC+3, Ford Ox wrote:
>> >>>
>> >>> For example
>> >>> true & false == true && false
>> >>>
>> >>> Is it just artifact from c where bool types don't exist?
>> >>>
>> >>

Re: [julia-users] Re: What is the difference between bitwise and logical operators?

[Ford Ox]

Yeah I have read it. Multiple times, since I forget things and I still 
don't remember all the things.

So basically the difference is that bitwise operators are functions. That 
means its arguments get evaluated before they are passed in. That also 
means, that if that function would be inlined, && would be same as & 
because:

&(x::Bool, y::Bool) = box(Bool,and_int(unbox(Bool,x),unbox(Bool,y)))
I dont really understand that function, since I dont know what box, unbox 
is, but I guess it is something like 
&(x::Bool, y::Bool) = x && y
so if & would be inlined before x, y are evaluated, than && and & would 
have identical meaning ( for booleans ), right?

I was trying to achieve that with @generated, but it didn't work.
function x()
println("x")
true
end
function y()
println("y")
false
end
@generated and_gen(x::Bool, y::Bool)
return :(x && y)
end

and_gen(y(), x())

y
>
x
>
false
>

Which is kinda weird, since x and y always returns Bool, so @generated 
should know types of x() and y() before their evaluation. 
and_gen(y()::Bool, x()::Bool) # also doesn't work




On Monday, May 30, 2016 at 1:19:05 PM UTC+2, Tamas Papp wrote:
>
> See 
>
>
> http://docs.julialang.org/en/release-0.4/manual/control-flow/#man-short-circuit-evaluation
>  
>
> A lot of effort went into writing and improving the language manual, so 
> that you can find very detailed answers to questions like this one. It 
> is fine to ask on the list if you can't find it, but giving the whole 
> manual a read is very useful for new users of Julia. 
>
> On Mon, May 30 2016, Ford Ox wrote: 
>
> > Ye I know what bitwise operator does. 
> > I will ask in different way, maybe it will be clearer to you. 
> > 
> > Why people use logical operators ( f.e. in conditions ) instead of 
> bitwise 
> > operators? Is && <: & ? 
> > 
> > 
> > On Monday, May 30, 2016 at 9:58:02 AM UTC+2, Kaj Wiik wrote: 
> >> 
> >> 
> >> Here's a clue: 
> >> 
> >> 
> >> julia> 0b10010011 & 0b10010011 
> >> 0x93 
> >> 
> >> julia> 0b10010011 && 0b10010011 
> >> ERROR: TypeError: non-boolean (UInt8) used in boolean context 
> >> 
> >> 
> >> Kaj 
> >> 
> >> 
> >> On Monday, May 30, 2016 at 9:30:22 AM UTC+3, Ford Ox wrote: 
> >>> 
> >>> For example 
> >>> true & false == true && false 
> >>> 
> >>> Is it just artifact from c where bool types don't exist? 
> >>> 
> >> 
>

[julia-users] step subplots in Gadfly

[farsheed . hesaraki]

  In Gadfly, how can I plot the rows of a given matrix using Stat.step in 
subplots? i.e., one subplot for each row of the given matrix. 

[julia-users] Re: doc fix: transposition operators in section highlighting difference to R

[James Gilbert]

Worked out how to do markup from the Sphinx documentation:

  http://www.sphinx-doc.org/en/stable/markup/inline.html#inline-markup

Submitted pull request.

[julia-users] Re: doc fix: transposition operators in section highlighting difference to R

[James Gilbert]

Worked out how to do markup from the Spinx documentation:

  http://www.sphinx-doc.org/en/stable/markup/inline.html#inline-markup

Submitted pull request.

Re: [julia-users] Bizarre Segfault during ccall on OSX

[Helge Eichhorn]

Thanks for testing, Rob!

It was pre-compilation problem. I switched on pre-compilation for a package 
that depends on Dopri.jl which itself does not use pre-compilation. My 
bad...

Am Montag, 30. Mai 2016 18:25:29 UTC+2 schrieb Rob J Goedman:
>
> Helge,
>
> Not sure if this helps, but below the (successful) output on my machine. 
> I’m on OS X 11.6-beta, but I don’t think that is important. I do remember 
> installing an updated Xcode.
>
> Regards,
> Rob
>
> On May 30, 2016, at 08:41, Helge Eichhorn  > wrote:
>
>
>
> Hi!
>
> I am having a strange problem with a segfault that seemingly appeared out 
> of nowhere while calling Fortran code on OSX.
>
> When I try to run the tests of my Dopri.jl 
>  package on Julia 0.4.5 on OSX 
> 10.11.5 the process consistently fails with this error message:
> signal (11): Segmentation fault: 11
> unknown function (ip: 0x0)
>
> Tests pass on master and 0.3.12. Could somebody try to reproduce this 
> behavior on their machine? What puzzles me is that this did not happen 23 
> days ago when I fixed the lastest issue with the package. In the meantime I 
> did not change anything about neither the code nor the Julia runtime. I did 
> install an OS update, though.
>
> Any ideas?
>
> The only other data point I have is that the tests also segfault on 0.3 on 
> Travis but not consistently. On the third to fourth re-run the build 
> usually succeeds. I have attached the log.
>
> Cheers,
> Helge
> 
>
>
>
> *julia> **Pkg.add("Dopri")*
> *INFO: No packages to install, update or remove*
> *INFO: Package database updated*
>
> *julia> **using Dopri*
>
> *julia> **Pkg.test("Dopri")*
> *INFO: Testing Dopri*
> *ERROR: LoadError: could not spawn 
> setenv(`/Users/rob/.julia/v0.4/Dopri/deps/testrunner`,Union{ASCIIString,UTF8String}["LD_LIBRARY_PATH=/Users/rob/.julia/v0.4/Dopri/deps"]):
>  
> no such file or directory (ENOENT)*
> * in _jl_spawn at process.jl:262*
> * in anonymous at process.jl:415*
> * in setup_stdio at process.jl:403*
> * in spawn at process.jl:414*
> * in open at process.jl:478*
> * in open at process.jl:492*
> * in include at 
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib*
> * in include_from_node1 at 
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib*
> * in process_options at 
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib*
> * in _start at 
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib*
> *while loading /Users/rob/.julia/v0.4/Dopri/test/runtests.jl, in 
> expression starting on line 9*
> *===[ ERROR: Dopri 
> ]===*
>
> *failed process: 
> Process(`/Applications/Julia-0.4.5.app/Contents/Resources/julia/bin/julia 
> --check-bounds=yes --code-coverage=none --color=yes 
> /Users/rob/.julia/v0.4/Dopri/test/runtests.jl`, ProcessExited(1)) [1]*
>
>
> *==*
> *ERROR: Dopri had test errors*
> * in error at 
> /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib*
> * in test at pkg/entry.jl:803*
> * in anonymous at pkg/dir.jl:31*
> * in cd at file.jl:22*
> * in cd at pkg/dir.jl:31*
> * in test at pkg.jl:71*
>
> *julia> **Pkg.build("Dopri")*
> *INFO: Building Dopri*
>
> *julia> **Pkg.test("Dopri")*
> *INFO: Testing Dopri*
> *INFO: Dopri tests passed*
>
> *julia> **versioninfo()*
> Julia Version 0.4.5
> Commit 2ac304d (2016-03-18 00:58 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin13.4.0)
>   CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> *shell> **gfortran -v*
> Using built-in specs.
> COLLECT_GCC=gfortran
>
> COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/5.3.0/libexec/gcc/x86_64-apple-darwin15.0.0/5.3.0/lto-wrapper
> Target: x86_64-apple-darwin15.0.0
> Configured with: ../configure --build=x86_64-apple-darwin15.0.0 
> --prefix=/usr/local/Cellar/gcc/5.3.0 
> --libdir=/usr/local/Cellar/gcc/5.3.0/lib/gcc/5 
> --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5 
> --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr 
> --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl 
> --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking 
> --enable-checking=release --enable-lto --with-build-config=bootstrap-debug 
> --disable-werror --with-pkgversion='Homebrew gcc 5.3.0' --with-bugurl=
> https://github.com/Homebrew/homebrew/issues --enable-plugin --disable-nls 
> --enable-multilib
> Thread model: posix
> gcc version 5.3.0 (Homebrew gcc 5.3.0) 
>
>

Re: [julia-users] Bizarre Segfault during ccall on OSX

[Rob J. Goedman]

Helge,

Not sure if this helps, but below the (successful) output on my machine. I’m on 
OS X 11.6-beta, but I don’t think that is important. I do remember installing 
an updated Xcode.

Regards,
Rob

> On May 30, 2016, at 08:41, Helge Eichhorn  wrote:
> 
> 
> 
> Hi!
> 
> I am having a strange problem with a segfault that seemingly appeared out of 
> nowhere while calling Fortran code on OSX.
> 
> When I try to run the tests of my Dopri.jl 
>  package on Julia 0.4.5 on OSX 10.11.5 
> the process consistently fails with this error message:
> signal (11): Segmentation fault: 11
> unknown function (ip: 0x0)
> 
> Tests pass on master and 0.3.12. Could somebody try to reproduce this 
> behavior on their machine? What puzzles me is that this did not happen 23 
> days ago when I fixed the lastest issue with the package. In the meantime I 
> did not change anything about neither the code nor the Julia runtime. I did 
> install an OS update, though.
> 
> Any ideas?
> 
> The only other data point I have is that the tests also segfault on 0.3 on 
> Travis but not consistently. On the third to fourth re-run the build usually 
> succeeds. I have attached the log.
> 
> Cheers,
> Helge
> 


julia> Pkg.add("Dopri")
INFO: No packages to install, update or remove
INFO: Package database updated

julia> using Dopri

julia> Pkg.test("Dopri")
INFO: Testing Dopri
ERROR: LoadError: could not spawn 
setenv(`/Users/rob/.julia/v0.4/Dopri/deps/testrunner`,Union{ASCIIString,UTF8String}["LD_LIBRARY_PATH=/Users/rob/.julia/v0.4/Dopri/deps"]):
 no such file or directory (ENOENT)
 in _jl_spawn at process.jl:262
 in anonymous at process.jl:415
 in setup_stdio at process.jl:403
 in spawn at process.jl:414
 in open at process.jl:478
 in open at process.jl:492
 in include at 
/Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
 in include_from_node1 at 
/Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
 in process_options at 
/Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
 in _start at 
/Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
while loading /Users/rob/.julia/v0.4/Dopri/test/runtests.jl, in expression 
starting on line 9
===[ ERROR: Dopri 
]===

failed process: 
Process(`/Applications/Julia-0.4.5.app/Contents/Resources/julia/bin/julia 
--check-bounds=yes --code-coverage=none --color=yes 
/Users/rob/.julia/v0.4/Dopri/test/runtests.jl`, ProcessExited(1)) [1]

==
ERROR: Dopri had test errors
 in error at 
/Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/julia/sys.dylib
 in test at pkg/entry.jl:803
 in anonymous at pkg/dir.jl:31
 in cd at file.jl:22
 in cd at pkg/dir.jl:31
 in test at pkg.jl:71

julia> Pkg.build("Dopri")
INFO: Building Dopri

julia> Pkg.test("Dopri")
INFO: Testing Dopri
INFO: Dopri tests passed

julia> versioninfo()
Julia Version 0.4.5
Commit 2ac304d (2016-03-18 00:58 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

shell> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/5.3.0/libexec/gcc/x86_64-apple-darwin15.0.0/5.3.0/lto-wrapper
Target: x86_64-apple-darwin15.0.0
Configured with: ../configure --build=x86_64-apple-darwin15.0.0 
--prefix=/usr/local/Cellar/gcc/5.3.0 
--libdir=/usr/local/Cellar/gcc/5.3.0/lib/gcc/5 
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5 
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr 
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl 
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking 
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug 
--disable-werror --with-pkgversion='Homebrew gcc 5.3.0' 
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin 
--disable-nls --enable-multilib
Thread model: posix
gcc version 5.3.0 (Homebrew gcc 5.3.0) 

[julia-users] What do @_inline_meta and @_propagate_inbounds_meta do?

[Kristoffer Carlsson]

I believe they insert the corresponding Meta node into the AST before the 
actual macros (like @inline) have been defined.

[julia-users] Re: Getting sequence of time and subset it

[Evan Fields]

I'm not 100% sure I understand your question, but let me give it a shot. 

First thing is to note why you're getting that MethodError. It's from the 
line

println(si in sdt1[i, [:BreakTime1, :BreakTime2]])

Define sdt1 as you do (I just copied into a Julia REPL) and set i = 1 to 
for the first iteration of the for loop.

Then:

julia> sdt1[i, [:BreakTime1, :BreakTime2]]
1×2 DataFrames.DataFrame
│ Row │ BreakTime1  │ BreakTime2  │
├─┼─┼─┤
│ 1   │ 2016-04-13T10:00:00 │ 2016-04-13T12:00:00 │

julia> si = 
Dates.format([sdt1[i,:StartTime]:Dates.Minute(30):sdt1[i,:EndTime]], 
"HH:MM")
WARNING: [a] concatenation is deprecated; use collect(a) instead
 in depwarn at deprecated.jl:73
 in oldstyle_vcat_warning at abstractarray.jl:29
 in vect at abstractarray.jl:32
while loading no file, in expression starting on line 0
11-element Array{Any,1}:
 "07:15"
 "07:45"
 "08:15"
 "08:45"
 "09:15"
 "09:45"
 "10:15"
 "10:45"
 "11:15"
 "11:45"
 "12:15"

julia> si in sdt1[i, [:BreakTime1, :BreakTime2]]
ERROR: MethodError: `start` has no method matching 
start(::DataFrames.DataFrame)
 in mapreduce_sc_impl at reduce.jl:194
 in in at reduce.jl:377

So si is of type Vector{Any} but happens to hold strings. sdt1[i, 
[:BreakTime1, :BreakTime2]] is a DataFrame. What does it mean to ask if a 
vector is in a DataFrame? That's what's happening in your println; the `in` 
is just an infix operator of function in.

3-element Array{Int64,1}:
 1
 2
 3

julia> 1 in x
true

julia> in(1,x)
true

julia> in(5,x)
false

I assume you get the MethodError of no method start because in(a,b) 
iterates over b, checking each element of b for equality to a. But 
DataFrames are not iterable in this way. (This part just a guess; look it 
up in the manual before telling your friends.)

Anyway, to get output as from your R snippet, you could use a loop like the 
following:

julia> for i in 1:nrow(sdt1), t in 
sdt1[:StartTime][i]:Dates.Minute(30):sdt1[:EndTime][i]
   if !(t in [sdt1[:BreakTime1][i], sdt1[:BreakTime2][i]])
   println("$i $(Dates.format(t, "HH:MM"))")
   end
   end
1 07:00
1 07:30
1 08:00
1 08:30
1 09:00
1 09:30
1 10:30
1 11:00
1 11:30
2 07:15
2 07:45
2 08:15
2 08:45
2 09:15
2 09:45
2 10:45
2 11:15
2 11:45

I hope this helps!

[julia-users] Bizarre Segfault during ccall on OSX

[Helge Eichhorn]

Hi!

I am having a strange problem with a segfault that seemingly appeared out 
of nowhere while calling Fortran code on OSX.

When I try to run the tests of my Dopri.jl 
 package on Julia 0.4.5 on OSX 10.11.5 
the process consistently fails with this error message:
signal (11): Segmentation fault: 11
unknown function (ip: 0x0)

Tests pass on master and 0.3.12. Could somebody try to reproduce this 
behavior on their machine? What puzzles me is that this did not happen 23 
days ago when I fixed the lastest issue with the package. In the meantime I 
did not change anything about neither the code nor the Julia runtime. I did 
install an OS update, though.

Any ideas?

The only other data point I have is that the tests also segfault on 0.3 on 
Travis but not consistently. On the third to fourth re-run the build 
usually succeeds. I have attached the log.

Cheers,
Helge
travis_fold:start:worker_info
Worker information
hostname: worker-jupiter-brain:16379610-1a24-4cf8-a86c-f609d20857aa
version: v2.0.0 
https://github.com/travis-ci/worker/tree/ca6cb0c5d3920912b1c3acc87c44a5da2120a971
instance: 8788b526-6ab4-47ae-8e76-5dce8d508685:
startup: 1m5.751060889s
travis_fold:end:worker_info
travis_fold:start:system_info
Build system information

Build language: julia

Build group: stable

Build dist: precise

travis_fold:end:system_info


travis_fold:start:fix.CVE-2015-7547
$ export DEBIAN_FRONTEND=noninteractive

travis_fold:end:fix.CVE-2015-7547
Fix WWDRCA Certificate

travis_fold:start:git.checkout
travis_time:start:0f8b7642
$ git clone --depth=50 --branch=v0.1.2 
https://github.com/helgee/Dopri.jl.git helgee/Dopri.jl

Cloning into 'helgee/Dopri.jl'...

remote: Counting objects: 177, done.

remote: Compressing objects:  20% (1/5)   
remote: Compressing objects:  40% (2/5)   
remote: Compressing objects:  60% (3/5)   
remote: Compressing objects:  80% (4/5)   
remote: Compressing objects: 100% (5/5)   
remote: Compressing objects: 100% (5/5), done.

Receiving objects:   0% (1/177)   
Receiving objects:   1% (2/177)   
Receiving objects:   2% (4/177)   
Receiving objects:   3% (6/177)   
Receiving objects:   4% (8/177)   
Receiving objects:   5% (9/177)   
Receiving objects:   6% (11/177)   
Receiving objects:   7% (13/177)   
Receiving objects:   8% (15/177)   
Receiving objects:   9% (16/177)   
Receiving objects:  10% (18/177)   
Receiving objects:  11% (20/177)   
Receiving objects:  12% (22/177)   
Receiving objects:  13% (24/177)   
Receiving objects:  14% (25/177)   
Receiving objects:  15% (27/177)   
Receiving objects:  16% (29/177)   
Receiving objects:  17% (31/177)   
Receiving objects:  18% (32/177)   
Receiving objects:  19% (34/177)   
Receiving objects:  20% (36/177)   
Receiving objects:  21% (38/177)   
Receiving objects:  22% (39/177)   
Receiving objects:  23% (41/177)   
Receiving objects:  24% (43/177)   
Receiving objects:  25% (45/177)   
Receiving objects:  26% (47/177)   
Receiving objects:  27% (48/177)   
Receiving objects:  28% (50/177)   
Receiving objects:  29% (52/177)   
Receiving objects:  30% (54/177)   
Receiving objects:  31% (55/177)   
Receiving objects:  32% (57/177)   
Receiving objects:  33% (59/177)   
Receiving objects:  34% (61/177)   
Receiving objects:  35% (62/177)   
Receiving objects:  36% (64/177)   
Receiving objects:  37% (66/177)   
Receiving objects:  38% (68/177)   
Receiving objects:  39% (70/177)   
Receiving objects:  40% (71/177)   
Receiving objects:  41% (73/177)   
Receiving objects:  42% (75/177)   
Receiving objects:  43% (77/177)   
Receiving objects:  44% (78/177)   
Receiving objects:  45% (80/177)   
Receiving objects:  46% (82/177)   
Receiving objects:  47% (84/177)   
Receiving objects:  48% (85/177)   
remote: Total 177 (delta 0), reused 5 (delta 0), pack-reused 172

Receiving objects:  49% (87/177)   
Receiving objects:  50% (89/177)   
Receiving objects:  51% (91/177)   
Receiving objects:  52% (93/177)   
Receiving objects:  53% (94/177)   
Receiving objects:  54% (96/177)   
Receiving objects:  55% (98/177)   
Receiving objects:  56% (100/177)   
Receiving objects:  57% (101/177)   
Receiving objects:  58% (103/177)   
Receiving objects:  59% (105/177)   
Receiving objects:  60% (107/177)   
Receiving objects:  61% (108/177)   
Receiving objects:  62% (110/177)   
Receiving objects:  63% (112/177)   
Receiving objects:  64% (114/177)   
Receiving objects:  65% (116/177)   
Receiving objects:  66% (117/177)   
Receiving objects:  67% (119/177)   
Receiving objects:  68% (121/177)   
Receiving objects:  69% (123/177)   
Receiving objects:  70% (124/177)   
Receiving objects:  71% (126/177)   
Receiving objects:  72% (128/177)   
Receiving objects:  73% (130/177)   
Receiving objects:  74% (131/177)   
Receiving objects:  75% (133/177)   
Receiving objects:  76% (135/177)   
Receiving objects:  77% (137/177)   
Receiving objects:  78%

[julia-users] What do @_inline_meta and @_propagate_inbounds_meta do?

[Davide Lasagna]

Hi, 

code in abstractarray.jl (master) is filled with calls to @_inline_meta and 
@_propagate_inbounds_meta. Can someone explain what do these to macro do? 

Thanks!

[julia-users] Re: Julia Users Berlin

[Simon Danisch]

That's awesome!
I'm based in Berlin and just recently discussed with different people that 
we really need a meetup... So, thanks for doing this!
I should be able to attend, looking forward seeing everyone there.

Best,
Simon

Am Montag, 30. Mai 2016 15:16:08 UTC+2 schrieb David Higgins:
>
> Hi all,
>
> I gave a talk at the recent PyData Berlin conference (
> http://pydata.org/berlin2016/) and there seems to be enough interest in 
> forming a regular users group in the city. Some of you may recall that we 
> had a preliminary meeting a year ago, which happened to coincide with Viral 
> Shah being within striking distance and he came along, but at the time none 
> of us were really ready to make it a regular event.
>
> A year is a long time in the life of a Julia user. Now there are more of 
> us and we'd like to meet up again.
>
> On *Thursday June 9th *at* 7pm*, we're going to meet at St Oberholz 
> (Rosenthaler 
> Str. 72A, 10119 Berlin). Miles Lubin from JuMP happens to be in town, so 
> the topics of the night might include (i) numerical optimisation and (ii) 
> how to organise more regular meetings (topics, location). So please come 
> along. The reservation is in the name Robert Schwarz and based on previous 
> experience we'll probably be upstairs at the back of the room.
>
> By the way, I've created a landing page for a Julia Users Group - Berlin 
> on GitHub. Feel free to contribute. http://julia-users-berlin.github.io/
>
> David Higgins
>
>

Re: [julia-users] Julia users Berlin

[David Higgins]

Hi all,

I've announced a new meet-up with a visiting speaker 
here https://groups.google.com/forum/#!topic/julia-users/S3eMY64c_dE

Hope to see you in two weeks.

David.

On Thursday, 26 March 2015 22:55:02 UTC+1, Max Suster wrote:
>
>
> I would have loved to join too, but it was too short notice for me. . .
> I will definitely do this regularly (and be happy to help) once I have 
> settled in Berlin. 
>
> Max
>
> On Wednesday, March 25, 2015 at 4:19:01 PM UTC+1, David Higgins wrote:
>>
>> Reservation changed:
>>
>> Thursday, 26th March, *5pm* at St. Oberholz, Rosenthaler Straße 72A
>>
>> It's still in my name (Higgins).
>>
>> Looking forward to seeing you then,
>> David.
>>
>> On Wednesday, 25 March 2015 15:05:07 UTC+1, Keyan wrote:
>>>
>>> I won’t make it either, but I hope that I can join in on some other day.
>>>
>>> Cheers,
>>> Keyan
>>>
>>> On 25 Mar 2015, at 11:54, Felix Jung  wrote:
>>>
>>> Sorry guys. Would have loved to come but can't make it on that date. If 
>>> we make this a regular thing I'd be happy to participate in an active 
>>> manner.
>>>
>>> Have fun,
>>>
>>> Felix
>>>
>>> On 25 Mar 2015, at 09:37, David Higgins  wrote:
>>>
>>> Both times are fine with me, I just need to change the reservation if we 
>>> go with that.
>>>
>>> By my count, from the thread above the following people are probably 
>>> coming:
>>> Viral Shah
>>> Simon Danisch
>>> Felix Schueler
>>> David Higgins
>>> Felix Jung? ("wow, cool stuff" :) )
>>> Fabian Gans?? (Jena)
>>> One other person contacted me off-list to say they'll come if some 
>>> travel arrangements work out.
>>>
>>> The first four are ok with an earlier meeting time. I imagine it's 
>>> getting late for Fabian to arrange a train from Jena, but 5pm would 
>>> certainly work better for him.
>>>
>>> So, any objections to changing from 7pm to 5pm? (ie. who's lurking out 
>>> there and hasn't replied yet but was hoping to come?)
>>>
>>> David.
>>>
>>> On Wednesday, 25 March 2015 07:26:16 UTC+1, Viral Shah wrote:

 How about we aim for 5pm in that case? I think I can make it by then. 
 Does that work for others?

 -viral

 On Tuesday, March 24, 2015 at 11:07:40 AM UTC+1, Simon Danisch wrote:
>
> My train leaves at 9pm (at least the train station is close), so I'd 
> probably go there 1-2 hours early and see who drops by.
> Felix Schüler would come earlier as well ;)
> @David Higgins
> Do we need to call them to adjust this properly?
> On 24 Mar 2015 08:56, "Fabian Gans"  wrote:
>
>> I will not be there. 7 seems to be too late for me to get back to 
>> Jena the same day. 
>>
>> Fabian
>>
>
>>>

[julia-users] Julia Users Berlin

[David Higgins]

Hi all,

I gave a talk at the recent PyData Berlin conference 
(http://pydata.org/berlin2016/) and there seems to be enough interest in 
forming a regular users group in the city. Some of you may recall that we 
had a preliminary meeting a year ago, which happened to coincide with Viral 
Shah being within striking distance and he came along, but at the time none 
of us were really ready to make it a regular event.

A year is a long time in the life of a Julia user. Now there are more of us 
and we'd like to meet up again.

On *Thursday June 9th *at* 7pm*, we're going to meet at St Oberholz 
(Rosenthaler 
Str. 72A, 10119 Berlin). Miles Lubin from JuMP happens to be in town, so 
the topics of the night might include (i) numerical optimisation and (ii) 
how to organise more regular meetings (topics, location). So please come 
along. The reservation is in the name Robert Schwarz and based on previous 
experience we'll probably be upstairs at the back of the room.

By the way, I've created a landing page for a Julia Users Group - Berlin on 
GitHub. Feel free to contribute. http://julia-users-berlin.github.io/

David Higgins

Re: [julia-users] Re: Using Julia for real time astronomy

[Tamas Papp]

You could test whether the GC is fast enough by implementing the
computational core (using simulated data or something similar), then
just running it. Then if you find it is not acceptable, you haven't
wasted time on writing the code for interfacing with the equipment.

Also, you could think about the "cost" of an occasional longer GC run,
and what the acceptable failure rate is. For example, is it a great
concern if you have suboptimal quality or even total loss of every
1000th frame? or 1th? Of course one would like to have all the data,
but equipment can be down for all sorts of reasons and maybe the GC
hiccups will not be your primary concern.

Best,

Tamas

On Mon, May 30 2016, Leger Jonathan wrote:

> Thanks for the answer.
>
> I don't intend to use any package, only use my array so I can confirm 
> that I will not have dynamic memory allocation (let's hope that I'm true 
> ;) ).
> But even in this case Julia itself may do allocations, so my question 
> would be more: if there is nearly nothing to do, is the GC fast ?
> I already read many topics about GC and yes, even if there was very good 
> improvements, is it enough for my case ?
>
> In the worst case Julia will be for testing and will only call the main 
> loop in C++.
>
> Le 30/05/2016 14:10, Uwe Fechner a écrit :
>> I think, that would be difficult.
>>
>> As soon as you use any packages for image conversion or estimation you 
>> have to assume that they use dynamic memory allocation.
>>
>> The garbage collector of Julia is fast, but not suitable for hard 
>> real-time requirements. Implementing a garbage collector for hard 
>> real-time
>> applications is possible, but a lot of work and will probably not 
>> happen in the near future.
>>
>> Their was an issue on this topic, that was closed as "won't fix":
>> https://github.com/JuliaLang/julia/issues/8543
>>
>> Uwe
>>
>> On Monday, May 30, 2016 at 12:00:13 PM UTC+2, John leger wrote:
>>
>> Hi everyone,
>>
>> I am working in astronomy and we are thinking of using Julia for a
>> real time, high performance adaptive optics system on a solar
>> telescope.
>>
>> This is how the system is supposed to work:
>>1) the image is read from the camera
>>2) some correction are applied
>>3) the atmospheric turbulence is numerically estimated in order
>> to calculate the command to be sent to the deformable mirror
>>
>> The overall process should be executed in less than 1ms so that it
>> can be integrated to the chain (closed loop).
>>
>> Do you think it is possible to do all the computation in Julia or
>> would it be better to code some part in C/C++. What I fear the
>> most is the GC but in our case we can pre-allocate everything, so
>> once we launch the system there will not be any memory allocated
>> during the experiment and it will run for days.
>>
>> So, what do you think? Considering the current state of Julia will
>> I be able to get the performances I need. Will the garbage
>> collector be an hindrance ?
>>
>> Thank you.
>>

Re: [julia-users] Re: Using Julia for real time astronomy

[Leger Jonathan]

Thanks for the answer.

I don't intend to use any package, only use my array so I can confirm 
that I will not have dynamic memory allocation (let's hope that I'm true 
;) ).
But even in this case Julia itself may do allocations, so my question 
would be more: if there is nearly nothing to do, is the GC fast ?
I already read many topics about GC and yes, even if there was very good 
improvements, is it enough for my case ?


In the worst case Julia will be for testing and will only call the main 
loop in C++.


Le 30/05/2016 14:10, Uwe Fechner a écrit :

I think, that would be difficult.

As soon as you use any packages for image conversion or estimation you 
have to assume that they use dynamic memory allocation.


The garbage collector of Julia is fast, but not suitable for hard 
real-time requirements. Implementing a garbage collector for hard 
real-time
applications is possible, but a lot of work and will probably not 
happen in the near future.


Their was an issue on this topic, that was closed as "won't fix":
https://github.com/JuliaLang/julia/issues/8543

Uwe

On Monday, May 30, 2016 at 12:00:13 PM UTC+2, John leger wrote:

Hi everyone,

I am working in astronomy and we are thinking of using Julia for a
real time, high performance adaptive optics system on a solar
telescope.

This is how the system is supposed to work:
   1) the image is read from the camera
   2) some correction are applied
   3) the atmospheric turbulence is numerically estimated in order
to calculate the command to be sent to the deformable mirror

The overall process should be executed in less than 1ms so that it
can be integrated to the chain (closed loop).

Do you think it is possible to do all the computation in Julia or
would it be better to code some part in C/C++. What I fear the
most is the GC but in our case we can pre-allocate everything, so
once we launch the system there will not be any memory allocated
during the experiment and it will run for days.

So, what do you think? Considering the current state of Julia will
I be able to get the performances I need. Will the garbage
collector be an hindrance ?

Thank you.

[julia-users] Re: Using Julia for real time astronomy

[Uwe Fechner]

I think, that would be difficult.

As soon as you use any packages for image conversion or estimation you have 
to assume that they use dynamic memory allocation.

The garbage collector of Julia is fast, but not suitable for hard real-time 
requirements. Implementing a garbage collector for hard real-time
applications is possible, but a lot of work and will probably not happen in 
the near future.

Their was an issue on this topic, that was closed as "won't fix":
https://github.com/JuliaLang/julia/issues/8543

Uwe

On Monday, May 30, 2016 at 12:00:13 PM UTC+2, John leger wrote:
>
> Hi everyone,
>
> I am working in astronomy and we are thinking of using Julia for a real 
> time, high performance adaptive optics system on a solar telescope.
>
> This is how the system is supposed to work: 
>1) the image is read from the camera
>2) some correction are applied
>3) the atmospheric turbulence is numerically estimated in order to 
> calculate the command to be sent to the deformable mirror
>
> The overall process should be executed in less than 1ms so that it can be 
> integrated to the chain (closed loop).
>
> Do you think it is possible to do all the computation in Julia or would it 
> be better to code some part in C/C++. What I fear the most is the GC but in 
> our case we can pre-allocate everything, so once we launch the system there 
> will not be any memory allocated during the experiment and it will run for 
> days.
>
> So, what do you think? Considering the current state of Julia will I be 
> able to get the performances I need. Will the garbage collector be an 
> hindrance ?
>
> Thank you.
>

Re: [julia-users] Re: What is the difference between bitwise and logical operators?

[Tamas Papp]

See

http://docs.julialang.org/en/release-0.4/manual/control-flow/#man-short-circuit-evaluation

A lot of effort went into writing and improving the language manual, so
that you can find very detailed answers to questions like this one. It
is fine to ask on the list if you can't find it, but giving the whole
manual a read is very useful for new users of Julia.

On Mon, May 30 2016, Ford Ox wrote:

> Ye I know what bitwise operator does.
> I will ask in different way, maybe it will be clearer to you.
>
> Why people use logical operators ( f.e. in conditions ) instead of bitwise
> operators? Is && <: & ?
>
>
> On Monday, May 30, 2016 at 9:58:02 AM UTC+2, Kaj Wiik wrote:
>>
>>
>> Here's a clue:
>>
>>
>> julia> 0b10010011 & 0b10010011
>> 0x93
>>
>> julia> 0b10010011 && 0b10010011
>> ERROR: TypeError: non-boolean (UInt8) used in boolean context
>>
>>
>> Kaj
>>
>>
>> On Monday, May 30, 2016 at 9:30:22 AM UTC+3, Ford Ox wrote:
>>>
>>> For example
>>> true & false == true && false
>>>
>>> Is it just artifact from c where bool types don't exist?
>>>
>>

[julia-users] Re: doc fix: transposition operators in section highlighting difference to R

[James Gilbert]

Ah, there is!  Didn't refresh the tab I left open with this thread.

On Monday, 30 May 2016 12:07:14 UTC+1, James Gilbert wrote:
>
> Hmm, this line was introduced in this commit:
>
>   Major cleanup of 'Noteworth differences' 
> 
>
> where it appears to be correct.  Is there some kind of bug rendering 
> :obj:`.'`?
>
>

[julia-users] Re: doc fix: transposition operators in section highlighting difference to R

[James Gilbert]

Hmm, this line was introduced in this commit:

  Major cleanup of 'Noteworth differences' 


where it appears to be correct.  Is there some kind of bug rendering 
:obj:`.'`?

[julia-users] Re: What is the difference between bitwise and logical operators?

[Scott Jones]

The &&  and || operators are conditional, as in other languages.
The second operand is not always evaluated.

[julia-users] Re: What is the difference between bitwise and logical operators?

[Ford Ox]

Ye I know what bitwise operator does.
I will ask in different way, maybe it will be clearer to you.

Why people use logical operators ( f.e. in conditions ) instead of bitwise 
operators? Is && <: & ?


On Monday, May 30, 2016 at 9:58:02 AM UTC+2, Kaj Wiik wrote:
>
>
> Here's a clue:
>
>
> julia> 0b10010011 & 0b10010011
> 0x93
>
> julia> 0b10010011 && 0b10010011
> ERROR: TypeError: non-boolean (UInt8) used in boolean context
>
>
> Kaj
>
>
> On Monday, May 30, 2016 at 9:30:22 AM UTC+3, Ford Ox wrote:
>>
>> For example 
>> true & false == true && false
>>
>> Is it just artifact from c where bool types don't exist?
>>
>

[julia-users] Using Julia for real time astronomy

[John leger]

Hi everyone,

I am working in astronomy and we are thinking of using Julia for a real 
time, high performance adaptive optics system on a solar telescope.

This is how the system is supposed to work: 
   1) the image is read from the camera
   2) some correction are applied
   3) the atmospheric turbulence is numerically estimated in order to 
calculate the command to be sent to the deformable mirror

The overall process should be executed in less than 1ms so that it can be 
integrated to the chain (closed loop).

Do you think it is possible to do all the computation in Julia or would it 
be better to code some part in C/C++. What I fear the most is the GC but in 
our case we can pre-allocate everything, so once we launch the system there 
will not be any memory allocated during the experiment and it will run for 
days.

So, what do you think? Considering the current state of Julia will I be 
able to get the performances I need. Will the garbage collector be an 
hindrance ?

Thank you.

Re: [julia-users] doc fix: transposition operators in section highlighting difference to R

[Tamas Papp]

See

https://github.com/JuliaLang/julia/issues/16259#issuecomment-217703153

On Sun, May 29 2016, James Gilbert wrote:

> In Noteworthy Differences to R it says:
>
> * Julia performs matrix transposition using the ' operator and conjugated 
> transposition using
>  the ' operator. Julia’s A.' is therefore equivalent to R’s t(A).
>
> The matrix transposition should be: .'

[julia-users] Getting sequence of time and subset it

[akrun]

I have a dataset similar to the one below

   sdt1 = DataFrame(ID = 1:2, StartTime = DateTime(["4/13/2016 07:00", 
"4/13/2016 07:15"], "m/d/y H:M"), 
EndTime = DateTime(["4/13/2016 12:00", 
"4/13/2016 12:15"], "m/d/y H:M"),
BreakTime1 = DateTime(["4/13/2016 10:00", 
"4/13/2016 10:15"], "m/d/y H:M"),
BreakTime2 = DateTime(["4/13/2016 12:00", 
"4/13/2016 12:15"], "m/d/y H:M") 
)

I can get the sequence of date time using

   for i in 1:nrow(sdt1)
   si = 
Dates.format([sdt1[i,:StartTime]:Dates.Minute(30):sdt1[i,:EndTime]], 
"HH:MM")
println(si)
  end 

#Any["07:00","07:30","08:00","08:30","09:00","09:30","10:00","10:30","11:00","11:30","12:00"]
#Any["07:15","07:45","08:15","08:45","09:15","09:45","10:15","10:45","11:15","11:45","12:15"]


Suppose I want to subset the sequence to not include the times in BreakTime 
columns, how do I do it?  I have tried
  for i in 1:nrow(sdt1)
si = 
Dates.format([sdt1[i,:StartTime]:Dates.Minute(30):sdt1[i,:EndTime]], 
"HH:MM")
 println(si in sdt1[i, [:BreakTime1, :BreakTime2]])
   end 

I get an error message
MethodError: `start` has no method matching start(::DataFrames.DataFrame)
 in mapreduce_sc_impl at reduce.jl:194
 in in at reduce.jl:377
 
I can do this using data.table in R

library(data.table)
dt1 <- data.table(ID = 1:2, StartTime =as.POSIXct(c("4/13/2016 07:00", 
"4/13/2016 07:15"), "%m/%d/%Y %H:%M", tz = "GMT"), 
EndTime =as.POSIXct(c("4/13/2016 14:00", 
"4/13/2016 14:15"), "%m/%d/%Y %H:%M", tz = "GMT"),
BreakTime1 = as.POSIXct(c("4/13/2016 10:00", 
"4/13/2016 10:15"), "%m/%d/%Y %H:%M", tz = "GMT"),
BreakTime2 = as.POSIXct(c("4/13/2016 12:00", 
"4/13/2016 12:15"), "%m/%d/%Y %H:%M", tz = "GMT"))
dt1[, {
 s1 <- head(seq(StartTime, EndTime, by = "30 min"), -1)
 list(time= format(s1[!s1 %in% c(BreakTime1, BreakTime2)], "%H:%M"))}, 
  by = ID]
ID  time
 1:  1 07:00
 2:  1 07:30
 3:  1 08:00
 4:  1 08:30
 5:  1 09:00
 6:  1 09:30
 7:  1 10:30
 8:  1 11:00
 9:  1 11:30
10:  1 12:30
11:  1 13:00
12:  1 13:30
13:  2 07:15
14:  2 07:45
15:  2 08:15
16:  2 08:45
17:  2 09:15
18:  2 09:45
19:  2 10:45
20:  2 11:15
21:  2 11:45
22:  2 12:45
23:  2 13:15
24:  2 13:45

Thanks.




   

[julia-users] Re: What is the difference between bitwise and logical operators?

[Kaj Wiik]

Here's a clue:


julia> 0b10010011 & 0b10010011
0x93

julia> 0b10010011 && 0b10010011
ERROR: TypeError: non-boolean (UInt8) used in boolean context


Kaj


On Monday, May 30, 2016 at 9:30:22 AM UTC+3, Ford Ox wrote:
>
> For example 
> true & false == true && false
>
> Is it just artifact from c where bool types don't exist?
>

[julia-users] Getting sequence of datetime and format it

[akrun]

I have a data similar to the one below

sdt1 = DataFrame(ID = 1:2, StartTime = DateTime(["4/13/2016 07:00", 
"4/13/2016 07:15"], "m/d/y H:M"), EndTime = DateTime(["4/13/2016 12:00", 
"4/13/2016 12:15"], "m/d/y H:M"))

I would like to get the sequence between StartTime and EndTime by 30 minutes

I can get it formatted using

for i in 1:nrow(sdt1)
si = 
Dates.format([sdt1[i,:StartTime]:Dates.Minute(30):sdt1[i,:EndTime]], 
"HH:MM")
println(si)
end 
 
and get the result as

 
Any["07:00","07:30","08:00","08:30","09:00","09:30","10:00","10:30","11:00","11:30","12:00"]

Any["07:15","07:45","08:15","08:45","09:15","09:45","10:15","10:45","11:15","11:45","12:15"]


Is it possible to get an output like the one I get with `data.table` from R 
by storing the intermediate results in a array or so?

  library(data.table)
 dt1 <- data.table(ID = 1:2, StartTime =as.POSIXct(c("4/13/2016 07:00", 
"4/13/2016 07:15"), "%m/%d/%Y %H:%M", tz = "GMT"), EndTime 
=as.POSIXct(c("4/13/2016 12:00", "4/13/2016 12:15"), "%m/%d/%Y %H:%M", tz = 
"GMT"))

  dt1[, .(time = format(seq(StartTime, EndTime, by = "30 min"), 
"%H:%M")) ,by = ID]
ID  time
 1:  1 07:00
 2:  1 07:30
 3:  1 08:00
 4:  1 08:30
 5:  1 09:00
 6:  1 09:30
 7:  1 10:00
 8:  1 10:30
 9:  1 11:00
10:  1 11:30
11:  1 12:00
12:  2 07:15
13:  2 07:45
14:  2 08:15
15:  2 08:45
16:  2 09:15
17:  2 09:45
18:  2 10:15
19:  2 10:45
20:  2 11:15
21:  2 11:45
22:  2 12:15
ID  time



Thanking you,