[julia-users] Re: Convert ASCIIString to Uint8

[Scott Jones]

convert(Vector{UInt8}, str) will work fine.


On Saturday, February 6, 2016 at 8:31:19 PM UTC-5, icebl...@gmail.com wrote:
>
> Hello,
>
> I m trying to convert ASCIIString (or ASCII) to Uint8 . 
>
> b"string" seems to be the option. However it doesnt seem to handle 
> b"$(variable)"
>
> Also, reinterpret and convert dont seem to do the job.
>
> Any easy way to do this conversion?  Any ideas?
>
> Thanks 
>

[julia-users] Re: Convert ASCIIString to Uint8

[iceblue25 . 1]

Thanks, it works

On Saturday, February 6, 2016 at 6:43:28 PM UTC-8, Fengyang Wang wrote:
>
> collect(UInt8, "hello world")
>
> should do the trick.
>
> On Saturday, February 6, 2016 at 8:31:19 PM UTC-5, icebl...@gmail.com 
> wrote:
>>
>> Hello,
>>
>> I m trying to convert ASCIIString (or ASCII) to Uint8 . 
>>
>> b"string" seems to be the option. However it doesnt seem to handle 
>> b"$(variable)"
>>
>> Also, reinterpret and convert dont seem to do the job.
>>
>> Any easy way to do this conversion?  Any ideas?
>>
>> Thanks 
>>
>

Re: [julia-users] Color.jl - Colors.jl?

[Kevin Squire]

Hi Andreas,

Colors.jl is meant as a complete replacement for Color.jl.  The latter is
not installable on Julia v0.4 and above.

See this julia-users post
 for
more information.

I'm not sure why Issues were disabled on Colors.jl, but I just reenabled
them.

Cheers,
   Kevin


On Sat, Feb 6, 2016 at 11:45 PM, Andreas Lobinger 
wrote:

> Hello colleagues,
>
> although i was somehow connected to the discussion about this transitions,
> i'm a little bit lost right now.
> Is Colors.jl replacing Color.jl completely? Or it's 'just' a fork for the
> use of the new ColorTypes?
> And why do i miss to see an issues tab on the githup page? Is the
> development closed to JuliaGraphics users?
>
> Wishing a happy day,
>  Andreas
>

Re: [julia-users] Re: Understanding immutables

[Cedric St-Jean]

On Sun, Feb 7, 2016 at 10:11 AM, Bart Janssens  wrote:

>
> On Sunday, February 7, 2016 at 3:39:51 PM UTC+1, Cedric St-Jean wrote:
>
>> then `a` is stack-allocated. The foo(a) call may either copy `a` further,
>> or just pass on a stack pointer to the existing `a`, depending on compiler
>> details. Any stack-allocated object gets automatically wiped as the stack
>> unwinds, hence does not need GC'ing.
>>
>>
> I think that in this case "a" is heap-allocated, since ImagePos is not a
> bits type.
>

I don't think this necessarily follows. Inside ImagePos, there is a pointer
to an Image, which is why it's not a bits type, but that doesn't preclude
stack allocation in general.


> You can check this with isbits(). Just today, I found the following post
> that explains this at length:
> http://julialang.org/blog/2013/03/efficient-aggregates/
>
> Cheers,
>
> Bart
>

Re: [julia-users] Re: Periodic or cyclic arrays possible?

[Erik Schnetter]

The expression `(i-1) % length + 1` is not correct for negative `i`.
You have to use `mod` instead of `%`.

Julia has a function `mod1(x,y)` that is essentially defined as
`mod(x-1, y) +1`, so that's what you probably want to use.

-erik

On Sat, Feb 6, 2016 at 8:40 PM, Cedric St-Jean  wrote:
> You can define our own datatype to do this. It's one of the most fundamental
> tasks in Julia!
>
> immutable CircularArray{T}
> arr::Vector{T}
> end
>
> Base.getindex(ca::CircularArray, i) = ca.arr[(i-1) % length(ca.arr) + 1]
> Base.setindex(...) = ...
> ...
>
> a = CircularArray([1,2,3])
> a[14] # yields 2
>
> Cédric
>
>
> On Saturday, February 6, 2016 at 7:08:03 PM UTC-5, Ferran Mazzanti wrote:
>>
>> Hi folks,
>>
>> I was wondering if it is possible to use in a simple way cyclic arrays in
>> Julia? What I'm after is sometbing that understands that the next element in
>> a[] after end is a[1], so a[end+1]=a[1], a[end+2]=a[2] etc... I know I can
>> index the array with the remainder operator % to achieve this same result,
>> but I wonder if one can declare the array directly in one way or another to
>> achieve this directly.
>>
>> Thanks in advance,
>>
>> Ferran.



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

Re: [julia-users] Memory allocation free array slices ?

[Stefan Karpinski]

Being able to stack-allocate objects that refer to the heap is an important
case that we need to address, but doing so is non-trivial and hasn't been
done yet.

On Sunday, February 7, 2016, Tim Holy  wrote:

