[julia-users] planned array changes

[harven]

I see that there are many changes scheduled for arrays in the next release. 
Can someone summarize what is planned?

I understand that [,] will become non concatenating. What will be the type 
of expressions such as

  ["julia", [1, 1.0]]

Any,  union{AbstractString, Array{Float64}}?

Will the following code return an error or an array of some type?

  push!(["one", [1, 5.1]], 1.5)

Is there some syntactic sugar planned for Any arrays, in the spirit of {}?

Re: [julia-users] Re: IDE for Julia

[Daniel Carrera]

There are no Qt bindings for Julia yet. I also don't know what text editing
component is provided by Qt or what its features are. I began working with
Gtk in part because the Julia Gtk bindings seem to be the most developed.

Is there a reason you like Qt besides it being cross-platform?


On 17 September 2015 at 23:50, SrAceves  wrote:

> What about Qt? RStudio is fantastic: Qt based, multi-platoform. Everything
> anyone ever wanted of an IDE.
>
> El martes, 15 de septiembre de 2015, 8:13:04 (UTC-5), Daniel Carrera
> escribió:
>>
>>
>> Last night I started experimenting with Gtk, and started making a sketch
>> of what a Julia IDE might look like. In the process I am writing down a
>> list of things that are probably needed before a Julia IDE
>>
>>
>>  getting a list of things that probably need to exist before a Julia IDE
>> can be completed. This is what I have so far:
>> 1) A Julia package for the GNOME Docking Library
>>
>> I think most people expect that an IDE has docking
>>
>> Despite the name, it does not depend on any GNOME libraries, only Gtk.
>> This is what Anjuta and MonoDevelop use to get docking windows. I think
>> most people expect to be able to move things around in an IDE.
>>
>> https://developer.gnome.org/gdl/
>>
>>
>> 2)
>>
>>
>>
>> On 14 September 2015 at 17:10,  wrote:
>>
>>> Gtk, the code isn't published but it's very similar to Julietta:
>>>
>>> https://github.com/tknopp/Julietta.jl
>>>
>>
>>

Re: [julia-users] Help with a parameterized function declaration

[Spencer Russell]

Thanks for your help, Tom.

In the end it looks like this is a dup of 
https://groups.google.com/forum/#!msg/julia-users/Khe1Eh-K6i0/kxvj3day77AJ 
, 
and in my particular case the cleanest solution was to implement similar() on 
my subtypes (as recommended by Tim Holy in that thread). Then I could define 
the single-index indexing on the supertype and the abstractarray and 
multidimensional code would construct the appropriate subtype for me. This is 
described in the Interfaces section of the manual, but I didn’t get at first 
that similar() was the key and was called by the code in Base to construct your 
type during indexing.

I’ll see if I can expand the docs there to make my oversight less over-seeable.

-s

> On Sep 17, 2015, at 5:30 PM, Tom Breloff  wrote:
> 
> Try:
> 
> 
> # this one for any AbstractFoo that is NOT Foo1
> julia> Base.getindex(foo::AbstractFoo, I...) = Foo2(foo.data[I...])
> getindex (generic function with 185 methods)
>  
> julia> Base.getindex(foo::Foo1, I...) = Foo1(foo.data[I...])
> getindex (generic function with 184 methods)
>  
> julia> f1 = Foo1{2,Float64}(rand(2,2))
> Error showing value of type Foo1{2,Float64}:
> ERROR: MethodError: `size` has no method matching 
> size(::Foo1{2,Float64})SYSTEM: show(lasterr) caused an error
>  
> julia> f1.data  # notice we actually did create it... the error was just in 
> trying to show it
> 2x2 Array{Float64,2}:
>  0.696612  0.337268
>  0.987464  0.719724
>  
> julia> tmp = f1[1,:]
> Error showing value of type Foo1{2,Float64}:
> ERROR: MethodError: `size` has no method matching 
> size(::Foo1{2,Float64})SYSTEM: show(lasterr) caused an error
>  
> julia> tmp.data
> 1x2 Array{Float64,2}:
>  0.696612  0.337268
> 
> 
> 
> On Thu, Sep 17, 2015 at 4:14 PM, Spencer Russell  > wrote:
> On Thu, Sep 17, 2015, at 02:31 PM, Tom Breloff wrote:
>> f{T<:AbstractInnerType}(x::AbstractOuterType{T}) = 
>  
> I don't quite see how to map that onto my problem (forgive me if I'm just 
> being dense). I have 3 types:
> Foo1{N, T} <: AbstractFoo{N, T} <: AbstractArray{T, 2}
>  
> and I want to define a method (in this case getindex) that accepts any 
> subtype of AbstractFoo{N, T}. If the given instance is a Foo1{N, T} I want to 
> call the constructor Foo1(someval). If the instance was a Foo2{N, T} then I'd 
> want to call Foo2(someval). I think the tricky bit is accepting a Foo1{N, T} 
> and just extracting the Foo1 part of it. I think that my first attempt:
>  
> Base.getindex{BT{N, T} <: AbstractFoo{N, T}}(foo::BT, I...) = 
> BT(foo.data[I...])
>  
> Gets across what I'm trying to do, but is not legal.
>  
> Maybe a clearer way to state the underlying problem is:
>  
> given Foo1{N, T} <: AbstractFoo{N, T}
> Foo1{1, Int} is a subtype of both Foo1 and AbstractFoo{1, Int}
> super(Foo1{1, Int}) returns AbstractFoo{1, Int}, but I want something that 
> gives me Foo1.
>  
> Thanks for the help, sorry this seems pretty in-the-weeds.
>  
>> However I would be very careful attaching a parameter N to the number of 
>> columns of an array.  Unless you are sure you'll only have a small handful 
>> of unique values, you risk creating tons and tons of different types, all 
>> requiring specialized compilation of every function they touch.
>  
> Re: parameterizing on N - 
> I'm using this for multichannel audio signals, so the vast majority of the 
> time N will be 1 or 2, sometimes 4 or 8. Even if it's a different number, I 
> expect usage will be grouped such that there won't be a whole lot of 
> different channel counts in the same application. 
> That said, it's part of the design that I'm not 100% sure on, so once I get 
> further down the line I may go back on it.
>  
> -s
>  
>  
>>  
>>  
>>  
>> On Thu, Sep 17, 2015 at 2:10 PM, Spencer Russell > > wrote:
>> 
>> I think my question boils down to: "How do I define a method catches any 
>> subtype of a parametric supertype, but access the unparameterized part of 
>> the subtype within the function body?"
>>  
>> Say I have this type:
>>  
>> abstract AbstractFoo{N, T} <: AbstractArray{T, 2}
>>  
>> type Foo1{N, T} <: AbstractFoo{N, T}
>> data::Array{T, 2}
>> end
>>  
>> Foo1{T}(arr::AbstractArray{T, 2}) = Foo1{size(arr, 2), T}(arr)
>>  
>> So the Foo1 outer constructor sets the type parameter N based on the number 
>> of columns of the contained array.
>>  
>> When indexed by a Range, I want the returned value to be wrapped in a Foo1 
>> type, but it might be parameterized with a different value for N, but I 
>> can't figure out the right type definition. The plan is to catch types that 
>> are a subtype of Foo, but call the outer constructor to build the result 
>> value.
>>  
>> I've tried:
>>  
>> Base.getindex{BT{N, T} <: AbstractFoo{N, T}}(foo::BT, I...) = 
>> BT(foo.data[I...])
>>  
>> but apparently that has a malformed type parameter list.
>>  
>> I've also tried
>>  
>> 

Re: [julia-users] Re: IDE for Julia

[Scott Jones]

On Thursday, September 17, 2015 at 9:09:15 PM UTC-4, SrAceves wrote:
>
> What about Qt? RStudio is fantastic: Qt based, multi-platoform. Everything 
> anyone ever wanted of an IDE.
>

Does it support C, C++, Python (2 & 3), Java, JS, and Julia (as well as 
large Unicode text files)?
If not, it most definitely doesn't support everything anyone ever wanted of 
in an IDE.
 

[julia-users] CORS

[Eric Forgy]

Hi,

I am having some trouble getting CORS to work. I have a simple Julia server 
on an Azure VM. If I navigate to the URL, I can see the response I expect, 
but I am now trying to get this to work cross origin.

I tried the following, but it is not working:

using HttpServer
using JSON
import Requests

http = HttpHandler() do req::Request, res::Response
res.headers["Access-Control-Allow-Origin"] = "*"
 
# Messy route handling here.
 
end
server = Server(http)
run(server, 8000)

Any suggestions? Thanks!

[julia-users] Re: Vector of Matrices - a good or bad idea?

[Patrick Kofod Mogensen]

Yes, I did indeed just notice I had made a mistake with the ;.

My state spaces typically have more than two values, so they're more likely 
hundreds-by-hundreds instead of 2-by-2.

What does the "right dimensions for locality" mean? Are you referring to 
the memory addresses (to make sure I'm not jumping all over the place) or 
what does "locality" mean in this context? Sorry if this is basic stuff.

On Thursday, September 17, 2015 at 11:25:45 PM UTC-4, Steven G. Johnson 
wrote:
>
>
>
> On Thursday, September 17, 2015 at 11:11:57 PM UTC-4, Patrick Kofod 
> Mogensen wrote:
>>
>> Second, I can create a vector, and store [F1; F2] as F, and simply do 
>> F[1] to access F given a = 1, and F[2] to access F given a = 2. I think it 
>> makes the code so much easier to read when looping over A = {1, 2, ..., J} 
>> - but I am not sure if it is a good idea or not performance wise. Since 
>> I've done this so many times, I really just wanted to put my ignorance out 
>> there, and ask if there is a particular reason why I shouldn't be doing 
>> this, and if there is some other great way to do it.
>>
>
> This is perfectly reasonable, and there is no reason it can't be fast.  (I 
> think you mean [F1, F2] rather than [F1; F2], as the latter concatenates 
> into a single matrix.)
>
> The only case I can think of where it would be better to use a single 
> concatenated matrix would be if your individual F1 and F2 matrices were 
> tiny (say 2x2), in which case it might be better to avoid the slight cost 
> of the nested indexing operations.  But you wouldn't want to use slicing 
> either in that case (which does indeed create a temporary array): you would 
> want to index directly into the big matrix via F[i, j+offset]  (taking care 
> to concatenate along the right dimensions for locality!) and inline 
> everything.  But it doesn't sound like that level of micro-optimization is 
> going to be worth it for you.
>

Re: [julia-users] Vector of Matrices - a good or bad idea?

[Patrick Kofod Mogensen]

Yes, they will always be used as the distinct matrices. I just wanted to 
make sure that there wasn't any subtle performance issues with this 
approach.

On Thursday, September 17, 2015 at 11:17:15 PM UTC-4, Tom Breloff wrote:
>
> If you'll only ever be working with them as distinct matrices, then a 
> vector of matrices sounds fine.  Are there computations that require the 
> full stacked matrix?
>
> On Thu, Sep 17, 2015 at 11:11 PM, Patrick Kofod Mogensen <
> patrick@gmail.com > wrote:
>
>> I know the title is extremely general, so let me explain myself.
>>
>> I am an economist, and I often work with discrete choice models. Some 
>> agent can take an action, a, indexed by j = 1 ... J. When solving the the 
>> model, there are often a lot of features which depend on the action - a 
>> transition matrix, a payoff, and so on. Let's go with the transition 
>> matrix. Say given a = 1 the state transition from the current period to the 
>> next is governed by F1, but given a = 2 it is governed by another F2.
>>
>> Now, I know of two ways to deal with this. 
>>
>> First, I can store the to transition matrices next to each other (or 
>> above each other) in a matrix with double the number of columns (rows) as 
>> would be needed for one of them. My main concern here is, that every time I 
>> have to use either, I am pretty sure that a temporary will necessarily be 
>> created (when indexing into F[1:n, :] and F[n+1:end,:] for example). Also, 
>> I have to fiddle with indexes (but I can live with that if necessary). I 
>> guess stacking on top of each other is probably smartest performance wise.
>>
>> Second, I can create a vector, and store [F1; F2] as F, and simply do 
>> F[1] to access F given a = 1, and F[2] to access F given a = 2. I think it 
>> makes the code so much easier to read when looping over A = {1, 2, ..., J} 
>> - but I am not sure if it is a good idea or not performance wise. Since 
>> I've done this so many times, I really just wanted to put my ignorance out 
>> there, and ask if there is a particular reason why I shouldn't be doing 
>> this, and if there is some other great way to do it.
>>
>> Best,
>> Patrick
>>
>
>

[julia-users] Re: Vector of Matrices - a good or bad idea?

[Steven G. Johnson]

On Thursday, September 17, 2015 at 11:11:57 PM UTC-4, Patrick Kofod 
Mogensen wrote:
>
> Second, I can create a vector, and store [F1; F2] as F, and simply do F[1] 
> to access F given a = 1, and F[2] to access F given a = 2. I think it makes 
> the code so much easier to read when looping over A = {1, 2, ..., J} - but 
> I am not sure if it is a good idea or not performance wise. Since I've done 
> this so many times, I really just wanted to put my ignorance out there, and 
> ask if there is a particular reason why I shouldn't be doing this, and if 
> there is some other great way to do it.
>

This is perfectly reasonable, and there is no reason it can't be fast.  (I 
think you mean [F1, F2] rather than [F1; F2], as the latter concatenates 
into a single matrix.)

The only case I can think of where it would be better to use a single 
concatenated matrix would be if your individual F1 and F2 matrices were 
tiny (say 2x2), in which case it might be better to avoid the slight cost 
of the nested indexing operations.  But you wouldn't want to use slicing 
either in that case (which does indeed create a temporary array): you would 
want to index directly into the big matrix via F[i, j+offset]  (taking care 
to concatenate along the right dimensions for locality!) and inline 
everything.  But it doesn't sound like that level of micro-optimization is 
going to be worth it for you.

Re: [julia-users] Vector of Matrices - a good or bad idea?

[Tom Breloff]

If you'll only ever be working with them as distinct matrices, then a
vector of matrices sounds fine.  Are there computations that require the
full stacked matrix?

On Thu, Sep 17, 2015 at 11:11 PM, Patrick Kofod Mogensen <
patrick.mogen...@gmail.com> wrote:

> I know the title is extremely general, so let me explain myself.
>
> I am an economist, and I often work with discrete choice models. Some
> agent can take an action, a, indexed by j = 1 ... J. When solving the the
> model, there are often a lot of features which depend on the action - a
> transition matrix, a payoff, and so on. Let's go with the transition
> matrix. Say given a = 1 the state transition from the current period to the
> next is governed by F1, but given a = 2 it is governed by another F2.
>
> Now, I know of two ways to deal with this.
>
> First, I can store the to transition matrices next to each other (or above
> each other) in a matrix with double the number of columns (rows) as would
> be needed for one of them. My main concern here is, that every time I have
> to use either, I am pretty sure that a temporary will necessarily be
> created (when indexing into F[1:n, :] and F[n+1:end,:] for example). Also,
> I have to fiddle with indexes (but I can live with that if necessary). I
> guess stacking on top of each other is probably smartest performance wise.
>
> Second, I can create a vector, and store [F1; F2] as F, and simply do F[1]
> to access F given a = 1, and F[2] to access F given a = 2. I think it makes
> the code so much easier to read when looping over A = {1, 2, ..., J} - but
> I am not sure if it is a good idea or not performance wise. Since I've done
> this so many times, I really just wanted to put my ignorance out there, and
> ask if there is a particular reason why I shouldn't be doing this, and if
> there is some other great way to do it.
>
> Best,
> Patrick
>

[julia-users] Vector of Matrices - a good or bad idea?

[Patrick Kofod Mogensen]

I know the title is extremely general, so let me explain myself.

I am an economist, and I often work with discrete choice models. Some agent 
can take an action, a, indexed by j = 1 ... J. When solving the the model, 
there are often a lot of features which depend on the action - a transition 
matrix, a payoff, and so on. Let's go with the transition matrix. Say given 
a = 1 the state transition from the current period to the next is governed 
by F1, but given a = 2 it is governed by another F2.

Now, I know of two ways to deal with this. 

First, I can store the to transition matrices next to each other (or above 
each other) in a matrix with double the number of columns (rows) as would 
be needed for one of them. My main concern here is, that every time I have 
to use either, I am pretty sure that a temporary will necessarily be 
created (when indexing into F[1:n, :] and F[n+1:end,:] for example). Also, 
I have to fiddle with indexes (but I can live with that if necessary). I 
guess stacking on top of each other is probably smartest performance wise.

Second, I can create a vector, and store [F1; F2] as F, and simply do F[1] 
to access F given a = 1, and F[2] to access F given a = 2. I think it makes 
the code so much easier to read when looping over A = {1, 2, ..., J} - but 
I am not sure if it is a good idea or not performance wise. Since I've done 
this so many times, I really just wanted to put my ignorance out there, and 
ask if there is a particular reason why I shouldn't be doing this, and if 
there is some other great way to do it.

Best,
Patrick

Re: [julia-users] speed comparison with Mathematica

[Duane Wilson]

On Thursday, September 17, 2015 at 5:25:40 PM UTC-3, Kristoffer Carlsson 
wrote:
>
> It is fast in IJulia too if you split the function definition and the 
> timing into two different cells.


Just to make sure what Kristoffer is saying is clear (because it has an 
implicit reason way). If you run the function definition and the then 
function call in the same cell, the function is overwritten and needs to be 
recompiled by the JIT when you do the timing each time you run the cell. If 
the timing is in a separate cell the function doesn't need to be recompiled 
each time you run the cell.

Re: [julia-users] speed comparison with Mathematica

[Steven G. Johnson]

On Thursday, September 17, 2015 at 4:25:40 PM UTC-4, Kristoffer Carlsson 
wrote:
>
> It is fast in IJulia too if you split the function definition and the 
> timing into two different cells.


If you put the function definition in the same cell as the @time, then you 
are re-defining the function each time you benchmark it, so it needs to be 
recompiled every time. 

Re: [julia-users] another performance datapoint for Julia

[Steven G. Johnson]

On Thursday, September 17, 2015 at 10:14:53 PM UTC-4, Steven G. Johnson 
wrote:
>
>
>
> On Thursday, September 17, 2015 at 10:08:02 PM UTC-4, Steven G. Johnson 
> wrote:
>>
>> This looks likely to be rather slow to me, although I haven't benchmarked 
>> it, and is quite a bit uglier, probably because you can't easily declare a 
>> UInt32 in Python and do the natural bitwise operations on it.
>>
>
> Or maybe that's just the author's style; the C++ code by the same author 
> is similar: http://people.sc.fsu.edu/~jburkardt/cpp_src/sobol/sobol.cpp 
>

(To be fair, it was converted from code originally written in Fortran 77, 
which is not the ideal language for this sort of bit twiddling either.) 

Re: [julia-users] Re: Counterintuitive slices of 2d array

[Tim Holy]

Instead of A[:,2,3,4:7] you can call slice(A,:,2,3,4:7) and it will drop 
scalar dimensions. That's available now, and in 0.4 it's fast.

The difference between what we have now and what we will have in the future is 
that A[...] will likely become an alias for slice(A,...).

So, no need to lead a frustrated life.

--Tim

On Wednesday, April 16, 2014 12:54:59 PM Bob Nnamtrop wrote:
> I completely agree with you and would love to see julia drop singleton
> dimensions indexed with scalar. There is an issue on this with lots of
> discussion, which was left at the point of waiting til someone implements
> some code to give it a try (see
> https://github.com/JuliaLang/julia/issues/5949). Maybe after 0.3 is
> released there will be some action on this (I am willing to try myself but
> it does seem like a hard 1st problem to deal with the julia internals).
> IMO, there is some underlying tension in julia that revolves around people
> who primarily use arrays as containers (who generally want this changed)
> and those who use one and two dimensional arrays as a linear algebra system
> (some of who do not want it implemented). I am firmly in the camp of using
> arrays primarily as containers and, in addition to this issue, find it very
> annoying that the elementwise operators are all are 2nd class citizens
> (i.e., you must use .*, ./, .+, .-, etc). The fact that the 1st class
> versions only work on a subset of arrays (i.e., those 1 and 2 dimensional)
> seems like a poor design choice to me. But this is different to the
> dripping dimensions indexed by scalars issue where there is still hope for
> a change.
> 
> As a practical version of your function example in your second email is the
> plot command. You are plotting some slices from some higher dimensional
> arrays, e.g.
> 
> plot(x[2,3,7,:,9], y[2,3,7,:,9])
> 
> and you just want to get two one dimensional slices passed into plot with
> no fuss.
> 
> Bob
> 
> On Wed, Apr 16, 2014 at 12:13 PM, Paweł Biernat 
wrote:
> > Adding a real life use case:
> > 
> > x=[j+10*i for i=1:2, j=1:2]
> > 
> > function f(x::Array{Int,1})
> > 
> > x
> > 
> > end
> > 
> > and then
> > 
> > julia> f(x[1:2,1])
> > 
> > 2-element Array{Int64,1}:
> >  11
> >  21
> > 
> > julia> f(x[1,1:2])
> > ERROR: no method f(Array{Int64,2})

Re: [julia-users] another performance datapoint for Julia

[Steven G. Johnson]

On Thursday, September 17, 2015 at 10:08:02 PM UTC-4, Steven G. Johnson 
wrote:
>
> This looks likely to be rather slow to me, although I haven't benchmarked 
> it, and is quite a bit uglier, probably because you can't easily declare a 
> UInt32 in Python and do the natural bitwise operations on it.
>

Or maybe that's just the author's style; the C++ code by the same author is 
similar: http://people.sc.fsu.edu/~jburkardt/cpp_src/sobol/sobol.cpp 

Re: [julia-users] another performance datapoint for Julia

[Steven G. Johnson]

On Thursday, September 17, 2015 at 9:46:05 PM UTC-4, Stefan Karpinski wrote:
>
> That's quite nice. The Julia version 
>  is pretty 
> short? Is the C version much longer?
>

The C version is about the same length (maybe 20-40 lines longer): 
https://github.com/stevengj/nlopt/blob/master/util/sobolseq.c

It is interesting to compare to the Python version; most people seem to use 
an implementation based on Burkardt's code, e.g.
  
https://github.com/naught101/sobol_seq/blob/master/sobol_seq/sobol_seq.py
This looks likely to be rather slow to me, although I haven't benchmarked 
it, and is quite a bit uglier, probably because you can't easily declare a 
UInt32 in Python and do the natural bitwise operations on it.

(Mathworks provides a built-in sobolset function, but the core computation 
seems to be in mex files.)

Generation of low-discrepancy sequences like Sobol sequences seems 
inherently hard to vectorize, so it is a challenge for traditional dynamic 
languages.

Re: [julia-users] Re: Counterintuitive slices of 2d array

[Alex Dowling]

I'd like to kick-up this thread again, and ask a related questions:

Let's say I have a 2d array, and take a slice of it. How do I then append 
the slice with an additional value? The slice is type Array{Float64,2}. 
Neither push! or append! work.

Thanks,
Alex

On Wednesday, April 16, 2014 at 5:25:36 PM UTC-5, Paweł Biernat wrote:
>
> Thanks for linking to the issue.  It seems that the array slicing is just 
> a tip of the iceberg, I had no idea about the discussion on the algebraic 
> interpretation of n x n arrays and respective operators.  I somewhat 
> understand the arguments behind the need of elementwise operators (although 
> they are still pretty arbitrary), but I find the current state of array 
> slicing really unintuitive.  I am new to Julia and I am constantly 
> impressed by its features but for my work a decent array slicing rules are 
> critical and lack of them is, to me, very annoying.
>
> W dniu środa, 16 kwietnia 2014 20:54:59 UTC+2 użytkownik Bob Nnamtrop 
> napisał:
>>
>> I completely agree with you and would love to see julia drop singleton 
>> dimensions indexed with scalar. There is an issue on this with lots of 
>> discussion, which was left at the point of waiting til someone implements 
>> some code to give it a try (see 
>> https://github.com/JuliaLang/julia/issues/5949). Maybe after 0.3 is 
>> released there will be some action on this (I am willing to try myself but 
>> it does seem like a hard 1st problem to deal with the julia internals).  
>> IMO, there is some underlying tension in julia that revolves around people 
>> who primarily use arrays as containers (who generally want this changed) 
>> and those who use one and two dimensional arrays as a linear algebra system 
>> (some of who do not want it implemented). I am firmly in the camp of using 
>> arrays primarily as containers and, in addition to this issue, find it very 
>> annoying that the elementwise operators are all are 2nd class citizens 
>> (i.e., you must use .*, ./, .+, .-, etc). The fact that the 1st class 
>> versions only work on a subset of arrays (i.e., those 1 and 2 dimensional) 
>> seems like a poor design choice to me. But this is different to the 
>> dripping dimensions indexed by scalars issue where there is still hope for 
>> a change.
>>
>> As a practical version of your function example in your second email is 
>> the plot command. You are plotting some slices from some higher dimensional 
>> arrays, e.g.
>>
>> plot(x[2,3,7,:,9], y[2,3,7,:,9])
>>
>> and you just want to get two one dimensional slices passed into plot with 
>> no fuss.
>>
>> Bob
>>
>>
>> On Wed, Apr 16, 2014 at 12:13 PM, Paweł Biernat  
>> wrote:
>>
>>> Adding a real life use case:
>>>
>>> x=[j+10*i for i=1:2, j=1:2]
>>>
>>> function f(x::Array{Int,1})
>>> x
>>> end
>>>
>>> and then
>>>
>>> julia> f(x[1:2,1])
>>>
>>> 2-element Array{Int64,1}:
>>>  11
>>>  21
>>>
>>>
>>> julia> f(x[1,1:2])
>>> ERROR: no method f(Array{Int64,2})
>>>
>>>
>>>
>>

Re: [julia-users] Help reading structured binary data files

[Stefan Karpinski]

You can pretty easily just read the pieces out of the file stream one at a
time. E.g. if the file starts with the four-byte magic sequence "FuZz" and
then has two big-endian two-byte words, and a bunch of bytes, you can do
this:

# create a "file" in memory:

julia> io = IOBuffer()
IOBuffer(data=UInt8[...], readable=true, writable=true, seekable=true,
append=false, size=0, maxsize=Inf, ptr=1, mark=-1)

julia> write(io, "FuZz")
4

julia> write(io, hton(UInt16(12)), hton(UInt16(34)))
4

julia> data = rand(UInt8, 12, 34)
12x34 Array{UInt8,2}:
 0x32  0x12  0xc5  0x8d  0x30  0x32  …  0x99  0x57  0x41  0x14  0xb1  0x28
 0x8f  0x0b  0x8a  0x81  0x1c  0x53 0xc5  0x9b  0x2b  0x88  0x87  0x6f
 0x1e  0xff  0xb1  0xac  0x74  0x08 0x1a  0x61  0x6a  0x54  0x8c  0x25
 0xca  0x70  0x87  0x9d  0x44  0xc7 0x48  0x62  0x10  0xf2  0x3e  0x40
 0xce  0x39  0x23  0xc9  0x54  0x15 0x8d  0xfd  0x32  0xfe  0xab  0x00
 0x0c  0xd1  0x86  0x66  0x06  0xa9  …  0x58  0x4f  0x45  0x4c  0x7e  0xe3
 0x1e  0x98  0xde  0x87  0x71  0x14 0x65  0x5b  0x0f  0xdb  0x5b  0xc5
 0x42  0xc1  0x75  0xc5  0x8d  0xd8 0x91  0x5d  0xce  0xa5  0x84  0x58
 0xf5  0xd7  0xdf  0x71  0x65  0x6e 0xd2  0xc8  0xec  0xcf  0x46  0xc7
 0x64  0x88  0x57  0x58  0x3f  0x5b 0x41  0xad  0x14  0xf8  0x03  0xf4
 0xa0  0xb5  0x42  0xed  0xed  0x80  …  0xb4  0xe3  0x5e  0xa7  0xde  0xa3
 0x6a  0x30  0x15  0xd9  0xe5  0xbd 0x17  0x3b  0xfd  0x6f  0x4e  0x98

julia> write(io, data)
408

julia> seek(io, 0)
IOBuffer(data=UInt8[...], readable=true, writable=true, seekable=true,
append=false, size=416, maxsize=Inf, ptr=1, mark=-1)

# now read data back from that file:

julia> readbytes(io, 4) == b"FuZz" || error("invalid magic bytes")
true

julia> m = ntoh(read(io, UInt16))
0x000c

julia> n = ntoh(read(io, UInt16))
0x0022

julia> data = Array(UInt8, m, n);

julia> read!(io, data)
12x34 Array{UInt8,2}:
 0x32  0x12  0xc5  0x8d  0x30  0x32  …  0x99  0x57  0x41  0x14  0xb1  0x28
 0x8f  0x0b  0x8a  0x81  0x1c  0x53 0xc5  0x9b  0x2b  0x88  0x87  0x6f
 0x1e  0xff  0xb1  0xac  0x74  0x08 0x1a  0x61  0x6a  0x54  0x8c  0x25
 0xca  0x70  0x87  0x9d  0x44  0xc7 0x48  0x62  0x10  0xf2  0x3e  0x40
 0xce  0x39  0x23  0xc9  0x54  0x15 0x8d  0xfd  0x32  0xfe  0xab  0x00
 0x0c  0xd1  0x86  0x66  0x06  0xa9  …  0x58  0x4f  0x45  0x4c  0x7e  0xe3
 0x1e  0x98  0xde  0x87  0x71  0x14 0x65  0x5b  0x0f  0xdb  0x5b  0xc5
 0x42  0xc1  0x75  0xc5  0x8d  0xd8 0x91  0x5d  0xce  0xa5  0x84  0x58
 0xf5  0xd7  0xdf  0x71  0x65  0x6e 0xd2  0xc8  0xec  0xcf  0x46  0xc7
 0x64  0x88  0x57  0x58  0x3f  0x5b 0x41  0xad  0x14  0xf8  0x03  0xf4
 0xa0  0xb5  0x42  0xed  0xed  0x80  …  0xb4  0xe3  0x5e  0xa7  0xde  0xa3
 0x6a  0x30  0x15  0xd9  0xe5  0xbd 0x17  0x3b  0xfd  0x6f  0x4e  0x98

On Thu, Sep 17, 2015 at 9:22 PM, Tom Breloff  wrote:

> I have an alternative to StrPack.jl here:
> https://github.com/tbreloff/CTechCommon.jl/blob/master/src/macros.jl.  If
> you have a type that mimics a c-struct, you can create like:
>
> @packedStruct immutable MyStruct
>   field1::UInt8
>   field2::Byte
> end
>
> and it creates some methods: read, reinterpret, etc which can convert raw
> bytes into the immutable type.
>
> I've only used it on very specific types of data, but it may work for you.
>
> On Thu, Sep 17, 2015 at 6:04 PM, David McInnis  wrote:
>
>> I'm in the process of switching from python to julia and have gotten
>> stuck for a couple of days trying to read a, for me, typical data file.
>>
>> In python I'd create a C-style format, open the file and read the data.
>> I don't see an equivalent method in Julia.
>>
>> Ex:
>> Using a data structure of something like:"<4sii28s4i"
>> I'd figure out the size of the structure, point to the beginning byte,
>> and then unpack it.
>>
>> In Julia it looks like *maybe* I could make a data type to do this, but I
>> can't figure out how.
>> There's also StrPack.jl,  but it too is a little beyond what I understand.
>>
>> I work with a lot of different instruments, each with its own file
>> format.  Usually I only need to read these files.  After processing I'll
>> save everything into an hdf5 file.
>>
>> Thanks,  David.
>>
>>
>

Re: [julia-users] another performance datapoint for Julia

[Stefan Karpinski]

That's quite nice. The Julia version
 is pretty
short? Is the C version much longer?

On Thu, Sep 17, 2015 at 9:06 PM, Steven G. Johnson 
wrote:

> The Sobol.jl package was originally a wrapper around a fairly optimized C
> implementation of the Sobol sequence (from NLopt), but Ken-B just ported my
> original C code to pure Julia.  The performance of the Julia implementation
> is essentially indistinguishable from the C speed.
>
> It's not too surprising since the algorithm is mainly bit twiddling, but
> it's always nice to see C performance on "real" problems compared to
> optimized C implementations.
>

Re: [julia-users] Help reading structured binary data files

[Tom Breloff]

I have an alternative to StrPack.jl here:
https://github.com/tbreloff/CTechCommon.jl/blob/master/src/macros.jl.  If
you have a type that mimics a c-struct, you can create like:

@packedStruct immutable MyStruct
  field1::UInt8
  field2::Byte
end

and it creates some methods: read, reinterpret, etc which can convert raw
bytes into the immutable type.

I've only used it on very specific types of data, but it may work for you.

On Thu, Sep 17, 2015 at 6:04 PM, David McInnis  wrote:

> I'm in the process of switching from python to julia and have gotten stuck
> for a couple of days trying to read a, for me, typical data file.
>
> In python I'd create a C-style format, open the file and read the data.
> I don't see an equivalent method in Julia.
>
> Ex:
> Using a data structure of something like:"<4sii28s4i"
> I'd figure out the size of the structure, point to the beginning byte, and
> then unpack it.
>
> In Julia it looks like *maybe* I could make a data type to do this, but I
> can't figure out how.
> There's also StrPack.jl,  but it too is a little beyond what I understand.
>
> I work with a lot of different instruments, each with its own file
> format.  Usually I only need to read these files.  After processing I'll
> save everything into an hdf5 file.
>
> Thanks,  David.
>
>

[julia-users] Help reading structured binary data files

[David McInnis]

I'm in the process of switching from python to julia and have gotten stuck 
for a couple of days trying to read a, for me, typical data file.

In python I'd create a C-style format, open the file and read the data.
I don't see an equivalent method in Julia.

Ex:
Using a data structure of something like:"<4sii28s4i"  
I'd figure out the size of the structure, point to the beginning byte, and 
then unpack it. 

In Julia it looks like *maybe* I could make a data type to do this, but I 
can't figure out how.
There's also StrPack.jl,  but it too is a little beyond what I understand.

I work with a lot of different instruments, each with its own file format. 
 Usually I only need to read these files.  After processing I'll save 
everything into an hdf5 file.  

Thanks,  David.

Re: [julia-users] Re: IDE for Julia

[SrAceves]

What about Qt? RStudio is fantastic: Qt based, multi-platoform. Everything 
anyone ever wanted of an IDE.

El martes, 15 de septiembre de 2015, 8:13:04 (UTC-5), Daniel Carrera 
escribió:
>
>
> Last night I started experimenting with Gtk, and started making a sketch 
> of what a Julia IDE might look like. In the process I am writing down a 
> list of things that are probably needed before a Julia IDE
>
>
>  getting a list of things that probably need to exist before a Julia IDE 
> can be completed. This is what I have so far:
> 1) A Julia package for the GNOME Docking Library
>
> I think most people expect that an IDE has docking 
>
> Despite the name, it does not depend on any GNOME libraries, only Gtk. 
> This is what Anjuta and MonoDevelop use to get docking windows. I think 
> most people expect to be able to move things around in an IDE.
>
> https://developer.gnome.org/gdl/
>
>
> 2)
>
>
>
> On 14 September 2015 at 17:10, > 
> wrote:
>
>> Gtk, the code isn't published but it's very similar to Julietta:
>>
>> https://github.com/tknopp/Julietta.jl
>>
>
>

[julia-users] another performance datapoint for Julia

[Steven G. Johnson]

The Sobol.jl package was originally a wrapper around a fairly optimized C 
implementation of the Sobol sequence (from NLopt), but Ken-B just ported my 
original C code to pure Julia.  The performance of the Julia implementation 
is essentially indistinguishable from the C speed.

It's not too surprising since the algorithm is mainly bit twiddling, but 
it's always nice to see C performance on "real" problems compared to 
optimized C implementations.

Re: [julia-users] IDE for Julia

[Sheehan Olver]

Mike:  the deoms seem a lot more advanced than my version of julia-client.  Is 
there a better way to stay up-to-date than just clicking update package inside 
Atom?