> I filed an issue, https://github.com/JuliaLang/julia/issues/14955, which
> you
> can check to learn about progress on this problem.
>
> Best,
> --Tim
>
> On Saturday, February 06, 2016 03:35:34 PM Nitin Arora wrote:
> > I see, thanks for the information. I think, if possible, this feature
> will
> > help the language a lot.
> >
> > I have recommended Julia to many of my colleagues (they all love it over
> > Fortran and Matlab) and most of them seem to run into this issue. I
> think,
> > a modern language with soo much elegance and potential, like Julia,
> should
> > nail such major issues. I am sure by V-1.0 we will have the best
> scientific
> > programming language ever :-)
> >
> > thanks,
> > Nitin
> >
> > On Saturday, February 6, 2016 at 3:55:56 AM UTC-8, Tim Holy wrote:
> > > On Friday, February 05, 2016 05:24:04 PM Nitin Arora wrote:
> > > > Thanks Tim, this is very useful. I will probably use CartesianRange
> now.
> > > >
> > > > Is Julia 0.5 Arraypocalypse planning to address this issue as well ?
> > >
> > > I don't think there's a way to solve this by changing our
> implementation
> > > of
> > > views; I think it's more of a compiler issue, and the fact that
> > >
> > > julia> isbits(CartesianRange((3,5)))
> > > true
> > >
> > > julia> immutable ArrayWrapper{M}
> > >
> > >data::M
> > >
> > >end
> > >
> > > julia> z = rand(5,5);
> > >
> > > julia> isbits(ArrayWrapper(z))
> > > false
> > >
> > >
> > > Since I don't work on the compiler, I can't speak for what's going to
> > > happen
> > > there, but I'd be surprised if this changes in 0.5.
> > >
> > > Best,
> > > --Tim
> > >
> > > > thanks,
> > > > Nitin
> > > >
> > > > On Friday, February 5, 2016 at 3:24:34 PM UTC-8, Tim Holy wrote:
> > > > > On Friday, February 05, 2016 08:17:21 AM Kevin Squire wrote:
> > > > > > I think this needs to be @time bar(A).
> > > > >
> > > > > Yeah, sorry for the typo.
> > > > >
> > > > > > I get
> > > > > >
> > > > > > julia> @time bar(A)
> > > > > >
> > > > > >   0.000269 seconds (5 allocations: 176 bytes)
> > > > > >
> > > > > > 20010.937886591404
> > > > >
> > > > > That's just REPL allocation. Since A has 1 columns, if this
> > >
> > > strategy
> > >
> > > > > were
> > > > > allocating you'd expect "1+n allocations," where n comes from
> the
> > > > > REPL.
> > > > >
> > > > > --Tim
>
>

Re: [julia-users] Memory allocation free array slices ?

[Tim Holy]

I filed an issue, https://github.com/JuliaLang/julia/issues/14955, which you 
can check to learn about progress on this problem.

Best,
--Tim

On Saturday, February 06, 2016 03:35:34 PM Nitin Arora wrote:
> I see, thanks for the information. I think, if possible, this feature will
> help the language a lot.
> 
> I have recommended Julia to many of my colleagues (they all love it over
> Fortran and Matlab) and most of them seem to run into this issue. I think,
> a modern language with soo much elegance and potential, like Julia, should
> nail such major issues. I am sure by V-1.0 we will have the best scientific
> programming language ever :-)
> 
> thanks,
> Nitin
> 
> On Saturday, February 6, 2016 at 3:55:56 AM UTC-8, Tim Holy wrote:
> > On Friday, February 05, 2016 05:24:04 PM Nitin Arora wrote:
> > > Thanks Tim, this is very useful. I will probably use CartesianRange now.
> > > 
> > > Is Julia 0.5 Arraypocalypse planning to address this issue as well ?
> > 
> > I don't think there's a way to solve this by changing our implementation
> > of
> > views; I think it's more of a compiler issue, and the fact that
> > 
> > julia> isbits(CartesianRange((3,5)))
> > true
> > 
> > julia> immutable ArrayWrapper{M}
> > 
> >data::M
> >
> >end
> > 
> > julia> z = rand(5,5);
> > 
> > julia> isbits(ArrayWrapper(z))
> > false
> > 
> > 
> > Since I don't work on the compiler, I can't speak for what's going to
> > happen
> > there, but I'd be surprised if this changes in 0.5.
> > 
> > Best,
> > --Tim
> > 
> > > thanks,
> > > Nitin
> > > 
> > > On Friday, February 5, 2016 at 3:24:34 PM UTC-8, Tim Holy wrote:
> > > > On Friday, February 05, 2016 08:17:21 AM Kevin Squire wrote:
> > > > > I think this needs to be @time bar(A).
> > > > 
> > > > Yeah, sorry for the typo.
> > > > 
> > > > > I get
> > > > > 
> > > > > julia> @time bar(A)
> > > > > 
> > > > >   0.000269 seconds (5 allocations: 176 bytes)
> > > > > 
> > > > > 20010.937886591404
> > > > 
> > > > That's just REPL allocation. Since A has 1 columns, if this
> > 
> > strategy
> > 
> > > > were
> > > > allocating you'd expect "1+n allocations," where n comes from the
> > > > REPL.
> > > > 
> > > > --Tim