> On 18 Sep 2015, at 1:33 am, Mike Innes  wrote:
> 
> Hey folks,
> 
> If you're interested in Juno/Atom you might like to check out the demos 
>  I just published which give an idea of 
> some of the UI work we've done so far. Like any tool, Atom certainly isn't 
> going to be Everybody's Everything, but you might be pleasantly surprised how 
> far we can push it towards being a fully-featured IDE. (Although really, the 
> core utility of the IDE is not so much the flashy ui bits so much as the 
> improved workflow it enables – more on that here 
> ).
> 
> Alternative approaches are welcome and even encouraged, but I really think 
> that Atom provides the fastest route to a high-quality Julia IDE – and if you 
> want to speed that along even more, it's well worth poking around in the code 
> to see where you can make improvements. It's pretty easy to get into and 
> we're more than happy to help out where we can.
> 
> Quick meta-note about this thread: I think it's important to emphasise that 
> the julia-users list isn't designed to handle this kind of open-ended 
> discussion. It's not that discussion is bad per se, but this list has a lot 
> of subscribers who are mostly interested in sharply-focused technical issues 
> – usually announcements or giving and receiving help. Topics that involve, 
> say, debating the merits of various technologies are better suited to 
> platforms such as reddit with features like comment threads for tangents, 
> more focused notifications for other users, etc.
> 
> – Mike
> 
> On Thu, 17 Sep 2015 at 15:24 Daniel Carrera  > wrote:
> On 17 September 2015 at 15:57, Kristoffer Carlsson  > wrote:
> Look up GitSavy if you want git integration in Sublime.
> 
> I guess different people have different tolerances to latency. I try atom 
> over and over because it is open source and I want it to be the best but 
> everytime it feels like running through syrup.
> 
> 
> It might also depend on our use case. For instance, I never close Atom, so I 
> wouldn't notice if it is slow to start up. Maybe I also have smaller or 
> fiewer files than you do.
> 
> Cheers,
> Daniel.
> 
> 

Re: [julia-users] Run gcc in build.jl

[Mike Nolta]

The problem with

  `gcc -L. -shared -o libcrlibm.dylib $(find . -d 1 -name *.o)`

is that the stuff inside $(...) is interpreted as julia code.

I'm not sure what's the best way to do this -- maybe something like:

  pipeline(`find . -d 1 -name *.o`, `xargs gcc -L. -shared -o libcrlibm.dylib`)

?

-Mike

On Thu, Sep 17, 2015 at 5:06 PM, David P. Sanders  wrote:
> Hi,
>
> I am almost ready to release a simple wrapper of the CRlibm library: see
> https://github.com/dpsanders/CRlibm.jl
>
> The last (?) step I need is to get the gcc command in the below build script
> in deps/build.jl to work.
> Could somone please suggest how to do this? The problem is that *.o is not
> expanded in Julia commands
> (maybe this could be added?)
>
> I found a previous discussion at
> https://groups.google.com/forum/#!topic/julia-users/hzBeluKU7P0
>
> I tried the solutions suggested, but the ones involving Julia code don't
> seem
> to work inside the @build_steps macro, and the one using find, implemented
> as
>
>  `gcc -L. -shared -o libcrlibm.dylib $(find . -d 1 -name *.o)`
>
> gives
> ERROR: ParseError("missing separator in tuple")
>
> Thanks,
> David
>
> Extract from script:
>
> provides(SimpleBuild,
> (@build_steps begin
> GetSources(libcrlibm)
>
> @build_steps begin
> ChangeDirectory(srcdir)
> @build_steps begin
> `./configure CFLAGS=-fpic`
> `make`
>
> `gcc -L. -shared -o libcrlibm.dylib *.o`
> end
> end
> end),
> libcrlibm, os = :Unix
> )
>
> (How is one supposed to include code here??)

[julia-users] Re: Overloading a function with type not compiled yet

[amiksvi]

Ok, great, thanks a lot.

Re: [julia-users] Help with a parameterized function declaration

[Tom Breloff]

Try:


# this one for any AbstractFoo that is NOT Foo1
> julia> Base.getindex(foo::AbstractFoo, I...) = Foo2(foo.data[I...])
> getindex (generic function with 185 methods)
>


> julia> Base.getindex(foo::Foo1, I...) = Foo1(foo.data[I...])
> getindex (generic function with 184 methods)
>


> julia> f1 = Foo1{2,Float64}(rand(2,2))
> Error showing value of type Foo1{2,Float64}:
> ERROR: MethodError: `size` has no method matching
> size(::Foo1{2,Float64})SYSTEM: show(lasterr) caused an error
>


> julia> f1.data  # notice we actually did create it... the error was just
> in trying to show it
> 2x2 Array{Float64,2}:
>  0.696612  0.337268
>  0.987464  0.719724
>


> julia> tmp = f1[1,:]
> Error showing value of type Foo1{2,Float64}:
> ERROR: MethodError: `size` has no method matching
> size(::Foo1{2,Float64})SYSTEM: show(lasterr) caused an error
>


> julia> tmp.data
> 1x2 Array{Float64,2}:
>  0.696612  0.337268




On Thu, Sep 17, 2015 at 4:14 PM, Spencer Russell  wrote:

> On Thu, Sep 17, 2015, at 02:31 PM, Tom Breloff wrote:
>
> f{T<:AbstractInnerType}(x::AbstractOuterType{T}) = 
>
>
> I don't quite see how to map that onto my problem (forgive me if I'm just
> being dense). I have 3 types:
> Foo1{N, T} <: AbstractFoo{N, T} <: AbstractArray{T, 2}
>
> and I want to define a method (in this case getindex) that accepts any
> subtype of AbstractFoo{N, T}. If the given instance is a Foo1{N, T} I
> want to call the constructor Foo1(someval). If the instance was a Foo2{N,
> T} then I'd want to call Foo2(someval). I think the tricky bit is
> accepting a Foo1{N, T} and just extracting the Foo1 part of it. I think
> that my first attempt:
>
> Base.getindex{BT{N, T} <: AbstractFoo{N, T}}(foo::BT, I...) =
> BT(foo.data[I...])
>
> Gets across what I'm trying to do, but is not legal.
>
> Maybe a clearer way to state the underlying problem is:
>
> given Foo1{N, T} <: AbstractFoo{N, T}
> Foo1{1, Int} is a subtype of both Foo1 and AbstractFoo{1, Int}
> super(Foo1{1, Int}) returns AbstractFoo{1, Int}, but I want something
> that gives me Foo1.
>
> Thanks for the help, sorry this seems pretty in-the-weeds.
>
>
> However I would be very careful attaching a parameter N to the number of
> columns of an array.  Unless you are sure you'll only have a small handful
> of unique values, you risk creating tons and tons of different types, all
> requiring specialized compilation of every function they touch.
>
>
> Re: parameterizing on N -
> I'm using this for multichannel audio signals, so the vast majority of the
> time N will be 1 or 2, sometimes 4 or 8. Even if it's a different number, I
> expect usage will be grouped such that there won't be a whole lot of
> different channel counts in the same application.
> That said, it's part of the design that I'm not 100% sure on, so once I
> get further down the line I may go back on it.
>
> -s
>
>
>
>
>
>
> On Thu, Sep 17, 2015 at 2:10 PM, Spencer Russell 
> wrote:
>
>
> I think my question boils down to: "How do I define a method catches any
> subtype of a parametric supertype, but access the unparameterized part of
> the subtype within the function body?"
>
> Say I have this type:
>
> abstract AbstractFoo{N, T} <: AbstractArray{T, 2}
>
> type Foo1{N, T} <: AbstractFoo{N, T}
> data::Array{T, 2}
> end
>
> Foo1{T}(arr::AbstractArray{T, 2}) = Foo1{size(arr, 2), T}(arr)
>
> So the Foo1 outer constructor sets the type parameter N based on the
> number of columns of the contained array.
>
> When indexed by a Range, I want the returned value to be wrapped in a Foo1
> type, but it might be parameterized with a different value for N, but I
> can't figure out the right type definition. The plan is to catch types that
> are a subtype of Foo, but call the outer constructor to build the result
> value.
>
> I've tried:
>
> Base.getindex{BT{N, T} <: AbstractFoo{N, T}}(foo::BT, I...) =
> BT(foo.data[I...])
>
> but apparently that has a malformed type parameter list.
>
> I've also tried
>
> Base.getindex{BT <: AbstractFoo}(foo::BT, I::Idx...) = BT(foo.data[I...])
>
> But that doesn't get called because Foo1{N, T} is not a subtype of
> AbstractFoo.
>
> What does work is defining
>
> Base.getindex(foo::Foo1, I::Idx...) = Foo1(foo.data[I...])
>
> But then I have to define the getindex method for each concrete subtype
> of AbstractFoo.
>
> Thanks for any help. It's possible that these gymnastics are a sign that I
> just shouldn't parameterize on N and do any necessary checks at runtime,
> but it feels like I'm close on this one.
>
>
> -s
>
>
>
>

Re: [julia-users] Re: IDE for Julia

[Tom Breloff]

I vote for creating a julia-tangents group.

On Thu, Sep 17, 2015 at 4:56 PM, Stefan Karpinski 
wrote:

> I think that julia-users is ok as a it's been used, although some of the
> discussions can get a bit long and tangential (case in point). I've been
> contemplating creating a julia-help list that is more specifically for
> people have problems or confusion. Kind of waiting to see if we decide to
> switch to some other kind of forum first.
>
> On Thu, Sep 17, 2015 at 4:26 PM, Tim Holy  wrote:
>
>> While I do tune out some of the long discussions, there's also a subset
>> that I
>> find quite engaging. I would hate it if julia-users just became about
>> short
>> requests for help installing a package or fixing a performance
>> problem---there
>> would be little to keep the interest of people who've been there, done
>> that.
>>
>> Best,
>> --Tim
>>
>> On Thursday, September 17, 2015 07:36:22 PM Mike Innes wrote:
>> > I'm not necessarily saying google groups is fundamentally bad for
>> > discussion, e.g. if you set up a daily digest and such, just that for
>> most
>> > people here it's not the expectation. For the most part every email you
>> > send to -users ends up in the inbox of every Julia dev and many more in
>> the
>> > community. That's a great set up for getting fast feedback and help from
>> > the right person, but it's much less convenient when there's a lot of
>> > back-and-forth between a subset of users.
>> >
>> > But I take your point – we could use more guidelines about what the
>> > expectations actually are, as well as alternatives for people who want
>> to
>> > have those kinds of discussions.
>> >
>> > On Thu, 17 Sep 2015 at 20:09 Daniel Carrera  wrote:
>> > > On 17 September 2015 at 17:33, Mike Innes 
>> wrote:
>> > >> Quick meta-note about this thread: I think it's important to
>> emphasise
>> > >> that the julia-users list isn't designed to handle this kind of
>> > >> open-ended
>> > >> discussion. It's not that discussion is bad per se, but this list
>> has a
>> > >> lot
>> > >> of subscribers who are mostly interested in sharply-focused technical
>> > >> issues – usually announcements or giving and receiving help. Topics
>> that
>> > >> involve, say, debating the merits of various technologies are better
>> > >> suited
>> > >> to platforms such as reddit with features like comment threads for
>> > >> tangents, more focused notifications for other users, etc.
>> > >
>> > > I don't agree. A Google group is well designed for open-ended
>> discussion.
>> > > I receive a daily digest, where I can scan topics and subscribe only
>> to
>> > > the
>> > > ones that I find interesting. Also, the Julia community page does not
>> > > recommend any other forum for general discussion besides the users
>> group.
>> > > Nor have am I aware of any official policy that when threads reach
>> some
>> > > number of posts the participants are expected to relocate to Reddit.
>> When
>> > > the time comes, and a new group is made for open-ended discussion
>> about
>> > > Julia, I will be happy to subscribe to that group.
>> > >
>> > > Just my two cents.
>> > >
>> > > Cheers,
>> > > Daniel.
>>
>>
>

[julia-users] Run gcc in build.jl

[David P. Sanders]

Hi,

I am almost ready to release a simple wrapper of the CRlibm library: see
https://github.com/dpsanders/CRlibm.jl

The last (?) step I need is to get the gcc command in the below build 
script in deps/build.jl to work.
Could somone please suggest how to do this? The problem is that *.o is not 
expanded in Julia commands
(maybe this could be added?)

I found a previous discussion at
https://groups.google.com/forum/#!topic/julia-users/hzBeluKU7P0

I tried the solutions suggested, but the ones involving Julia code don't 
seem
to work inside the @build_steps macro, and the one using find, implemented 
as

 `gcc -L. -shared -o libcrlibm.dylib $(find . -d 1 -name *.o)`

gives 
ERROR: ParseError("missing separator in tuple")

Thanks,
David

Extract from script:

provides(SimpleBuild,
(@build_steps begin
GetSources(libcrlibm)

@build_steps begin
ChangeDirectory(srcdir)
@build_steps begin
`./configure CFLAGS=-fpic`
`make`

`gcc -L. -shared -o libcrlibm.dylib *.o`
end
end
end),
libcrlibm, os = :Unix
)

(How is one supposed to include code here??)

Re: [julia-users] Re: IDE for Julia

[Stefan Karpinski]

I think that julia-users is ok as a it's been used, although some of the
discussions can get a bit long and tangential (case in point). I've been
contemplating creating a julia-help list that is more specifically for
people have problems or confusion. Kind of waiting to see if we decide to
switch to some other kind of forum first.

On Thu, Sep 17, 2015 at 4:26 PM, Tim Holy  wrote:

> While I do tune out some of the long discussions, there's also a subset
> that I
> find quite engaging. I would hate it if julia-users just became about short
> requests for help installing a package or fixing a performance
> problem---there
> would be little to keep the interest of people who've been there, done
> that.
>
> Best,
> --Tim
>
> On Thursday, September 17, 2015 07:36:22 PM Mike Innes wrote:
> > I'm not necessarily saying google groups is fundamentally bad for
> > discussion, e.g. if you set up a daily digest and such, just that for
> most
> > people here it's not the expectation. For the most part every email you
> > send to -users ends up in the inbox of every Julia dev and many more in
> the
> > community. That's a great set up for getting fast feedback and help from
> > the right person, but it's much less convenient when there's a lot of
> > back-and-forth between a subset of users.
> >
> > But I take your point – we could use more guidelines about what the
> > expectations actually are, as well as alternatives for people who want to
> > have those kinds of discussions.
> >
> > On Thu, 17 Sep 2015 at 20:09 Daniel Carrera  wrote:
> > > On 17 September 2015 at 17:33, Mike Innes 
> wrote:
> > >> Quick meta-note about this thread: I think it's important to emphasise
> > >> that the julia-users list isn't designed to handle this kind of
> > >> open-ended
> > >> discussion. It's not that discussion is bad per se, but this list has
> a
> > >> lot
> > >> of subscribers who are mostly interested in sharply-focused technical
> > >> issues – usually announcements or giving and receiving help. Topics
> that
> > >> involve, say, debating the merits of various technologies are better
> > >> suited
> > >> to platforms such as reddit with features like comment threads for
> > >> tangents, more focused notifications for other users, etc.
> > >
> > > I don't agree. A Google group is well designed for open-ended
> discussion.
> > > I receive a daily digest, where I can scan topics and subscribe only to
> > > the
> > > ones that I find interesting. Also, the Julia community page does not
> > > recommend any other forum for general discussion besides the users
> group.
> > > Nor have am I aware of any official policy that when threads reach some
> > > number of posts the participants are expected to relocate to Reddit.
> When
> > > the time comes, and a new group is made for open-ended discussion about
> > > Julia, I will be happy to subscribe to that group.
> > >
> > > Just my two cents.
> > >
> > > Cheers,
> > > Daniel.
>
>

Re: [julia-users] Re: IDE for Julia

[Tim Holy]

While I do tune out some of the long discussions, there's also a subset that I 
find quite engaging. I would hate it if julia-users just became about short 
requests for help installing a package or fixing a performance problem---there 
would be little to keep the interest of people who've been there, done that.

Best,
--Tim

On Thursday, September 17, 2015 07:36:22 PM Mike Innes wrote:
> I'm not necessarily saying google groups is fundamentally bad for
> discussion, e.g. if you set up a daily digest and such, just that for most
> people here it's not the expectation. For the most part every email you
> send to -users ends up in the inbox of every Julia dev and many more in the
> community. That's a great set up for getting fast feedback and help from
> the right person, but it's much less convenient when there's a lot of
> back-and-forth between a subset of users.
> 
> But I take your point – we could use more guidelines about what the
> expectations actually are, as well as alternatives for people who want to
> have those kinds of discussions.
> 
> On Thu, 17 Sep 2015 at 20:09 Daniel Carrera  wrote:
> > On 17 September 2015 at 17:33, Mike Innes  wrote:
> >> Quick meta-note about this thread: I think it's important to emphasise
> >> that the julia-users list isn't designed to handle this kind of
> >> open-ended
> >> discussion. It's not that discussion is bad per se, but this list has a
> >> lot
> >> of subscribers who are mostly interested in sharply-focused technical
> >> issues – usually announcements or giving and receiving help. Topics that
> >> involve, say, debating the merits of various technologies are better
> >> suited
> >> to platforms such as reddit with features like comment threads for
> >> tangents, more focused notifications for other users, etc.
> > 
> > I don't agree. A Google group is well designed for open-ended discussion.
> > I receive a daily digest, where I can scan topics and subscribe only to
> > the
> > ones that I find interesting. Also, the Julia community page does not
> > recommend any other forum for general discussion besides the users group.
> > Nor have am I aware of any official policy that when threads reach some
> > number of posts the participants are expected to relocate to Reddit. When
> > the time comes, and a new group is made for open-ended discussion about
> > Julia, I will be happy to subscribe to that group.
> > 
> > Just my two cents.
> > 
> > Cheers,
> > Daniel.

Re: [julia-users] speed comparison with Mathematica

[Kristoffer Carlsson]

It is fast in IJulia too if you split the function definition and the timing 
into two different cells.

Re: [julia-users] Emacs, ESS and julia-mode

[Cedric St-Jean]

Tamas,

I've hacked into SLIME/Swank before to support a DSL, and it wasn't too 
horrible. I'd love to get SLIME support for Julia, but my workflow revolves 
around notebooks these days, and I don't want to give those up. Do you see 
any way of combining the two?

(thank you for your LLA library BTW!)

Cédric

On Thursday, September 17, 2015 at 12:20:41 PM UTC-4, Stephen Eglen wrote:
>
> Its even simpler, of course...   *@doc eig* gets you the documentation 
> for eig.  So, try editing ess/etc/ess-julia.jl so that your help definition 
> is simply:
>
>
> function help(topic::String)
> eval(parse("@doc $topic"))
> end
>
> and start a new *julia* session.  
>
> On Thursday, September 17, 2015 at 4:34:21 PM UTC+1, Michael Turok wrote:
>>
>> Thank you!  And for that pointer to the doc string
>>
>> On Thursday, September 17, 2015 at 9:55:52 AM UTC-4, Stephen Eglen wrote:
>>>
>>> As one of the ESS developers, I will try and fix this with 0.4.  From 
>>> quick inspection, it looks like I can get the same help from the command 
>>> line using:
>>>
>>>
>>> -
>>>
>>> julia> Base.Docs.@repl pwd
>>>
>>> search: pwd powermod print_with_color
>>>
>>>
>>>   pwd() -> AbstractString
>>>
>>>
>>>   Get the current working directory.
>>>
>>> -
>>>
>>>
>>> If that looks right, I'll try to add that.
>>>
>>> On Thursday, September 17, 2015 at 2:33:29 PM UTC+1, Andrei Zh wrote:

 ESS mode's integration with Julia's REPL is quite simple and can't 
 handle special sequences. It's a pity that `help()` function has been 
 removed from 0.4, I didn't see it before your post.

 There was a discussion regarding better REPL (network REPL?) recently, 
 but AFAIK nobody is working on such solution yet.


 On Thursday, September 17, 2015 at 4:16:33 PM UTC+3, Michael Turok 
 wrote:
>
> The issue is that ?Pkg.init isn't recognized either - is there some 
> special REPL handling?
>
> julia> ?Pkg.init
> ERROR: UndefVarError: ? not defined
>
>
> julia> 
>
>
> On Thursday, September 17, 2015 at 9:11:54 AM UTC-4, Mauro wrote:
>>
>> Well, help is not a function in 0.4 anymore.  Use ?Pkg.init 
>>
>> Can't help with the other ESS things.   I've tried it for a bit but 
>> it 
>> introduced a noticeable lag so I switch back to just using 
>> julia-mode.el 
>>
>> On Thu, 2015-09-17 at 14:32, Michael Turok  
>> wrote: 
>> > Anyone here running julia under ESS in emacs? 
>> > 
>> > It seems that emacs's ess-mode for julia isn't quite as happy 
>> lately - 
>> > especially with some changes in 0.4 (related to REPL changes, 
>> possibly?).   
>> > For example, help() doesn't do anything...perhaps b/c the REPL now 
>> expects 
>> > "?" to do something useful. 
>> > 
>> > Anyone have any suggestions?   (Or am I moving to atom+hydrogen 
>> later 
>> > today?) 
>> > 
>> > *Julia 0.3:* 
>> > julia> help(Pkg.init) 
>> > Base.Pkg.init(meta::String=DEFAULT_META, 
>> branch::String=META_BRANCH) 
>> > 
>> > 
>> >Initialize "Pkg.dir()" as a package directory. This will be done 
>> >automatically when the "JULIA_PKGDIR" is not set and 
>> >"Pkg.dir()" uses its default value. As part of this process, 
>> >clones a local METADATA git repository from the site and branch 
>> >specified by its arguments, which are typically not provided. 
>> >Explicit (non-default) arguments can be used to support a custom 
>> >METADATA setup. 
>> > 
>> > 
>> > julia> 
>> > 
>> > *Julia 0.4* 
>> > 
>> > 
>> > 
>> > 
>> > *julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> 
>> * 
>>
>>

Re: [julia-users] speed comparison with Mathematica

[Frank Kampas]

In IJulia, it's about 1.8 mSec no matter how many times I run it.  In the 
command window, it's about 57 microSeconds the second time.  Why is that?