Re: [julia-users] Understanding immutables

[Tim Holy]

heap <--> stack (oops)

On Sunday, February 07, 2016 06:39:51 AM Cedric St-Jean wrote:
> There's an issue  on Github
> to add GC support for stack-allocated objects, and that makes no sense to
> me! Could someone please help me out? In my mind, stack-allocated objects =
> Int+Float+...+Immutable (in some circumstances). I thought that with
> Immutables, if I have
> 
> immutable ImagePos
>img::Image
>x::Int
>y::Int
> end
> 
> function blah(img)
>a = ImagePos(img, 10, 20)
>foo(a)
>l = Any[40, a]
> end
> 
> then `a` is stack-allocated. The foo(a) call may either copy `a` further,
> or just pass on a stack pointer to the existing `a`, depending on compiler
> details. Any stack-allocated object gets automatically wiped as the stack
> unwinds, hence does not need GC'ing.
> 
> Then on the `l` line, because it's an Any array, the ImagePos needs to be
> copied, boxed and heap-allocated. So that one needs GC.
> 
> What did I miss?
> 
> Cédric

Re: [julia-users] Using `Rational` with `Poly`

[Stefan Karpinski]

There are various assumptions baked into the rational code that may or may
not be satisfied by non-integer numeric types. I would suggest taking the
code from Base and trying it out without that restriction and seeing how it
goes.

On Saturday, February 6, 2016, Fengyang Wang 
wrote:

> I was looking for a Julia package to handle rational functions, when I
> noticed that the `Polynomials` package implements `gcd`, `div`, and `rem`.
> So it would be possible to simply use `Rational{Poly}`... or so I thought.
> Unfortunately, the type `Rational` prevents this use, since it requires its
> type parameter to derive from `Integer`.
>
> I think it would be more in line with Julia's goal of polymorphism if
> `Rational` "just worked" with any Euclidean domain. Is there some
> justification for the current behaviour, or should I file this as a issue
> (or make a pull request)?
>

[julia-users] Understanding immutables

[Cedric St-Jean]

There's an issue  on Github 
to add GC support for stack-allocated objects, and that makes no sense to 
me! Could someone please help me out? In my mind, stack-allocated objects = 
Int+Float+...+Immutable (in some circumstances). I thought that with 
Immutables, if I have

immutable ImagePos
   img::Image
   x::Int
   y::Int
end

function blah(img)
   a = ImagePos(img, 10, 20)
   foo(a)
   l = Any[40, a]
end

then `a` is stack-allocated. The foo(a) call may either copy `a` further, 
or just pass on a stack pointer to the existing `a`, depending on compiler 
details. Any stack-allocated object gets automatically wiped as the stack 
unwinds, hence does not need GC'ing.

Then on the `l` line, because it's an Any array, the ImagePos needs to be 
copied, boxed and heap-allocated. So that one needs GC.

What did I miss?

Cédric

Re: [julia-users] Understanding immutables

[Tim Holy]

I'm not certain this is correct, but here's my understanding: `a = 
ImagePos(img, 10, 20)` absolutely must protect `img` from being GCed in code 
like this:

function foo()
img = rand(5,5)
return ImagePos(img, 10, 20)
end

But currently objects on the heap do not seem to protect stack-allocated 
objects from being GCed. So, the current choice is stack-allocate all(?) 
immutables that are non-bitstypes, just to make sure we adequately protect 
objects from being GCed. IICU, the new PR adds the ability to support 
protection from heap-allocated objects, which means that it will no longer be 
necessary to stack-allocate non-bitstypes immutables.

Best,
--Tim

On Sunday, February 07, 2016 06:39:51 AM Cedric St-Jean wrote:
> There's an issue  on Github
> to add GC support for stack-allocated objects, and that makes no sense to
> me! Could someone please help me out? In my mind, stack-allocated objects =
> Int+Float+...+Immutable (in some circumstances). I thought that with
> Immutables, if I have
> 
> immutable ImagePos
>img::Image
>x::Int
>y::Int
> end
> 
> function blah(img)
>a = ImagePos(img, 10, 20)
>foo(a)
>l = Any[40, a]
> end
> 
> then `a` is stack-allocated. The foo(a) call may either copy `a` further,
> or just pass on a stack pointer to the existing `a`, depending on compiler
> details. Any stack-allocated object gets automatically wiped as the stack
> unwinds, hence does not need GC'ing.
> 
> Then on the `l` line, because it's an Any array, the ImagePos needs to be
> copied, boxed and heap-allocated. So that one needs GC.
> 
> What did I miss?
> 
> Cédric

Re: [julia-users] Understanding immutables

[Yichao Yu]

On Sun, Feb 7, 2016 at 9:39 AM, Cedric St-Jean  wrote:
> There's an issue on Github to add GC support for stack-allocated objects,
> and that makes no sense to me! Could someone please help me out? In my mind,
> stack-allocated objects = Int+Float+...+Immutable (in some circumstances). I
> thought that with Immutables, if I have

by `Int + Float + ...` I think you mean bitstype.

>
> immutable ImagePos
>img::Image
>x::Int
>y::Int
> end
>
> function blah(img)
>a = ImagePos(img, 10, 20)
>foo(a)
>l = Any[40, a]
> end
>
> then `a` is stack-allocated. The foo(a) call may either copy `a` further, or
> just pass on a stack pointer to the existing `a`, depending on compiler

Right

> details. Any stack-allocated object gets automatically wiped as the stack
> unwinds, hence does not need GC'ing.

s/GC/root/ might be a better word.

>
> Then on the `l` line, because it's an Any array, the ImagePos needs to be
> copied, boxed and heap-allocated. So that one needs GC.

I'm not really sure what you mean by `needs GC` here. What will happen
is that the element of a `Any` array will be heap(GC) allocated
(boxed) and so is the Array l itself. Therefore, `l` wiill be GC
rooted and elements in the `l` array are reachable by the GC from the
array `l`.

>
> What did I miss?
>
> Cédric

[julia-users] Re: Simultaneous audio playback / recording.

[CrocoDuck O'Ducks]

I am starting looking into your module and... ehm... what is the proper way 
to install it?

On Wednesday, 3 February 2016 18:54:49 UTC, Sebastian Kraft wrote:
>
>
> Hi,
>
> in the last weeks I started a PortAudio.jl package (based on parts of the 
> AudioIO.jl package). It is still under development and far from perfect, 
> but should already work well for basic audio IO.
>
> https://github.com/seebk/PortAudio.jl
>
> Sebastian
>

Re: [julia-users] Understanding immutables

[Cedric St-Jean]

On Sun, Feb 7, 2016 at 9:54 AM, Yichao Yu  wrote:

> On Sun, Feb 7, 2016 at 9:39 AM, Cedric St-Jean 
> wrote:
> > There's an issue on Github to add GC support for stack-allocated objects,
> > and that makes no sense to me! Could someone please help me out? In my
> mind,
> > stack-allocated objects = Int+Float+...+Immutable (in some
> circumstances). I
> > thought that with Immutables, if I have
>
> by `Int + Float + ...` I think you mean bitstype.
>

Yes.


>
> > details. Any stack-allocated object gets automatically wiped as the stack
> > unwinds, hence does not need GC'ing.
>
> s/GC/root/ might be a better word.
>

Agreed.


>
> >
> > Then on the `l` line, because it's an Any array, the ImagePos needs to be
> > copied, boxed and heap-allocated. So that one needs GC.
>
> I'm not really sure what you mean by `needs GC` here. What will happen
> is that the element of a `Any` array will be heap(GC) allocated
> (boxed) and so is the Array l itself. Therefore, `l` wiill be GC
> rooted and elements in the `l` array are reachable by the GC from the
> array `l`.
>

Yes, that's what I meant.

Could you please explain what the Github issue is about?


> >
> > What did I miss?
> >
> > Cédric
>

Re: [julia-users] Color.jl - Colors.jl?

[Tim Holy]

It was getting spammed (it's happened twice now), so I "temporarily" turned 
them off but forgot to turn them back on again.

I just edited the README of Color.jl.

Best,
--Tim

On Sunday, February 07, 2016 12:26:47 AM Kevin Squire wrote:
> Hi Andreas,
> 
> Colors.jl is meant as a complete replacement for Color.jl.  The latter is
> not installable on Julia v0.4 and above.
> 
> See this julia-users post
>  for
> more information.
> 
> I'm not sure why Issues were disabled on Colors.jl, but I just reenabled
> them.
> 
> Cheers,
>Kevin
> 
> 
> On Sat, Feb 6, 2016 at 11:45 PM, Andreas Lobinger 
> 
> wrote:
> > Hello colleagues,
> > 
> > although i was somehow connected to the discussion about this transitions,
> > i'm a little bit lost right now.
> > Is Colors.jl replacing Color.jl completely? Or it's 'just' a fork for the
> > use of the new ColorTypes?
> > And why do i miss to see an issues tab on the githup page? Is the
> > development closed to JuliaGraphics users?
> > 
> > Wishing a happy day,
> > 
> >  Andreas

Re: [julia-users] associating outer constructors with different names with a type

[Toivo Henningsson]

I think rather the issue here is that SomeType instances should behave more or 
less the same no matter whether they were constructed through TypeA or TypeB, 
and it would be wasteful for the compiler to specialise code on these two cases 
separately?

To try to answer the question from this point of view though: Julia does not 
provide a way to override <: , you would have to create your own function for 
the purpose of being able to make this distinction. With the new function 
overhaul though, it will be possible to overload it sparsely separately for an 
argument TypeA and TypeB, though. 

[julia-users] Re: Understanding immutables

[Bart Janssens]

On Sunday, February 7, 2016 at 3:39:51 PM UTC+1, Cedric St-Jean wrote:

> then `a` is stack-allocated. The foo(a) call may either copy `a` further, 
> or just pass on a stack pointer to the existing `a`, depending on compiler 
> details. Any stack-allocated object gets automatically wiped as the stack 
> unwinds, hence does not need GC'ing.
>
>
I think that in this case "a" is heap-allocated, since ImagePos is not a 
bits type. You can check this with isbits(). Just today, I found the 
following post that explains this at length:
http://julialang.org/blog/2013/03/efficient-aggregates/

Cheers,

Bart

Re: [julia-users] Pre-compiling images for different CPUs on GCloud

[Erik Schnetter]

An even better command is:
```
julia -e 'println(Sys.cpu_name)'
```

-erik


On Sat, Feb 6, 2016 at 7:24 PM, Pavel  wrote:
> The "core-avx2" target worked (LLVL 3.4), and it was in the output of `llc
> --version`. I was able to precompile locally and deploy on GCloud haswell.
> The run time of my test suite was effectively the same with that and with
> the "native" option precompilation. Thank you Milan and Erik for your input.
>
> On Saturday, February 6, 2016 at 7:09:17 AM UTC-8, Erik Schnetter wrote:
>>
>> You can run `llc --version` to determine the host's CPU type. You
>> should probably use the same llc that comes with the LLVM that Julia
>> is using.
>>
>> The exact command is
>>
>> `llc --version | awk '/Host CPU:/ { print $3; }')`
>>
>> -erik
>>
>>
>> On Sat, Feb 6, 2016 at 9:50 AM, Milan Bouchet-Valat 
>> wrote:
>> > Le vendredi 05 février 2016 à 18:24 -0800, Pavel a écrit :
>> >> I tried this approach using a local machine with
>> >> product: Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
>> >> which in my understanding belongs to the "haswell" type.
>> >>
>> >> setting
>> >> build_sysimg(joinpath(dirname(Libdl.dlpath("libjulia")),"sys"),
>> >> "haswell", "/home/juser/jimg.jl", force=true)
>> >>
>> >> resulted in
>> >> 'haswell' is not a recognized processor for this target (ignoring
>> >> processor)
>> > Have you looked at the output of llc -mattr=help (or usr/bin/llc
>> > -mattr=help from the Julia install/build directory)? If this is with
>> > LLVM 3.3, then it doesn't look like it supported "haswell" as a target.
>> > You should be able to specify "core-avx2" instead.
>> >
>> >> On the other hand, setting "native" instead, after deploying on
>> >> GCloud haswell-zone says that the image was precompiled for a
>> >> different architecture.
>> > By definition, "native" isn't intended to be portable, so it doesn't
>> > sound unexpected.
>> >
>> >
>> > Regards
>> >
>> >
>> >> On Friday, February 5, 2016 at 1:01:37 AM UTC-8, Milan Bouchet-Valat
>> >> wrote:
>> >> > Le jeudi 04 février 2016 à 17:17 -0800, Pavel a écrit :
>> >> > > I am deploying a CPU-intensive application on Google Cloud
>> >> > Compute
>> >> > > with Julia code running inside a Docker container. GCloud
>> >> > instances
>> >> > > have a few different CPU architectures depending on the zone.
>> >> > > Ideally, I would like to pre-compile Julia images (i.e.
>> >> > different
>> >> > > docker container images) for all of those architectures.
>> >> > >
>> >> > > Currently the following runs on container launch:
>> >> > >
>> >> > > include(joinpath(JULIA_HOME, Base.DATAROOTDIR, "julia",
>> >> > > "build_sysimg.jl"))
>> >> > >
>> >> > build_sysimg(joinpath(dirname(Libdl.dlpath("libjulia")),"sys"),
>> >> > > "native", "/home/juser/jimg.jl", force=true)
>> >> > >
>> >> > > so that the "native" setting pre-compiles for the CPU that these
>> >> > > commands are running on. That takes time and having that done at
>> >> > the
>> >> > > container image build time would save cloud runtime.
>> >> > >
>> >> > > Would it be possible to pre-compile for different CPUs on my
>> >> > > development machine or do I need to run the pre-compilation on
>> >> > those
>> >> > > exact CPUs? If the former is possible, what build_sysimg
>> >> > arguments
>> >> > > would help? GCloud virtual machine architectures of interest
>> >> > include
>> >> > > Sandy Bridge, Ivy Bridge, and Haswell CPU types.
>> >> > You should be able to build images for older architectures on a
>> >> > machine
>> >> > with a newer one, i.e. build images for Sandy Bridge and Ivy Bridge
>> >> > on
>> >> > a Haswell machine. I don't think it would work in the other
>> >> > direction,
>> >> > since some instructions wouldn't be supported and the code
>> >> > wouldn't
>> >> > run.
>> >> >
>> >> > So in your case you could replace "native" with "sandybridge",
>> >> > "ivybridge", "haswell", or any value from the list printed by
>> >> > llc -mattr=help.
>> >> >
>> >> >
>> >> > Regards
>>
>>
>>
>> --
>> Erik Schnetter 
>> http://www.perimeterinstitute.ca/personal/eschnetter/



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

Re: [julia-users] Re: Periodic or cyclic arrays possible?

[Matt Bauman]

I highly recommend reading the Interfaces chapter[1] for a walk-through on 
creating your own array type.  Another great trick that you can use is 
`A[mod1(x, end)]`.

1. http://docs.julialang.org/en/release-0.4/manual/interfaces/

On Sunday, February 7, 2016 at 10:52:45 AM UTC-5, Erik Schnetter wrote:
>
> The expression `(i-1) % length + 1` is not correct for negative `i`. 
> You have to use `mod` instead of `%`. 
>
> Julia has a function `mod1(x,y)` that is essentially defined as 
> `mod(x-1, y) +1`, so that's what you probably want to use. 
>
> -erik 
>
> On Sat, Feb 6, 2016 at 8:40 PM, Cedric St-Jean  > wrote: 
> > You can define our own datatype to do this. It's one of the most 
> fundamental 
> > tasks in Julia! 
> > 
> > immutable CircularArray{T} 
> > arr::Vector{T} 
> > end 
> > 
> > Base.getindex(ca::CircularArray, i) = ca.arr[(i-1) % length(ca.arr) + 1] 
> > Base.setindex(...) = ... 
> > ... 
> > 
> > a = CircularArray([1,2,3]) 
> > a[14] # yields 2 
> > 
> > Cédric 
> > 
> > 
> > On Saturday, February 6, 2016 at 7:08:03 PM UTC-5, Ferran Mazzanti 
> wrote: 
> >> 
> >> Hi folks, 
> >> 
> >> I was wondering if it is possible to use in a simple way cyclic arrays 
> in 
> >> Julia? What I'm after is sometbing that understands that the next 
> element in 
> >> a[] after end is a[1], so a[end+1]=a[1], a[end+2]=a[2] etc... I know I 
> can 
> >> index the array with the remainder operator % to achieve this same 
> result, 
> >> but I wonder if one can declare the array directly in one way or 
> another to 
> >> achieve this directly. 
> >> 
> >> Thanks in advance, 
> >> 
> >> Ferran. 
>
>
>
> -- 
> Erik Schnetter  
> http://www.perimeterinstitute.ca/personal/eschnetter/ 
>

[julia-users] Re: Simultaneous audio playback / recording.

[CrocoDuck O'Ducks]

Thanks! The module is installed. I will make some experiment and report 
back!

On Sunday, 7 February 2016 16:31:57 UTC, Sebastian Kraft wrote:
>
> Am Sonntag, 7. Februar 2016 16:51:35 UTC+1 schrieb CrocoDuck O'Ducks:
>>
>> I am starting looking into your module and... ehm... what is the proper 
>> way to install it?
>>
>
> It's not a registered package, yet. Therefore, it requires the following 
> steps:
>
> Pkg.clone("https://github.com/seebk/PortAudio.jl.git;)
> Pkg.build("PortAudio")
>
>  
>

Re: [julia-users] Understanding immutables

[Yichao Yu]

On Sun, Feb 7, 2016 at 10:19 AM, Cedric St-Jean  wrote:
>
>
> On Sun, Feb 7, 2016 at 9:54 AM, Yichao Yu  wrote:
>>
>> On Sun, Feb 7, 2016 at 9:39 AM, Cedric St-Jean 
>> wrote:
>> > There's an issue on Github to add GC support for stack-allocated
>> > objects,
>> > and that makes no sense to me! Could someone please help me out? In my
>> > mind,
>> > stack-allocated objects = Int+Float+...+Immutable (in some
>> > circumstances). I
>> > thought that with Immutables, if I have
>>
>> by `Int + Float + ...` I think you mean bitstype.
>
>
> Yes.
>
>>
>>
>> > details. Any stack-allocated object gets automatically wiped as the
>> > stack
>> > unwinds, hence does not need GC'ing.
>>
>> s/GC/root/ might be a better word.
>
>
> Agreed.
>
>>
>>
>> >
>> > Then on the `l` line, because it's an Any array, the ImagePos needs to
>> > be
>> > copied, boxed and heap-allocated. So that one needs GC.
>>
>> I'm not really sure what you mean by `needs GC` here. What will happen
>> is that the element of a `Any` array will be heap(GC) allocated
>> (boxed) and so is the Array l itself. Therefore, `l` wiill be GC
>> rooted and elements in the `l` array are reachable by the GC from the
>> array `l`.
>
>
> Yes, that's what I meant.
>
> Could you please explain what the Github issue is about?

Ahh, I didn't realize that `Image` is `!isbits`

The issue is that the current format of our GC frame can only handle
array of pointers so in order to root an object (and therefore objects
that are referenced by it), it has to be boxed.

>
>>
>> >
>> > What did I miss?
>> >
>> > Cédric
>
>

[julia-users] Re: Simultaneous audio playback / recording.

[Sebastian Kraft]

Am Sonntag, 7. Februar 2016 16:51:35 UTC+1 schrieb CrocoDuck O'Ducks:
>
> I am starting looking into your module and... ehm... what is the proper 
> way to install it?
>

It's not a registered package, yet. Therefore, it requires the following 
steps:

Pkg.clone("https://github.com/seebk/PortAudio.jl.git;)
Pkg.build("PortAudio")

 

[julia-users] Re: I think I'm obtaining the nightly ubuntu PPA incorrectly...

[Jeff Waller]

this is a downside of having a project that spans 3 travis languages; (c++, 
node, julia)  -- currently the language is set to c++.  
Ironically, the c++ provided by language c++ is the wrong one on Linux (gcc 
4.6 is too old).  I think I copied that script back in
the day, but have since modified it to allow additional permutations. 
 Isn't though there an issue to seeing what a project backed
by a language julia instance does -- julia is pre-installed?

[julia-users] Re: Dual licenses for Julia packages

[Jeffrey Sarnoff]

Well, maybe maybe not -- irrelevant, though. I was not advocating its use, 
just relating something.
As I said, this is a legal question.  I am going to ask an intellectual 
property lawyer.  

On Sunday, February 7, 2016 at 7:04:06 PM UTC-5, Steven G. Johnson wrote:
>
>
>
> On Sunday, February 7, 2016 at 6:17:14 PM UTC-5, Jeffrey Sarnoff wrote:
>>
>> The question is a legal question. This is* not* legal advice.
>>
>> I have not done this with any Julia code.  I did do something similar 
>> some years ago with other source code.
>> Understanding that permission may be contingent on an agreement to pay 
>> money, the gist of it was:
>>
>> LICENCE:
>> For strictly non-commercial use, including education and research, the 
>> MIT licence applies.
>>
>
> This is incoherent — the MIT license does not limit licensees to 
> non-commercial use.   Effecitively, you are trying to use MIT license + an 
> additional restriction (or minus some permissions), but written in a very 
> confusing way.  You are basically saying: "you can do anything with this 
> code [MIT license], except that you can't."
>
> The general advice from most sources is: don't write your own license; the 
> odds are high that you will mess up and say something whose effects are not 
> what you intend.
>

[julia-users] Re: Dual licenses for Julia packages

[Jeffrey Sarnoff]

The question is a legal question. This is* not* legal advice.

I have not done this with any Julia code.  I did do something similar some 
years ago with other source code.
Understanding that permission may be contingent on an agreement to pay 
money, the gist of it was:

LICENCE:
For strictly non-commercial use, including education and research, the MIT 
licence applies.
For all other uses, including without limitation, any effort intended to 
generate income, 
  written permission must be obtained from the author prior to use.



On Friday, February 5, 2016 at 5:54:32 PM UTC-5, Páll Haraldsson wrote:
>
> On Friday, February 5, 2016 at 3:10:54 PM UTC, Scott Jones wrote:
>>
>> I'm curious about how one could release packages for use with Julia such 
>> that they would be free for non-commercial use (under GPL maybe?) but also 
>> available with a paid license for commercial use.
>>
>
> I guess you know, it's just not completely clear: You can't release under 
> GPL and, say only non-commercial is only ok (neither can you with any 
> permissive/OSI certified license or DFSG-compliant that inspired OSI/it's 
> based on).
>
> Effectively, even if GPL allows commercial use, you might be putting off 
> many of your competitors, by using it, because of it "viral" (or 
> "spider-plant"-nature). Since/when you own the copyright you can release 
> under any other (proprietary) license forcing to pay, for using and getting 
> out of the viral nature.
>
> One thing the GPL (or any license? at least free/open source) doesn't 
> forbid (and it's not like it's easy to know anyway), is using privately 
> within you whole organization/company. Then you can link with whatever 
> other software (just not distribute/convey outside).
>
> One even stricter license, might help you, AGPL based on the GPLv3. Then 
> you force your competitor to release code, if the code to any user of a 
> server you have ("software as a service").
>
>
> https://people.debian.org/~bap/dfsg-faq.html
>
> https://www.debian.org/social_contract
>
> https://opensource.org/licenses
>
> Has anybody else done this?
>>
>> As much as possible, I'd like to release things under the MIT license, 
>> however, there are many things that might be useful to other Julians, that 
>> they (the company I'm consulting for) don't want to give away for free to a 
>> commercial competitor (we need to eat also!).
>>
>>
>>

Re: [julia-users] Memory allocation free array slices ?

[Nitin Arora]

Thanks and Tim and Stefan, if there is anyway I can contribute to help, do 
let me know.

thanks,
Nitin

On Sunday, February 7, 2016 at 8:24:38 AM UTC-8, Stefan Karpinski wrote:
>
> Being able to stack-allocate objects that refer to the heap is an 
> important case that we need to address, but doing so is non-trivial and 
> hasn't been done yet.
>
> On Sunday, February 7, 2016, Tim Holy  
> wrote:
>
>> I filed an issue, https://github.com/JuliaLang/julia/issues/14955, which 
>> you
>> can check to learn about progress on this problem.
>>
>> Best,
>> --Tim
>>
>> On Saturday, February 06, 2016 03:35:34 PM Nitin Arora wrote:
>> > I see, thanks for the information. I think, if possible, this feature 
>> will
>> > help the language a lot.
>> >
>> > I have recommended Julia to many of my colleagues (they all love it over
>> > Fortran and Matlab) and most of them seem to run into this issue. I 
>> think,
>> > a modern language with soo much elegance and potential, like Julia, 
>> should
>> > nail such major issues. I am sure by V-1.0 we will have the best 
>> scientific
>> > programming language ever :-)
>> >
>> > thanks,
>> > Nitin
>> >
>> > On Saturday, February 6, 2016 at 3:55:56 AM UTC-8, Tim Holy wrote:
>> > > On Friday, February 05, 2016 05:24:04 PM Nitin Arora wrote:
>> > > > Thanks Tim, this is very useful. I will probably use CartesianRange 
>> now.
>> > > >
>> > > > Is Julia 0.5 Arraypocalypse planning to address this issue as well ?
>> > >
>> > > I don't think there's a way to solve this by changing our 
>> implementation
>> > > of
>> > > views; I think it's more of a compiler issue, and the fact that
>> > >
>> > > julia> isbits(CartesianRange((3,5)))
>> > > true
>> > >
>> > > julia> immutable ArrayWrapper{M}
>> > >
>> > >data::M
>> > >
>> > >end
>> > >
>> > > julia> z = rand(5,5);
>> > >
>> > > julia> isbits(ArrayWrapper(z))
>> > > false
>> > >
>> > >
>> > > Since I don't work on the compiler, I can't speak for what's going to
>> > > happen
>> > > there, but I'd be surprised if this changes in 0.5.
>> > >
>> > > Best,
>> > > --Tim
>> > >
>> > > > thanks,
>> > > > Nitin
>> > > >
>> > > > On Friday, February 5, 2016 at 3:24:34 PM UTC-8, Tim Holy wrote:
>> > > > > On Friday, February 05, 2016 08:17:21 AM Kevin Squire wrote:
>> > > > > > I think this needs to be @time bar(A).
>> > > > >
>> > > > > Yeah, sorry for the typo.
>> > > > >
>> > > > > > I get
>> > > > > >
>> > > > > > julia> @time bar(A)
>> > > > > >
>> > > > > >   0.000269 seconds (5 allocations: 176 bytes)
>> > > > > >
>> > > > > > 20010.937886591404
>> > > > >
>> > > > > That's just REPL allocation. Since A has 1 columns, if this
>> > >
>> > > strategy
>> > >
>> > > > > were
>> > > > > allocating you'd expect "1+n allocations," where n comes from 
>> the
>> > > > > REPL.
>> > > > >
>> > > > > --Tim
>>
>>

[julia-users] Re: Dual licenses for Julia packages

[Steven G. Johnson]

On Sunday, February 7, 2016 at 6:17:14 PM UTC-5, Jeffrey Sarnoff wrote:
>
> The question is a legal question. This is* not* legal advice.
>
> I have not done this with any Julia code.  I did do something similar some 
> years ago with other source code.
> Understanding that permission may be contingent on an agreement to pay 
> money, the gist of it was:
>
> LICENCE:
> For strictly non-commercial use, including education and research, the MIT 
> licence applies.
>

This is incoherent — the MIT license does not limit licensees to 
non-commercial use.   Effecitively, you are trying to use MIT license + an 
additional restriction (or minus some permissions), but written in a very 
confusing way.  You are basically saying: "you can do anything with this 
code [MIT license], except that you can't."

The general advice from most sources is: don't write your own license; the 
odds are high that you will mess up and say something whose effects are not 
what you intend.

[julia-users] Re: Dual licenses for Julia packages

[Jeffrey Sarnoff]

So there is no misunderstanding -- I deleted the prior post.
I will relate whatever the lawyer I ask has to say about this.

On Sunday, February 7, 2016 at 7:11:36 PM UTC-5, Jeffrey Sarnoff wrote:
>
> Well, maybe maybe not -- irrelevant, though. I was not advocating its use, 
> just relating something.
> As I said, this is a legal question.  I am going to ask an intellectual 
> property lawyer.  
>
> On Sunday, February 7, 2016 at 7:04:06 PM UTC-5, Steven G. Johnson wrote:
>>
>>
>>
>> On Sunday, February 7, 2016 at 6:17:14 PM UTC-5, Jeffrey Sarnoff wrote:
>>>
>>> The question is a legal question. This is* not* legal advice.
>>>
>>> I have not done this with any Julia code.  I did do something similar 
>>> some years ago with other source code.
>>> Understanding that permission may be contingent on an agreement to pay 
>>> money, the gist of it was:
>>>
>>> LICENCE:
>>> For strictly non-commercial use, including education and research, the 
>>> MIT licence applies.
>>>
>>
>> This is incoherent — the MIT license does not limit licensees to 
>> non-commercial use.   Effecitively, you are trying to use MIT license + an 
>> additional restriction (or minus some permissions), but written in a very 
>> confusing way.  You are basically saying: "you can do anything with this 
>> code [MIT license], except that you can't."
>>
>> The general advice from most sources is: don't write your own license; 
>> the odds are high that you will mess up and say something whose effects are 
>> not what you intend.
>>
>

[julia-users] Re: I think I'm obtaining the nightly ubuntu PPA incorrectly...

[Tony Kelman]

No, julia isn't actually pre-installed in the VM image on travis. If you expand 
out the first few build steps from some package's log, you can see how it 
downloads and extracts a binary at the start of the build.