On Thursday, September 17, 2015 at 4:07:29 PM UTC-4, Elliot Saba wrote:
>
> Because Julia is a just-in-time compiled language, the first time you run 
> something, it gets compiled immediately before running it.  Therefore, we 
> suggest you time the execution after "warming up" the JIT:
>
> julia> fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
> fib (generic function with 1 method)
>
> julia> @time fib(20)
> elapsed time: 0.003523425 seconds (47856 bytes allocated)
> 6765
>
> julia> @time fib(20)
> elapsed time: 0.000144034 seconds (96 bytes allocated)
> 6765
>
> julia> @time fib(20)
> elapsed time: 0.000143337 seconds (96 bytes allocated)
> 6765
>
>
> Also note that the @time macro is doing the printing, so you don't need 
> the parentheses or the println() call for this.
>
> On Thu, Sep 17, 2015 at 12:53 PM, Frank Kampas  > wrote:
>
>> On julialang.org, it is stated that Julia is about 170 times faster than 
>> Mathematica for the the test "fib".  I get about a factor 2.
>>
>> Julia:
>>
>> fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
>> println(@time(fib(20)))
>>
>> elapsed time: 0.001868071 seconds (33280 bytes allocated)
>> 6765
>>
>>
>> Mathematica:
>>
>>
>> In[1]:= AbsoluteTiming[fib = 
>> Compile[{{n,_Integer}},If[n<2,n,fib[n-1]+fib[n-2
>> Out[1]= {0.000134563,CompiledFunction[Argument count: 1
>> Argument types: {_Integer}]}
>>
>>
>>
>> In[2]:= AbsoluteTiming[fib[20]]
>> Out[2]= {0.00385017,6765}
>>
>>
>>
>>
>>
>

Re: [julia-users] Help with a parameterized function declaration

[Spencer Russell]

On Thu, Sep 17, 2015, at 02:31 PM, Tom Breloff wrote:
> f{T<:AbstractInnerType}(x::AbstractOuterType{T}) = 

I don't quite see how to map that onto my problem (forgive me if I'm
just being dense). I have 3  types: Foo1{N, T} <: AbstractFoo{N, T} <:
AbstractArray{T, 2}

and I want to define a method (in this case getindex) that accepts any
subtype of AbstractFoo{N, T}. If the given instance is a Foo1{N, T} I
want to call the constructor Foo1(someval). If the instance was a
Foo2{N, T} then I'd want to call Foo2(someval). I think the tricky bit
is accepting a Foo1{N, T} and just extracting the Foo1 part of it. I
think that my first attempt:

Base.getindex{BT{N, T} <: AbstractFoo{N, T}}(foo::BT, I...) =
BT(foo.data[I...])

Gets across what I'm trying to do, but is not legal.

Maybe a clearer way to state the underlying problem is:

given Foo1{N, T} <: AbstractFoo{N, T} Foo1{1, Int} is a subtype of both
Foo1 and AbstractFoo{1, Int} super(Foo1{1, Int}) returns AbstractFoo{1,
Int}, but I want something that gives me Foo1.

Thanks for the help, sorry this seems pretty in-the-weeds.

> However I would be very careful attaching a parameter N to the number
> of columns of an array.  Unless you are sure you'll only have a small
> handful of unique values, you risk creating tons and tons of
> different types, all requiring specialized compilation of every
> function they touch.

Re: parameterizing on N - I'm using this for multichannel audio signals,
so the vast majority of the time N will be 1 or 2, sometimes 4 or 8.
Even if it's a different number, I expect usage will be grouped such
that there won't be a whole lot of different channel counts in the same
application. That said, it's part of the design that I'm not 100% sure
on, so once I get further down the line I may go back on it.

-s


>
>
>
> On Thu, Sep 17, 2015 at 2:10 PM, Spencer Russell
>  wrote:
>> __
>> I think my question boils down to: "How do I define a method catches
>> any subtype of a parametric supertype, but access the unparameterized
>> part of the subtype within the function body?"
>>
>> Say I have this type:
>>
>> abstract AbstractFoo{N, T} <: AbstractArray{T, 2}
>>
>> type Foo1{N, T} <: AbstractFoo{N, T}    data::Array{T, 2} end
>>
>> Foo1{T}(arr::AbstractArray{T, 2}) = Foo1{size(arr, 2), T}(arr)
>>
>> So the Foo1 outer constructor sets the type parameter N based on the
>> number of columns of the contained array.
>>
>> When indexed by a Range, I want the returned value to be wrapped in a
>> Foo1 type, but it might be parameterized with a different value for
>> N, but I can't figure out the right type definition. The plan is to
>> catch types that are a subtype of Foo, but call the outer constructor
>> to build the result value.
>>
>> I've tried:
>>
>> Base.getindex{BT{N, T} <: AbstractFoo{N, T}}(foo::BT, I...) =
>> BT(foo.data[I...])
>>
>> but apparently that has a malformed type parameter list.
>>
>> I've also tried
>>
>> Base.getindex{BT <: AbstractFoo}(foo::BT, I::Idx...) =
>> BT(foo.data[I...])
>>
>> But that doesn't get called because Foo1{N, T} is not a subtype of
>> AbstractFoo.
>>
>> What does work is defining
>>
>> Base.getindex(foo::Foo1, I::Idx...) = Foo1(foo.data[I...])
>>
>> But then I have to define the getindex method for each concrete
>> subtype of AbstractFoo.
>>
>> Thanks for any help. It's possible that these gymnastics are a sign
>> that I just shouldn't parameterize on N and do any necessary checks
>> at runtime, but it feels like I'm close on this one.
>>
>>
>> -s
>>

Re: [julia-users] speed comparison with Mathematica

[Elliot Saba]

For further reading, I suggest you check out the the performance section
 of
the manual; it explains all this and more.  Welcome to Julia, and because
many of these micro benchmarks can be highly dependent on system
configuration (what CPU features you have, what operating system you're on,
what version of MATLAB/Mathematica you are comparing against) I highly
recommend coming up with benchmarks that are specific to your use case,
consulting the performance tips section of the manual when you run into a
problem, and then mailing this list if you are still seeing suboptimal
performance.  Writing high performance code in Julia isn't automatic, but
we do strive to make it as easy as possible.
-E

On Thu, Sep 17, 2015 at 1:06 PM, Shashi Gowda 
wrote:

> The first time you run a function with a certain tuple of types of
> arguments it gets just-in-time compiled adding to the time you measure.
> Subsequent runs will be faster and allocate much less memory. Try:
>
> fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
> @time(fib(20))
> @time(fib(20))
>
> and consider the second result.
>
>
> On Fri, Sep 18, 2015 at 1:23 AM, Frank Kampas  wrote:
>
>> On julialang.org, it is stated that Julia is about 170 times faster than
>> Mathematica for the the test "fib".  I get about a factor 2.
>>
>> Julia:
>>
>> fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
>> println(@time(fib(20)))
>>
>> elapsed time: 0.001868071 seconds (33280 bytes allocated)
>> 6765
>>
>>
>> Mathematica:
>>
>>
>> In[1]:= AbsoluteTiming[fib = 
>> Compile[{{n,_Integer}},If[n<2,n,fib[n-1]+fib[n-2
>> Out[1]= {0.000134563,CompiledFunction[Argument count: 1
>> Argument types: {_Integer}]}
>>
>>
>>
>> In[2]:= AbsoluteTiming[fib[20]]
>> Out[2]= {0.00385017,6765}
>>
>>
>>
>>
>>
>

Re: [julia-users] speed comparison with Mathematica

[Elliot Saba]

Because Julia is a just-in-time compiled language, the first time you run
something, it gets compiled immediately before running it.  Therefore, we
suggest you time the execution after "warming up" the JIT:

julia> fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
fib (generic function with 1 method)

julia> @time fib(20)
elapsed time: 0.003523425 seconds (47856 bytes allocated)
6765

julia> @time fib(20)
elapsed time: 0.000144034 seconds (96 bytes allocated)
6765

julia> @time fib(20)
elapsed time: 0.000143337 seconds (96 bytes allocated)
6765


Also note that the @time macro is doing the printing, so you don't need the
parentheses or the println() call for this.

On Thu, Sep 17, 2015 at 12:53 PM, Frank Kampas  wrote:

> On julialang.org, it is stated that Julia is about 170 times faster than
> Mathematica for the the test "fib".  I get about a factor 2.
>
> Julia:
>
> fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
> println(@time(fib(20)))
>
> elapsed time: 0.001868071 seconds (33280 bytes allocated)
> 6765
>
>
> Mathematica:
>
>
> In[1]:= AbsoluteTiming[fib = 
> Compile[{{n,_Integer}},If[n<2,n,fib[n-1]+fib[n-2
> Out[1]= {0.000134563,CompiledFunction[Argument count: 1
> Argument types: {_Integer}]}
>
>
>
> In[2]:= AbsoluteTiming[fib[20]]
> Out[2]= {0.00385017,6765}
>
>
>
>
>

Re: [julia-users] speed comparison with Mathematica

[Shashi Gowda]

The first time you run a function with a certain tuple of types of
arguments it gets just-in-time compiled adding to the time you measure.
Subsequent runs will be faster and allocate much less memory. Try:

fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
@time(fib(20))
@time(fib(20))

and consider the second result.


On Fri, Sep 18, 2015 at 1:23 AM, Frank Kampas  wrote:

> On julialang.org, it is stated that Julia is about 170 times faster than
> Mathematica for the the test "fib".  I get about a factor 2.
>
> Julia:
>
> fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
> println(@time(fib(20)))
>
> elapsed time: 0.001868071 seconds (33280 bytes allocated)
> 6765
>
>
> Mathematica:
>
>
> In[1]:= AbsoluteTiming[fib = 
> Compile[{{n,_Integer}},If[n<2,n,fib[n-1]+fib[n-2
> Out[1]= {0.000134563,CompiledFunction[Argument count: 1
> Argument types: {_Integer}]}
>
>
>
> In[2]:= AbsoluteTiming[fib[20]]
> Out[2]= {0.00385017,6765}
>
>
>
>
>

[julia-users] speed comparison with Mathematica

[Frank Kampas]

On julialang.org, it is stated that Julia is about 170 times faster than 
Mathematica for the the test "fib".  I get about a factor 2.

Julia:

fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
println(@time(fib(20)))

elapsed time: 0.001868071 seconds (33280 bytes allocated)
6765


Mathematica:


In[1]:= AbsoluteTiming[fib = 
Compile[{{n,_Integer}},If[n<2,n,fib[n-1]+fib[n-2
Out[1]= {0.000134563,CompiledFunction[Argument count: 1
Argument types: {_Integer}]}



In[2]:= AbsoluteTiming[fib[20]]
Out[2]= {0.00385017,6765}

Re: [julia-users] Re: IDE for Julia

[Mike Innes]

I'm not necessarily saying google groups is fundamentally bad for
discussion, e.g. if you set up a daily digest and such, just that for most
people here it's not the expectation. For the most part every email you
send to -users ends up in the inbox of every Julia dev and many more in the
community. That's a great set up for getting fast feedback and help from
the right person, but it's much less convenient when there's a lot of
back-and-forth between a subset of users.

But I take your point – we could use more guidelines about what the
expectations actually are, as well as alternatives for people who want to
have those kinds of discussions.

On Thu, 17 Sep 2015 at 20:09 Daniel Carrera  wrote:

> On 17 September 2015 at 17:33, Mike Innes  wrote:
>
>>
>> Quick meta-note about this thread: I think it's important to emphasise
>> that the julia-users list isn't designed to handle this kind of open-ended
>> discussion. It's not that discussion is bad per se, but this list has a lot
>> of subscribers who are mostly interested in sharply-focused technical
>> issues – usually announcements or giving and receiving help. Topics that
>> involve, say, debating the merits of various technologies are better suited
>> to platforms such as reddit with features like comment threads for
>> tangents, more focused notifications for other users, etc.
>>
>
> I don't agree. A Google group is well designed for open-ended discussion.
> I receive a daily digest, where I can scan topics and subscribe only to the
> ones that I find interesting. Also, the Julia community page does not
> recommend any other forum for general discussion besides the users group.
> Nor have am I aware of any official policy that when threads reach some
> number of posts the participants are expected to relocate to Reddit. When
> the time comes, and a new group is made for open-ended discussion about
> Julia, I will be happy to subscribe to that group.
>
> Just my two cents.
>
> Cheers,
> Daniel.
>
>
>
>
>
>
>

Re: [julia-users] Re: IDE for Julia

[Daniel Carrera]

On 17 September 2015 at 17:33, Mike Innes  wrote:

>
> Quick meta-note about this thread: I think it's important to emphasise
> that the julia-users list isn't designed to handle this kind of open-ended
> discussion. It's not that discussion is bad per se, but this list has a lot
> of subscribers who are mostly interested in sharply-focused technical
> issues – usually announcements or giving and receiving help. Topics that
> involve, say, debating the merits of various technologies are better suited
> to platforms such as reddit with features like comment threads for
> tangents, more focused notifications for other users, etc.
>

I don't agree. A Google group is well designed for open-ended discussion. I
receive a daily digest, where I can scan topics and subscribe only to the
ones that I find interesting. Also, the Julia community page does not
recommend any other forum for general discussion besides the users group.
Nor have am I aware of any official policy that when threads reach some
number of posts the participants are expected to relocate to Reddit. When
the time comes, and a new group is made for open-ended discussion about
Julia, I will be happy to subscribe to that group.

Just my two cents.

Cheers,
Daniel.

Re: [julia-users] Re: Dispatch on arbitrary wrapper types

[Josh Langsfeld]

Yes, it's definitely a special case of such a trait system. I had heard 
some mentions of bringing in traits but was not aware of the details at all.

Looking at Mauro's code, it seems it would be somewhat unwieldy to use in 
this case, since if I'm not mistaken, one would have to specify manually 
that 'ASCIIString' satisfies the 'ASCIIString trait'. It also didn't appear 
that you can automatically base traits on type parameters.

On Thursday, September 17, 2015 at 2:27:50 PM UTC-4, Tom Breloff wrote:
>
> I think what you're looking for are traits.  There's discussion about 
> making them part of the core language eventually, but in the meantime, 
> check out https://github.com/mauro3/Traits.jl
>
> On Thu, Sep 17, 2015 at 2:16 PM, Josh Langsfeld  > wrote:
>
>> Essentially, it would really cool to be able to do something like 'type 
>> SubString{T<: AbstractString} <:T ...' for dispatch purposes. 
>> 'SubString{ASCIIString} <: ASCIIString' would still return false in general.
>>
>> On Thursday, September 17, 2015 at 1:47:24 PM UTC-4, Josh Langsfeld wrote:
>>>
>>> I recently was stumped when I wanted to write a function that dispatched 
>>> on 'ASCIIString' versus 'UTF8String' but then had to deal with a 
>>> 'SubString{ASCIIString}'. It made me think that given Julia's prolific use 
>>> of wrapper types, it would be very nice to be able to dispatch on a type T 
>>> and also any wrapper with a single type parameter of T that acts just like 
>>> a regular T.
>>>
>>> As far as I'm aware, that's only possible with a UnionType, but that's 
>>> quite cumbersome to code, especially if you don't know the names of all the 
>>> wrappers you might see beforehand. Any thoughts on the feasibility of 
>>> something like this?
>>>
>>
>

Re: [julia-users] Help with a parameterized function declaration

[Tom Breloff]

f{T<:AbstractInnerType}(x::AbstractOuterType{T}) = 

However I would be very careful attaching a parameter N to the number of
columns of an array.  Unless you are sure you'll only have a small handful
of unique values, you risk creating tons and tons of different types, all
requiring specialized compilation of every function they touch.

On Thu, Sep 17, 2015 at 2:10 PM, Spencer Russell  wrote:

> I think my question boils down to: "How do I define a method catches any
> subtype of a parametric supertype, but access the unparameterized part of
> the subtype within the function body?"
>
> Say I have this type:
>
> abstract AbstractFoo{N, T} <: AbstractArray{T, 2}
>
> type Foo1{N, T} <: AbstractFoo{N, T}
> data::Array{T, 2}
> end
>
> Foo1{T}(arr::AbstractArray{T, 2}) = Foo1{size(arr, 2), T}(arr)
>
> So the Foo1 outer constructor sets the type parameter N based on the
> number of columns of the contained array.
>
> When indexed by a Range, I want the returned value to be wrapped in a Foo1
> type, but it might be parameterized with a different value for N, but I
> can't figure out the right type definition. The plan is to catch types that
> are a subtype of Foo, but call the outer constructor to build the result
> value.
>
> I've tried:
>
> Base.getindex{BT{N, T} <: AbstractFoo{N, T}}(foo::BT, I...) =
> BT(foo.data[I...])
>
> but apparently that has a malformed type parameter list.
>
> I've also tried
>
> Base.getindex{BT <: AbstractFoo}(foo::BT, I::Idx...) = BT(foo.data[I...])
>
> But that doesn't get called because Foo1{N, T} is not a subtype of
> AbstractFoo.
>
> What does work is defining
>
> Base.getindex(foo::Foo1, I::Idx...) = Foo1(foo.data[I...])
>
> But then I have to define the getindex method for each concrete subtype
> of AbstractFoo.
>
> Thanks for any help. It's possible that these gymnastics are a sign that I
> just shouldn't parameterize on N and do any necessary checks at runtime,
> but it feels like I'm close on this one.
>
> -s
>

Re: [julia-users] Re: Dispatch on arbitrary wrapper types

[Tom Breloff]

I think what you're looking for are traits.  There's discussion about
making them part of the core language eventually, but in the meantime,
check out https://github.com/mauro3/Traits.jl

On Thu, Sep 17, 2015 at 2:16 PM, Josh Langsfeld  wrote:

> Essentially, it would really cool to be able to do something like 'type
> SubString{T<: AbstractString} <:T ...' for dispatch purposes.
> 'SubString{ASCIIString} <: ASCIIString' would still return false in general.
>
> On Thursday, September 17, 2015 at 1:47:24 PM UTC-4, Josh Langsfeld wrote:
>>
>> I recently was stumped when I wanted to write a function that dispatched
>> on 'ASCIIString' versus 'UTF8String' but then had to deal with a
>> 'SubString{ASCIIString}'. It made me think that given Julia's prolific use
>> of wrapper types, it would be very nice to be able to dispatch on a type T
>> and also any wrapper with a single type parameter of T that acts just like
>> a regular T.
>>
>> As far as I'm aware, that's only possible with a UnionType, but that's
>> quite cumbersome to code, especially if you don't know the names of all the
>> wrappers you might see beforehand. Any thoughts on the feasibility of
>> something like this?
>>
>

Re: [julia-users] Debugging help with NLopt

[Nils Gudat]

Argh, I can't believe I actually made this mistake - this is the umptiest 
minimum distance estimator I'm writing using NLopt, and I always ensure 
that a scalar instead of a vector is returned by doing exactly what you're 
suggesting, but for whatever reason I simply missed it this time around. 
Thanks for pointing it out!

(And yes, there's a lot more upper and lower bounds, tolerance levels and, 
indeed, an objective to specify, I just left this out for brevity)

[julia-users] Re: Dispatch on arbitrary wrapper types

[Josh Langsfeld]

Essentially, it would really cool to be able to do something like 'type 
SubString{T<: AbstractString} <:T ...' for dispatch purposes. 
'SubString{ASCIIString} <: ASCIIString' would still return false in general.

On Thursday, September 17, 2015 at 1:47:24 PM UTC-4, Josh Langsfeld wrote:
>
> I recently was stumped when I wanted to write a function that dispatched 
> on 'ASCIIString' versus 'UTF8String' but then had to deal with a 
> 'SubString{ASCIIString}'. It made me think that given Julia's prolific use 
> of wrapper types, it would be very nice to be able to dispatch on a type T 
> and also any wrapper with a single type parameter of T that acts just like 
> a regular T.
>
> As far as I'm aware, that's only possible with a UnionType, but that's 
> quite cumbersome to code, especially if you don't know the names of all the 
> wrappers you might see beforehand. Any thoughts on the feasibility of 
> something like this?
>

[julia-users] Help with a parameterized function declaration

[Spencer Russell]

I think my question boils down to: "How do I define a method catches any 
subtype of a parametric supertype, but access the unparameterized part of the 
subtype within the function body?"

Say I have this type:

abstract AbstractFoo{N, T} <: AbstractArray{T, 2}

type Foo1{N, T} <: AbstractFoo{N, T}    data::Array{T, 2} end

Foo1{T}(arr::AbstractArray{T, 2}) = Foo1{size(arr, 2), T}(arr)

So the Foo1 outer constructor sets the type parameter N based on the
number of columns of the contained array.

When indexed by a Range, I want the returned value to be wrapped in a
Foo1 type, but it might be parameterized with a different value for N,
but I can't figure out the right type definition. The plan is to catch
types that are a subtype of Foo, but call the outer constructor to build
the result value.

I've tried:

Base.getindex{BT{N, T} <: AbstractFoo{N, T}}(foo::BT, I...) =
BT(foo.data[I...])

but apparently that has a malformed type parameter list.

I've also tried

Base.getindex{BT <: AbstractFoo}(foo::BT, I::Idx...) =
BT(foo.data[I...])

But that doesn't get called because Foo1{N, T} is not a subtype of
AbstractFoo.

What does work is defining

Base.getindex(foo::Foo1, I::Idx...) = Foo1(foo.data[I...])

But then I have to define the getindex method for each concrete subtype
of AbstractFoo.

Thanks for any help. It's possible that these gymnastics are a sign that
I just shouldn't parameterize on N and do any necessary checks at
runtime, but it feels like I'm close on this one.

-s

[julia-users] Re: suppress deprecation warnings

[Tony Kelman]

start julia with --depwarn=no

On Thursday, September 17, 2015 at 10:28:10 AM UTC-7, Michael Francis wrote:
>
> How can I suppress the printing of deprecation warnings in 0.4? I need to 
> temporarily suppress these so that I can see the wood for the trees. 
>

[julia-users] Dispatch on arbitrary wrapper types

[Josh Langsfeld]

I recently was stumped when I wanted to write a function that dispatched on 
'ASCIIString' versus 'UTF8String' but then had to deal with a 
'SubString{ASCIIString}'. It made me think that given Julia's prolific use 
of wrapper types, it would be very nice to be able to dispatch on a type T 
and also any wrapper with a single type parameter of T that acts just like 
a regular T.

As far as I'm aware, that's only possible with a UnionType, but that's 
quite cumbersome to code, especially if you don't know the names of all the 
wrappers you might see beforehand. Any thoughts on the feasibility of 
something like this?

RE: [julia-users] Debugging help with NLopt

[David Anthoff]

Your last line in the objective function creates an Array{Float64,1} and 
returns that, but you need to return just a Float64. Probably easiest to just 
write:

 

(result’*target)[1]

 

Instead. Also, in the code sent you seem to miss setting the objective for 
NLopt, but given that something ran I assume that was just an oversight in your 
email.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Nils Gudat
Sent: Thursday, September 17, 2015 10:24 AM
To: julia-users 
Subject: [julia-users] Debugging help with NLopt

 

Just putting this out here in the hope that someone has an idea:
I'm trying to fit a model to some targets using a minimum distance estimator 
with NLopt. The objective function basically computes the distance between 
model output given two parameters and the targets I set. 
The structure is:

objective(parameters::Vector{Float64}, grad)
  result = solvemodel(parameters)
  result'*target  
end

opt = Opt(:GN_CRS2_LM, 2)
lower_bounds!(opt, [numbers])
upper_bounds!(opt, [numbers])
xtol_rel!(opt,0.005)
(minf, minx, ret) = optimize(opt, [numbers])

When running this code, it stays busy for a while (which is expected, given 
that one evaluation of the model takes about 3 minutes) before throwing a 
MethodError, complaining `convert` has no method convert(::Type{Float64}, 
::Array{Float64,1}). I do get a `in callback catch` after every model 
evaluation, but I'm not sure where this is coming from, as when I simply 
evaluate objective() myself using some numbers, a value is returned without 
error. 

Re: [julia-users] Re: ANN: ApproxFun v0.0.8 with (experimental) nonlinear ODE solver

[Luke Stagner]

Nice! What were you stuck using Matlab or IDL (IDL for me). I looked up 
your masters thesis and it looks like we are in the same sub-field 
(Energetic Particles). For my Ph.D thesis work I need to calculate orbits 
in Constants of motion space so my plan was to write up some routines that 
can handle magnetic equilibriums (read EFIT files, switching from different 
flux coordinates, those sort of things) and implement this[1,2] guiding 
center code in Julia. Are you still working in the field? 

[1] Ellison, C. Leland, et al. "Development of variational guiding center 
algorithms for parallel calculations in experimental magnetic equilibria." 
*Plasma 
Physics and Controlled Fusion* 57.5 (2015): 054007.

[2] https://github.com/lellison/NCSI_Basic

On Thursday, September 17, 2015 at 12:06:06 AM UTC-7, Tomas Lycken wrote:
>
> Luke,
>
> I finished my Masters' Thesis work this past spring working with a C++ 
> simulation for fusion plasma physics applications - during most of that 
> time, I was clenching my teeth wishing I was allowed to use Julia 
> instead. If you want any help with your Fusion Plasma Physics toolbox, ping 
> me (@tlycken) on Github and I'll jump in where I can :)
>
> // T
>
> On Thursday, September 17, 2015 at 8:17:45 AM UTC+2, Sheehan Olver wrote:
>>
>> On what kind of domain?  
>>
>>
>> On 17 Sep 2015, at 12:07 pm, Luke Stagner  wrote:
>>
>> It's actually a 2D non-linear, elliptic PDE (psi is a function of R,Z). 
>> I'm thinking about created a Julia library for fusion/plasma physics and 
>> the ability to quickly calculate magnetic equilibrium would be a killer 
>> feature. 
>>
>>
>> On Wednesday, September 16, 2015 at 6:46:09 PM UTC-7, Sheehan Olver wrote:
>>>
>>>
>>> I’m having trouble reading the formulae, but I guess its a nonlinear PDE 
>>> in 3D?   Right now the package can only do nonlinear ODEs and linear PDEs 
>>> on rectangles and disks.  We’ll hopefully eventually extend it to nonlinear 
>>> PDEs, and 3D PDEs.
>>>
>>>
>>>
>>>
>>>
>>> On 17 Sep 2015, at 11:40 am, Luke Stagner  wrote:
>>>
>>> Can this package be used to solve the Grad-Shafranov equation 
>>> ? 
>>>
>>>
>>> On Wednesday, September 16, 2015 at 3:33:22 PM UTC-7, Sheehan Olver 
>>> wrote:


 ApproxFun is a package for approximating and solving differential 
 equations. ApproxFun v0.0.8 Adds (experimental) support for solving 
 nonlinear ODEs, using Newton iteration and automatic differentiation.  The 
 following example solves and plots a singularly perturbed nonlinear 
 two-point boundary value problem

 x=Fun()
 u0=0.x  # The initial guess for Newton iteration

 N=u->[u[-1.]-1.,u[1.]+0.5,0.001u''+6*(1-x^2)*u'+u^2-1.]
 u=newton(N,u0)

 ApproxFun.plot(u)  # Requires PyPlot or Gadfly



 Note: previous support for approximating functions on a disk has been 
 moved to a separate package:

  https://github.com/ApproxFun/DiskFun.jl

 And this will be the last version to support Julia 0.3!  


>>>
>>

[julia-users] suppress deprecation warnings

[Michael Francis]

How can I suppress the printing of deprecation warnings in 0.4? I need to 
temporarily suppress these so that I can see the wood for the trees. 

[julia-users] Debugging help with NLopt

[Nils Gudat]

Just putting this out here in the hope that someone has an idea:
I'm trying to fit a model to some targets using a minimum distance 
estimator with NLopt. The objective function basically computes the 
distance between model output given two parameters and the targets I set. 
The structure is:

objective(parameters::Vector{Float64}, grad)
  result = solvemodel(parameters)
  result'*target  
end

opt = Opt(:GN_CRS2_LM, 2)
lower_bounds!(opt, [numbers])
upper_bounds!(opt, [numbers])
xtol_rel!(opt,0.005)
(minf, minx, ret) = optimize(opt, [numbers])

When running this code, it stays busy for a while (which is expected, given 
that one evaluation of the model takes about 3 minutes) before throwing a 
MethodError, complaining `convert` has no method convert(::Type{Float64}, 
::Array{Float64,1}). I do get a `in callback catch` after every model 
evaluation, but I'm not sure where this is coming from, as when I simply 
evaluate objective() myself using some numbers, a value is returned without 
error. 

Re: [julia-users] Re: ANN: ApproxFun v0.0.8 with (experimental) nonlinear ODE solver

[Luke Stagner]

The Grad-Shafranov equation is typically solved in toroidal 
coordinates(R,Z,phi) assuming toroidal symmetry. Some equilibrium codes use 
conformal mapping to solve the equations[1,2]. Using this technique, the 
(arbitrarily shaped) cross section of the last closed flux surface is 
mapped to a circular disk (Hence why I think ApproxFun.jl/DiskFun.jl could 
be used).

[1] http://fusionwiki.ciemat.es/wiki/HBT
[2] Goedbloed, J. P. "Conformal mapping methods in two-dimensional 
magnetohydrodynamics." *Computer Physics Communications* 24.3 (1981): 
311-321.


On Wednesday, September 16, 2015 at 11:17:45 PM UTC-7, Sheehan Olver wrote:
>
> On what kind of domain?  
>
>
> On 17 Sep 2015, at 12:07 pm, Luke Stagner  > wrote:
>
> It's actually a 2D non-linear, elliptic PDE (psi is a function of R,Z). 
> I'm thinking about created a Julia library for fusion/plasma physics and 
> the ability to quickly calculate magnetic equilibrium would be a killer 
> feature. 
>
>
> On Wednesday, September 16, 2015 at 6:46:09 PM UTC-7, Sheehan Olver wrote:
>>
>>
>> I’m having trouble reading the formulae, but I guess its a nonlinear PDE 
>> in 3D?   Right now the package can only do nonlinear ODEs and linear PDEs 
>> on rectangles and disks.  We’ll hopefully eventually extend it to nonlinear 
>> PDEs, and 3D PDEs.
>>
>>
>>
>>
>>
>> On 17 Sep 2015, at 11:40 am, Luke Stagner  wrote:
>>
>> Can this package be used to solve the Grad-Shafranov equation 
>> ? 
>>
>>
>> On Wednesday, September 16, 2015 at 3:33:22 PM UTC-7, Sheehan Olver wrote:
>>>
>>>
>>> ApproxFun is a package for approximating and solving differential 
>>> equations. ApproxFun v0.0.8 Adds (experimental) support for solving 
>>> nonlinear ODEs, using Newton iteration and automatic differentiation.  The 
>>> following example solves and plots a singularly perturbed nonlinear 
>>> two-point boundary value problem
>>>
>>> x=Fun()
>>> u0=0.x  # The initial guess for Newton iteration
>>>
>>> N=u->[u[-1.]-1.,u[1.]+0.5,0.001u''+6*(1-x^2)*u'+u^2-1.]
>>> u=newton(N,u0)
>>>
>>> ApproxFun.plot(u)  # Requires PyPlot or Gadfly
>>>
>>>
>>>
>>> Note: previous support for approximating functions on a disk has been 
>>> moved to a separate package:
>>>
>>>  https://github.com/ApproxFun/DiskFun.jl
>>>
>>> And this will be the last version to support Julia 0.3!  
>>>
>>>
>>
>

Re: [julia-users] Re: IDE for Julia

[Scott Jones]

How much RAM is available on your system?
One of the people I'm mentoring was going to move to Atom from vim, but he 
said it was way too slow, but it worked fine for the other person. Turned 
out, he had 4GB RAM, she had 8GB RAM, other things roughly equal. (It was 
fine for me also, with 16GB on MBP and 20GB on MP).  
May just be that Atom is (currently?) a memory hog.
Sublime seemed very nice also, we had used Juno-LT as well (but since it 
seems dead, and Mike Innes has moved on to Atom, that's where we've 
followed).
Could a Julia IDE be done most simply be using Nuclide, from FB?
Since that's based on Atom as well, maybe Mike's work would fit in there, 
and John Myles White may have something to do with Nuclide as well, another 
point in it's favor.

On Thursday, September 17, 2015 at 9:57:57 AM UTC-4, Kristoffer Carlsson 
wrote:
>
> Look up GitSavy if you want git integration in Sublime.
>
> I guess different people have different tolerances to latency. I try atom 
> over and over because it is open source and I want it to be the best but 
> everytime it feels like running through syrup. 
>

[julia-users] Re: Overloading a function with type not compiled yet

[Kristoffer Carlsson]

It chooses the one which is "the mos specific". Array{state} <: Any so 
Array{state} is more specific and thus that function will be called.

On Thursday, September 17, 2015 at 6:11:58 PM UTC+2, ami...@gmail.com wrote:
>
> Well, thanks everyone, I think I understand now why it doesn't work when 
> specifying Array{Any}, and your answers completed each other.
> What I still fail to understand is why how Julia manages to choose the 
> correct function, assume I still have:
>
> function f(s)
>   println(s.x)
> end
>
> function f{T}(sl::Array{T})
>   for s in sl
> f(s)
>   end
> end
>
> If I call f on an Array of state, how does Julia know that it has to 
> choose the second function... After all, the argument of the first function 
> could still be an Array of state...
>

Re: [julia-users] Emacs, ESS and julia-mode

[Stephen Eglen]

Its even simpler, of course...   *@doc eig* gets you the documentation for 
eig.  So, try editing ess/etc/ess-julia.jl so that your help definition is 
simply:


function help(topic::String)
eval(parse("@doc $topic"))
end

and start a new *julia* session.  

On Thursday, September 17, 2015 at 4:34:21 PM UTC+1, Michael Turok wrote:
>
> Thank you!  And for that pointer to the doc string
>
> On Thursday, September 17, 2015 at 9:55:52 AM UTC-4, Stephen Eglen wrote:
>>
>> As one of the ESS developers, I will try and fix this with 0.4.  From 
>> quick inspection, it looks like I can get the same help from the command 
>> line using:
>>
>>
>> -
>>
>> julia> Base.Docs.@repl pwd
>>
>> search: pwd powermod print_with_color
>>
>>
>>   pwd() -> AbstractString
>>
>>
>>   Get the current working directory.
>>
>> -
>>
>>
>> If that looks right, I'll try to add that.
>>
>> On Thursday, September 17, 2015 at 2:33:29 PM UTC+1, Andrei Zh wrote:
>>>
>>> ESS mode's integration with Julia's REPL is quite simple and can't 
>>> handle special sequences. It's a pity that `help()` function has been 
>>> removed from 0.4, I didn't see it before your post.
>>>
>>> There was a discussion regarding better REPL (network REPL?) recently, 
>>> but AFAIK nobody is working on such solution yet.
>>>
>>>
>>> On Thursday, September 17, 2015 at 4:16:33 PM UTC+3, Michael Turok wrote:

 The issue is that ?Pkg.init isn't recognized either - is there some 
 special REPL handling?

 julia> ?Pkg.init
 ERROR: UndefVarError: ? not defined


 julia> 


 On Thursday, September 17, 2015 at 9:11:54 AM UTC-4, Mauro wrote:
>
> Well, help is not a function in 0.4 anymore.  Use ?Pkg.init 
>
> Can't help with the other ESS things.   I've tried it for a bit but it 
> introduced a noticeable lag so I switch back to just using 
> julia-mode.el 
>
> On Thu, 2015-09-17 at 14:32, Michael Turok  
> wrote: 
> > Anyone here running julia under ESS in emacs? 
> > 
> > It seems that emacs's ess-mode for julia isn't quite as happy lately 
> - 
> > especially with some changes in 0.4 (related to REPL changes, 
> possibly?).   
> > For example, help() doesn't do anything...perhaps b/c the REPL now 
> expects 
> > "?" to do something useful. 
> > 
> > Anyone have any suggestions?   (Or am I moving to atom+hydrogen 
> later 
> > today?) 
> > 
> > *Julia 0.3:* 
> > julia> help(Pkg.init) 
> > Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH) 
> > 
> > 
> >Initialize "Pkg.dir()" as a package directory. This will be done 
> >automatically when the "JULIA_PKGDIR" is not set and 
> >"Pkg.dir()" uses its default value. As part of this process, 
> >clones a local METADATA git repository from the site and branch 
> >specified by its arguments, which are typically not provided. 
> >Explicit (non-default) arguments can be used to support a custom 
> >METADATA setup. 
> > 
> > 
> > julia> 
> > 
> > *Julia 0.4* 
> > 
> > 
> > 
> > 
> > *julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> * 
>
>

[julia-users] Re: Overloading a function with type not compiled yet

[amiksvi]

Well, thanks everyone, I think I understand now why it doesn't work when 
specifying Array{Any}, and your answers completed each other.
What I still fail to understand is why how Julia manages to choose the 
correct function, assume I still have:

function f(s)
  println(s.x)
end

function f{T}(sl::Array{T})
  for s in sl
f(s)
  end
end

If I call f on an Array of state, how does Julia know that it has to choose 
the second function... After all, the argument of the first function could 
still be an Array of state...

Re: [julia-users] Where do they come from: jl_uv_writecb() ERROR: bad file descriptor EBADF

[Andreas Lobinger]

On Thursday, September 17, 2015 at 10:54:29 AM UTC+2, Jameson wrote:
>
> If RsvgHandle is a GObject object then, yes, it's almost certainly trying 
> to write to STDERR that it detected a double-free error (GObject handles 
> are finalized automatically by GLib.jl, so calling gc_unref manually will 
> result in the object getting freed twice).
>

The librsvg reference tells me: Returns a new rsvg handle. Must be freed 
with *g_object_unref. *So i put the gc_unref into the finalizer. 
But another thing: Wouldn't it be somehow better, that STDERR is available 
for functions to report error messages?  

Re: [julia-users] Re: Help me understand counterintuitive result with type delcaration

[Scott Jones]

On Thursday, September 17, 2015 at 11:18:13 AM UTC-4, Stefan Karpinski 
wrote:
>
> Which, of course, doesn't catch cases where the identifier is on the next 
> line rather than separated by a literal semicolon.
>

Yep, also misses with `return` on the line or next line, or with comments 
in between.
Also, what I had seen may have just been a local maximum, and not common 
elsewhere at all.

Re: [julia-users] Re: Help me understand counterintuitive result with type delcaration

[Scott Jones]

That regex is a bit literal, and I should have been clearer, semantic not 
exact syntax, i.e.:
x = expr ; x
x = expr ; return x
x = expr
x
x = expr
return x

For example, things like this, in symmetric.jl:
 
  retmat = (F.vectors * Diagonal(($func)(complex(F.values * F.vectors'
  return retmat




On Thursday, September 17, 2015 at 11:10:45 AM UTC-4, Stefan Karpinski 
wrote:
>
> Do you really? I just ran this regex r"^\s*(\w+)\s*=.*;\s*\1\s*$" on 
> Julia's code base and all .jl files in all the packages I have installed 
> for both 0.3 and 0.4 and there are zero matches.
>
> On Wed, Sep 16, 2015 at 5:52 PM, Scott Jones  > wrote:
>
>> This is why you see frequently in Julia functions: 
>> x = expr ; x
>>
>>
>>
>> On Wednesday, September 16, 2015 at 5:25:15 PM UTC-4, g wrote:
>>>
>>> That makes a lot of sense, thanks. 
>>>
>>> On Wednesday, September 16, 2015 at 2:22:54 PM UTC-6, Spencer Russell 
>>> wrote:

 There’s an issue where Jeff describes the reasoning here: 
 https://github.com/JuliaLang/julia/issues/5532

 On Sep 16, 2015, at 3:57 PM, j verzani  wrote:

 The return value of the function is value of the last expression 
 evaluated. For assignment, the right-hand side is always returned. So in 
 `f` you get the value x*2.0 returned which is 2.0.

 On Wednesday, September 16, 2015 at 3:41:22 PM UTC-4, g wrote:
>
> I was playing around with type declarations and came across an 
> counterintuitive result. I'm not sure if this is the intended behavior or 
> not, but it certainly surprised me.
>
> Consider the functions
>
> *function f(x)*
>
>*y::Int*
>
>*y=x*2.0*
>
> *end*
>
> *function g(x)*
>
>*y::Int*
>
>*y=x*2.0*
>
>*y*
>
> *end*
>
> *julia> **f(1),g(1)*
>
> *(2.0,2)*
>
> I expected them to behave identically, always returning an Int. But 
> clearly f returns a Float64.
>
>
> It seems like in the presence of the type delaration y=x*2.0 is 
> interpreted as
>
> temp=x*2.0
>
> y=Int(temp)
>
> temp
>
> is that right?
>


>

Re: [julia-users] Emacs, ESS and julia-mode

[Michael Turok]

Thank you!  And for that pointer to the doc string

On Thursday, September 17, 2015 at 9:55:52 AM UTC-4, Stephen Eglen wrote:
>
> As one of the ESS developers, I will try and fix this with 0.4.  From 
> quick inspection, it looks like I can get the same help from the command 
> line using:
>
>
> -
>
> julia> Base.Docs.@repl pwd
>
> search: pwd powermod print_with_color
>
>
>   pwd() -> AbstractString
>
>
>   Get the current working directory.
>
> -
>
>
> If that looks right, I'll try to add that.
>
> On Thursday, September 17, 2015 at 2:33:29 PM UTC+1, Andrei Zh wrote:
>>
>> ESS mode's integration with Julia's REPL is quite simple and can't handle 
>> special sequences. It's a pity that `help()` function has been removed from 
>> 0.4, I didn't see it before your post.
>>
>> There was a discussion regarding better REPL (network REPL?) recently, 
>> but AFAIK nobody is working on such solution yet.
>>
>>
>> On Thursday, September 17, 2015 at 4:16:33 PM UTC+3, Michael Turok wrote:
>>>
>>> The issue is that ?Pkg.init isn't recognized either - is there some 
>>> special REPL handling?
>>>
>>> julia> ?Pkg.init
>>> ERROR: UndefVarError: ? not defined
>>>
>>>
>>> julia> 
>>>
>>>
>>> On Thursday, September 17, 2015 at 9:11:54 AM UTC-4, Mauro wrote:

 Well, help is not a function in 0.4 anymore.  Use ?Pkg.init 

 Can't help with the other ESS things.   I've tried it for a bit but it 
 introduced a noticeable lag so I switch back to just using 
 julia-mode.el 

 On Thu, 2015-09-17 at 14:32, Michael Turok  
 wrote: 
 > Anyone here running julia under ESS in emacs? 
 > 
 > It seems that emacs's ess-mode for julia isn't quite as happy lately 
 - 
 > especially with some changes in 0.4 (related to REPL changes, 
 possibly?).   
 > For example, help() doesn't do anything...perhaps b/c the REPL now 
 expects 
 > "?" to do something useful. 
 > 
 > Anyone have any suggestions?   (Or am I moving to atom+hydrogen later 
 > today?) 
 > 
 > *Julia 0.3:* 
 > julia> help(Pkg.init) 
 > Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH) 
 > 
 > 
 >Initialize "Pkg.dir()" as a package directory. This will be done 
 >automatically when the "JULIA_PKGDIR" is not set and 
 >"Pkg.dir()" uses its default value. As part of this process, 
 >clones a local METADATA git repository from the site and branch 
 >specified by its arguments, which are typically not provided. 
 >Explicit (non-default) arguments can be used to support a custom 
 >METADATA setup. 
 > 
 > 
 > julia> 
 > 
 > *Julia 0.4* 
 > 
 > 
 > 
 > 
 > *julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> * 

Re: [julia-users] Re: IDE for Julia

[Mike Innes]

Hey folks,

If you're interested in Juno/Atom you might like to check out the demos
 I just published which give an idea
of some of the UI work we've done so far. Like any tool, Atom certainly
isn't going to be Everybody's Everything, but you might be pleasantly
surprised how far we can push it towards being a fully-featured IDE.
(Although really, the core utility of the IDE is not so much the flashy ui
bits so much as the improved workflow it enables – more on that here

).

Alternative approaches are welcome and even encouraged, but I really think
that Atom provides the fastest route to a high-quality Julia IDE – and if
you want to speed that along even more, it's well worth poking around in
the code to see where you can make improvements. It's pretty easy to get
into and we're more than happy to help out where we can.

Quick meta-note about this thread: I think it's important to emphasise that
the julia-users list isn't designed to handle this kind of open-ended
discussion. It's not that discussion is bad per se, but this list has a lot
of subscribers who are mostly interested in sharply-focused technical
issues – usually announcements or giving and receiving help. Topics that
involve, say, debating the merits of various technologies are better suited
to platforms such as reddit with features like comment threads for
tangents, more focused notifications for other users, etc.

– Mike

On Thu, 17 Sep 2015 at 15:24 Daniel Carrera  wrote:

> On 17 September 2015 at 15:57, Kristoffer Carlsson 
> wrote:
>
>> Look up GitSavy if you want git integration in Sublime.
>>
>> I guess different people have different tolerances to latency. I try atom
>> over and over because it is open source and I want it to be the best but
>> everytime it feels like running through syrup.
>
>
>
> It might also depend on our use case. For instance, I never close Atom, so
> I wouldn't notice if it is slow to start up. Maybe I also have smaller or
> fiewer files than you do.
>
> Cheers,
> Daniel.
>
>
>

Re: [julia-users] Re: Help me understand counterintuitive result with type delcaration

[Stefan Karpinski]

https://github.com/JuliaLang/julia/issues/13186

On Thu, Sep 17, 2015 at 11:17 AM, Stefan Karpinski 
wrote:

> Which, of course, doesn't catch cases where the identifier is on the next
> line rather than separated by a literal semicolon.
>
> On Thu, Sep 17, 2015 at 11:10 AM, Stefan Karpinski 
> wrote:
>
>> Do you really? I just ran this regex r"^\s*(\w+)\s*=.*;\s*\1\s*$" on
>> Julia's code base and all .jl files in all the packages I have installed
>> for both 0.3 and 0.4 and there are zero matches.
>>
>>
>> On Wed, Sep 16, 2015 at 5:52 PM, Scott Jones 
>> wrote:
>>
>>> This is why you see frequently in Julia functions:
>>> x = expr ; x
>>>
>>>
>>>
>>> On Wednesday, September 16, 2015 at 5:25:15 PM UTC-4, g wrote:

 That makes a lot of sense, thanks.

 On Wednesday, September 16, 2015 at 2:22:54 PM UTC-6, Spencer Russell
 wrote:
>
> There’s an issue where Jeff describes the reasoning here:
> https://github.com/JuliaLang/julia/issues/5532
>
> On Sep 16, 2015, at 3:57 PM, j verzani  wrote:
>
> The return value of the function is value of the last expression
> evaluated. For assignment, the right-hand side is always returned. So in
> `f` you get the value x*2.0 returned which is 2.0.
>
> On Wednesday, September 16, 2015 at 3:41:22 PM UTC-4, g wrote:
>>
>> I was playing around with type declarations and came across an
>> counterintuitive result. I'm not sure if this is the intended behavior or
>> not, but it certainly surprised me.
>>
>> Consider the functions
>>
>> *function f(x)*
>>
>>*y::Int*
>>
>>*y=x*2.0*
>>
>> *end*
>>
>> *function g(x)*
>>
>>*y::Int*
>>
>>*y=x*2.0*
>>
>>*y*
>>
>> *end*
>>
>> *julia> **f(1),g(1)*
>>
>> *(2.0,2)*
>>
>> I expected them to behave identically, always returning an Int. But
>> clearly f returns a Float64.
>>
>>
>> It seems like in the presence of the type delaration y=x*2.0 is
>> interpreted as
>>
>> temp=x*2.0
>>
>> y=Int(temp)
>>
>> temp
>>
>> is that right?
>>
>
>
>>
>

Re: [julia-users] Re: Help me understand counterintuitive result with type delcaration

[Stefan Karpinski]

Which, of course, doesn't catch cases where the identifier is on the next
line rather than separated by a literal semicolon.

On Thu, Sep 17, 2015 at 11:10 AM, Stefan Karpinski 
wrote:

> Do you really? I just ran this regex r"^\s*(\w+)\s*=.*;\s*\1\s*$" on
> Julia's code base and all .jl files in all the packages I have installed
> for both 0.3 and 0.4 and there are zero matches.
>
>
> On Wed, Sep 16, 2015 at 5:52 PM, Scott Jones 
> wrote:
>
>> This is why you see frequently in Julia functions:
>> x = expr ; x
>>
>>
>>
>> On Wednesday, September 16, 2015 at 5:25:15 PM UTC-4, g wrote:
>>>
>>> That makes a lot of sense, thanks.
>>>
>>> On Wednesday, September 16, 2015 at 2:22:54 PM UTC-6, Spencer Russell
>>> wrote:

 There’s an issue where Jeff describes the reasoning here:
 https://github.com/JuliaLang/julia/issues/5532

 On Sep 16, 2015, at 3:57 PM, j verzani  wrote:

 The return value of the function is value of the last expression
 evaluated. For assignment, the right-hand side is always returned. So in
 `f` you get the value x*2.0 returned which is 2.0.

 On Wednesday, September 16, 2015 at 3:41:22 PM UTC-4, g wrote:
>
> I was playing around with type declarations and came across an
> counterintuitive result. I'm not sure if this is the intended behavior or
> not, but it certainly surprised me.
>
> Consider the functions
>
> *function f(x)*
>
>*y::Int*
>
>*y=x*2.0*
>
> *end*
>
> *function g(x)*
>
>*y::Int*
>
>*y=x*2.0*
>
>*y*
>
> *end*
>
> *julia> **f(1),g(1)*
>
> *(2.0,2)*
>
> I expected them to behave identically, always returning an Int. But
> clearly f returns a Float64.
>
>
> It seems like in the presence of the type delaration y=x*2.0 is
> interpreted as
>
> temp=x*2.0
>
> y=Int(temp)
>
> temp
>
> is that right?
>


>

Re: [julia-users] Re: Help me understand counterintuitive result with type delcaration

[Stefan Karpinski]

Do you really? I just ran this regex r"^\s*(\w+)\s*=.*;\s*\1\s*$" on
Julia's code base and all .jl files in all the packages I have installed
for both 0.3 and 0.4 and there are zero matches.

On Wed, Sep 16, 2015 at 5:52 PM, Scott Jones 
wrote:

> This is why you see frequently in Julia functions:
> x = expr ; x
>
>
>
> On Wednesday, September 16, 2015 at 5:25:15 PM UTC-4, g wrote:
>>
>> That makes a lot of sense, thanks.
>>
>> On Wednesday, September 16, 2015 at 2:22:54 PM UTC-6, Spencer Russell
>> wrote:
>>>
>>> There’s an issue where Jeff describes the reasoning here:
>>> https://github.com/JuliaLang/julia/issues/5532
>>>
>>> On Sep 16, 2015, at 3:57 PM, j verzani  wrote:
>>>
>>> The return value of the function is value of the last expression
>>> evaluated. For assignment, the right-hand side is always returned. So in
>>> `f` you get the value x*2.0 returned which is 2.0.
>>>
>>> On Wednesday, September 16, 2015 at 3:41:22 PM UTC-4, g wrote:

 I was playing around with type declarations and came across an
 counterintuitive result. I'm not sure if this is the intended behavior or
 not, but it certainly surprised me.

 Consider the functions

 *function f(x)*

*y::Int*

*y=x*2.0*

 *end*

 *function g(x)*

*y::Int*

*y=x*2.0*

*y*

 *end*

 *julia> **f(1),g(1)*

 *(2.0,2)*

 I expected them to behave identically, always returning an Int. But
 clearly f returns a Float64.


 It seems like in the presence of the type delaration y=x*2.0 is
 interpreted as

 temp=x*2.0

 y=Int(temp)

 temp

 is that right?

>>>
>>>

Re: [julia-users] Re: IDE for Julia

[Daniel Carrera]

On 17 September 2015 at 15:57, Kristoffer Carlsson 
wrote:

> Look up GitSavy if you want git integration in Sublime.
>
> I guess different people have different tolerances to latency. I try atom
> over and over because it is open source and I want it to be the best but
> everytime it feels like running through syrup.



It might also depend on our use case. For instance, I never close Atom, so
I wouldn't notice if it is slow to start up. Maybe I also have smaller or
fiewer files than you do.

Cheers,
Daniel.

Re: [julia-users] Re: IDE for Julia

[Kristoffer Carlsson]

Look up GitSavy if you want git integration in Sublime.

I guess different people have different tolerances to latency. I try atom over 
and over because it is open source and I want it to be the best but everytime 
it feels like running through syrup. 

Re: [julia-users] Overloading a function with type not compiled yet

[Yichao Yu]

On Thu, Sep 17, 2015 at 9:45 AM,   wrote:
>> function f{T}(sl::Array{T})
>> .
>> end
>
>
> Worked like a charm, thank you.
> I don't really get why though, what mechanism prevents Julia to use the
> first version now?

The reason is what Tom said. In julia ParameterizedType{A} is not a
subtype of ParametrizedType{B} even if A <: B (i.e. A is a subtype of
B) (with Tuple as the only exception now) See doc [1] (in particular
the bold note following "the last point is very important").

In your example, you specify f(sl::Array{Any}) to be applicable to sl
of type `Array{Any}`. However, the argument you supply is of type
`Array{state}` which is not a subtype of `Array{Any}` so the method is
not applicable. On the other hand, with `f{T}(sl::Array{T})`, the
method matches when `T == state`.

[1] 
http://julia.readthedocs.org/en/latest/manual/types/#parametric-composite-types

> Does it look at all the available functions called f and see if one is
> better suited, is likely to produce an error of some sort, something else?

Re: [julia-users] Overloading a function with type not compiled yet

[Matt Bauman]

On Thursday, September 17, 2015 at 9:45:11 AM UTC-4, ami...@gmail.com wrote:
>
> I don't really get why though, what mechanism prevents Julia to use the 
> first version now?
> Does it look at all the available functions called f and see if one is 
> better suited, is likely to produce an error of some sort, something else?
>

This is called parametric invariance.  See here for more details: 
http://docs.julialang.org/en/release-0.4/manual/types/#parametric-composite-types

A type theorist will be able to tell you lots more, but on a practical 
level, it allows `Array{Int}` to be stored *differently* than an 
`Array{Any}`.  The latter is an array of pointers to other memory regions, 
whereas the former is just a contiguous chunk of raw `Int`s.  This is 
crucially important for fast numeric arrays and interop with BLAS and other 
C libraries.

Re: [julia-users] Emacs, ESS and julia-mode

[Stephen Eglen]

As one of the ESS developers, I will try and fix this with 0.4.  From quick 
inspection, it looks like I can get the same help from the command line 
using:


-

julia> Base.Docs.@repl pwd

search: pwd powermod print_with_color


  pwd() -> AbstractString


  Get the current working directory.

-


If that looks right, I'll try to add that.

On Thursday, September 17, 2015 at 2:33:29 PM UTC+1, Andrei Zh wrote:
>
> ESS mode's integration with Julia's REPL is quite simple and can't handle 
> special sequences. It's a pity that `help()` function has been removed from 
> 0.4, I didn't see it before your post.
>
> There was a discussion regarding better REPL (network REPL?) recently, but 
> AFAIK nobody is working on such solution yet.
>
>
> On Thursday, September 17, 2015 at 4:16:33 PM UTC+3, Michael Turok wrote:
>>
>> The issue is that ?Pkg.init isn't recognized either - is there some 
>> special REPL handling?
>>
>> julia> ?Pkg.init
>> ERROR: UndefVarError: ? not defined
>>
>>
>> julia> 
>>
>>
>> On Thursday, September 17, 2015 at 9:11:54 AM UTC-4, Mauro wrote:
>>>
>>> Well, help is not a function in 0.4 anymore.  Use ?Pkg.init 
>>>
>>> Can't help with the other ESS things.   I've tried it for a bit but it 
>>> introduced a noticeable lag so I switch back to just using julia-mode.el 
>>>
>>> On Thu, 2015-09-17 at 14:32, Michael Turok  wrote: 
>>> > Anyone here running julia under ESS in emacs? 
>>> > 
>>> > It seems that emacs's ess-mode for julia isn't quite as happy lately - 
>>> > especially with some changes in 0.4 (related to REPL changes, 
>>> possibly?).   
>>> > For example, help() doesn't do anything...perhaps b/c the REPL now 
>>> expects 
>>> > "?" to do something useful. 
>>> > 
>>> > Anyone have any suggestions?   (Or am I moving to atom+hydrogen later 
>>> > today?) 
>>> > 
>>> > *Julia 0.3:* 
>>> > julia> help(Pkg.init) 
>>> > Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH) 
>>> > 
>>> > 
>>> >Initialize "Pkg.dir()" as a package directory. This will be done 
>>> >automatically when the "JULIA_PKGDIR" is not set and 
>>> >"Pkg.dir()" uses its default value. As part of this process, 
>>> >clones a local METADATA git repository from the site and branch 
>>> >specified by its arguments, which are typically not provided. 
>>> >Explicit (non-default) arguments can be used to support a custom 
>>> >METADATA setup. 
>>> > 
>>> > 
>>> > julia> 
>>> > 
>>> > *Julia 0.4* 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > *julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> * 
>>>
>>>

Re: [julia-users] Emacs, ESS and julia-mode

[Tamas Papp]

Hi Michael,

I am using Emacs+ESS for Julia. Having asked about various issues on the
ESS list I was told to wait until the ESS internals are reorganized. I
am currently collecting fixes and workarounds in

https://github.com/tpapp/ESS-julia-extensions

, feel free to contribute.

That said, I believe that the future for integrating Emacs and Julia is
more along the lines of SLIME/CIDER (Swank/nREPL). The comint-based ESS
architecture is a bit archaic and cannot utilize the full power of Julia
easily. As soon as there is work on the Julia end (which I believe can
be shared among various interfaces), I will look into the Emacs
part.

Julia+Emacs integration comes up sporadically on this mailing list. I
wonder if interested parties could merge their efforts and come up with
something. My constraint is that even though I have some Lisp
experience, I am not an Emacs hacker, just a power user, so if I try to
do it alone it may be really slow.

Best,

Tamas

On Thu, Sep 17 2015, Michael Turok  wrote:

> Anyone here running julia under ESS in emacs?
>
> It seems that emacs's ess-mode for julia isn't quite as happy lately - 
> especially with some changes in 0.4 (related to REPL changes, possibly?).   
> For example, help() doesn't do anything...perhaps b/c the REPL now expects 
> "?" to do something useful.
>
> Anyone have any suggestions?   (Or am I moving to atom+hydrogen later 
> today?)
>
> *Julia 0.3:*
> julia> help(Pkg.init)
> Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH)
>
>
>Initialize "Pkg.dir()" as a package directory. This will be done
>automatically when the "JULIA_PKGDIR" is not set and
>"Pkg.dir()" uses its default value. As part of this process,
>clones a local METADATA git repository from the site and branch
>specified by its arguments, which are typically not provided.
>Explicit (non-default) arguments can be used to support a custom
>METADATA setup.
>
>
> julia> 
>
> *Julia 0.4*
>
>
>
>
> *julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> *

Re: [julia-users] Overloading a function with type not compiled yet

[amiksvi]

>
> function f{T}(sl::Array{T}) 
> . 
> end 
>

Worked like a charm, thank you.
I don't really get why though, what mechanism prevents Julia to use the 
first version now?
Does it look at all the available functions called f and see if one is 
better suited, is likely to produce an error of some sort, something else?

[julia-users] Re: Allowed module names

[Ján Dolinský]

Guys,

Thanks a lot, indeed, minus is a minus :).

Jan

Dňa štvrtok, 17. septembra 2015 15:19:18 UTC+2 Matt Bauman napísal(-a):
>
> On Thursday, September 17, 2015 at 9:09:45 AM UTC-4, Ján Dolinský wrote:
>>
>> Hello,
>>
>> Is a module name consisting of minus sign allowed ?
>> E.g. my-new-module
>>
>
> Module names follow the same rules as all identifiers do.  See here for 
> details: 
> http://docs.julialang.org/en/latest/manual/variables/?highlight=allowed#allowed-variable-names
>  
>

Re: [julia-users] Emacs, ESS and julia-mode

[Andrei Zh]

ESS mode's integration with Julia's REPL is quite simple and can't handle 
special sequences. It's a pity that `help()` function has been removed from 
0.4, I didn't see it before your post.

There was a discussion regarding better REPL (network REPL?) recently, but 
AFAIK nobody is working on such solution yet.


On Thursday, September 17, 2015 at 4:16:33 PM UTC+3, Michael Turok wrote:
>
> The issue is that ?Pkg.init isn't recognized either - is there some 
> special REPL handling?
>
> julia> ?Pkg.init
> ERROR: UndefVarError: ? not defined
>
>
> julia> 
>
>
> On Thursday, September 17, 2015 at 9:11:54 AM UTC-4, Mauro wrote:
>>
>> Well, help is not a function in 0.4 anymore.  Use ?Pkg.init 
>>
>> Can't help with the other ESS things.   I've tried it for a bit but it 
>> introduced a noticeable lag so I switch back to just using julia-mode.el 
>>
>> On Thu, 2015-09-17 at 14:32, Michael Turok  wrote: 
>> > Anyone here running julia under ESS in emacs? 
>> > 
>> > It seems that emacs's ess-mode for julia isn't quite as happy lately - 
>> > especially with some changes in 0.4 (related to REPL changes, 
>> possibly?).   
>> > For example, help() doesn't do anything...perhaps b/c the REPL now 
>> expects 
>> > "?" to do something useful. 
>> > 
>> > Anyone have any suggestions?   (Or am I moving to atom+hydrogen later 
>> > today?) 
>> > 
>> > *Julia 0.3:* 
>> > julia> help(Pkg.init) 
>> > Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH) 
>> > 
>> > 
>> >Initialize "Pkg.dir()" as a package directory. This will be done 
>> >automatically when the "JULIA_PKGDIR" is not set and 
>> >"Pkg.dir()" uses its default value. As part of this process, 
>> >clones a local METADATA git repository from the site and branch 
>> >specified by its arguments, which are typically not provided. 
>> >Explicit (non-default) arguments can be used to support a custom 
>> >METADATA setup. 
>> > 
>> > 
>> > julia> 
>> > 
>> > *Julia 0.4* 
>> > 
>> > 
>> > 
>> > 
>> > *julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> * 
>>
>>

Re: [julia-users] Re: IDE for Julia

[tony]

You're probably missing dependencies. Check the files in dependency walker. Or 
use the WinRPM.jl package which handles them automatically.



On Thu, Sep 17, 2015 at 6:06 AM -0700, "STAR0SS"  wrote:
Talking about GtkSourceView, shouldn't these binaries work on windows ?
They seems to be valid windows dll's but Julia
gives me a "The specified module could not be found." if I try to open them
with dlopen.

http://rpmfind.net/linux/rpm2html/search.php?query=mingw64%28libgtksourceview-3.0-1.dll%29&submit=Search+...&system=&arch=

http://rpmfind.net/linux/rpm2html/search.php?query=mingw32%28libgtksourceview-3.0-1.dll%29&submit=Search+...&system=&arch=

Re: [julia-users] Deprecation of require

[Christopher Fisher]

Thanks Michele. I found the file and I think I figured out part of the 
issue. 

If I understand correctly, I can 
use push!(LOAD_PATH,"/my/code/repository")  within my script instead of 
hard coding it into the .juliarc.jl file, which would only be useful if I 
want to search that directory every start up.  Is that true? 

On Thursday, September 17, 2015 at 8:31:14 AM UTC-4, Michele Zaffalon wrote:
>
> I answer your first question only:
>
>>
>> First, where can I find the .juliarc.jl file?
>>
>
> It's in the HOME directory. Alternatively in Windows in the directory 
> pointed to by HOMEDRIVE\HOMEPATH
>
>
>> Second, is there an easier way to load a .jl file from my working 
>> directory into Julia onto a local computer or cluster of computers that 
>> does not require editing the .juliarc.fil file? (Editing this file for 
>> every project seems a little inconvenient). 
>>
>> Third, will the code loaded from a .jl  always be precompiled in .4? If 
>> not, how do I choose whether it is precompiled or not?
>>
>> Thanks in advance (and my apologies for the basic questions;I'm not a 
>> programmer per se)
>>
>> Chris 
>>
>> On Friday, July 31, 2015 at 7:30:44 AM UTC-4, Tim Holy wrote:
>>>
>>> If MyModule.jl is on your LOAD_PATH, 
>>>
>>> @everywhere import MyModule 
>>>
>>> should work. You can add 
>>>
>>> push!(LOAD_PATH,"/my/code/repository") 
>>>
>>> to your .juliarc.jl file. 
>>>
>>> This has been deprecated because of precompilation; it was felt that the 
>>> string version left it too ambiguous about whether you wanted to load 
>>> the raw 
>>> file or the cached version. 
>>>
>>> Best, 
>>> --Tim 
>>>
>>> On Thursday, July 23, 2015 11:58:58 AM Eduardo Lenz wrote: 
>>> > Hi 
>>> > I just downloaded the last nightly build  and I am receiving a new 
>>> > deprecation message: 
>>> > 
>>> > Warning, "require" is deprecated, use "using" or "import" instead. 
>>> > 
>>> > My question is: I am using "require" due to the need to automatically 
>>> > import these functions for all workers in a cluster. As long as I 
>>> know, to 
>>> > accomplish this task I have to use "require" and also provide the 
>>> correct 
>>> > path of the corresponding .jl files. How can I do this same thing 
>>> using 
>>> > "using" or "import" ? I tried to use it as I was using "require" and 
>>> it is 
>>> > not working as expected. 
>>> > 
>>> > Thanks for your help and sorry for the dumb question. 
>>>
>>>
>

[julia-users] Re: Allowed module names

[Matt Bauman]

On Thursday, September 17, 2015 at 9:09:45 AM UTC-4, Ján Dolinský wrote:
>
> Hello,
>
> Is a module name consisting of minus sign allowed ?
> E.g. my-new-module
>

Module names follow the same rules as all identifiers do.  See here for 
details: 
http://docs.julialang.org/en/latest/manual/variables/?highlight=allowed#allowed-variable-names
 

Re: [julia-users] Allowed module names

[Yichao Yu]

On Thu, Sep 17, 2015 at 9:09 AM, Ján Dolinský  wrote:
> Hello,
>
> Is a module name consisting of minus sign allowed ?
> E.g. my-new-module
>
> typing
>
> using my-new-module
>
> results in an error
> ERROR: syntax: invalid "using" statement

I think is allowed at AST level (i.e. when you manually construct an
AST with `symbol("my-new-module")` in it) but otherwise the parser
would limit it to the allowed identifier names[1].

[1] 
http://julia.readthedocs.org/en/latest/manual/variables/#allowed-variable-names

>
> Thanks a lot,
> Jan

Re: [julia-users] Allowed module names

[Mauro]

No, a minus is a minus

On Thu, 2015-09-17 at 15:09, Ján Dolinský  wrote:
> Hello,
>
> Is a module name consisting of minus sign allowed ?
> E.g. my-new-module
>
> typing 
>
> using my-new-module
>
> results in an error
> ERROR: syntax: invalid "using" statement
>
> Thanks a lot,
> Jan

Re: [julia-users] Emacs, ESS and julia-mode

[Michael Turok]

The issue is that ?Pkg.init isn't recognized either - is there some special 
REPL handling?

julia> ?Pkg.init
ERROR: UndefVarError: ? not defined


julia> 


On Thursday, September 17, 2015 at 9:11:54 AM UTC-4, Mauro wrote:
>
> Well, help is not a function in 0.4 anymore.  Use ?Pkg.init 
>
> Can't help with the other ESS things.   I've tried it for a bit but it 
> introduced a noticeable lag so I switch back to just using julia-mode.el 
>
> On Thu, 2015-09-17 at 14:32, Michael Turok  > wrote: 
> > Anyone here running julia under ESS in emacs? 
> > 
> > It seems that emacs's ess-mode for julia isn't quite as happy lately - 
> > especially with some changes in 0.4 (related to REPL changes, 
> possibly?).   
> > For example, help() doesn't do anything...perhaps b/c the REPL now 
> expects 
> > "?" to do something useful. 
> > 
> > Anyone have any suggestions?   (Or am I moving to atom+hydrogen later 
> > today?) 
> > 
> > *Julia 0.3:* 
> > julia> help(Pkg.init) 
> > Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH) 
> > 
> > 
> >Initialize "Pkg.dir()" as a package directory. This will be done 
> >automatically when the "JULIA_PKGDIR" is not set and 
> >"Pkg.dir()" uses its default value. As part of this process, 
> >clones a local METADATA git repository from the site and branch 
> >specified by its arguments, which are typically not provided. 
> >Explicit (non-default) arguments can be used to support a custom 
> >METADATA setup. 
> > 
> > 
> > julia> 
> > 
> > *Julia 0.4* 
> > 
> > 
> > 
> > 
> > *julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> * 
>
>

Re: [julia-users] Emacs, ESS and julia-mode

[Mauro]

Well, help is not a function in 0.4 anymore.  Use ?Pkg.init

Can't help with the other ESS things.   I've tried it for a bit but it
introduced a noticeable lag so I switch back to just using julia-mode.el

On Thu, 2015-09-17 at 14:32, Michael Turok  wrote:
> Anyone here running julia under ESS in emacs?
>
> It seems that emacs's ess-mode for julia isn't quite as happy lately - 
> especially with some changes in 0.4 (related to REPL changes, possibly?).   
> For example, help() doesn't do anything...perhaps b/c the REPL now expects 
> "?" to do something useful.
>
> Anyone have any suggestions?   (Or am I moving to atom+hydrogen later 
> today?)
>
> *Julia 0.3:*
> julia> help(Pkg.init)
> Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH)
>
>
>Initialize "Pkg.dir()" as a package directory. This will be done
>automatically when the "JULIA_PKGDIR" is not set and
>"Pkg.dir()" uses its default value. As part of this process,
>clones a local METADATA git repository from the site and branch
>specified by its arguments, which are typically not provided.
>Explicit (non-default) arguments can be used to support a custom
>METADATA setup.
>
>
> julia> 
>
> *Julia 0.4*
>
>
>
>
> *julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> *

[julia-users] Allowed module names

[Ján Dolinský]

Hello,

Is a module name consisting of minus sign allowed ?
E.g. my-new-module

typing 

using my-new-module

results in an error
ERROR: syntax: invalid "using" statement

Thanks a lot,
Jan

Re: [julia-users] Re: Overloading a function with type not compiled yet

[Tom Breloff]

The ordering of includes isn't your problem.  It's that Array{state} is NOT
a subtype of Array{Any}   Jeff will be able to explain that reasoning
better than I can.  Try:

julia> type state
>x
>y
>z
>end
> julia> s1 = state(1.0, 5.0, 7.0)
> state(1.0,5.0,7.0)
> julia> s2 = state(2.0, 6.0, 8.0)
> state(2.0,6.0,8.0)
> julia> sl = [s1, s2]
> 2-element Array{state,1}:
>  state(1.0,5.0,7.0)
>  state(2.0,6.0,8.0)
> julia> f(s) = "first version"
> f (generic function with 1 method)
> julia> f(sl)
> "first version"
> julia> f(sl::Array{Any}) = "second version"
> f (generic function with 2 methods)
> julia> f(sl)
> "first version"
> julia> f(sl::Array{state}) = "this is probably what you want"
> f (generic function with 3 methods)
> julia> f(sl)
> "this is probably what you want"



On Thu, Sep 17, 2015 at 8:24 AM,  wrote:

> And of course I can't include my_type.jl before my_module.jl and specify
> the types in the function f(s::state) or f(sl::Array{state}), because in
> the real case I use a lot of things inside my_type.jl from my_module.jl...
>

[julia-users] Re: IDE for Julia

[STAR0SS]

Talking about GtkSourceView, shouldn't these binaries work on windows ? 
They seems to be valid windows dll's but Julia
gives me a "The specified module could not be found." if I try to open them 
with dlopen.

http://rpmfind.net/linux/rpm2html/search.php?query=mingw64%28libgtksourceview-3.0-1.dll%29&submit=Search+...&system=&arch=

http://rpmfind.net/linux/rpm2html/search.php?query=mingw32%28libgtksourceview-3.0-1.dll%29&submit=Search+...&system=&arch=

Re: [julia-users] Overloading a function with type not compiled yet

[Yichao Yu]

On Thu, Sep 17, 2015 at 8:21 AM,   wrote:
> Hi,
>
> I have a module with a function that I'd like to be overloaded, one version
> should take as an argument a type that I declare somewhere else and later
> (i.e. this module is required before the argument type) and another version
> should be an Array of such a type. That's the idea.
>
> Simple example: I have three files.
>
> In my_module.jl:
>
> function f(s)
> println(s.x)
> end
>
> function f(sl::Array{Any})
> for s in sl
> f(s)
> end
> end

function f{T}(sl::Array{T})
.
end

>
> In my_type.jl:
>
> type state
> x
> y
> z
> end
>
> In my_main.jl:
>
> include("my_module.jl")
> include("my_type.jl")
>
> s1 = state(1.0, 5.0, 7.0)
> s2 = state(2.0, 6.0, 8.0)
> sl = [s1, s2]
>
> println("f(s1)")
> f(s1)
> println("f(s2)")
> f(s2)
> println("f(sl)")
> f(sl)
>
> If I run: julia my_main.jl
> I get this error: "ERROR: type Array has no field x" because it uses the
> first version of the function, nothing prevents it indeed.
>
> I would like to find a way to make it understand it has to choose the second
> version of the function. How could I do that?
>
> Thanks a lot,

[julia-users] Re: Sharing a typealias among two or more packages

[Ján Dolinský]

Indeed :). Thanks.

Jan

Dňa štvrtok, 17. septembra 2015 14:26:45 UTC+2 Ján Dolinský napísal(-a):
>
> Hi,
>
> Is it possible to share a user defined type alias among two or more 
> modules ?
>
> E.g. I define the following typealias in a moduleA as follows:
> if haskey(ENV, "USE_FLOAT32") && ENV["USE_FLOAT32"] == "1"
>   typealias UserFloat Float32
> else
>   typealias UserFloat Float64
> end
>
> I would like moduleB to know what "UserFloat" defined in moduleA means.
>
> Can I do in moduleB e.g.
>
> module moduleB
>
> using moduleA
> moduleA.UserFloat 
>
> end
>
> Thanks,
> Jan
>

Re: [julia-users] Re: IDE for Julia

[Spencer Russell]

I agree that Atom has some speed issues. With so much buy-in though I'm
hoping that things get better on that front.

Also be careful about what packages you have installed. Atom makes
it really easy to subscribe to events on things like cursor moves,
which can slow things down a lot if packages do any heavy lifting in
those events.

I think the web tech in Atom is a net win as it makes it much easier to
get people involved building packages and gives a nice path to
customization, but I think that speed is definitely a trade-off right
now. That said I'm using Atom daily now and pretty excited about it.

-s


On Thu, Sep 17, 2015, at 08:49 AM, Daniel Carrera wrote:
> On 17 September 2015 at 14:17, Kristoffer Carlsson
>  wrote:
>> It was just an example. Everything is slow, startup is slow, marking
>> text lags behind the cursor, even pressing Ctrl + Shift + P has a
>> noticeable delay. When you are used to something like Sublime where
>> everything is instantaneous it is basically unusable.
>
> But I *did* come from Sublime, and I honestly don't notice the delays
> you are talking about. Marking text lags behind the cursor? Really?
> I'm trying it right now and I just can't reproduce it. I loved
> Sublime, but I felt that Atom was better (I was sold on the Git
> integration).
>
>
>> And yes, the fact that if you want to look in a log file means you
>> have to start up another text editor is also frankly embarrasing.
>
>
> What? Why would I be looking at log files in an editor? I use `less`
> or `grep` when I need to look at a log file. If I'm looking at log
> files, chances are that I am also at a terminal, and the natural thing
> for me to do is to use standard commands like less, grep, gawk, sed
> and similar. When I was using Sublime, I never once thought to open a
> log file in Sublime. It just seems so much less efficient than
> less/grep.
>
> Cheers, Daniel.

Re: [julia-users] Re: IDE for Julia

[Daniel Carrera]

On 17 September 2015 at 14:57, Tom Breloff  wrote:

> Now that Sublime has been mentioned a couple times... that's what I use
> exclusively now.  I do all my code in Sublime Text 3, and then have a
> separate window with a julia prompt and a terminal which I do any
> git-stuff.
>
> My question... can anyone convince me why I should switch to Atom?
> Everyone seems to talk about it as the only viable option... what am I
> missing?
>


For me Atom is only a small epsilon improvement on Sublime. I chose it
because it has Git integration and because it is open source. That's it.
Besides that, everything awesome and great about Atom was directly copied
from Sublime.

Oh, and it's easier to give Atom to your non-computer-savy friend because
Atom has a GUI way to change settings.

Cheers,
Daniel.

Re: [julia-users] Sharing a typealias among two or more packages

[Tom Breloff]

export it?

julia> module B; export MyInt; typealias MyInt Int; end
> B
> julia> module A; using B; println("I can see $MyInt"); end
> I can see Int64
> A



On Thu, Sep 17, 2015 at 8:26 AM, Ján Dolinský 
wrote:

> Hi,
>
> Is it possible to share a user defined type alias among two or more
> modules ?
>
> E.g. I define the following typealias in a moduleA as follows:
> if haskey(ENV, "USE_FLOAT32") && ENV["USE_FLOAT32"] == "1"
>   typealias UserFloat Float32
> else
>   typealias UserFloat Float64
> end
>
> I would like moduleB to know what "UserFloat" defined in moduleA means.
>
> Can I do in moduleB e.g.
>
> module moduleB
>
> using moduleA
> moduleA.UserFloat
>
> end
>
> Thanks,
> Jan
>

Re: [julia-users] Re: IDE for Julia

[Tom Breloff]

Now that Sublime has been mentioned a couple times... that's what I use
exclusively now.  I do all my code in Sublime Text 3, and then have a
separate window with a julia prompt and a terminal which I do any
git-stuff.

My question... can anyone convince me why I should switch to Atom?
Everyone seems to talk about it as the only viable option... what am I
missing?

On Thu, Sep 17, 2015 at 8:49 AM, Daniel Carrera  wrote:

> On 17 September 2015 at 14:17, Kristoffer Carlsson 
> wrote:
>
>> It was just an example. Everything is slow, startup is slow, marking text
>> lags behind the cursor, even pressing Ctrl + Shift + P has a
>> noticeable delay. When you are used to something like Sublime where
>> everything is instantaneous it is basically unusable.
>>
>
> But I *did* come from Sublime, and I honestly don't notice the delays you
> are talking about. Marking text lags behind the cursor? Really? I'm trying
> it right now and I just can't reproduce it. I loved Sublime, but I felt
> that Atom was better (I was sold on the Git integration).
>
>
>
>> And yes, the fact that if you want to look in a log file means you have
>> to start up another text editor is also frankly embarrasing.
>>
>
>
> What? Why would I be looking at log files in an editor? I use `less` or
> `grep` when I need to look at a log file. If I'm looking at log files,
> chances are that I am also at a terminal, and the natural thing for me to
> do is to use standard commands like less, grep, gawk, sed and similar. When
> I was using Sublime, I never once thought to open a log file in Sublime. It
> just seems so much less efficient than less/grep.
>
> Cheers,
> Daniel.
>

Re: [julia-users] Re: printing UInt displays hex instead of decimal

[Tom Breloff]

If I understand correctly, the "returned value" is really calling this:

function display(d::REPLDisplay, ::MIME"text/plain", x)
> io = outstream(d.repl)
> Base.have_color && write(io, answer_color(d.repl))
> writemime(io, MIME("text/plain"), x)
> println(io)
> end
> display(d::REPLDisplay, x) = display(d, MIME("text/plain"), x)


So there is a quick way to short-circuit the displayed value (without
changing Base for everyone else):

julia> x = one(UInt8)
> 0x01
> julia> Base.display(d::Base.REPL.REPLDisplay, x::Unsigned) = println(x)
> display (generic function with 11 methods)
> julia> x
> 1


 The nicest solution (IMO) is letting a user turn on/off this functionality
dynamically for whatever types they want, and setting display format easily
for a session.  I think all this belongs in Formatting, not in Base.

On Thu, Sep 17, 2015 at 8:16 AM, Sisyphuss  wrote:

> This is not "printing" but "returned value"
> Try `a[1]`, you get 0x0001
> Try `print(a[1])`, you get 1
>
> So overload `print` if ever needed.
>
>
> On Wednesday, September 16, 2015 at 11:34:33 PM UTC+2,
> holocro...@gmail.com wrote:
>>
>> In Julia 0.4rc1, when I create a UInt, either as an individual value or
>> array, and then print it hex values are usually displayed instead of
>> decimals. I say 'usually' because the behavior changes a bit between REPL
>> and
>>
>> For instance:
>>
>> julia> a = UInt[1 2 3 4]
>> 1x4 Array{UInt64,2}:
>>  0x0001  0x0002  …  0x0004
>>
>> This annoys me because 98% of the time I want the decimal representation.
>> Decimal is shown for Int, so why is hex the default for UInt? Is it a bug?
>>
>

Re: [julia-users] Re: IDE for Julia

[Daniel Carrera]

On 17 September 2015 at 14:17, Kristoffer Carlsson 
wrote:

> It was just an example. Everything is slow, startup is slow, marking text
> lags behind the cursor, even pressing Ctrl + Shift + P has a
> noticeable delay. When you are used to something like Sublime where
> everything is instantaneous it is basically unusable.
>

But I *did* come from Sublime, and I honestly don't notice the delays you
are talking about. Marking text lags behind the cursor? Really? I'm trying
it right now and I just can't reproduce it. I loved Sublime, but I felt
that Atom was better (I was sold on the Git integration).



> And yes, the fact that if you want to look in a log file means you have to
> start up another text editor is also frankly embarrasing.
>


What? Why would I be looking at log files in an editor? I use `less` or
`grep` when I need to look at a log file. If I'm looking at log files,
chances are that I am also at a terminal, and the natural thing for me to
do is to use standard commands like less, grep, gawk, sed and similar. When
I was using Sublime, I never once thought to open a log file in Sublime. It
just seems so much less efficient than less/grep.

Cheers,
Daniel.

[julia-users] Emacs, ESS and julia-mode

[Michael Turok]

Anyone here running julia under ESS in emacs?

It seems that emacs's ess-mode for julia isn't quite as happy lately - 
especially with some changes in 0.4 (related to REPL changes, possibly?).   
For example, help() doesn't do anything...perhaps b/c the REPL now expects 
"?" to do something useful.

Anyone have any suggestions?   (Or am I moving to atom+hydrogen later 
today?)

*Julia 0.3:*
julia> help(Pkg.init)
Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH)


   Initialize "Pkg.dir()" as a package directory. This will be done
   automatically when the "JULIA_PKGDIR" is not set and
   "Pkg.dir()" uses its default value. As part of this process,
   clones a local METADATA git repository from the site and branch
   specified by its arguments, which are typically not provided.
   Explicit (non-default) arguments can be used to support a custom
   METADATA setup.


julia> 

*Julia 0.4*




*julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> *

Re: [julia-users] Deprecation of require

[Michele Zaffalon]

I answer your first question only:

>
> First, where can I find the .juliarc.jl file?
>

It's in the HOME directory. Alternatively in Windows in the directory
pointed to by HOMEDRIVE\HOMEPATH


> Second, is there an easier way to load a .jl file from my working
> directory into Julia onto a local computer or cluster of computers that
> does not require editing the .juliarc.fil file? (Editing this file for
> every project seems a little inconvenient).
>
> Third, will the code loaded from a .jl  always be precompiled in .4? If
> not, how do I choose whether it is precompiled or not?
>
> Thanks in advance (and my apologies for the basic questions;I'm not a
> programmer per se)
>
> Chris
>
> On Friday, July 31, 2015 at 7:30:44 AM UTC-4, Tim Holy wrote:
>>
>> If MyModule.jl is on your LOAD_PATH,
>>
>> @everywhere import MyModule
>>
>> should work. You can add
>>
>> push!(LOAD_PATH,"/my/code/repository")
>>
>> to your .juliarc.jl file.
>>
>> This has been deprecated because of precompilation; it was felt that the
>> string version left it too ambiguous about whether you wanted to load the
>> raw
>> file or the cached version.
>>
>> Best,
>> --Tim
>>
>> On Thursday, July 23, 2015 11:58:58 AM Eduardo Lenz wrote:
>> > Hi
>> > I just downloaded the last nightly build  and I am receiving a new
>> > deprecation message:
>> >
>> > Warning, "require" is deprecated, use "using" or "import" instead.
>> >
>> > My question is: I am using "require" due to the need to automatically
>> > import these functions for all workers in a cluster. As long as I know,
>> to
>> > accomplish this task I have to use "require" and also provide the
>> correct
>> > path of the corresponding .jl files. How can I do this same thing using
>> > "using" or "import" ? I tried to use it as I was using "require" and it
>> is
>> > not working as expected.
>> >
>> > Thanks for your help and sorry for the dumb question.
>>
>>

[julia-users] Sharing a typealias among two or more packages

[Ján Dolinský]

Hi,

Is it possible to share a user defined type alias among two or more modules 
?

E.g. I define the following typealias in a moduleA as follows:
if haskey(ENV, "USE_FLOAT32") && ENV["USE_FLOAT32"] == "1"
  typealias UserFloat Float32
else
  typealias UserFloat Float64
end

I would like moduleB to know what "UserFloat" defined in moduleA means.

Can I do in moduleB e.g.

module moduleB

using moduleA
moduleA.UserFloat 

end

Thanks,
Jan

[julia-users] Re: Overloading a function with type not compiled yet

[amiksvi]

And of course I can't include my_type.jl before my_module.jl and specify 
the types in the function f(s::state) or f(sl::Array{state}), because in 
the real case I use a lot of things inside my_type.jl from my_module.jl...

[julia-users] Overloading a function with type not compiled yet

[amiksvi]

Hi,

I have a module with a function that I'd like to be overloaded, one version 
should take as an argument a type that I declare somewhere else and later 
(i.e. this module is required before the argument type) and another version 
should be an Array of such a type. That's the idea.

Simple example: I have three files.

In my_module.jl:

function f(s)
println(s.x)
end

function f(sl::Array{Any})
for s in sl
f(s)
end
end

In my_type.jl:

type state
x
y
z
end

In my_main.jl:

include("my_module.jl")
include("my_type.jl")

s1 = state(1.0, 5.0, 7.0)
s2 = state(2.0, 6.0, 8.0)
sl = [s1, s2]

println("f(s1)")
f(s1)
println("f(s2)")
f(s2)
println("f(sl)")
f(sl)

If I run: julia my_main.jl
I get this error: "ERROR: type Array has no field x" because it uses the 
first version of the function, nothing prevents it indeed.

I would like to find a way to make it understand it has to choose the 
second version of the function. How could I do that?

Thanks a lot,

Re: [julia-users] Deprecation of require

[Christopher Fisher]

I am using .4.0-rc1 and have encountered a similar situation and have 
fairly basic questions about the way .4 loads files. I normally use require 
to load a file of functions from my working directory in to Julia on a 
local computer or a cluster of computers. I was hoping someone would be 
willing to answer a few related questions. 

First, where can I find the .juliarc.jl file?

Second, is there an easier way to load a .jl file from my working directory 
into Julia onto a local computer or cluster of computers that does not 
require editing the .juliarc.fil file? (Editing this file for every project 
seems a little inconvenient). 

Third, will the code loaded from a .jl  always be precompiled in .4? If 
not, how do I choose whether it is precompiled or not?

Thanks in advance (and my apologies for the basic questions;I'm not a 
programmer per se)

Chris 

On Friday, July 31, 2015 at 7:30:44 AM UTC-4, Tim Holy wrote:
>
> If MyModule.jl is on your LOAD_PATH, 
>
> @everywhere import MyModule 
>
> should work. You can add 
>
> push!(LOAD_PATH,"/my/code/repository") 
>
> to your .juliarc.jl file. 
>
> This has been deprecated because of precompilation; it was felt that the 
> string version left it too ambiguous about whether you wanted to load the 
> raw 
> file or the cached version. 
>
> Best, 
> --Tim 
>
> On Thursday, July 23, 2015 11:58:58 AM Eduardo Lenz wrote: 
> > Hi 
> > I just downloaded the last nightly build  and I am receiving a new 
> > deprecation message: 
> > 
> > Warning, "require" is deprecated, use "using" or "import" instead. 
> > 
> > My question is: I am using "require" due to the need to automatically 
> > import these functions for all workers in a cluster. As long as I know, 
> to 
> > accomplish this task I have to use "require" and also provide the 
> correct 
> > path of the corresponding .jl files. How can I do this same thing using 
> > "using" or "import" ? I tried to use it as I was using "require" and it 
> is 
> > not working as expected. 
> > 
> > Thanks for your help and sorry for the dumb question. 
>
>

[julia-users] Re: ANN: Immerse package, and more videos on interactive plotting

[Kristoffer Carlsson]

Announcement

On Thursday, September 17, 2015 at 2:08:51 PM UTC+2, Jon Norberg wrote:
>
> What does the ANN: in the title mean?
>