[julia-users] DataFrames + RDatasets error

[km]

Dear  All,

I am using the following version of Julia  and trying to load iris dataset
from RDatasets package using Dataframes.
Do you think things are broken ?

_
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+5452 (2015-06-19 01:28 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 01293bd* (0 days old master)
|__/   |  x86_64-linux-gnu

julia> using
   RDatasets
Docile: upgrading cache to 0.0.1.

julia> using DataFrames

julia> iris = dataset("datasets","iris")
WARNING: gc_disable() is deprecated, use gc_enable(false) instead.
 in depwarn at ./deprecated.jl:62
 in gc_disable at deprecated.jl:49
 in close at /home/km/.julia/v0.4/GZip/src/GZip.jl:304
 in gzopen at /home/km/.julia/v0.4/GZip/src/GZip.jl:265
 in read_rda at /home/km/.julia/v0.4/DataFrames/src/RDA.jl:418
 in dataset at /home/km/.julia/v0.4/RDatasets/src/dataset.jl:6
while loading no file, in expression starting on line 0
WARNING: gc_enable() is deprecated, use gc_enable(true) instead.
 in depwarn at ./deprecated.jl:62
 in gc_enable at deprecated.jl:49
 in close at /home/km/.julia/v0.4/GZip/src/GZip.jl:310
 in gzopen at /home/km/.julia/v0.4/GZip/src/GZip.jl:265
 in read_rda at /home/km/.julia/v0.4/DataFrames/src/RDA.jl:418
 in dataset at /home/km/.julia/v0.4/RDatasets/src/dataset.jl:6
while loading no file, in expression starting on line 0
WARNING: gc_enable() is deprecated, use gc_enable(true) instead.error in
running finalizer: ErrorException("task switch not allowed from inside gc
finalizer")
150x5 DataFrames.DataFrame
| Row | SepalLength | SepalWidth | PetalLength | PetalWidth | Species |
|-|-||-||-|
| 1   | 5.1 | 3.5| 1.4 | 0.2| "setosa"|
| 2   | 4.9 | 3.0| 1.4 | 0.2| "setosa"|
| 3   | 4.7 | 3.2| 1.3 | 0.2| "setosa"|
| 4   | 4.6 | 3.1| 1.5 | 0.2| "setosa"|
...

 and then

julia> head(iris)
ERROR: MethodError: `getindex` has no method matching
getindex(::DataFrames.DataFrame, ::UnitRange{Int64}, ::Colon)
Closest candidates are:
  getindex{T<:Real}(::DataFrames.DataFrame, ::AbstractArray{T<:Real,1},
::Union{Real,Symbol})
  getindex{R<:Real,T<:Union{Real,Symbol}}(::DataFrames.DataFrame,
::AbstractArray{R<:Real,1}, ::AbstractArray{T<:Union{Real,Symbol},1})
  getindex{T<:Union{Real,Symbol}}(::DataFrames.DataFrame,
::AbstractArray{T<:Union{Real,Symbol},1})
  ...
 in head at
/home/km/.julia/v0.4/DataFrames/src/abstractdataframe/abstractdataframe.jl:316


Please let me know
Regards,
KM

Re: [julia-users] Tests failing on latest Julia

[Yichao Yu]

Maybe https://github.com/JuliaLang/julia/pull/10331 ? @mbauman ?

On Thu, Jun 18, 2015 at 11:28 PM, Júlio Hoffimann
 wrote:
> Hi,
>
> One of my packages is now failing tests due to some change in Julia, what
> exactly is the change that is causing the issue?
>
> http://pkg.julialang.org/?pkg=ImageQuilting&ver=nightly
>
> -Júlio

[julia-users] Tests failing on latest Julia

[Júlio Hoffimann]

Hi,

One of my packages is now failing tests due to some change in Julia, what 
exactly is the change that is causing the issue?

http://pkg.julialang.org/?pkg=ImageQuilting&ver=nightly

-Júlio

Re: [julia-users] inverse function error?

[David P. Sanders]

El jueves, 18 de junio de 2015, 22:18:48 (UTC+2), Mauro escribió:
>
> I don't know why Y does not get its type inferred correctly.  But you 
>

Array comprehensions in global scope never (?) have their types inferred.
You can try putting the array comprehension inside a 
function -- this may (or may not) help.

[Note that to avoid performance problems, you should in fact avoid as much
as possible having *anything* global -- everything should be in a function.]

David.
 

> can do: 
> eltype(df[2])[df[i,2] for i in 1:size(df,1)] 
>
> On Thu, 2015-06-18 at 20:21, SG > wrote: 
> > #= This line adds functions to take   
> >an AR(2) model for US inflation   
> > =# 
> >   
> > using DataFrames 
> >   
> > function lag0(x,p) 
> >  R::Int32=size(x,1) 
> >  C::Int32=size(x,2) 
> >   
> > # Take the first R-p rows of matrix x 
> >  x1=x[1:(R-p),:] 
> >  return out=[zeros(p,C); x1] 
> >   
> > end 
> >   
> >   
> > #load inflation datatable 
> > #df=readtable("inflation.csv") 
> >   
> > df=DataFrame() 
> > df[:A]=1:8 
> > df[:B]=10:17 
> >   
> > ## 
> > # Way of converting DataArray to Array  # 
> > ## 
> > Y=[df[i,2] for i in [1:size(df,1)]] 
> >   
> > ##  type of (Y) is now "Any"   
> >   
> >   
> > T=size(Y,1) 
> > X=[ones(T,1) lag0(Y,1) lag0(Y,2)] 
> > inv(X'*X) 
> > 
> > == 
> > 
> > Hi All, 
> > 
> > I am posting again the issue. I found when I create an Array as shown 
> > above, the type of Array 
> > changed to "Any" which is not acceptable for the base Inverse 
> function(an 
> > error occurred). 
> > I am wondering why Julia does not assume the type of original data, here 
> in 
> > the example, Int64. 
> > 
> > Many thanks, 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Thursday, June 18, 2015 at 7:23:16 PM UTC+2, SG wrote: 
> >> 
> >> Thank you, I will cut it down and post it again soon. 
> >> 
> >> On Thursday, June 18, 2015 at 7:01:16 PM UTC+2, Stefan Karpinski wrote: 
> >>> 
> >>> I think these sample programs may be too big for people to review for 
> >>> you. If you can pare the problem down to an example that can be posted 
> in 
> >>> an email, you've more likely to get help. 
> >>> 
> >>> On Thu, Jun 18, 2015 at 11:11 AM, SG  wrote: 
> >>> 
>  
>  Hi All, 
>  
>  I am a novice to Julia. 
>  
>  While I am running the attached julia program, I found "inverse" 
>  function throws an error? 
>  However it worked well in Matlab. Can you help me? Many thanks. 
>  
>  
>  
>  
> >>> 
>
>

Re: [julia-users] Overloading `eval`

[David P. Sanders]

Maybe you can name the function you need "evaluate", for example.

David.

El jueves, 18 de junio de 2015, 20:44:20 (UTC+2), Christoph Ortner escribió:
>
> ok - thank you for clarifying!
> Christoph
>
>

[julia-users] Re: iterate over rows of sparse matrix and get index of nonzeros?

[Jerzy Głowacki]

You can get non-zero indexes of a sparse matrix using find(sparseMatrix), 
then you can iterate over them.

[julia-users] Re: Building Julia from Source in Windows

[Tony Kelman]

See my reply at 
https://groups.google.com/forum/#!topic/julia-dev/RBJbuxqM1OQ


On Thursday, June 18, 2015 at 1:43:27 PM UTC-7, Sayeed Tasnim wrote:
>
> Hi,
>
>
> I’m trying to build Julia from source in Windows.  I’m following the 
> instructions described in the README.windows.md here:
>
> https://github.com/JuliaLang/julia/blob/master/README.windows.md
>
>
> However, I’m getting stuck on step 6.iv where I begin the build.  I get 
> the following error in msys: 
>
>  
>
> $ make -j 4
>
> /home/t-satasn-win8/julia/Make.inc:432: *** "cannot build julia with 
> msys-target compilers. please see the README.windows document for 
> instructions on setting
>
> up mingw-w64 compilers".  Stop.
>
>
> I noticed that the mingw-builds installer doesn’t correctly install and 
> quits with error message “ERROR res”.  It claims it installed 
> successfully but there are barely any files in there.  Instead, I 
> downloaded from the source and unzipped it and directly moved it to my C:\ 
> drive.  I have also tried using the MinGW-w64 installer and using a newer 
> 4.9.2 version, but that didn’t work either.
>
>
> Would anyone be able to help me on this problem?  Thanks!
>

Re: [julia-users] Multiple lines statement?

[Stefan Karpinski]

I don't think there are any ASCII character sequences available for this.

On Thu, Jun 18, 2015 at 4:50 PM, Art Kuo  wrote:

> A small comment in favor of optional line continuations. I've sometimes
> used code to write out complicated symbolic equations, sometimes thousands
> of lines long. I found it easy to programmatically spit out both C and
> Matlab code, only having to do a semi-colon (and a ... for Matlab). I agree
> parens can mostly take care of anything, but it might be nice to have an
> optional continuator, which can be clear, simple, and explicit. A parser
> might not need it, but a human might still find it easier.
>
> If there were an optional continuator, I would suggest against "..." which
> should be reserved for splatting, so x... means only one thing. I have
> complained about how the Julia documentation is confusing because sometimes
> ... means splat, sometimes it means "and so on", with no clear indicator
> which is intended. In most cases context is sufficient to figure out the
> meaning, but better to be explicit and use a separate symbol to mean a
> separate thing.
>
> On Thursday, June 18, 2015 at 8:59:49 AM UTC-4, Christoph Ortner wrote:
>>
>> As I said, it is "OK". I am getting used to it.
>> Christoph
>>
>> On Thursday, 18 June 2015 13:34:14 UTC+1, Patrick O'Leary wrote:
>>>
>>> "Busier" I agree with, but it's marginal; grouping is lightweight as
>>> syntax goes. Parens (1) already work, (2) consistently mean "keep these
>>> things together" in a variety of computing environments, (3) have match
>>> highlighting support in many editors which make it easy, given one end of
>>> the parenthesized subexpression, to find the other end. So I'm not sure I
>>> agree with the latter, especially if indentation is used effectively.
>>>
>>> On Thursday, June 18, 2015 at 6:53:54 AM UTC-5, Christoph Ortner wrote:


 I think parenthesis are "ok", but only just. They make the code busier
 and more difficult to read.
 Christoph


 On Tuesday, 16 June 2015 01:21:45 UTC+1, David Gold wrote:
>
> @Ben: as has been noted elsewhere in this thread, you can use parens
> to this end:
>
> julia> function foo(a, b, c, d, e, f)
>if (a > b
>   || c > d
>   || e > f)
> println("Foo for you.")
>end
>end
> foo (generic function with 1 method)
>
> julia> foo(1, 2, 3, 4, 6, 5)
> Foo for you.
>
>
> Is there a reason this is significantly worse than what you described?
>
> On Monday, June 15, 2015 at 5:54:56 PM UTC-4, Ben Arthur wrote:
>>
>> in addition to adhering to mathematical typsetting conventions,
>> permitting binary operators to be on the following line would make it
>> easier to comment out sub-expressions.  for example,
>>
>> if a>b
>>   || c>d
>>   || e>f
>> end
>>
>> could become
>>
>> if a>b
>>   # || c>d
>>   || e>f
>> end
>>
>> i'm not advocating for a mandatory line continuation character.  that
>> would be terrible.  but changing julia to look at the preceding line if 
>> the
>> current line doesn't make sense by itself would be great.
>>
>> ben
>>
>>
>>
>> On Monday, June 1, 2015 at 3:35:50 PM UTC-4, Christoph Ortner wrote:
>>>
>>>
>>> Just to reiterate a comment I made above: the convention in
>>> mathematical typesetting is
>>>b
>>> + c
>>> and not
>>>b +
>>>  c
>>>
>>> this is the main reason I have (more than once) fallen into this
>>> trap. Anyhow, I will try to use brackets for a while and see how I like 
>>> it.
>>>
>>> Christoph
>>>
>>

Re: [julia-users] Multiple lines statement?

[Art Kuo]

A small comment in favor of optional line continuations. I've sometimes 
used code to write out complicated symbolic equations, sometimes thousands 
of lines long. I found it easy to programmatically spit out both C and 
Matlab code, only having to do a semi-colon (and a ... for Matlab). I agree 
parens can mostly take care of anything, but it might be nice to have an 
optional continuator, which can be clear, simple, and explicit. A parser 
might not need it, but a human might still find it easier.

If there were an optional continuator, I would suggest against "..." which 
should be reserved for splatting, so x... means only one thing. I have 
complained about how the Julia documentation is confusing because sometimes 
... means splat, sometimes it means "and so on", with no clear indicator 
which is intended. In most cases context is sufficient to figure out the 
meaning, but better to be explicit and use a separate symbol to mean a 
separate thing.

On Thursday, June 18, 2015 at 8:59:49 AM UTC-4, Christoph Ortner wrote:
>
> As I said, it is "OK". I am getting used to it.
> Christoph
>
> On Thursday, 18 June 2015 13:34:14 UTC+1, Patrick O'Leary wrote:
>>
>> "Busier" I agree with, but it's marginal; grouping is lightweight as 
>> syntax goes. Parens (1) already work, (2) consistently mean "keep these 
>> things together" in a variety of computing environments, (3) have match 
>> highlighting support in many editors which make it easy, given one end of 
>> the parenthesized subexpression, to find the other end. So I'm not sure I 
>> agree with the latter, especially if indentation is used effectively.
>>
>> On Thursday, June 18, 2015 at 6:53:54 AM UTC-5, Christoph Ortner wrote:
>>>
>>>
>>> I think parenthesis are "ok", but only just. They make the code busier 
>>> and more difficult to read. 
>>> Christoph
>>>
>>>
>>> On Tuesday, 16 June 2015 01:21:45 UTC+1, David Gold wrote:

 @Ben: as has been noted elsewhere in this thread, you can use parens to 
 this end:

 julia> function foo(a, b, c, d, e, f)
if (a > b 
   || c > d 
   || e > f) 
 println("Foo for you.") 
end 
end 
 foo (generic function with 1 method) 

 julia> foo(1, 2, 3, 4, 6, 5) 
 Foo for you.


 Is there a reason this is significantly worse than what you described?

 On Monday, June 15, 2015 at 5:54:56 PM UTC-4, Ben Arthur wrote:
>
> in addition to adhering to mathematical typsetting conventions, 
> permitting binary operators to be on the following line would make it 
> easier to comment out sub-expressions.  for example,
>
> if a>b
>   || c>d
>   || e>f
> end
>
> could become
>
> if a>b
>   # || c>d
>   || e>f
> end
>
> i'm not advocating for a mandatory line continuation character.  that 
> would be terrible.  but changing julia to look at the preceding line if 
> the 
> current line doesn't make sense by itself would be great.
>
> ben
>
>
>
> On Monday, June 1, 2015 at 3:35:50 PM UTC-4, Christoph Ortner wrote:
>>
>>
>> Just to reiterate a comment I made above: the convention in 
>> mathematical typesetting is 
>>b
>> + c
>> and not
>>b + 
>>  c
>>
>> this is the main reason I have (more than once) fallen into this 
>> trap. Anyhow, I will try to use brackets for a while and see how I like 
>> it.
>>
>> Christoph
>>
>

[julia-users] Building Julia from source in Windows

[Sayeed Tasnim]

 

Hi,


I’m trying to build Julia from source in Windows.  I’m following the 
instructions described in the README.windows.md here: 





https://github.com/JuliaLang/julia/blob/master/README.windows.md 


However, I’m getting stuck on step 6.iv where I begin the build.  I get the 
following error in msys:


$ make -j 4

/home/t-satasn-win8/julia/Make.inc:432: *** "cannot build julia with 
msys-target compilers. please see the README.windows document for 
instructions on setting

up mingw-w64 compilers".  Stop.


I noticed that the mingw-builds installer doesn’t correctly install and 
quits with error message “ERROR res”.  It claims it installed successfully 
but there are barely any files in there.  Instead, I downloaded from the 
source and unzipped it and directly moved it to my C:\ drive.  I have also 
tried using the MinGW-w64 installer and using a newer 4.9.2 version, but 
that didn’t work either.


Would anyone be able to help me on this problem?  Thanks!

  

Kind regards,

Sayeed 

[julia-users] Building Julia from Source in Windows

[Sayeed Tasnim]

 

Hi,


I’m trying to build Julia from source in Windows.  I’m following the 
instructions described in the README.windows.md here:

https://github.com/JuliaLang/julia/blob/master/README.windows.md


However, I’m getting stuck on step 6.iv where I begin the build.  I get the 
following error in msys: 

 

$ make -j 4

/home/t-satasn-win8/julia/Make.inc:432: *** "cannot build julia with 
msys-target compilers. please see the README.windows document for 
instructions on setting

up mingw-w64 compilers".  Stop.


I noticed that the mingw-builds installer doesn’t correctly install and 
quits with error message “ERROR res”.  It claims it installed successfully 
but there are barely any files in there.  Instead, I downloaded from the 
source and unzipped it and directly moved it to my C:\ drive.  I have also 
tried using the MinGW-w64 installer and using a newer 4.9.2 version, but 
that didn’t work either.


Would anyone be able to help me on this problem?  Thanks!

Re: [julia-users] Adding a native function to julia's scheduler

[Stefan Karpinski]

At some point I wrote this code
 which allows
you to create a separate thread and make arbitrary ccalls on that thread.
It uses ZMQ for communication though, and the Julia process segfaults when
it quits, so it's not ideal. It might be good to have an API for spawning
threads and running ccalls in them. You probably don't want to spawn the
thread for each call, so it would look something like this:

   1. create an object to represent the worker thread
   2. make a thread_ccall with the thread object as an additional argument
   c.f. ccall
   3. the co-routine where the call occurs blocks waiting for the call to
   finish

So the usage largely looks just like making a blocking ccall, but it allows
the scheduler to do other work while the ccall happens in the other thread.

On Thu, Jun 18, 2015 at 4:07 PM, Keno Fischer 
wrote:

> The generic solution here is to use a thread and uv's async primitive
> which allows you to queue an event on julia's event loop (and is
> represented by a SingleAsyncWork at the julia level - ZMQ does this for
> example). Depending on what you're waiting on, there may also be deeper
> integration available at the libuv level, but that would depend on the
> application.
>
> On Wed, Jun 17, 2015 at 3:29 AM,  wrote:
>
>>
>> I need to call "waitformultipleobjects" (windows equivalent of "select"
>> call in linux) from julia using ccall. As this is a blocking function, I
>> would like to call it within another coroutine (task).
>>
>>
>>
>> The problem is that the “Taks” in Julia only function effectively if all
>> the blocking calls within it emanates from julia's own I/O interface. It
>> cannot deal with any blocking call to native C-functions.
>>
>>
>>
>> As far as I can see julia is based on Libuv. I guess every time a
>> blocking call (from defined I/O interface) is issued, julia internally
>> calls a corresponding function from the asynchronous libuv and then waits()
>> for a notify() from the libuv. I guess the entire scheduler of julia is
>> based on this paradigm so that It can deal with asynch operation within a
>> single thread.
>>
>>
>>
>> My question is, is it possible to extent this wait() - notify() paradigm
>> for any arbitrary blocking ccall call?
>>
>>
>>
>> I have tried the following solution, but it fails miserably:
>>
>> 0) Start a task which calls a non-blocking function from the dll and then
>> wait() for a notify().
>> 1)  (In C) Implement a dll which creates another thread to call the real
>> blocking function whenever julia calls the non-blocking function in the
>> previous step.
>>
>> 2) Provide a Julia callback function to the dll which is called at the
>> finalizing step of the thread by the dll.
>>
>> 3) (In Julia) the callback function calls the notify() function.
>>
>> However, it turned out that notify() function itself is not thread safe
>> and Julia’s respond to notify() from another thread (created in C) is
>> totally random.
>>
>> Is it possible to make the julia’s scheduler handle the arbitrary
>> blocking calls?
>>
>>
>>
>> (PS: I was previously advised a solution based on parallel processes.
>> However, for several reasons, multi-process paradigm is not a suitable
>> option for me right now.)
>>
>
>

Re: [julia-users] inverse function error?

[Mauro]

I don't know why Y does not get its type inferred correctly.  But you
can do:
eltype(df[2])[df[i,2] for i in 1:size(df,1)]

On Thu, 2015-06-18 at 20:21, SG  wrote:
> #= This line adds functions to take  
>an AR(2) model for US inflation  
> =# 
>  
> using DataFrames 
>  
> function lag0(x,p) 
>  R::Int32=size(x,1) 
>  C::Int32=size(x,2) 
>  
> # Take the first R-p rows of matrix x 
>  x1=x[1:(R-p),:] 
>  return out=[zeros(p,C); x1] 
>  
> end 
>  
>  
> #load inflation datatable 
> #df=readtable("inflation.csv") 
>  
> df=DataFrame() 
> df[:A]=1:8 
> df[:B]=10:17 
>  
> ##
> # Way of converting DataArray to Array  #
> ##
> Y=[df[i,2] for i in [1:size(df,1)]] 
>  
> ##  type of (Y) is now "Any"  
>  
>  
> T=size(Y,1) 
> X=[ones(T,1) lag0(Y,1) lag0(Y,2)] 
> inv(X'*X)
>
> ==
>
> Hi All, 
>
> I am posting again the issue. I found when I create an Array as shown 
> above, the type of Array 
> changed to "Any" which is not acceptable for the base Inverse function(an 
> error occurred). 
> I am wondering why Julia does not assume the type of original data, here in 
> the example, Int64.
>
> Many thanks, 
>
>
>
>
>
>
> On Thursday, June 18, 2015 at 7:23:16 PM UTC+2, SG wrote:
>>
>> Thank you, I will cut it down and post it again soon. 
>>
>> On Thursday, June 18, 2015 at 7:01:16 PM UTC+2, Stefan Karpinski wrote:
>>>
>>> I think these sample programs may be too big for people to review for 
>>> you. If you can pare the problem down to an example that can be posted in 
>>> an email, you've more likely to get help.
>>>
>>> On Thu, Jun 18, 2015 at 11:11 AM, SG  wrote:
>>>

 Hi All, 

 I am a novice to Julia. 

 While I am running the attached julia program, I found "inverse" 
 function throws an error? 
 However it worked well in Matlab. Can you help me? Many thanks.




>>>

Re: [julia-users] JuliaCon: Software expectations / attendance lists?

[Mauro]

> 2) Along the lines of #1, are all of the talks just going to be a 
> free-for-all of attendance? I'm not suggesting that anything rigorous is 
> desirable, just wondering how I would communicate to people coming to my 
> workshop (hopefully someone!). Or, should we just do environment/package 
> setup via GitHub at the beginning of the session?

I think having all on GitHub one Pkg.clone(...) away is the way to go.
Pretty much everyone should be familiar with that and it should only
take 5min (unless it doesn't...).

Re: [julia-users] Adding a native function to julia's scheduler

[Keno Fischer]

The generic solution here is to use a thread and uv's async primitive which
allows you to queue an event on julia's event loop (and is represented by a
SingleAsyncWork at the julia level - ZMQ does this for example). Depending
on what you're waiting on, there may also be deeper integration available
at the libuv level, but that would depend on the application.

On Wed, Jun 17, 2015 at 3:29 AM,  wrote:

>
> I need to call "waitformultipleobjects" (windows equivalent of "select"
> call in linux) from julia using ccall. As this is a blocking function, I
> would like to call it within another coroutine (task).
>
>
>
> The problem is that the “Taks” in Julia only function effectively if all
> the blocking calls within it emanates from julia's own I/O interface. It
> cannot deal with any blocking call to native C-functions.
>
>
>
> As far as I can see julia is based on Libuv. I guess every time a blocking
> call (from defined I/O interface) is issued, julia internally calls a
> corresponding function from the asynchronous libuv and then waits() for a
> notify() from the libuv. I guess the entire scheduler of julia is based on
> this paradigm so that It can deal with asynch operation within a single
> thread.
>
>
>
> My question is, is it possible to extent this wait() - notify() paradigm
> for any arbitrary blocking ccall call?
>
>
>
> I have tried the following solution, but it fails miserably:
>
> 0) Start a task which calls a non-blocking function from the dll and then
> wait() for a notify().
> 1)  (In C) Implement a dll which creates another thread to call the real
> blocking function whenever julia calls the non-blocking function in the
> previous step.
>
> 2) Provide a Julia callback function to the dll which is called at the
> finalizing step of the thread by the dll.
>
> 3) (In Julia) the callback function calls the notify() function.
>
> However, it turned out that notify() function itself is not thread safe
> and Julia’s respond to notify() from another thread (created in C) is
> totally random.
>
> Is it possible to make the julia’s scheduler handle the arbitrary blocking
> calls?
>
>
>
> (PS: I was previously advised a solution based on parallel processes.
> However, for several reasons, multi-process paradigm is not a suitable
> option for me right now.)
>

Re: [julia-users] How to manually install julia packages on a Windows system

[Jameson Nash]

WinRPM can be run from a mac/linux system directly, if you pass "win32" as
the architecture flag to the install methods. I intended it to be fairly
friendly and object oriented to use from the command line (and wrote most
of it from a Mac).

On Thu, Jun 18, 2015 at 2:26 PM Isaiah Norton 
wrote:

> I just noticed your sig... in a regulated environment I guess it is not
> surprising if github is specifically filtered. Various ideas:
>
> - git probably does not pick up Windows proxy server settings
> automatically (whereas your web browser would). if you access the internet
> through a proxy server, try configuring git to use it:
>
> http://stackoverflow.com/questions/783811/getting-git-to-work-with-a-proxy-server
> - It might be possible to run Windows Julia on your Mac under wine,
> install the packages, and then copy the resulting folder to the firewalled
> system. Haven't tried this myself.
> - Find an external Windows system on which to run the installations, and
> then copy everything to the internal system. Possibly EC2 or similar cloud
> service will let you run a small instance for free for some period of time
> (I haven't looked recently).
>
>
> On Thu, Jun 18, 2015 at 1:24 PM, Yonatan  wrote:
>
>> yes, unfortunately i'm getting a similar error:
>>
>> fatal: unable to access 'https://github.com/JuliaLang/julia/': Failed
>> connect to github.com:443; No error
>> ERROR: failed process: Process(`git clone
>> https://github.com/JuliaLang/julia/`
>> , ProcessExited(128)) [128] in
>> error at error.jl:22 (repeats 2 times)
>>
>> On Wednesday, June 17, 2015 at 5:28:43 PM UTC-4, Isaiah wrote:
>>>
>>> Well, if https is in fact accessible then the best bet is to
>>> troubleshoot git directly first. After configuring the `insteadOf` git
>>> setting (per the README) try something simple like `git clone
>>> https://github.com/JuliaLang/julia` .
>>> There are a lot of guides on the internet for troubleshooting this issue.
>>>
>>> On Wed, Jun 17, 2015 at 4:46 PM, Yonatan Tekleab 
>>> wrote:
>>>
 yea, i figured the same thing since I am on the same system using https
 through my browser, but for some reason that I don't understand, Julia
 won't add/update packages, even when git is configured to use https

 On Wednesday, June 17, 2015 at 3:04:26 PM UTC-4, Isaiah wrote:
>
> Are you using the gmail web interface from this same system? If so,
> then https:// should, in principle, be available and work for git
> too...
>
> On the other hand, if you are using a separate (windows) system for
> gmail, then you ought to be able to run Pkg.install/build on the second
> system, get all requirements you need, and then copy your
> "C:/Users/USERNAME/.julia/v0.#" directory onto the firewalled system. This
> is tricky/unreliable on linux, but should be quite simple on windows as
> long as both systems are same word size -- both 32-bit or 64-bit (because
> of Microsoft's ABI permanence).
>
> On Wed, Jun 17, 2015 at 2:31 PM, Yonatan Tekleab 
> wrote:
>
>> I think I'm moving in the right direction. I downloaded several
>> packages that IJulia depends on and put them in the ~/.julia/v0.3 
>> directory
>> along with the IJulia package itself. Before I was just sticking them in
>> the ~/.julia directory, and I don't think Julia was seeing the packages.
>>
>> When trying `using IJulia`, I get "ERROR: ZMQ not properly installed.
>> Please run Pkg.build("ZMQ"). When I run that command, it tries to build
>> Homebrew, WinRPM, and ZMQ, all of which have their own errors.
>> Homebrew: "could not spawn setenv(`git rev-parse --git-dir`;
>> dir="P:\\.julia\\v0.3\\Homebrew\\deps\\usr"): no such file or directory
>> (ENOENT)"
>> WinRPM: "update not defined"
>> ZMQ: "RPM not defined"
>>
>> When I try `Pkg.build("IJulia")`, it trys to build Homebrew, WinRPM,
>> Nettle, ZMQ, and IJulia.  I get errors for all except IJulia.  The
>> Homebrew, WinRPM and ZMQ errors are the same.  For Nettle, I get: "RPM 
>> not
>> defined"
>>
>> Now I can open an IJulia instance, but the kernel dies shortly after
>> it comes up. The command window states "ERROR: ZMQ not properly 
>> installed.
>> Please run Pkg.build("ZMQ")". Then it attempts to restart the kernel and
>> repeats the process.
>>
>>
>> On Wednesday, June 17, 2015 at 12:31:22 AM UTC-4, Tony Kelman wrote:
>>>
>>> Can you do `using IJulia`, and/or `Pkg.build("IJulia")` ? Note also
>>> that IJulia depends on several other packages, indicated in the REQUIRE
>>> file (and those packages may have other dependencies of their own).
>>>
>>>
>>> On Tuesday, June 16, 2015 at 3:40:14 PM UTC-7, Yonatan Tekleab wrote:

 Hi Stefan,

 I'm having the same problem.  Unfortunately the firewall I'm 

[julia-users] Re: X.2=X*0.2, easy to make mistake.

[Art Kuo]

That does sound like a good thing to check with lint. Whether it should be 
considered a bug or not might depend on how the language spec is 
interpreted. The documentation 

 
says "Julia allows variables to be immediately preceded by a numeric 
literal," the only exceptions being explicit hexadecimals and literal 
floats (e.g. 0xff, 1e-10). I couldn't find anything explicit saying it's 
okay to write x.2 to mean x*0.2. If there's any code out there using that, 
I wonder if it's an undiscovered bug or really intentional.


On Wednesday, June 17, 2015 at 9:07:25 PM UTC-4, Patrick O'Leary wrote:
>
> Changing this would be breaking--syntax that currently works (even if you 
> don't expect it to) wouldn't work anymore. If someone is actually using 
> this syntax, then we'd break their code on a release which is billed as a 
> minor maintenance release. That's not going to work.
>
> There may be a Lint.jl check for this, though? It sounds familiar.
>
> On Wednesday, June 17, 2015 at 5:12:31 PM UTC-5, Art Kuo wrote:
>>
>> That's great that it's fixed in 0.4, but even in 0.3.X I would still 
>> label it inconsistent behavior, or perhaps even a bug. Why should this 
>> happen:
>>
>> *julia> **x.2 == x*.2*
>>
>> *true*
>>
>> *julia> **x0.2 == x*0.2*
>>
>> *ERROR: x0 not defined*
>>
>> *julia> **x2 == x*2*
>>
>> *ERROR: x2 not defined*
>>
>> It seems consistent that .2X == .2*X, 0.2X == 0.2*X, 2X == 2*X, so it is 
>> fine if the number occurs before the variable. But not if the number occurs 
>> after, so I agree with the proposal to ban X.2, meaning trigger an error. 
>> Shouldn't this be the case for 0.3 versions as well?
>>
>>
>> On Wednesday, June 17, 2015 at 9:14:24 AM UTC-4, Seth wrote:
>>>
>>>
>>>
>>> On Wednesday, June 17, 2015 at 8:04:11 AM UTC-5, Jerry Xiong wrote:

 Today I spend many time to find a bug in my code. It is turn out that I 
 mistakenly wrote sum(X,2) as sum(X.2). No any error information is 
 reported 
 and Julia regarded X.2 as X*0.2. The comma "," is quite close to dot "." 
 in 
 the keyboard and looks quite similar in some fonts. As there is no any 
 error occur, this bug will be dangerous. Also, it is not intuitive to 
 understand X.2 is X*0.2. I think maybe it is better to forbid syntax like 
 X.2 but only allowed .2X. 

>>>
>>> This appears to be fixed in 0.4:
>>>
>>> julia> x = 100
>>> 100
>>>
>>> julia> x.2
>>> ERROR: syntax: extra token "0.2" after end of expression
>>>
>>> julia> sum(x.2)
>>> ERROR: syntax: missing comma or ) in argument list
>>>
>>> julia> f(x) = x.2
>>> ERROR: syntax: extra token "0.2" after end of expression
>>>
>>> julia> f(x) = sum(x.2)
>>> ERROR: syntax: missing comma or ) in argument list
>>>
>>>  
>>>
>>

Re: [julia-users] Adding a native function to julia's scheduler

[Isaiah Norton]

You could potentially yield to Julia from C instead. See
https://github.com/JuliaLang/julia/issues/6006 (use with caution...)

On Wed, Jun 17, 2015 at 7:54 AM, Tim Holy  wrote:

> Not sure it will help your specific use case, but see
>
> http://docs.julialang.org/en/release-0.3/manual/calling-c-and-fortran-code/#thread-safety
> and an example in
> https://github.com/JuliaGPU/CUDArt.jl/blob/master/src/stream.jl
>
> --Tim
>
>
> On Wednesday, June 17, 2015 12:29:18 AM yigiter.pub...@gmail.com wrote:
> > I need to call "waitformultipleobjects" (windows equivalent of "select"
> > call in linux) from julia using ccall. As this is a blocking function, I
> > would like to call it within another coroutine (task).
> >
> >
> >
> > The problem is that the “Taks” in Julia only function effectively if all
> > the blocking calls within it emanates from julia's own I/O interface. It
> > cannot deal with any blocking call to native C-functions.
> >
> >
> >
> > As far as I can see julia is based on Libuv. I guess every time a
> blocking
> > call (from defined I/O interface) is issued, julia internally calls a
> > corresponding function from the asynchronous libuv and then waits() for a
> > notify() from the libuv. I guess the entire scheduler of julia is based
> on
> > this paradigm so that It can deal with asynch operation within a single
> > thread.
> >
> >
> >
> > My question is, is it possible to extent this wait() - notify() paradigm
> > for any arbitrary blocking ccall call?
> >
> >
> >
> > I have tried the following solution, but it fails miserably:
> >
> > 0) Start a task which calls a non-blocking function from the dll and then
> > wait() for a notify().
> > 1)  (In C) Implement a dll which creates another thread to call the real
> > blocking function whenever julia calls the non-blocking function in the
> > previous step.
> >
> > 2) Provide a Julia callback function to the dll which is called at the
> > finalizing step of the thread by the dll.
> >
> > 3) (In Julia) the callback function calls the notify() function.
> >
> > However, it turned out that notify() function itself is not thread safe
> and
> > Julia’s respond to notify() from another thread (created in C) is totally
> > random.
> >
> > Is it possible to make the julia’s scheduler handle the arbitrary
> blocking
> > calls?
> >
> >
> >
> > (PS: I was previously advised a solution based on parallel processes.
> > However, for several reasons, multi-process paradigm is not a suitable
> > option for me right now.)
>
>

Re: [julia-users] Help: My "parallel" code 8300x slower than the serial.

[Stefan Karpinski]

Unfortunately, I suspect that even with threads and fully shared process
memory this would not parallelize well.

On Thu, Jun 18, 2015 at 2:41 PM, Daniel Carrera  wrote:

> On 18 June 2015 at 18:48, Stefan Karpinski  wrote:
>
>> On Wed, Jun 17, 2015 at 4:38 PM, Daniel Carrera 
>> wrote:
>>
>>> An irritating problem with all the codes that solve planetary systems is
>>> that they are all serial -- this problem is apparently hard to parallelize.
>>
>>
>> That appears to be a language-independent issue. Even with mature
>> threading, it doesn't seem like this problem would scale well. It might be
>> possible to figure out a clever way to parallelize it, but that is a
>> serious algorithmic research problem. A superficial Google Scholar search
>> indicates that some work has been done in this direction using tree data
>> structures.
>>
>
>
> Yeah, this is an algorithmic issue and many people much smarter than me
> are working on it. I was just hoping that using shared memory would give me
> a small amount of parallelism without clever algorithms.
>
> Tree codes are the standard solution for systems like galaxies, where the
> number of particles is very large, but the dynamical age is small. In a
> galaxy you have 200 billion particles that have each done 40 orbits.
>
> For planet systems the problem is reversed. We have few particles and long
> ages (Earth has gone around the Sun 4 billion times). This means that small
> errors can really accumulate. For these problems the state of the art is
> either very high order integrators, or "symplectic" integrators which are
> designed to preserve a Hamiltonian that is closely related to the
> Hamiltonian of the system.
>
> Unfortunately, unlike the tree codes, none of these solutions are
> parallel. Because every particle affects every particle and you can't
> afford to throw away any information, the problem is very resistant to
> parallelization. I was wondering if I could get a free lunch by using
> shared memory.
>
> Cheers,
> Daniel.
> --
> When an engineer says that something can't be done, it's a code phrase
> that means it's not fun to do.
>

Re: [julia-users] Overloading `eval`

[Christoph Ortner]

ok - thank you for clarifying!
Christoph

Re: [julia-users] Help: My "parallel" code 8300x slower than the serial.

[Daniel Carrera]

On 18 June 2015 at 18:48, Stefan Karpinski  wrote:

> On Wed, Jun 17, 2015 at 4:38 PM, Daniel Carrera 
> wrote:
>
>> An irritating problem with all the codes that solve planetary systems is
>> that they are all serial -- this problem is apparently hard to parallelize.
>
>
> That appears to be a language-independent issue. Even with mature
> threading, it doesn't seem like this problem would scale well. It might be
> possible to figure out a clever way to parallelize it, but that is a
> serious algorithmic research problem. A superficial Google Scholar search
> indicates that some work has been done in this direction using tree data
> structures.
>


Yeah, this is an algorithmic issue and many people much smarter than me are
working on it. I was just hoping that using shared memory would give me a
small amount of parallelism without clever algorithms.

Tree codes are the standard solution for systems like galaxies, where the
number of particles is very large, but the dynamical age is small. In a
galaxy you have 200 billion particles that have each done 40 orbits.

For planet systems the problem is reversed. We have few particles and long
ages (Earth has gone around the Sun 4 billion times). This means that small
errors can really accumulate. For these problems the state of the art is
either very high order integrators, or "symplectic" integrators which are
designed to preserve a Hamiltonian that is closely related to the
Hamiltonian of the system.

Unfortunately, unlike the tree codes, none of these solutions are parallel.
Because every particle affects every particle and you can't afford to throw
away any information, the problem is very resistant to parallelization. I
was wondering if I could get a free lunch by using shared memory.

Cheers,
Daniel.
-- 
When an engineer says that something can't be done, it's a code phrase that
means it's not fun to do.

Re: [julia-users] How to manually install julia packages on a Windows system

[Isaiah Norton]

I just noticed your sig... in a regulated environment I guess it is not
surprising if github is specifically filtered. Various ideas:

- git probably does not pick up Windows proxy server settings automatically
(whereas your web browser would). if you access the internet through a
proxy server, try configuring git to use it:
http://stackoverflow.com/questions/783811/getting-git-to-work-with-a-proxy-server
- It might be possible to run Windows Julia on your Mac under wine, install
the packages, and then copy the resulting folder to the firewalled system.
Haven't tried this myself.
- Find an external Windows system on which to run the installations, and
then copy everything to the internal system. Possibly EC2 or similar cloud
service will let you run a small instance for free for some period of time
(I haven't looked recently).


On Thu, Jun 18, 2015 at 1:24 PM, Yonatan  wrote:

> yes, unfortunately i'm getting a similar error:
>
> fatal: unable to access 'https://github.com/JuliaLang/julia/': Failed
> connect to github.com:443; No error
> ERROR: failed process: Process(`git clone
> https://github.com/JuliaLang/julia/` ,
> ProcessExited(128)) [128] in error at error.jl:22 (repeats 2 times)
>
> On Wednesday, June 17, 2015 at 5:28:43 PM UTC-4, Isaiah wrote:
>>
>> Well, if https is in fact accessible then the best bet is to troubleshoot
>> git directly first. After configuring the `insteadOf` git setting (per the
>> README) try something simple like `git clone
>> https://github.com/JuliaLang/julia` .
>> There are a lot of guides on the internet for troubleshooting this issue.
>>
>> On Wed, Jun 17, 2015 at 4:46 PM, Yonatan Tekleab 
>> wrote:
>>
>>> yea, i figured the same thing since I am on the same system using https
>>> through my browser, but for some reason that I don't understand, Julia
>>> won't add/update packages, even when git is configured to use https
>>>
>>> On Wednesday, June 17, 2015 at 3:04:26 PM UTC-4, Isaiah wrote:

 Are you using the gmail web interface from this same system? If so,
 then https:// should, in principle, be available and work for git
 too...

 On the other hand, if you are using a separate (windows) system for
 gmail, then you ought to be able to run Pkg.install/build on the second
 system, get all requirements you need, and then copy your
 "C:/Users/USERNAME/.julia/v0.#" directory onto the firewalled system. This
 is tricky/unreliable on linux, but should be quite simple on windows as
 long as both systems are same word size -- both 32-bit or 64-bit (because
 of Microsoft's ABI permanence).

 On Wed, Jun 17, 2015 at 2:31 PM, Yonatan Tekleab 
 wrote:

> I think I'm moving in the right direction. I downloaded several
> packages that IJulia depends on and put them in the ~/.julia/v0.3 
> directory
> along with the IJulia package itself. Before I was just sticking them in
> the ~/.julia directory, and I don't think Julia was seeing the packages.
>
> When trying `using IJulia`, I get "ERROR: ZMQ not properly installed.
> Please run Pkg.build("ZMQ"). When I run that command, it tries to build
> Homebrew, WinRPM, and ZMQ, all of which have their own errors.
> Homebrew: "could not spawn setenv(`git rev-parse --git-dir`;
> dir="P:\\.julia\\v0.3\\Homebrew\\deps\\usr"): no such file or directory
> (ENOENT)"
> WinRPM: "update not defined"
> ZMQ: "RPM not defined"
>
> When I try `Pkg.build("IJulia")`, it trys to build Homebrew, WinRPM,
> Nettle, ZMQ, and IJulia.  I get errors for all except IJulia.  The
> Homebrew, WinRPM and ZMQ errors are the same.  For Nettle, I get: "RPM not
> defined"
>
> Now I can open an IJulia instance, but the kernel dies shortly after
> it comes up. The command window states "ERROR: ZMQ not properly installed.
> Please run Pkg.build("ZMQ")". Then it attempts to restart the kernel and
> repeats the process.
>
>
> On Wednesday, June 17, 2015 at 12:31:22 AM UTC-4, Tony Kelman wrote:
>>
>> Can you do `using IJulia`, and/or `Pkg.build("IJulia")` ? Note also
>> that IJulia depends on several other packages, indicated in the REQUIRE
>> file (and those packages may have other dependencies of their own).
>>
>>
>> On Tuesday, June 16, 2015 at 3:40:14 PM UTC-7, Yonatan Tekleab wrote:
>>>
>>> Hi Stefan,
>>>
>>> I'm having the same problem.  Unfortunately the firewall I'm behind
>>> is clever enough prevent me from re-configuring git to use https, as 
>>> many
>>> other threads have indicated.
>>>
>>> I downloaded the master branch IJulia package from
>>> https://github.com/JuliaLang/IJulia.jl, extracted the folder,
>>> placed it inside the ~/.julia folder, then removed the ".jl-master"
>>> suffix.  This still isn't working for me.  When I try to open IJulia 
>

Re: [julia-users] inverse function error?

[SG]

#= This line adds functions to take  
   an AR(2) model for US inflation  
=# 
 
using DataFrames 
 
function lag0(x,p) 
 R::Int32=size(x,1) 
 C::Int32=size(x,2) 
 
# Take the first R-p rows of matrix x 
 x1=x[1:(R-p),:] 
 return out=[zeros(p,C); x1] 
 
end 
 
 
#load inflation datatable 
#df=readtable("inflation.csv") 
 
df=DataFrame() 
df[:A]=1:8 
df[:B]=10:17 
 
##
# Way of converting DataArray to Array  #
##
Y=[df[i,2] for i in [1:size(df,1)]] 
 
##  type of (Y) is now "Any"  
 
 
T=size(Y,1) 
X=[ones(T,1) lag0(Y,1) lag0(Y,2)] 
inv(X'*X)

==

Hi All, 

I am posting again the issue. I found when I create an Array as shown 
above, the type of Array 
changed to "Any" which is not acceptable for the base Inverse function(an 
error occurred). 
I am wondering why Julia does not assume the type of original data, here in 
the example, Int64.

Many thanks, 






On Thursday, June 18, 2015 at 7:23:16 PM UTC+2, SG wrote:
>
> Thank you, I will cut it down and post it again soon. 
>
> On Thursday, June 18, 2015 at 7:01:16 PM UTC+2, Stefan Karpinski wrote:
>>
>> I think these sample programs may be too big for people to review for 
>> you. If you can pare the problem down to an example that can be posted in 
>> an email, you've more likely to get help.
>>
>> On Thu, Jun 18, 2015 at 11:11 AM, SG  wrote:
>>
>>>
>>> Hi All, 
>>>
>>> I am a novice to Julia. 
>>>
>>> While I am running the attached julia program, I found "inverse" 
>>> function throws an error? 
>>> However it worked well in Matlab. Can you help me? Many thanks.
>>>
>>>
>>>
>>>
>>

Re: [julia-users] Re: Set precision when printing to file

[Scott Jones]

Waiting for your comments, over 
at https://github.com/lindahua/Formatting.jl/issues/8!

On Thursday, June 18, 2015 at 1:22:04 PM UTC-4, Tom Breloff wrote:
>
> Yes it was on julia-dev.  Regardless I think the right path forward is to 
> start a discussion on github (in Formatting.jl) and we could hash out 
> exactly what would be nice for users.  Based on your posts, you may have a 
> very different perspective on string formatting that your average 
> developer/scientist.  My goal would be to have methods that are extremely 
> simple to understand and super short to write, so that people actually use 
> them.  Bonus points if those methods are flexible enough for those that 
> need additional options.  Anyways... over to github?
>
> On Thursday, June 18, 2015 at 1:07:21 PM UTC-4, Scott Jones wrote:
>>
>>
>> I was aware that it could be any or all of those issues.  I was just 
>> stating the facts, not complaining.
>>
>> Here is what I sent him:
>>
>>> Hi, I hope you don’t mind a direct e-mail.
>>> I was pointed at your Formatting.jl package, after I’d made the 
>>> suggestion of adding a fmt function in a new package,
>>> and kmsquire pointed out that there was already a Formatting.jl package, 
>>> which is where it should go, and then
>>> when I investigated, I saw that it had a fmt function that was almost 
>>> exactly what I was suggesting.
>>> I was wondering what you’d think of me adding my idea (renamed possibly 
>>> `sfmt` to avoid the naming conflict`) to your very
>>> nice package (which I think should be in Base, instead of so much 
>>> *unused* stuff like “RopeString” ;-) ).
>>> My idea was the following:
>>> sfmt( value [, format [, format arguments] ] )
>>> The reason to have the value first, is that you could have methods added 
>>> to have a default format for specific types.
>>> For example, the C sprintf(buf, “%*s”, 8, string) would become something 
>>> like:
>>> sfmt( string, “*s”, 8)
>>> What do you think?
>>> Thanks, Scott
>>
>>
>> As I said, his formatting package does seem very nice, and very complete 
>> as well...
>> [OT: Will he be coming to JuliaCon?  I hope so!]
>>
>> On Thursday, June 18, 2015 at 1:00:20 PM UTC-4, Stefan Karpinski wrote:
>>>
>>> Dahua is pretty busy and lives in a very different time zone. He also 
>>> may not want to respond to direct messages.
>>>
>>> On Thu, Jun 18, 2015 at 11:44 AM, Scott Jones  
>>> wrote:
>>>
 I tried directly e-mailing him (after having gotten a lot of grief for 
 posting so much!), but I haven't heard back...

>>>

Re: [julia-users] JuliaCon: Software expectations / attendance lists?

[Stefan Karpinski]

Until 0.4 is released, I would suggest using the latest 0.3.x release –
that way anyone with some 0.3.x version should be able to follow along.

On Thu, Jun 18, 2015 at 1:28 PM, Randy Zwitch 
wrote:

> Two thoughts as a workshop presenter:
>
> 1) What version of Julia should we be using, both so that the presenter
> knows and anyone following along has a similar environment?
>
> 2) Along the lines of #1, are all of the talks just going to be a
> free-for-all of attendance? I'm not suggesting that anything rigorous is
> desirable, just wondering how I would communicate to people coming to my
> workshop (hopefully someone!). Or, should we just do environment/package
> setup via GitHub at the beginning of the session?
>

[julia-users] JuliaCon: Software expectations / attendance lists?

[Randy Zwitch]

Two thoughts as a workshop presenter:

1) What version of Julia should we be using, both so that the presenter 
knows and anyone following along has a similar environment?

2) Along the lines of #1, are all of the talks just going to be a 
free-for-all of attendance? I'm not suggesting that anything rigorous is 
desirable, just wondering how I would communicate to people coming to my 
workshop (hopefully someone!). Or, should we just do environment/package 
setup via GitHub at the beginning of the session?

Re: [julia-users] How to manually install julia packages on a Windows system

[Yonatan]

yes, unfortunately i'm getting a similar error:

fatal: unable to access 'https://github.com/JuliaLang/julia/': Failed 
connect to github.com:443; No error
ERROR: failed process: Process(`git clone 
https://github.com/JuliaLang/julia/`, ProcessExited(128)) [128] in error at 
error.jl:22 (repeats 2 times)

On Wednesday, June 17, 2015 at 5:28:43 PM UTC-4, Isaiah wrote:
>
> Well, if https is in fact accessible then the best bet is to troubleshoot 
> git directly first. After configuring the `insteadOf` git setting (per the 
> README) try something simple like `git clone 
> https://github.com/JuliaLang/julia` . 
> There are a lot of guides on the internet for troubleshooting this issue.
>
> On Wed, Jun 17, 2015 at 4:46 PM, Yonatan Tekleab  > wrote:
>
>> yea, i figured the same thing since I am on the same system using https 
>> through my browser, but for some reason that I don't understand, Julia 
>> won't add/update packages, even when git is configured to use https
>>
>> On Wednesday, June 17, 2015 at 3:04:26 PM UTC-4, Isaiah wrote:
>>>
>>> Are you using the gmail web interface from this same system? If so, then 
>>> https:// should, in principle, be available and work for git too...
>>>
>>> On the other hand, if you are using a separate (windows) system for 
>>> gmail, then you ought to be able to run Pkg.install/build on the second 
>>> system, get all requirements you need, and then copy your 
>>> "C:/Users/USERNAME/.julia/v0.#" directory onto the firewalled system. This 
>>> is tricky/unreliable on linux, but should be quite simple on windows as 
>>> long as both systems are same word size -- both 32-bit or 64-bit (because 
>>> of Microsoft's ABI permanence).
>>>
>>> On Wed, Jun 17, 2015 at 2:31 PM, Yonatan Tekleab  
>>> wrote:
>>>
 I think I'm moving in the right direction. I downloaded several 
 packages that IJulia depends on and put them in the ~/.julia/v0.3 
 directory 
 along with the IJulia package itself. Before I was just sticking them in 
 the ~/.julia directory, and I don't think Julia was seeing the packages.

 When trying `using IJulia`, I get "ERROR: ZMQ not properly installed. 
 Please run Pkg.build("ZMQ"). When I run that command, it tries to build 
 Homebrew, WinRPM, and ZMQ, all of which have their own errors.
 Homebrew: "could not spawn setenv(`git rev-parse --git-dir`; 
 dir="P:\\.julia\\v0.3\\Homebrew\\deps\\usr"): no such file or directory 
 (ENOENT)"
 WinRPM: "update not defined"
 ZMQ: "RPM not defined"

 When I try `Pkg.build("IJulia")`, it trys to build Homebrew, WinRPM, 
 Nettle, ZMQ, and IJulia.  I get errors for all except IJulia.  The 
 Homebrew, WinRPM and ZMQ errors are the same.  For Nettle, I get: "RPM not 
 defined"

 Now I can open an IJulia instance, but the kernel dies shortly after it 
 comes up. The command window states "ERROR: ZMQ not properly installed. 
 Please run Pkg.build("ZMQ")". Then it attempts to restart the kernel and 
 repeats the process.


 On Wednesday, June 17, 2015 at 12:31:22 AM UTC-4, Tony Kelman wrote:
>
> Can you do `using IJulia`, and/or `Pkg.build("IJulia")` ? Note also 
> that IJulia depends on several other packages, indicated in the REQUIRE 
> file (and those packages may have other dependencies of their own).
>
>
> On Tuesday, June 16, 2015 at 3:40:14 PM UTC-7, Yonatan Tekleab wrote:
>>
>> Hi Stefan,
>>
>> I'm having the same problem.  Unfortunately the firewall I'm behind 
>> is clever enough prevent me from re-configuring git to use https, as 
>> many 
>> other threads have indicated.
>>
>> I downloaded the master branch IJulia package from 
>> https://github.com/JuliaLang/IJulia.jl, extracted the folder, placed 
>> it inside the ~/.julia folder, then removed the ".jl-master" suffix.  
>> This 
>> still isn't working for me.  When I try to open IJulia from the command 
>> prompt ("ipython notebook --profile julia"), it pulls up the typical 
>> IPython notebook.
>>
>> Any thoughts on what I'm doing wrong?
>>
>> Thanks in advance.
>>
>> On Thursday, October 31, 2013 at 10:16:06 AM UTC-4, Stefan Karpinski 
>> wrote:
>>>
>>> If you just make sure that the package source exists in ~/.julia, 
>>> that should do the trick. In fact, you don't need to mess around with 
>>> the 
>>> package manager at all – Pkg commands will fail but loading packages 
>>> should 
>>> work fine. Unfortunately, building packages with binary dependencies 
>>> will 
>>> likely fail, but if you stick with pure-Julia packages, you should be 
>>> ok.
>>>
>>>
>>> On Thu, Oct 31, 2013 at 7:51 AM, Able Mashamba  
>>> wrote:
>>>
 Dear Informed,

 Is there a way to manually install julia packages on a Windows 
 system that has a

Re: [julia-users] inverse function error?

[SG]

Thank you, I will cut it down and post it again soon. 

On Thursday, June 18, 2015 at 7:01:16 PM UTC+2, Stefan Karpinski wrote:
>
> I think these sample programs may be too big for people to review for you. 
> If you can pare the problem down to an example that can be posted in an 
> email, you've more likely to get help.
>
> On Thu, Jun 18, 2015 at 11:11 AM, SG > 
> wrote:
>
>>
>> Hi All, 
>>
>> I am a novice to Julia. 
>>
>> While I am running the attached julia program, I found "inverse" function 
>> throws an error? 
>> However it worked well in Matlab. Can you help me? Many thanks.
>>
>>
>>
>>
>

Re: [julia-users] Re: Set precision when printing to file

[Tom Breloff]

Yes it was on julia-dev.  Regardless I think the right path forward is to 
start a discussion on github (in Formatting.jl) and we could hash out 
exactly what would be nice for users.  Based on your posts, you may have a 
very different perspective on string formatting that your average 
developer/scientist.  My goal would be to have methods that are extremely 
simple to understand and super short to write, so that people actually use 
them.  Bonus points if those methods are flexible enough for those that 
need additional options.  Anyways... over to github?

On Thursday, June 18, 2015 at 1:07:21 PM UTC-4, Scott Jones wrote:
>
>
> I was aware that it could be any or all of those issues.  I was just 
> stating the facts, not complaining.
>
> Here is what I sent him:
>
>> Hi, I hope you don’t mind a direct e-mail.
>> I was pointed at your Formatting.jl package, after I’d made the 
>> suggestion of adding a fmt function in a new package,
>> and kmsquire pointed out that there was already a Formatting.jl package, 
>> which is where it should go, and then
>> when I investigated, I saw that it had a fmt function that was almost 
>> exactly what I was suggesting.
>> I was wondering what you’d think of me adding my idea (renamed possibly 
>> `sfmt` to avoid the naming conflict`) to your very
>> nice package (which I think should be in Base, instead of so much 
>> *unused* stuff like “RopeString” ;-) ).
>> My idea was the following:
>> sfmt( value [, format [, format arguments] ] )
>> The reason to have the value first, is that you could have methods added 
>> to have a default format for specific types.
>> For example, the C sprintf(buf, “%*s”, 8, string) would become something 
>> like:
>> sfmt( string, “*s”, 8)
>> What do you think?
>> Thanks, Scott
>
>
> As I said, his formatting package does seem very nice, and very complete 
> as well...
> [OT: Will he be coming to JuliaCon?  I hope so!]
>
> On Thursday, June 18, 2015 at 1:00:20 PM UTC-4, Stefan Karpinski wrote:
>>
>> Dahua is pretty busy and lives in a very different time zone. He also may 
>> not want to respond to direct messages.
>>
>> On Thu, Jun 18, 2015 at 11:44 AM, Scott Jones  
>> wrote:
>>
>>> I tried directly e-mailing him (after having gotten a lot of grief for 
>>> posting so much!), but I haven't heard back...
>>>
>>

Re: [julia-users] Re: Set precision when printing to file

[Scott Jones]

I was aware that it could be any or all of those issues.  I was just 
stating the facts, not complaining.

Here is what I sent him:

> Hi, I hope you don’t mind a direct e-mail.
> I was pointed at your Formatting.jl package, after I’d made the suggestion 
> of adding a fmt function in a new package,
> and kmsquire pointed out that there was already a Formatting.jl package, 
> which is where it should go, and then
> when I investigated, I saw that it had a fmt function that was almost 
> exactly what I was suggesting.
> I was wondering what you’d think of me adding my idea (renamed possibly 
> `sfmt` to avoid the naming conflict`) to your very
> nice package (which I think should be in Base, instead of so much *unused* 
> stuff like “RopeString” ;-) ).
> My idea was the following:
> sfmt( value [, format [, format arguments] ] )
> The reason to have the value first, is that you could have methods added 
> to have a default format for specific types.
> For example, the C sprintf(buf, “%*s”, 8, string) would become something 
> like:
> sfmt( string, “*s”, 8)
> What do you think?
> Thanks, Scott

   
As I said, his formatting package does seem very nice, and very complete as 
well...
[OT: Will he be coming to JuliaCon?  I hope so!]

On Thursday, June 18, 2015 at 1:00:20 PM UTC-4, Stefan Karpinski wrote:
>
> Dahua is pretty busy and lives in a very different time zone. He also may 
> not want to respond to direct messages.
>
> On Thu, Jun 18, 2015 at 11:44 AM, Scott Jones  > wrote:
>
>> I tried directly e-mailing him (after having gotten a lot of grief for 
>> posting so much!), but I haven't heard back...
>>
>

Re: [julia-users] inverse function error?

[Stefan Karpinski]

I think these sample programs may be too big for people to review for you.
If you can pare the problem down to an example that can be posted in an
email, you've more likely to get help.

On Thu, Jun 18, 2015 at 11:11 AM, SG  wrote:

>
> Hi All,
>
> I am a novice to Julia.
>
> While I am running the attached julia program, I found "inverse" function
> throws an error?
> However it worked well in Matlab. Can you help me? Many thanks.
>
>
>
>

Re: [julia-users] Re: Set precision when printing to file

[Stefan Karpinski]

Dahua is pretty busy and lives in a very different time zone. He also may
not want to respond to direct messages.

On Thu, Jun 18, 2015 at 11:44 AM, Scott Jones 
wrote:

> I tried directly e-mailing him (after having gotten a lot of grief for
> posting so much!), but I haven't heard back...
>
>
> On Thursday, June 18, 2015 at 10:30:05 AM UTC-4, Tom Breloff wrote:
>>
>> Scott: I remember there being another discussion but I can't seem to find
>> it.  How did you try to get in touch?  Do you want to start a github issue
>> and I'll comment there?
>>
>> On Thursday, June 18, 2015 at 10:20:08 AM UTC-4, Scott Jones wrote:
>>>
>>> This was already discussed recently, here on julia-users, I'm trying to
>>> get in touch with Dahua Lin (author of Formatting.jl)
>>> to see about adding a simpler `sfmt` that would help with this).
>>>
>>> On Thursday, June 18, 2015 at 10:13:46 AM UTC-4, Tom Breloff wrote:

 I wonder if what we really need is just some extra additions to
 Formatting.jl (since I think this is the best place to keep standard
 formatting calls).  We could add fmt2, fmt3, etc which would be meant for
 formatting floats to that precision.  I suspect that's the most common use
 of formatting.  Additionally, just a shorter name than "generate_formatter"
 might help adoption for non-standard formatting.  If this makes sense to
 people, I'll start an issue on github, and perhaps a PR as well.


 julia> using Formatting

 julia> fmt2 = generate_formatter("%1.2f")
 sprintf_JTEuMmY! (generic function with 1 method)

 julia> fmt3 = generate_formatter("%1.3f")
 sprintf_JTEuM2Y! (generic function with 1 method)

 julia> @time fmt2(31231.345435245)
   55.763 milliseconds (33974 allocations: 1444 KB)
 "31231.35"

 julia> @time fmt2(31231.345435245)
   13.573 microseconds (15 allocations: 608 bytes)
 "31231.35"

 julia> @time fmt3(31231.345435245)
   11.193 milliseconds (5882 allocations: 254 KB)
 "31231.345"

 julia> @time fmt3(31231.345435245)
   16.231 microseconds (15 allocations: 608 bytes)
 "31231.345"




 On Thursday, June 18, 2015 at 3:55:01 AM UTC-4, cormu...@mac.com wrote:
>
> You could use a type:
>
> julia> type Out
>   n::Float64
>end
>
> julia> function Base.show(io::IO, n::Out)
>print(io, "$(round(n.n, 2))")
>end
> show (generic function with 83 methods)
>
> then you can just use Out(x) whenever you want x rounded to 2 d.p.
>
> julia> for i in 0.7454539:1.5:5
>println("i is $i and displayed as $(Out(i))")
>end
> i is 0.7454539 and displayed as 0.75
> i is 2.24545392 and displayed as 2.25
> i is 3.74545392 and displayed as 3.75
>
>

Re: [julia-users] Overloading `eval`

[Isaiah Norton]

I skipped a step: as Yichao said, the built-in eval is not a generic
function so it can't be extended.

my usage is simply that I have  type A, say, that defines a function and I
> want to call eval(A, arg) to evaluate. I am perfectly happy to just call
> `feval` instead of `eval`, but I was curious.


It's still a little unclear what the goal is, and AFAIK there is no
(built-in) `feval` in Julia. You might want constructors?
http://julia.readthedocs.org/en/release-0.3/manual/constructors/

Also note that in 0.4-dev (github master) you will be able to make A
directly callable, see:
https://github.com/JuliaLang/julia/issues/2403 (and the implementation in
#8712)



On Thu, Jun 18, 2015 at 11:35 AM, Christoph Ortner <
christophortn...@gmail.com> wrote:

> I didn't fully understand this: are you saying that, unless I use
> `baremodule`, I cannot overload `eval`?
>
> my usage is simply that I have  type A, say, that defines a function and I
> want to call eval(A, arg) to evaluate. I am perfectly happy to just call
> `feval` instead of `eval`, but I was curious.
>
> Many thanks,
> Christoph
>

Re: [julia-users] Overloading `eval`

[Stefan Karpinski]

Yes, I don't think there is a way to replace a module's eval function. At
least, I can't think of any way to accomplish this besides creating a
baremodule.

On Thu, Jun 18, 2015 at 11:35 AM, Christoph Ortner <
christophortn...@gmail.com> wrote:

> I didn't fully understand this: are you saying that, unless I use
> `baremodule`, I cannot overload `eval`?
>
> my usage is simply that I have  type A, say, that defines a function and I
> want to call eval(A, arg) to evaluate. I am perfectly happy to just call
> `feval` instead of `eval`, but I was curious.
>
> Many thanks,
> Christoph
>

Re: [julia-users] Help: My "parallel" code 8300x slower than the serial.

[Stefan Karpinski]

On Wed, Jun 17, 2015 at 4:38 PM, Daniel Carrera  wrote:

> An irritating problem with all the codes that solve planetary systems is
> that they are all serial -- this problem is apparently hard to parallelize.


That appears to be a language-independent issue. Even with mature
threading, it doesn't seem like this problem would scale well. It might be
possible to figure out a clever way to parallelize it, but that is a
serious algorithmic research problem. A superficial Google Scholar search
indicates that some work has been done in this direction using tree data
structures.

Re: [julia-users] Re: good time to start to learn julia?

[Scott Jones]

Yes, good points all... I'd also point out that there is a Compat.jl 
package, as well as a deprecation facility, that help smooth over most of 
the syntax changes that happen in Julia...

On Thursday, June 18, 2015 at 12:38:28 PM UTC-4, Isaiah wrote:
>
> I am just wondering if the core language itself (syntax etc.) would change 
>> a lot in the future or not.
>
>
> I think there is an important distinction to be made here:
>
> - depending on the features you use, parts of your code will almost 
> certainly break from 0.3 -> 0.4 -> 0.5 ->  As John said, these changes 
> are (a) usually beneficial overall, and (b) usually not tremendously hard 
> to adapt to (and will hopefully become easier over time as debugging tools 
> and things like Lint.jl mature)
>
> - your mental model *mostly* shouldn't. Julia probably won't be dropping 
> garbage collection, adopting whitespace-denoted blocks, switching to 
> 0-based indexing (don't ask...), adopting an Idris-level of strictness in 
> the type system, etc. Hopefully I don't eat my words, but this shouldn't be 
> like Rust 0.3 -> 1.0 where a similar-looking but remarkably changed 
> language emerged over the years [not meant as a criticism, btw: Rust's open 
> development process specifically, and overall community, are very 
> inspirational]
>
> On Thu, Jun 18, 2015 at 11:34 AM, J.Z. > 
> wrote:
>
>> I should have been more specific. I am just wondering if the core 
>> language itself (syntax etc.) would change a lot in the future or not. I am 
>> not expecting that Julia has a specific package that R provides. But then 
>> it's good to know whether the fundamentals like basic visualization and 
>> optimization functions are mature or not. 
>>
>>
>> On Thursday, June 18, 2015 at 10:57:08 AM UTC-4, John Myles White wrote:
>>>
>>> My answer to these questions is always the same these days: if you're 
>>> not sure that you have enough expertise to determine Julia's value for 
>>> yourself, then you should be cautious and stick to playing around with 
>>> Julia rather than trying to jump onboard wholesale. Julia is a wonderful 
>>> language and it's very usable for many things, but you shouldn't expect 
>>> that you can do all (or even most) of your work in Julia unless you're 
>>> confident that you can do the development work required to implement any 
>>> functionality that you find to be missing. Depending on your specific 
>>> interests, you might find that Julia is missing nothing or you might find 
>>> that Julia is missing everything.
>>>
>>>  -- John
>>>
>>> On Thursday, June 18, 2015 at 7:27:52 AM UTC-7, J.Z. wrote:

 Hi, 

 I have been following julia for some time and have seen lots of 
 positive comments. There are still lots of good work being put into its 
 development. I use R and Python to do lots of technical (statistical) 
 computing and would like to try julia for my work. My quick question to 
 the 
 current users and developers is that whether it is a good time to learn 
 julia now, or should I wait until the language is more mature? Could it be 
 the case that things I learn now would be broken in future releases and I 
 have to relearn everything?

 Thanks!
 JZ

>>>
>

Re: [julia-users] Re: good time to start to learn julia?

[Isaiah Norton]

>
> I am just wondering if the core language itself (syntax etc.) would change
> a lot in the future or not.


I think there is an important distinction to be made here:

- depending on the features you use, parts of your code will almost
certainly break from 0.3 -> 0.4 -> 0.5 ->  As John said, these changes
are (a) usually beneficial overall, and (b) usually not tremendously hard
to adapt to (and will hopefully become easier over time as debugging tools
and things like Lint.jl mature)

- your mental model *mostly* shouldn't. Julia probably won't be dropping
garbage collection, adopting whitespace-denoted blocks, switching to
0-based indexing (don't ask...), adopting an Idris-level of strictness in
the type system, etc. Hopefully I don't eat my words, but this shouldn't be
like Rust 0.3 -> 1.0 where a similar-looking but remarkably changed
language emerged over the years [not meant as a criticism, btw: Rust's open
development process specifically, and overall community, are very
inspirational]

On Thu, Jun 18, 2015 at 11:34 AM, J.Z.  wrote:

> I should have been more specific. I am just wondering if the core language
> itself (syntax etc.) would change a lot in the future or not. I am not
> expecting that Julia has a specific package that R provides. But then it's
> good to know whether the fundamentals like basic visualization and
> optimization functions are mature or not.
>
>
> On Thursday, June 18, 2015 at 10:57:08 AM UTC-4, John Myles White wrote:
>>
>> My answer to these questions is always the same these days: if you're not
>> sure that you have enough expertise to determine Julia's value for
>> yourself, then you should be cautious and stick to playing around with
>> Julia rather than trying to jump onboard wholesale. Julia is a wonderful
>> language and it's very usable for many things, but you shouldn't expect
>> that you can do all (or even most) of your work in Julia unless you're
>> confident that you can do the development work required to implement any
>> functionality that you find to be missing. Depending on your specific
>> interests, you might find that Julia is missing nothing or you might find
>> that Julia is missing everything.
>>
>>  -- John
>>
>> On Thursday, June 18, 2015 at 7:27:52 AM UTC-7, J.Z. wrote:
>>>
>>> Hi,
>>>
>>> I have been following julia for some time and have seen lots of positive
>>> comments. There are still lots of good work being put into its development.
>>> I use R and Python to do lots of technical (statistical) computing and
>>> would like to try julia for my work. My quick question to the current users
>>> and developers is that whether it is a good time to learn julia now, or
>>> should I wait until the language is more mature? Could it be the case that
>>> things I learn now would be broken in future releases and I have to relearn
>>> everything?
>>>
>>> Thanks!
>>> JZ
>>>
>>

[julia-users] Re: good time to start to learn julia?

[Scott Jones]

John Myles was right on when he said this:

> ...unless you're confident that you can do the development work required 
> to implement any functionality that you find to be missing.


That's true, but it is also very true that fixing any problems or 
implementing missing functionality (if you have the time) can be quite 
rewarding (if you can survive a *very* grueling and thorough review 
process, if you want to add or change anything to the core language).  I've 
learned so much in a short time by all the great advice during the review 
process,
that it's been well worth it (frustrating at times, but *don't* lose your 
patience, and many people are willing to donate a lot of their own time to 
help out)

Scott

[julia-users] Re: PyPlot not working on 0.4.0

[Scott T]

Oh and of course you could always revert Julia to an earlier version, like 
the parent commit (29d8c650) 
.
 
Using the nightlies, it's pretty much guaranteed that things will break 
occasionally. 

Cheers,
Scott

On Thursday, 18 June 2015 15:27:51 UTC+1, Linus Härenstam-Nielsen wrote:
>
> I am having problems with using PyPlot in the nightly build (version 
> 0.4.0). Typing 'using PyPlot' followed by 'plot([sin(a) for 
> a=linspace(0,2*pi)])' yields the following:
>
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "help()" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.4.0-dev+5416 (2015-06-17 00:39 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit 0bb31a0 (1 day old master)
> |__/   |  x86_64-w64-mingw32
>
> julia> using PyPlot
> Warning: New definition
> call(Type{PyCall.PyDict}, Base.Associative{#K<:Any, Any}) at 
> C:\Users\Linus\.julia\v0.4\PyCall
> rc\conversions.jl:464
> is ambiguous with:
> call(Type{PyCall.PyDict}, Base.Associative{Any, #V<:Any}) at 
> C:\Users\Linus\.julia\v0.4\PyCall
> rc\conversions.jl:463.
> To fix, define
> call(Type{PyCall.PyDict}, Base.Associative{Any, Any})
> before the new definition.
> WARNING: No working GUI backend found for matplotlib.
> C:\Anaconda\lib\site-packages\matplotlib\__init__.py:1318: UserWarning: 
>  This call to matplotlib.u
> () has no effect
> because the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
> or matplotlib.backends is imported for the first time.
>
>   warnings.warn(_use_error_msg)
> WARNING: ntuple(n::Integer,f::Function) is deprecated, use ntuple(f,n) 
> instead.
>  in depwarn at deprecated.jl:62
>  in ntuple at deprecated.jl:49
>  in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:222
>  in py2array at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:73
>  in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:429
>  in pywrap at C:\Users\Linus\.julia\v0.4\PyCall\src\PyCall.jl:305
>  in pywrap at C:\Users\Linus\.julia\v0.4\PyCall\src\PyCall.jl:304
>  in __init__ at C:\Users\Linus\.julia\v0.4\PyPlot\src\PyPlot.jl:149
>  in include at boot.jl:254
>  in include_from_node1 at loading.jl:133
>  in reload_path at loading.jl:157
>  in _require at loading.jl:69
>  in require at loading.jl:52
> while loading C:\Users\Linus\.julia\v0.4\PyPlot\src\PyPlot.jl, in 
> expression starting on line 560
>
> julia> plot([sin(a) for a=linspace(0,2*pi)])
> WARNING: ntuple(n::Integer,f::Function) is deprecated, use ntuple(f,n) 
> instead.
>  in depwarn at deprecated.jl:62
>  in ntuple at deprecated.jl:49
>  in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:222
>  in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:846
>  in jl_Function_call at 
> C:\Users\Linus\.julia\v0.4\PyCall\src\callback.jl:36
>  in pycall at C:\Users\Linus\.julia\v0.4\PyCall\src\PyCall.jl:73
>  in plot at C:\Users\Linus\.julia\v0.4\PyPlot\src\PyPlot.jl:371
>  in anonymous at no file
> while loading no file, in expression starting on line 0
> 1-element Array{Any,1}:
>  PyObject 
>
> julia> plot([sin(a) for a=linspace(0,2*pi)])
> 1-element Array{Any,1}:
>  PyObject 
>
>
> As you can see importing PyPlot produces several warnings, one of them is 
> 'WARNING: 
> No working GUI backend found for matplotlib' which led me to believe there 
> is a problem with loading matplotlib? I am using python 2.7.9 on windows 
> 8.1 with the Anaconda 2.2.0 distribution and matplotlib version 1.4.3. 
>
> The plot function returns a PyObject properly but no plot window is 
> opened. In Julia 0.3.9 everything works as you would expect with no 
> warnings.
>
> Any ideas?
>

[julia-users] Re: good time to start to learn julia?

[J.Z.]

Thanks for those strong voices. Will spend more time on Julia!

On Thursday, June 18, 2015 at 11:39:06 AM UTC-4, Scott Jones wrote:
>
> Ditto 110% to what Seth and Tom just said... and I only heard of Julia 3 
> months ago, and started contributing on GitHub less than 2 months ago...  I 
> still like C for some things (and Julia interfaces wonderfully with C), but 
> as for any other languages... I'd really prefer to just forget them!)
>
> On Thursday, June 18, 2015 at 11:29:33 AM UTC-4, Seth wrote:
>>
>>
>>
>> On Thursday, June 18, 2015 at 9:58:05 AM UTC-5, Tom Breloff wrote:
>>>
>>> Will the language change? Yes.  Will you have to relearn things? Yes. 
>>>  Will new releases break code? Yes.  Should you start using Julia now? 
>>>  YES!  
>>>
>>> The language is fairly mature, considering its age.  I've been using 
>>> Julia exclusively for 8 months now.  I used to do C/C++/Python/R and also 
>>> Java/Matlab.  If I never have to program in any of those languages again, 
>>> I'll be a happy man.  Commit to learning the "Julian" way of doing things, 
>>> and you won't regret it.
>>>
>>>
>> Just wanted to voice my strong agreement with this response. I, too, 
>> started using Julia exclusively about 8 months ago (after a frustrating 
>> false start). It's a great language that makes it easy to develop working, 
>> fast code.
>>
>>

[julia-users] Re: Is there a reason any(p, c) isn't lazy?

[Josh Langsfeld]

It's actually pretty weird. It will take the shortcut if you pass it an 
AbstractArray{Bool}, but only if it has 16 or more elements. For other 
array types, it still never takes it.

On Thursday, June 18, 2015 at 12:07:48 PM UTC-4, Seth wrote:
>
> Thanks, Josh. I opened #11750 
> .
>
> On Thursday, June 18, 2015 at 11:04:29 AM UTC-5, Josh Langsfeld wrote:
>>
>> It seems 'any' calls 'mapreduce' which calls 'mapfoldl' which has a 
>> specialization that will stop computing in the case of searching for a 
>> single true or false value. However, it seems the call to mapreduce instead 
>> goes to a more specific method that doesn't implement this shortcut. If 
>> 'any' were to call mapfoldl directly, it would do the lazy computing.
>>
>> On Thursday, June 18, 2015 at 11:18:12 AM UTC-4, Seth wrote:
>>>
>>>
>>>
>>> julia> function bar(x)
>>>  info("bar $x")
>>>  x
>>>end
>>> bar (generic function with 1 method)
>>>
>>> julia> any(v->bar(v), [false, false, true, false, false])
>>> INFO: bar false
>>> INFO: bar false
>>> INFO: bar true
>>> INFO: bar false
>>> INFO: bar false
>>> true
>>>
>>> Is there a reason the rest of the elements in the collection are 
>>> evaluated after the first true is encountered?
>>>
>>

Re: [julia-users] Reading from and writing to a process using a pipe

[Kevin Squire]

I don't think there's a standard way--at least, I couldn't find it when I
looked. I ended up rolling my own--see
https://github.com/kmsquire/VideoIO.jl/blob/master/src/util.jl.

This functionality should probably be part of readandwrite.

Cheers,
   Kevin

On Thursday, June 18, 2015, Miguel Bazdresch  wrote:

> Is there a way to read the spawned process' STDERR? Gnuplot likes to write
> most output to it. I've tried
>
> readandwrite(`gnuplot 2>&1`)
>
> but gnuplot interprets 2>&1 as a filename and fails.
>
> This, however, works:
>
> readandwrite(`gnuplot` .> "/tmp/gnuplot.err")
>
> but I'd like to avoid having to create a file.
>
> Thanks!
>
> On Wed, Jun 17, 2015 at 1:05 PM, Kevin Squire  > wrote:
>
>> `open(cmd, "w")` gives back a tuple.  Try using
>>
>> f, p = open(`gnuplot`,"w")
>> write(f, "plot sin(x)")
>>
>> There was a bit of discussion when this change was made (I couldn't find
>> it with a quick search), about this returning a tuple--it's a little
>> unintuitive, and could be `fixed` in a few different ways (easiest:
>> returning a complex type that can be written to and read from), but it's
>> probably been off most people's radar.  If you're up for it, why don't you
>> open an issue (if one doesn't exist).
>>
>> Anyway, for your particular application, you probably want `readandwrite`:
>>
>> help?> readandwrite
>> search: readandwrite
>>
>> Base.readandwrite(command)
>>
>>Starts running a command asynchronously, and returns a tuple
>>(stdout,stdin,process) of the output stream and input stream of the
>>process, and the process object itself.
>>
>> Which *also* returns a tuple (but at least now you know).
>>
>> See also http://blog.leahhanson.us/running-shell-commands-from-julia.html,
>> which has a full rundown of reading and writing from processes.
>>
>> Cheers!
>>Kevin
>>
>> On Wed, Jun 17, 2015 at 9:03 AM, Miguel Bazdresch > > wrote:
>>
>>> Hello,
>>>
>>> Gaston.jl is a plotting package based on gnuplot. Gnuplot is
>>> command-line tool, so I send commands to it via a pipe. I open the pipe (on
>>> Linux) with a ccall to "popen", and write gnuplot commands to the pipe
>>> using a ccall to fputs.
>>>
>>> This works fine, but I'm trying to see if Julia's native pipe and stream
>>> functionality can make this process more Julian and, in the process, more
>>> cross-platform. The documentation is encouraging:
>>>
>>> "You can use [a Cmd] object to connect the command to others via pipes,
>>> run it, and read or write to it." and "Julia provides a rich interface to
>>> deal with streaming I/O objects such as terminals, pipes and TCP sockets."
>>> Unfortunately, I just can't figure out how to use Julia's functionality for
>>> this purpose. This is what I've tried (I am on Julia 0.3.9):
>>>
>>> First, I tried using `open` with read and write:
>>>
>>> julia> f=open(`gnuplot`,"r+")
>>> ERROR: ArgumentError("mode must be \"r\" or \"w\", not \"r+\"")
>>>
>>> So I tried with write only:
>>>
>>> julia> f=open(`gnuplot`,"w")
>>> (Pipe(open, 0 bytes waiting),Process(`gnuplot`, ProcessRunning))
>>>
>>> So far, this looks good. I can see a gnuplot process running.
>>>
>>> Then I try to `write` to the pipe:
>>>
>>> julia> write(f,"plot sin(x)")
>>> ERROR: `write` has no method matching write(::(Pipe,Process),
>>> ::ASCIIString)
>>>
>>> OK, so let's try with `println`:
>>>
>>> julia> println(f,"plot sin(x)")
>>> (Pipe(open, 0 bytes waiting),Process(`gnuplot`, ProcessRunning))plot
>>> sin(x)
>>>
>>> and no plot is produced.
>>>
>>> I can't figure out how to read from the pipe, either:
>>>
>>> julia> readbytes(f)
>>> ERROR: `readbytes` has no method matching readbytes(::(Pipe,Process))
>>>
>>> julia> readall(f)
>>> ERROR: `readall` has no method matching readall(::(Pipe,Process))
>>>
>>> I'd appreciate any pointers. Thanks!
>>>
>>> -- mb
>>>
>>>
>>
>

[julia-users] Re: Is there a reason any(p, c) isn't lazy?

[Seth]

Thanks, Josh. I opened #11750 
.

On Thursday, June 18, 2015 at 11:04:29 AM UTC-5, Josh Langsfeld wrote:
>
> It seems 'any' calls 'mapreduce' which calls 'mapfoldl' which has a 
> specialization that will stop computing in the case of searching for a 
> single true or false value. However, it seems the call to mapreduce instead 
> goes to a more specific method that doesn't implement this shortcut. If 
> 'any' were to call mapfoldl directly, it would do the lazy computing.
>
> On Thursday, June 18, 2015 at 11:18:12 AM UTC-4, Seth wrote:
>>
>>
>>
>> julia> function bar(x)
>>  info("bar $x")
>>  x
>>end
>> bar (generic function with 1 method)
>>
>> julia> any(v->bar(v), [false, false, true, false, false])
>> INFO: bar false
>> INFO: bar false
>> INFO: bar true
>> INFO: bar false
>> INFO: bar false
>> true
>>
>> Is there a reason the rest of the elements in the collection are 
>> evaluated after the first true is encountered?
>>
>

[julia-users] Re: Multivariate optimization with bounds

[John Myles White]

Try NLopt.

 -- John

On Thursday, June 18, 2015 at 8:35:20 AM UTC-7, Nils Gudat wrote:
>
> I'm trying to minimize a function of multiple variables using the Optim 
> package. In my original Matlab code, I'm supplying two arrays to fmincon to 
> set upper and lower bounds on each of the variables, but it seems the 
> optimize function in Optim only allows for bounds in the univariate case. 
>
> Is this implemented somewhere else in Julia?
>

[julia-users] Re: good time to start to learn julia?

[John Myles White]

There will definitely still be some languages to the core language.

But, in my experience, the changes to the core language are seldom very 
burdensome. They're almost always large improvements to the language, so 
the code that you have to rewrite ends up being vastly easier to maintain. 
This, for example, was my experience when both default and keyword 
arguments were introduced into the language.

That said, I do spend a lot of time working on Julia code so I'm not so 
upset by the maintenance overhead.

Sounds like a lot of the newer arrivals to Julia are even more positive 
than I am, so it can't hurt to try.

 -- John

On Thursday, June 18, 2015 at 9:01:52 AM UTC-7, J.Z. wrote:
>
> I should have been more specific. I am just wondering if the core language 
> itself (syntax etc.) would change a lot in the future or not. I am not 
> expecting that Julia has a specific package that R provides. But then it's 
> good to know whether the fundamentals like basic visualization and 
> optimization functions are mature or not. 
>
> On Thursday, June 18, 2015 at 10:57:08 AM UTC-4, John Myles White wrote:
>>
>> My answer to these questions is always the same these days: if you're not 
>> sure that you have enough expertise to determine Julia's value for 
>> yourself, then you should be cautious and stick to playing around with 
>> Julia rather than trying to jump onboard wholesale. Julia is a wonderful 
>> language and it's very usable for many things, but you shouldn't expect 
>> that you can do all (or even most) of your work in Julia unless you're 
>> confident that you can do the development work required to implement any 
>> functionality that you find to be missing. Depending on your specific 
>> interests, you might find that Julia is missing nothing or you might find 
>> that Julia is missing everything.
>>
>>  -- John
>>
>> On Thursday, June 18, 2015 at 7:27:52 AM UTC-7, J.Z. wrote:
>>>
>>> Hi, 
>>>
>>> I have been following julia for some time and have seen lots of positive 
>>> comments. There are still lots of good work being put into its development. 
>>> I use R and Python to do lots of technical (statistical) computing and 
>>> would like to try julia for my work. My quick question to the current users 
>>> and developers is that whether it is a good time to learn julia now, or 
>>> should I wait until the language is more mature? Could it be the case that 
>>> things I learn now would be broken in future releases and I have to relearn 
>>> everything?
>>>
>>> Thanks!
>>> JZ
>>>
>>

[julia-users] Re: Is there a reason any(p, c) isn't lazy?

[Josh Langsfeld]

It seems 'any' calls 'mapreduce' which calls 'mapfoldl' which has a 
specialization that will stop computing in the case of searching for a 
single true or false value. However, it seems the call to mapreduce instead 
goes to a more specific method that doesn't implement this shortcut. If 
'any' were to call mapfoldl directly, it would do the lazy computing.

On Thursday, June 18, 2015 at 11:18:12 AM UTC-4, Seth wrote:
>
>
>
> julia> function bar(x)
>  info("bar $x")
>  x
>end
> bar (generic function with 1 method)
>
> julia> any(v->bar(v), [false, false, true, false, false])
> INFO: bar false
> INFO: bar false
> INFO: bar true
> INFO: bar false
> INFO: bar false
> true
>
> Is there a reason the rest of the elements in the collection are evaluated 
> after the first true is encountered?
>

[julia-users] inverse function error?

[SG]

Hi All, 

I am a novice to Julia. 

While I am running the attached julia program, I found "inverse" function 
throws an error? 
However it worked well in Matlab. Can you help me? Many thanks.





lag0.jl
Description: Binary data


example1_rev.jl
Description: Binary data
,Inflation
1948Q1,8.4685373161
1948Q2,8.626617999
1948Q3,8.1440129595
1948Q4,4.4294955046
1949Q1,1.3741439494
1949Q2,-0.3184571541
1949Q3,-2.8268277883
1949Q4,-2.1455778394
1950Q1,-1.5009188995
1950Q2,-0.6299318267
1950Q3,2.0302448585
1950Q4,4.2713747474
1951Q1,8.564404428
1951Q2,8.7766211618
1951Q3,6.9045371469
1951Q4,6.3692528033
1952Q1,2.7671832034
1952Q2,2.0598341129
1952Q3,2.7888499122
1952Q4,1.4347768223
1953Q1,0.7667805208
1953Q2,0.8770681093
1953Q3,0.6602463501
1953Q4,0.7214528994
1954Q1,1.2444018028
1954Q2,0.7085627515
1954Q3,-0.0123336831
1954Q4,-0.4969998158
1955Q1,-0.5953695298
1955Q2,-0.5714233563
1955Q3,-0.2364186471
1955Q4,0.3730423224
1956Q1,0.2484968957
1956Q2,1.040558176
1956Q3,1.9967798064
1956Q4,2.5486824224
1957Q1,3.3554485678
1957Q2,3.5488653853
1957Q3,3.4066871969
1957Q4,3.0386359058
1958Q1,3.3975891895
1958Q2,3.2201907795
1958Q3,2.2739125577
1958Q4,1.8952735282
1959Q1,0.8897593789
1959Q2,0.3908295391
1959Q3,0.9636745953
1959Q4,1.4633757762
1960Q1,1.3815336814
1960Q2,1.8085289491
1960Q3,1.34917
1960Q4,1.3863407274
1961Q1,1.4968691888
1961Q2,0.864190176
1961Q3,1.1981665564
1961Q4,0.7027192621
1962Q1,0.8895298851
1962Q2,1.2989361249
1962Q3,1.1946215824
1962Q4,1.2920615567
1963Q1,1.221584666
1963Q2,1.0313480132
1963Q3,1.354969964
1963Q4,1.3836785439
1964Q1,1.4765561298
1964Q2,1.4524194909
1964Q3,1.0684906821
1964Q4,1.2581594652
1965Q1,1.157197342
1965Q2,1.6324043283
1965Q3,1.703064599
1965Q4,1.7686541391
1966Q1,2.3887137264
1966Q2,2.6535371839
1966Q3,3.2186943786
1966Q4,3.5076144993
1967Q1,2.8310334073
1967Q2,2.5340383051
1967Q3,2.672638161
1967Q4,2.9458895144
1968Q1,3.6726867275
1968Q2,4.0377204539
1968Q3,4.3802871796
1968Q4,4.5222348525
1969Q1,4.7574355
1969Q2,5.3559726984
1969Q3,5.3763448222
1969Q4,5.6684644048
1970Q1,6.0407947626
1970Q2,5.8632002691
1970Q3,5.5302092572
1970Q4,5.4489164258
1971Q1,4.7005603833
1971Q2,4.2233004328
1971Q3,4.1815198972
1971Q4,3.4749468134
1972Q1,3.4455972037
1972Q2,3.1754981977
1972Q3,2.98506
1972Q4,3.2787469318
1973Q1,4.0286153005
1973Q2,5.4564162653
1973Q3,6.6084819515
1973Q4,8.0814045156
1974Q1,9.4520220295
1974Q2,10.0246264954
1974Q3,10.8470764802
1974Q4,11.3737145296
1975Q1,10.5601514536
1975Q2,9.1141496524
1975Q3,8.3267392554
1975Q4,7.1247742578
1976Q1,6.1488752919
1976Q2,5.8409562021
1976Q3,5.4391873832
1976Q4,5.0576493324
1977Q1,5.733809
1977Q2,6.5760365936
1977Q3,6.3669012945
1977Q4,6.3852914369
1978Q1,6.2751809522
1978Q2,6.7903858502
1978Q3,7.7169677907
1978Q4,8.5529998348
1979Q1,9.3313407219
1979Q2,10.2132068221
1979Q3,11.0842550124
1979Q4,11.9014257111
1980Q1,13.2844092033
1980Q2,13.4766019843
1980Q3,12.1654819882
1980Q4,11.8132704287
1981Q1,10.6746823258
1981Q2,9.4171278325
1981Q3,10.30302151
1981Q4,9.1541895741
1982Q1,7.3098690177
1982Q2,6.6771299249
1982Q3,5.6560736325
1982Q4,4.3480718817
1983Q1,3.5310773748
1983Q2,3.2497960238
1983Q3,2.4948193598
1983Q4,3.1821722843
1984Q1,4.5215635323
1984Q2,4.3107790453
1984Q3,4.2060230683
1984Q4,4.0705025706
1985Q1,3.5759934668
1985Q2,3.54349422
1985Q3,3.2976804042
1985Q4,3.4528651509
1986Q1,3.058567226
1986Q2,1.6644878559
1986Q3,1.654370283
1986Q4,1.3370400136
1987Q1,2.0178919924
1987Q2,3.6323170112
1987Q3,4.0782275688
1987Q4,4.3112877934
1988Q1,3.8890809076
1988Q2,3.9028252838
1988Q3,4.058790281
1988Q4,4.2160791481
1989Q1,4.5681260458
1989Q2,5.0313056536
1989Q3,4.5990354229
1989Q4,4.5233928496
1990Q1,5.1005116806
1990Q2,4.4815042225
1990Q3,5.4133001112
1990Q4,6.0875081174
1991Q1,5.1260346684
1991Q2,4.7330124911
1991Q3,3.78131252
1991Q4,2.9221047693
1992Q1,2.8525314661
1992Q2,3.0273903908
1992Q3,3.0284841559
1992Q4,3.0745233897
1993Q1,3.1239548982
1993Q2,3.0772639328
1993Q3,2.7783312856
1993Q4,2.7316126201
1994Q1,2.5077516493
1994Q2,2.3545871958
1994Q3,2.81495371
1994Q4,2.5700338975
1995Q1,2.8007430975
1995Q2,3.0484651896
1995Q3,2.6293397742
1995Q4,2.5925391998
1996Q1,2.7458230803
1996Q2,2.7878699172
1996Q3,2.8587881621
1996Q4,3.1800786598
1997Q1,2.9026082931
1997Q2,2.2757823107
1997Q3,2.2006234312
1997Q4,1.8733431887
1998Q1,1.4717383596
1998Q2,1.5708506016
1998Q3,1.5837577681
1998Q4,1.5142017533
1999Q1,1.6731628715
1999Q2,2.0904993849
1999Q3,2.3190134699
1999Q4,2.5860252639
2000Q1,3.2050130283
2000Q2,3.2402290638
2000Q3,3.410158438
2000Q4,3.3855468266
2001Q1,3.3536803016
2001Q2,3.270881533
2001Q3,2.6431185838
2001Q4,1.8576460055
2002Q1,1.224139831
2002Q2,1.3091217531
2002Q3,1.5639915525
2002Q4,2.2284239903
2003Q1,2.9326897095
2003Q2,1.986090497
2003Q3,2.1923532887
2003Q4,1.9820538821
2004Q1,1.8018327826
2004Q2,2.7472637382
2004Q3,2.6400614392
2004Q4,3.3287737866
2005Q1,2.9896677256
2005Q2,2.8815648068
2005Q3,3.7453038493
2005Q4,3.6087353121
2006Q1,3.6081283299
2006Q2,3.8654355154
2006Q3,3.2888060986
2006Q4,1.9297385143

[julia-users] Re: good time to start to learn julia?

[J.Z.]

I should have been more specific. I am just wondering if the core language 
itself (syntax etc.) would change a lot in the future or not. I am not 
expecting that Julia has a specific package that R provides. But then it's 
good to know whether the fundamentals like basic visualization and 
optimization functions are mature or not. 

On Thursday, June 18, 2015 at 10:57:08 AM UTC-4, John Myles White wrote:
>
> My answer to these questions is always the same these days: if you're not 
> sure that you have enough expertise to determine Julia's value for 
> yourself, then you should be cautious and stick to playing around with 
> Julia rather than trying to jump onboard wholesale. Julia is a wonderful 
> language and it's very usable for many things, but you shouldn't expect 
> that you can do all (or even most) of your work in Julia unless you're 
> confident that you can do the development work required to implement any 
> functionality that you find to be missing. Depending on your specific 
> interests, you might find that Julia is missing nothing or you might find 
> that Julia is missing everything.
>
>  -- John
>
> On Thursday, June 18, 2015 at 7:27:52 AM UTC-7, J.Z. wrote:
>>
>> Hi, 
>>
>> I have been following julia for some time and have seen lots of positive 
>> comments. There are still lots of good work being put into its development. 
>> I use R and Python to do lots of technical (statistical) computing and 
>> would like to try julia for my work. My quick question to the current users 
>> and developers is that whether it is a good time to learn julia now, or 
>> should I wait until the language is more mature? Could it be the case that 
>> things I learn now would be broken in future releases and I have to relearn 
>> everything?
>>
>> Thanks!
>> JZ
>>
>

[julia-users] Re: PyPlot not working on 0.4.0

[Scott T]

Hi Linus,

This is due to a change in Julia master 

 which 
altered the way timers work. It's broken PyCall and therefore PyPlot in 
this particular case.

There are pending pull requests on PyCall which should fix this, but they 
haven't been merged yet. You could check this one 
 out locally by doing the 
following (at the command line):

   - go to your Julia package directory - not sure what it is on Windows
   - go to v0.4/PyCall
   - git fetch origin pull/155/head:fix-timer-api
  - this will make a copy of the pull request on your machine in a 
  branch called "fix-timer-api"
   - git checkout fix-timer-api
  - this will switch to that branch
   
This got PyPlot working again for me. Note that it will freeze your version 
of PyCall so, once these fixes are actually merged into the package itself, 
you can swap to the latest version by doing Pkg.checkout("PyCall") from 
within Julia.

Cheers,
Scott


On Thursday, 18 June 2015 15:27:51 UTC+1, Linus Härenstam-Nielsen wrote:
>
> I am having problems with using PyPlot in the nightly build (version 
> 0.4.0). Typing 'using PyPlot' followed by 'plot([sin(a) for 
> a=linspace(0,2*pi)])' yields the following:
>
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "help()" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.4.0-dev+5416 (2015-06-17 00:39 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit 0bb31a0 (1 day old master)
> |__/   |  x86_64-w64-mingw32
>
> julia> using PyPlot
> Warning: New definition
> call(Type{PyCall.PyDict}, Base.Associative{#K<:Any, Any}) at 
> C:\Users\Linus\.julia\v0.4\PyCall
> rc\conversions.jl:464
> is ambiguous with:
> call(Type{PyCall.PyDict}, Base.Associative{Any, #V<:Any}) at 
> C:\Users\Linus\.julia\v0.4\PyCall
> rc\conversions.jl:463.
> To fix, define
> call(Type{PyCall.PyDict}, Base.Associative{Any, Any})
> before the new definition.
> WARNING: No working GUI backend found for matplotlib.
> C:\Anaconda\lib\site-packages\matplotlib\__init__.py:1318: UserWarning: 
>  This call to matplotlib.u
> () has no effect
> because the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
> or matplotlib.backends is imported for the first time.
>
>   warnings.warn(_use_error_msg)
> WARNING: ntuple(n::Integer,f::Function) is deprecated, use ntuple(f,n) 
> instead.
>  in depwarn at deprecated.jl:62
>  in ntuple at deprecated.jl:49
>  in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:222
>  in py2array at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:73
>  in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:429
>  in pywrap at C:\Users\Linus\.julia\v0.4\PyCall\src\PyCall.jl:305
>  in pywrap at C:\Users\Linus\.julia\v0.4\PyCall\src\PyCall.jl:304
>  in __init__ at C:\Users\Linus\.julia\v0.4\PyPlot\src\PyPlot.jl:149
>  in include at boot.jl:254
>  in include_from_node1 at loading.jl:133
>  in reload_path at loading.jl:157
>  in _require at loading.jl:69
>  in require at loading.jl:52
> while loading C:\Users\Linus\.julia\v0.4\PyPlot\src\PyPlot.jl, in 
> expression starting on line 560
>
> julia> plot([sin(a) for a=linspace(0,2*pi)])
> WARNING: ntuple(n::Integer,f::Function) is deprecated, use ntuple(f,n) 
> instead.
>  in depwarn at deprecated.jl:62
>  in ntuple at deprecated.jl:49
>  in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:222
>  in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:846
>  in jl_Function_call at 
> C:\Users\Linus\.julia\v0.4\PyCall\src\callback.jl:36
>  in pycall at C:\Users\Linus\.julia\v0.4\PyCall\src\PyCall.jl:73
>  in plot at C:\Users\Linus\.julia\v0.4\PyPlot\src\PyPlot.jl:371
>  in anonymous at no file
> while loading no file, in expression starting on line 0
> 1-element Array{Any,1}:
>  PyObject 
>
> julia> plot([sin(a) for a=linspace(0,2*pi)])
> 1-element Array{Any,1}:
>  PyObject 
>
>
> As you can see importing PyPlot produces several warnings, one of them is 
> 'WARNING: 
> No working GUI backend found for matplotlib' which led me to believe there 
> is a problem with loading matplotlib? I am using python 2.7.9 on windows 
> 8.1 with the Anaconda 2.2.0 distribution and matplotlib version 1.4.3. 
>
> The plot function returns a PyObject properly but no plot window is 
> opened. In Julia 0.3.9 everything works as you would expect with no 
> warnings.
>
> Any ideas?
>

[julia-users] Re: Set precision when printing to file

[Scott Jones]

I tried directly e-mailing him (after having gotten a lot of grief for 
posting so much!), but I haven't heard back...

On Thursday, June 18, 2015 at 10:30:05 AM UTC-4, Tom Breloff wrote:
>
> Scott: I remember there being another discussion but I can't seem to find 
> it.  How did you try to get in touch?  Do you want to start a github issue 
> and I'll comment there?
>
> On Thursday, June 18, 2015 at 10:20:08 AM UTC-4, Scott Jones wrote:
>>
>> This was already discussed recently, here on julia-users, I'm trying to 
>> get in touch with Dahua Lin (author of Formatting.jl)
>> to see about adding a simpler `sfmt` that would help with this).
>>
>> On Thursday, June 18, 2015 at 10:13:46 AM UTC-4, Tom Breloff wrote:
>>>
>>> I wonder if what we really need is just some extra additions to 
>>> Formatting.jl (since I think this is the best place to keep standard 
>>> formatting calls).  We could add fmt2, fmt3, etc which would be meant for 
>>> formatting floats to that precision.  I suspect that's the most common use 
>>> of formatting.  Additionally, just a shorter name than "generate_formatter" 
>>> might help adoption for non-standard formatting.  If this makes sense to 
>>> people, I'll start an issue on github, and perhaps a PR as well.
>>>
>>>
>>> julia> using Formatting
>>>
>>> julia> fmt2 = generate_formatter("%1.2f")
>>> sprintf_JTEuMmY! (generic function with 1 method)
>>>
>>> julia> fmt3 = generate_formatter("%1.3f")
>>> sprintf_JTEuM2Y! (generic function with 1 method)
>>>
>>> julia> @time fmt2(31231.345435245)
>>>   55.763 milliseconds (33974 allocations: 1444 KB)
>>> "31231.35"
>>>
>>> julia> @time fmt2(31231.345435245)
>>>   13.573 microseconds (15 allocations: 608 bytes)
>>> "31231.35"
>>>
>>> julia> @time fmt3(31231.345435245)
>>>   11.193 milliseconds (5882 allocations: 254 KB)
>>> "31231.345"
>>>
>>> julia> @time fmt3(31231.345435245)
>>>   16.231 microseconds (15 allocations: 608 bytes)
>>> "31231.345"
>>>
>>>
>>>
>>>
>>> On Thursday, June 18, 2015 at 3:55:01 AM UTC-4, cormu...@mac.com wrote:

 You could use a type: 

 julia> type Out 
   n::Float64 
end 

 julia> function Base.show(io::IO, n::Out) 
print(io, "$(round(n.n, 2))") 
end 
 show (generic function with 83 methods) 

 then you can just use Out(x) whenever you want x rounded to 2 d.p. 

 julia> for i in 0.7454539:1.5:5 
println("i is $i and displayed as $(Out(i))") 
end 
 i is 0.7454539 and displayed as 0.75 
 i is 2.24545392 and displayed as 2.25 
 i is 3.74545392 and displayed as 3.75   

[julia-users] Re: Set precision when printing to file

[Scott Jones]

Ah, I forgot, it wasn't in julia-users, it was in julia-dev!

https://groups.google.com/forum/#!topic/julia-dev/KloaO7zTYwo

On Thursday, June 18, 2015 at 10:30:05 AM UTC-4, Tom Breloff wrote:
>
> Scott: I remember there being another discussion but I can't seem to find 
> it.  How did you try to get in touch?  Do you want to start a github issue 
> and I'll comment there?
>
> On Thursday, June 18, 2015 at 10:20:08 AM UTC-4, Scott Jones wrote:
>>
>> This was already discussed recently, here on julia-users, I'm trying to 
>> get in touch with Dahua Lin (author of Formatting.jl)
>> to see about adding a simpler `sfmt` that would help with this).
>>
>> On Thursday, June 18, 2015 at 10:13:46 AM UTC-4, Tom Breloff wrote:
>>>
>>> I wonder if what we really need is just some extra additions to 
>>> Formatting.jl (since I think this is the best place to keep standard 
>>> formatting calls).  We could add fmt2, fmt3, etc which would be meant for 
>>> formatting floats to that precision.  I suspect that's the most common use 
>>> of formatting.  Additionally, just a shorter name than "generate_formatter" 
>>> might help adoption for non-standard formatting.  If this makes sense to 
>>> people, I'll start an issue on github, and perhaps a PR as well.
>>>
>>>
>>> julia> using Formatting
>>>
>>> julia> fmt2 = generate_formatter("%1.2f")
>>> sprintf_JTEuMmY! (generic function with 1 method)
>>>
>>> julia> fmt3 = generate_formatter("%1.3f")
>>> sprintf_JTEuM2Y! (generic function with 1 method)
>>>
>>> julia> @time fmt2(31231.345435245)
>>>   55.763 milliseconds (33974 allocations: 1444 KB)
>>> "31231.35"
>>>
>>> julia> @time fmt2(31231.345435245)
>>>   13.573 microseconds (15 allocations: 608 bytes)
>>> "31231.35"
>>>
>>> julia> @time fmt3(31231.345435245)
>>>   11.193 milliseconds (5882 allocations: 254 KB)
>>> "31231.345"
>>>
>>> julia> @time fmt3(31231.345435245)
>>>   16.231 microseconds (15 allocations: 608 bytes)
>>> "31231.345"
>>>
>>>
>>>
>>>
>>> On Thursday, June 18, 2015 at 3:55:01 AM UTC-4, cormu...@mac.com wrote:

 You could use a type: 

 julia> type Out 
   n::Float64 
end 

 julia> function Base.show(io::IO, n::Out) 
print(io, "$(round(n.n, 2))") 
end 
 show (generic function with 83 methods) 

 then you can just use Out(x) whenever you want x rounded to 2 d.p. 

 julia> for i in 0.7454539:1.5:5 
println("i is $i and displayed as $(Out(i))") 
end 
 i is 0.7454539 and displayed as 0.75 
 i is 2.24545392 and displayed as 2.25 
 i is 3.74545392 and displayed as 3.75   

[julia-users] Re: good time to start to learn julia?

[Scott Jones]

Ditto 110% to what Seth and Tom just said... and I only heard of Julia 3 
months ago, and started contributing on GitHub less than 2 months ago...  I 
still like C for some things (and Julia interfaces wonderfully with C), but 
as for any other languages... I'd really prefer to just forget them!)

On Thursday, June 18, 2015 at 11:29:33 AM UTC-4, Seth wrote:
>
>
>
> On Thursday, June 18, 2015 at 9:58:05 AM UTC-5, Tom Breloff wrote:
>>
>> Will the language change? Yes.  Will you have to relearn things? Yes. 
>>  Will new releases break code? Yes.  Should you start using Julia now? 
>>  YES!  
>>
>> The language is fairly mature, considering its age.  I've been using 
>> Julia exclusively for 8 months now.  I used to do C/C++/Python/R and also 
>> Java/Matlab.  If I never have to program in any of those languages again, 
>> I'll be a happy man.  Commit to learning the "Julian" way of doing things, 
>> and you won't regret it.
>>
>>
> Just wanted to voice my strong agreement with this response. I, too, 
> started using Julia exclusively about 8 months ago (after a frustrating 
> false start). It's a great language that makes it easy to develop working, 
> fast code.
>
>

Re: [julia-users] Overloading `eval`

[Christoph Ortner]

I didn't fully understand this: are you saying that, unless I use 
`baremodule`, I cannot overload `eval`?

my usage is simply that I have  type A, say, that defines a function and I 
want to call eval(A, arg) to evaluate. I am perfectly happy to just call 
`feval` instead of `eval`, but I was curious.

Many thanks,
Christoph

[julia-users] Multivariate optimization with bounds

[Nils Gudat]

I'm trying to minimize a function of multiple variables using the Optim 
package. In my original Matlab code, I'm supplying two arrays to fmincon to 
set upper and lower bounds on each of the variables, but it seems the 
optimize function in Optim only allows for bounds in the univariate case. 

Is this implemented somewhere else in Julia?

[julia-users] Re: good time to start to learn julia?

[Seth]

On Thursday, June 18, 2015 at 9:58:05 AM UTC-5, Tom Breloff wrote:
>
> Will the language change? Yes.  Will you have to relearn things? Yes. 
>  Will new releases break code? Yes.  Should you start using Julia now? 
>  YES!  
>
> The language is fairly mature, considering its age.  I've been using Julia 
> exclusively for 8 months now.  I used to do C/C++/Python/R and also 
> Java/Matlab.  If I never have to program in any of those languages again, 
> I'll be a happy man.  Commit to learning the "Julian" way of doing things, 
> and you won't regret it.
>
>
Just wanted to voice my strong agreement with this response. I, too, 
started using Julia exclusively about 8 months ago (after a frustrating 
false start). It's a great language that makes it easy to develop working, 
fast code.

Re: [julia-users] Reading from and writing to a process using a pipe

[Miguel Bazdresch]

Is there a way to read the spawned process' STDERR? Gnuplot likes to write
most output to it. I've tried

readandwrite(`gnuplot 2>&1`)

but gnuplot interprets 2>&1 as a filename and fails.

This, however, works:

readandwrite(`gnuplot` .> "/tmp/gnuplot.err")

but I'd like to avoid having to create a file.

Thanks!

On Wed, Jun 17, 2015 at 1:05 PM, Kevin Squire 
wrote:

> `open(cmd, "w")` gives back a tuple.  Try using
>
> f, p = open(`gnuplot`,"w")
> write(f, "plot sin(x)")
>
> There was a bit of discussion when this change was made (I couldn't find
> it with a quick search), about this returning a tuple--it's a little
> unintuitive, and could be `fixed` in a few different ways (easiest:
> returning a complex type that can be written to and read from), but it's
> probably been off most people's radar.  If you're up for it, why don't you
> open an issue (if one doesn't exist).
>
> Anyway, for your particular application, you probably want `readandwrite`:
>
> help?> readandwrite
> search: readandwrite
>
> Base.readandwrite(command)
>
>Starts running a command asynchronously, and returns a tuple
>(stdout,stdin,process) of the output stream and input stream of the
>process, and the process object itself.
>
> Which *also* returns a tuple (but at least now you know).
>
> See also http://blog.leahhanson.us/running-shell-commands-from-julia.html,
> which has a full rundown of reading and writing from processes.
>
> Cheers!
>Kevin
>
> On Wed, Jun 17, 2015 at 9:03 AM, Miguel Bazdresch 
> wrote:
>
>> Hello,
>>
>> Gaston.jl is a plotting package based on gnuplot. Gnuplot is command-line
>> tool, so I send commands to it via a pipe. I open the pipe (on Linux) with
>> a ccall to "popen", and write gnuplot commands to the pipe using a ccall to
>> fputs.
>>
>> This works fine, but I'm trying to see if Julia's native pipe and stream
>> functionality can make this process more Julian and, in the process, more
>> cross-platform. The documentation is encouraging:
>>
>> "You can use [a Cmd] object to connect the command to others via pipes,
>> run it, and read or write to it." and "Julia provides a rich interface to
>> deal with streaming I/O objects such as terminals, pipes and TCP sockets."
>> Unfortunately, I just can't figure out how to use Julia's functionality for
>> this purpose. This is what I've tried (I am on Julia 0.3.9):
>>
>> First, I tried using `open` with read and write:
>>
>> julia> f=open(`gnuplot`,"r+")
>> ERROR: ArgumentError("mode must be \"r\" or \"w\", not \"r+\"")
>>
>> So I tried with write only:
>>
>> julia> f=open(`gnuplot`,"w")
>> (Pipe(open, 0 bytes waiting),Process(`gnuplot`, ProcessRunning))
>>
>> So far, this looks good. I can see a gnuplot process running.
>>
>> Then I try to `write` to the pipe:
>>
>> julia> write(f,"plot sin(x)")
>> ERROR: `write` has no method matching write(::(Pipe,Process),
>> ::ASCIIString)
>>
>> OK, so let's try with `println`:
>>
>> julia> println(f,"plot sin(x)")
>> (Pipe(open, 0 bytes waiting),Process(`gnuplot`, ProcessRunning))plot
>> sin(x)
>>
>> and no plot is produced.
>>
>> I can't figure out how to read from the pipe, either:
>>
>> julia> readbytes(f)
>> ERROR: `readbytes` has no method matching readbytes(::(Pipe,Process))
>>
>> julia> readall(f)
>> ERROR: `readall` has no method matching readall(::(Pipe,Process))
>>
>> I'd appreciate any pointers. Thanks!
>>
>> -- mb
>>
>>
>

[julia-users] Is there a reason any(p, c) isn't lazy?

[Seth]

julia> function bar(x)
 info("bar $x")
 x
   end
bar (generic function with 1 method)

julia> any(v->bar(v), [false, false, true, false, false])
INFO: bar false
INFO: bar false
INFO: bar true
INFO: bar false
INFO: bar false
true

Is there a reason the rest of the elements in the collection are evaluated 
after the first true is encountered?

[julia-users] Re: Set precision when printing to file

[Simon Byrne]

You might be thinking of
https://github.com/JuliaLang/julia/issues/10610

On Thursday, 18 June 2015 15:30:05 UTC+1, Tom Breloff wrote:
>
> Scott: I remember there being another discussion but I can't seem to find 
> it.  How did you try to get in touch?  Do you want to start a github issue 
> and I'll comment there?
>
> On Thursday, June 18, 2015 at 10:20:08 AM UTC-4, Scott Jones wrote:
>>
>> This was already discussed recently, here on julia-users, I'm trying to 
>> get in touch with Dahua Lin (author of Formatting.jl)
>> to see about adding a simpler `sfmt` that would help with this).
>>
>> On Thursday, June 18, 2015 at 10:13:46 AM UTC-4, Tom Breloff wrote:
>>>
>>> I wonder if what we really need is just some extra additions to 
>>> Formatting.jl (since I think this is the best place to keep standard 
>>> formatting calls).  We could add fmt2, fmt3, etc which would be meant for 
>>> formatting floats to that precision.  I suspect that's the most common use 
>>> of formatting.  Additionally, just a shorter name than "generate_formatter" 
>>> might help adoption for non-standard formatting.  If this makes sense to 
>>> people, I'll start an issue on github, and perhaps a PR as well.
>>>
>>>
>>> julia> using Formatting
>>>
>>> julia> fmt2 = generate_formatter("%1.2f")
>>> sprintf_JTEuMmY! (generic function with 1 method)
>>>
>>> julia> fmt3 = generate_formatter("%1.3f")
>>> sprintf_JTEuM2Y! (generic function with 1 method)
>>>
>>> julia> @time fmt2(31231.345435245)
>>>   55.763 milliseconds (33974 allocations: 1444 KB)
>>> "31231.35"
>>>
>>> julia> @time fmt2(31231.345435245)
>>>   13.573 microseconds (15 allocations: 608 bytes)
>>> "31231.35"
>>>
>>> julia> @time fmt3(31231.345435245)
>>>   11.193 milliseconds (5882 allocations: 254 KB)
>>> "31231.345"
>>>
>>> julia> @time fmt3(31231.345435245)
>>>   16.231 microseconds (15 allocations: 608 bytes)
>>> "31231.345"
>>>
>>>
>>>
>>>
>>> On Thursday, June 18, 2015 at 3:55:01 AM UTC-4, cormu...@mac.com wrote:

 You could use a type: 

 julia> type Out 
   n::Float64 
end 

 julia> function Base.show(io::IO, n::Out) 
print(io, "$(round(n.n, 2))") 
end 
 show (generic function with 83 methods) 

 then you can just use Out(x) whenever you want x rounded to 2 d.p. 

 julia> for i in 0.7454539:1.5:5 
println("i is $i and displayed as $(Out(i))") 
end 
 i is 0.7454539 and displayed as 0.75 
 i is 2.24545392 and displayed as 2.25 
 i is 3.74545392 and displayed as 3.75   

[julia-users] Re: good time to start to learn julia?

[Tom Breloff]

Will the language change? Yes.  Will you have to relearn things? Yes.  Will 
new releases break code? Yes.  Should you start using Julia now?  YES!  

The language is fairly mature, considering its age.  I've been using Julia 
exclusively for 8 months now.  I used to do C/C++/Python/R and also 
Java/Matlab.  If I never have to program in any of those languages again, 
I'll be a happy man.  Commit to learning the "Julian" way of doing things, 
and you won't regret it.

On Thursday, June 18, 2015 at 10:27:52 AM UTC-4, J.Z. wrote:
>
> Hi, 
>
> I have been following julia for some time and have seen lots of positive 
> comments. There are still lots of good work being put into its development. 
> I use R and Python to do lots of technical (statistical) computing and 
> would like to try julia for my work. My quick question to the current users 
> and developers is that whether it is a good time to learn julia now, or 
> should I wait until the language is more mature? Could it be the case that 
> things I learn now would be broken in future releases and I have to relearn 
> everything?
>
> Thanks!
> JZ
>

[julia-users] Re: good time to start to learn julia?

[John Myles White]

My answer to these questions is always the same these days: if you're not 
sure that you have enough expertise to determine Julia's value for 
yourself, then you should be cautious and stick to playing around with 
Julia rather than trying to jump onboard wholesale. Julia is a wonderful 
language and it's very usable for many things, but you shouldn't expect 
that you can do all (or even most) of your work in Julia unless you're 
confident that you can do the development work required to implement any 
functionality that you find to be missing. Depending on your specific 
interests, you might find that Julia is missing nothing or you might find 
that Julia is missing everything.

 -- John

On Thursday, June 18, 2015 at 7:27:52 AM UTC-7, J.Z. wrote:
>
> Hi, 
>
> I have been following julia for some time and have seen lots of positive 
> comments. There are still lots of good work being put into its development. 
> I use R and Python to do lots of technical (statistical) computing and 
> would like to try julia for my work. My quick question to the current users 
> and developers is that whether it is a good time to learn julia now, or 
> should I wait until the language is more mature? Could it be the case that 
> things I learn now would be broken in future releases and I have to relearn 
> everything?
>
> Thanks!
> JZ
>

[julia-users] Re: Set precision when printing to file

[Tom Breloff]

Scott: I remember there being another discussion but I can't seem to find 
it.  How did you try to get in touch?  Do you want to start a github issue 
and I'll comment there?

On Thursday, June 18, 2015 at 10:20:08 AM UTC-4, Scott Jones wrote:
>
> This was already discussed recently, here on julia-users, I'm trying to 
> get in touch with Dahua Lin (author of Formatting.jl)
> to see about adding a simpler `sfmt` that would help with this).
>
> On Thursday, June 18, 2015 at 10:13:46 AM UTC-4, Tom Breloff wrote:
>>
>> I wonder if what we really need is just some extra additions to 
>> Formatting.jl (since I think this is the best place to keep standard 
>> formatting calls).  We could add fmt2, fmt3, etc which would be meant for 
>> formatting floats to that precision.  I suspect that's the most common use 
>> of formatting.  Additionally, just a shorter name than "generate_formatter" 
>> might help adoption for non-standard formatting.  If this makes sense to 
>> people, I'll start an issue on github, and perhaps a PR as well.
>>
>>
>> julia> using Formatting
>>
>> julia> fmt2 = generate_formatter("%1.2f")
>> sprintf_JTEuMmY! (generic function with 1 method)
>>
>> julia> fmt3 = generate_formatter("%1.3f")
>> sprintf_JTEuM2Y! (generic function with 1 method)
>>
>> julia> @time fmt2(31231.345435245)
>>   55.763 milliseconds (33974 allocations: 1444 KB)
>> "31231.35"
>>
>> julia> @time fmt2(31231.345435245)
>>   13.573 microseconds (15 allocations: 608 bytes)
>> "31231.35"
>>
>> julia> @time fmt3(31231.345435245)
>>   11.193 milliseconds (5882 allocations: 254 KB)
>> "31231.345"
>>
>> julia> @time fmt3(31231.345435245)
>>   16.231 microseconds (15 allocations: 608 bytes)
>> "31231.345"
>>
>>
>>
>>
>> On Thursday, June 18, 2015 at 3:55:01 AM UTC-4, cormu...@mac.com wrote:
>>>
>>> You could use a type: 
>>>
>>> julia> type Out 
>>>   n::Float64 
>>>end 
>>>
>>> julia> function Base.show(io::IO, n::Out) 
>>>print(io, "$(round(n.n, 2))") 
>>>end 
>>> show (generic function with 83 methods) 
>>>
>>> then you can just use Out(x) whenever you want x rounded to 2 d.p. 
>>>
>>> julia> for i in 0.7454539:1.5:5 
>>>println("i is $i and displayed as $(Out(i))") 
>>>end 
>>> i is 0.7454539 and displayed as 0.75 
>>> i is 2.24545392 and displayed as 2.25 
>>> i is 3.74545392 and displayed as 3.75   
>>>
>>>

Re: [julia-users] when running julia --code-coverage, where is the *.cov file?

[Isaiah Norton]

On Thu, Jun 18, 2015 at 10:25 AM, Kevin Squire 
wrote:

> There has been some discussion about moving to cmake, which should enable
> building in a separate directory. (
> https://github.com/JuliaLang/julia/issues/1832,
> https://github.com/JuliaLang/julia/pull/9422).
>
>
See also https://github.com/JuliaLang/julia/pull/11645



> There are some concerns raised by people who cross-compile (supposedly
> cmake doesn't have good support for this), and creating cmake files for
> something as complex as Julia isn't trivial.  But other complex projects
> have done so reasonably successfully (OpenCV comes to mind), so it should
> be possible.
>
> Cheers,
>Kevin
>
> On Thu, Jun 18, 2015 at 4:28 AM, Scott Jones 
> wrote:
>
>> It there any way to have these sorts of file go to another directory (as
>> well as the .o files during a build)?
>> We try to keep source directories always "clean", and shared between
>> different builds with different options...
>>
>>
>> On Monday, August 11, 2014 at 6:54:34 AM UTC-4, Tim Holy wrote:
>>>
>>> All the .cov files are in the same directory as the corresponding .jl
>>> source
>>> file. So you'll find a bunch in julia/base (given the "all"), as well as
>>> any
>>> other files used by your test.jl.
>>>
>>> --Tim
>>>
>>> On Monday, August 11, 2014 03:37:41 AM Keith Campbell wrote:
>>> > Hello,
>>> > When running --code-coverage, where does one find the .cov file?
>>> >
>>> > I tried: julia --code-coverage=all test.jl
>>> >
>>> > The program ran, but I couldn't find any coverage output.
>>> > thanks,
>>> > Keith
>>> >
>>> >
>>> > Version 0.3.0-rc2+22 (2014-08-07 07:55 UTC)
>>> > Commit 0816e99 (4 days old master)
>>> > x86_64-redhat-linux
>>>
>>>
>

Re: [julia-users] when running julia --code-coverage, where is the *.cov file?

[Kevin Squire]

(sorry, was responding to Scott's comment, but I should have changed the
title, as this isn't related to code coverage).

Cheers,
   Kevin

On Thu, Jun 18, 2015 at 7:25 AM, Kevin Squire 
wrote:

> There has been some discussion about moving to cmake, which should enable
> building in a separate directory. (
> https://github.com/JuliaLang/julia/issues/1832,
> https://github.com/JuliaLang/julia/pull/9422).
>
> There are some concerns raised by people who cross-compile (supposedly
> cmake doesn't have good support for this), and creating cmake files for
> something as complex as Julia isn't trivial.  But other complex projects
> have done so reasonably successfully (OpenCV comes to mind), so it should
> be possible.
>
> Cheers,
>Kevin
>
> On Thu, Jun 18, 2015 at 4:28 AM, Scott Jones 
> wrote:
>
>> It there any way to have these sorts of file go to another directory (as
>> well as the .o files during a build)?
>> We try to keep source directories always "clean", and shared between
>> different builds with different options...
>>
>>
>> On Monday, August 11, 2014 at 6:54:34 AM UTC-4, Tim Holy wrote:
>>>
>>> All the .cov files are in the same directory as the corresponding .jl
>>> source
>>> file. So you'll find a bunch in julia/base (given the "all"), as well as
>>> any
>>> other files used by your test.jl.
>>>
>>> --Tim
>>>
>>> On Monday, August 11, 2014 03:37:41 AM Keith Campbell wrote:
>>> > Hello,
>>> > When running --code-coverage, where does one find the .cov file?
>>> >
>>> > I tried: julia --code-coverage=all test.jl
>>> >
>>> > The program ran, but I couldn't find any coverage output.
>>> > thanks,
>>> > Keith
>>> >
>>> >
>>> > Version 0.3.0-rc2+22 (2014-08-07 07:55 UTC)
>>> > Commit 0816e99 (4 days old master)
>>> > x86_64-redhat-linux
>>>
>>>
>

[julia-users] PyPlot not working on 0.4.0

[Linus Härenstam-Nielsen]

I am having problems with using PyPlot in the nightly build (version 
0.4.0). Typing 'using PyPlot' followed by 'plot([sin(a) for 
a=linspace(0,2*pi)])' yields the following:

   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+5416 (2015-06-17 00:39 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 0bb31a0 (1 day old master)
|__/   |  x86_64-w64-mingw32

julia> using PyPlot
Warning: New definition
call(Type{PyCall.PyDict}, Base.Associative{#K<:Any, Any}) at 
C:\Users\Linus\.julia\v0.4\PyCall
rc\conversions.jl:464
is ambiguous with:
call(Type{PyCall.PyDict}, Base.Associative{Any, #V<:Any}) at 
C:\Users\Linus\.julia\v0.4\PyCall
rc\conversions.jl:463.
To fix, define
call(Type{PyCall.PyDict}, Base.Associative{Any, Any})
before the new definition.
WARNING: No working GUI backend found for matplotlib.
C:\Anaconda\lib\site-packages\matplotlib\__init__.py:1318: UserWarning: 
 This call to matplotlib.u
() has no effect
because the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.

  warnings.warn(_use_error_msg)
WARNING: ntuple(n::Integer,f::Function) is deprecated, use ntuple(f,n) 
instead.
 in depwarn at deprecated.jl:62
 in ntuple at deprecated.jl:49
 in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:222
 in py2array at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:73
 in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:429
 in pywrap at C:\Users\Linus\.julia\v0.4\PyCall\src\PyCall.jl:305
 in pywrap at C:\Users\Linus\.julia\v0.4\PyCall\src\PyCall.jl:304
 in __init__ at C:\Users\Linus\.julia\v0.4\PyPlot\src\PyPlot.jl:149
 in include at boot.jl:254
 in include_from_node1 at loading.jl:133
 in reload_path at loading.jl:157
 in _require at loading.jl:69
 in require at loading.jl:52
while loading C:\Users\Linus\.julia\v0.4\PyPlot\src\PyPlot.jl, in 
expression starting on line 560

julia> plot([sin(a) for a=linspace(0,2*pi)])
WARNING: ntuple(n::Integer,f::Function) is deprecated, use ntuple(f,n) 
instead.
 in depwarn at deprecated.jl:62
 in ntuple at deprecated.jl:49
 in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:222
 in convert at C:\Users\Linus\.julia\v0.4\PyCall\src\conversions.jl:846
 in jl_Function_call at C:\Users\Linus\.julia\v0.4\PyCall\src\callback.jl:36
 in pycall at C:\Users\Linus\.julia\v0.4\PyCall\src\PyCall.jl:73
 in plot at C:\Users\Linus\.julia\v0.4\PyPlot\src\PyPlot.jl:371
 in anonymous at no file
while loading no file, in expression starting on line 0
1-element Array{Any,1}:
 PyObject 

julia> plot([sin(a) for a=linspace(0,2*pi)])
1-element Array{Any,1}:
 PyObject 


As you can see importing PyPlot produces several warnings, one of them is 
'WARNING: 
No working GUI backend found for matplotlib' which led me to believe there 
is a problem with loading matplotlib? I am using python 2.7.9 on windows 
8.1 with the Anaconda 2.2.0 distribution and matplotlib version 1.4.3. 

The plot function returns a PyObject properly but no plot window is opened. 
In Julia 0.3.9 everything works as you would expect with no warnings.

Any ideas?

[julia-users] good time to start to learn julia?

[J.Z.]

Hi, 

I have been following julia for some time and have seen lots of positive 
comments. There are still lots of good work being put into its development. 
I use R and Python to do lots of technical (statistical) computing and 
would like to try julia for my work. My quick question to the current users 
and developers is that whether it is a good time to learn julia now, or 
should I wait until the language is more mature? Could it be the case that 
things I learn now would be broken in future releases and I have to relearn 
everything?

Thanks!
JZ

Re: [julia-users] when running julia --code-coverage, where is the *.cov file?

[Kevin Squire]

There has been some discussion about moving to cmake, which should enable
building in a separate directory. (
https://github.com/JuliaLang/julia/issues/1832,
https://github.com/JuliaLang/julia/pull/9422).

There are some concerns raised by people who cross-compile (supposedly
cmake doesn't have good support for this), and creating cmake files for
something as complex as Julia isn't trivial.  But other complex projects
have done so reasonably successfully (OpenCV comes to mind), so it should
be possible.

Cheers,
   Kevin

On Thu, Jun 18, 2015 at 4:28 AM, Scott Jones 
wrote:

> It there any way to have these sorts of file go to another directory (as
> well as the .o files during a build)?
> We try to keep source directories always "clean", and shared between
> different builds with different options...
>
>
> On Monday, August 11, 2014 at 6:54:34 AM UTC-4, Tim Holy wrote:
>>
>> All the .cov files are in the same directory as the corresponding .jl
>> source
>> file. So you'll find a bunch in julia/base (given the "all"), as well as
>> any
>> other files used by your test.jl.
>>
>> --Tim
>>
>> On Monday, August 11, 2014 03:37:41 AM Keith Campbell wrote:
>> > Hello,
>> > When running --code-coverage, where does one find the .cov file?
>> >
>> > I tried: julia --code-coverage=all test.jl
>> >
>> > The program ran, but I couldn't find any coverage output.
>> > thanks,
>> > Keith
>> >
>> >
>> > Version 0.3.0-rc2+22 (2014-08-07 07:55 UTC)
>> > Commit 0816e99 (4 days old master)
>> > x86_64-redhat-linux
>>
>>

[julia-users] Re: Set precision when printing to file

[Scott Jones]

This was already discussed recently, here on julia-users, I'm trying to get 
in touch with Dahua Lin (author of Formatting.jl)
to see about adding a simpler `sfmt` that would help with this).

On Thursday, June 18, 2015 at 10:13:46 AM UTC-4, Tom Breloff wrote:
>
> I wonder if what we really need is just some extra additions to 
> Formatting.jl (since I think this is the best place to keep standard 
> formatting calls).  We could add fmt2, fmt3, etc which would be meant for 
> formatting floats to that precision.  I suspect that's the most common use 
> of formatting.  Additionally, just a shorter name than "generate_formatter" 
> might help adoption for non-standard formatting.  If this makes sense to 
> people, I'll start an issue on github, and perhaps a PR as well.
>
>
> julia> using Formatting
>
> julia> fmt2 = generate_formatter("%1.2f")
> sprintf_JTEuMmY! (generic function with 1 method)
>
> julia> fmt3 = generate_formatter("%1.3f")
> sprintf_JTEuM2Y! (generic function with 1 method)
>
> julia> @time fmt2(31231.345435245)
>   55.763 milliseconds (33974 allocations: 1444 KB)
> "31231.35"
>
> julia> @time fmt2(31231.345435245)
>   13.573 microseconds (15 allocations: 608 bytes)
> "31231.35"
>
> julia> @time fmt3(31231.345435245)
>   11.193 milliseconds (5882 allocations: 254 KB)
> "31231.345"
>
> julia> @time fmt3(31231.345435245)
>   16.231 microseconds (15 allocations: 608 bytes)
> "31231.345"
>
>
>
>
> On Thursday, June 18, 2015 at 3:55:01 AM UTC-4, cormu...@mac.com wrote:
>>
>> You could use a type: 
>>
>> julia> type Out 
>>   n::Float64 
>>end 
>>
>> julia> function Base.show(io::IO, n::Out) 
>>print(io, "$(round(n.n, 2))") 
>>end 
>> show (generic function with 83 methods) 
>>
>> then you can just use Out(x) whenever you want x rounded to 2 d.p. 
>>
>> julia> for i in 0.7454539:1.5:5 
>>println("i is $i and displayed as $(Out(i))") 
>>end 
>> i is 0.7454539 and displayed as 0.75 
>> i is 2.24545392 and displayed as 2.25 
>> i is 3.74545392 and displayed as 3.75   
>>
>>

[julia-users] Re: Set precision when printing to file

[Tom Breloff]

I wonder if what we really need is just some extra additions to 
Formatting.jl (since I think this is the best place to keep standard 
formatting calls).  We could add fmt2, fmt3, etc which would be meant for 
formatting floats to that precision.  I suspect that's the most common use 
of formatting.  Additionally, just a shorter name than "generate_formatter" 
might help adoption for non-standard formatting.  If this makes sense to 
people, I'll start an issue on github, and perhaps a PR as well.


julia> using Formatting

julia> fmt2 = generate_formatter("%1.2f")
sprintf_JTEuMmY! (generic function with 1 method)

julia> fmt3 = generate_formatter("%1.3f")
sprintf_JTEuM2Y! (generic function with 1 method)

julia> @time fmt2(31231.345435245)
  55.763 milliseconds (33974 allocations: 1444 KB)
"31231.35"

julia> @time fmt2(31231.345435245)
  13.573 microseconds (15 allocations: 608 bytes)
"31231.35"

julia> @time fmt3(31231.345435245)
  11.193 milliseconds (5882 allocations: 254 KB)
"31231.345"

julia> @time fmt3(31231.345435245)
  16.231 microseconds (15 allocations: 608 bytes)
"31231.345"




On Thursday, June 18, 2015 at 3:55:01 AM UTC-4, cormu...@mac.com wrote:
>
> You could use a type: 
>
> julia> type Out 
>   n::Float64 
>end 
>
> julia> function Base.show(io::IO, n::Out) 
>print(io, "$(round(n.n, 2))") 
>end 
> show (generic function with 83 methods) 
>
> then you can just use Out(x) whenever you want x rounded to 2 d.p. 
>
> julia> for i in 0.7454539:1.5:5 
>println("i is $i and displayed as $(Out(i))") 
>end 
> i is 0.7454539 and displayed as 0.75 
> i is 2.24545392 and displayed as 2.25 
> i is 3.74545392 and displayed as 3.75   
>
>

Re: [julia-users] map() vs list comprehension - any preference?

[Josh Langsfeld]

If anyone's interested, using a generic instead of anonymous function 
reduces the penalty to ~10x

julia> function f3(g,a)
 pairit(x) = Pair(x,g)
 map(pairit, a)
   end
f3 (generic function with 1 method)


julia> @time f3(2,ones(1_000_000));
 108.542 milliseconds (2082 k allocations: 73928 KB, 13.02% gc time)


julia> @time f3(2,ones(1_000_000));
  58.142 milliseconds (2000 k allocations: 70313 KB, 42.84% gc time)


julia> @time f3(2,ones(1_000_000));
  39.441 milliseconds (2000 k allocations: 70313 KB, 12.40% gc time)

On Wednesday, June 17, 2015 at 12:52:34 PM UTC-4, Seth wrote:
>
> Gah. I'm sorry. I can't reproduce my original results! I don't know why, 
> but the same tests I ran two days ago are not giving me the same timing. I 
> need to go back to the drawing board here.
>
> On Wednesday, June 17, 2015 at 11:37:52 AM UTC-5, Josh Langsfeld wrote:
>>
>> For me, map is 100x slower:
>>
>> julia> function f1(g,a)
>>  [Pair(x,g) for x in a]
>>end
>> f1 (generic function with 1 method)
>>
>>
>> julia> function f2(g,a)
>>  map(x->Pair(x,g), a)
>>end
>> f2 (generic function with 1 method)
>>
>>
>> julia> @time f1(2,ones(1_000_000));
>>   25.158 milliseconds (28491 allocations: 24736 KB, 12.69% gc time)
>>
>>
>> julia> @time f1(2,ones(1_000_000));
>>6.866 milliseconds (8 allocations: 23438 KB, 37.10% gc time)
>>
>>
>> julia> @time f1(2,ones(1_000_000));
>>6.126 milliseconds (8 allocations: 23438 KB, 25.99% gc time)
>>
>>
>> julia> @time f2(2,ones(1_000_000));
>>  684.994 milliseconds (2057 k allocations: 72842 KB, 1.72% gc time)
>>
>>
>> julia> @time f2(2,ones(1_000_000));
>>  647.267 milliseconds (2000 k allocations: 70313 KB, 3.64% gc time)
>>
>>
>> julia> @time f2(2,ones(1_000_000));
>>  633.149 milliseconds (2000 k allocations: 70313 KB, 0.91% gc time)
>>
>>
>> On Wednesday, June 17, 2015 at 12:04:52 PM UTC-4, Seth wrote:
>>>
>>> Sorry - it's part of a function:
>>>
>>> in_edges(g::AbstractGraph, v::Int) = [Edge(x,v) for x in badj(g,v)]
>>>
>>> vs
>>>
>>> in_edges(g::AbstractGraph, v::Int) = map(x->Edge(x,v), badj(g,v))
>>>
>>>
>>>
>>>
>>> On Wednesday, June 17, 2015 at 10:51:22 AM UTC-5, Mauro wrote:

 Note that inside a module is also global scope as each module has its 
 own global scope.  Best move it into a function.  M 

 On Wed, 2015-06-17 at 17:22, Seth  wrote: 
 > The speedups are both via the REPL (global scope?) and inside a 
 module. I 
 > did a code_native on both - results are 
 > here: https://gist.github.com/sbromberger/b5656189bcece492ffd9. 
 > 
 > 
 > 
 > On Wednesday, June 17, 2015 at 9:56:22 AM UTC-5, Stefan Karpinski 
 wrote: 
 >> 
 >> I would have expected the comprehension to be faster. Is this in 
 global 
 >> scope? If so you may want to try the speed comparison again where 
 each of 
 >> these occur in a function body and only depend on function 
 arguments. 
 >> 
 >> On Tue, Jun 16, 2015 at 10:12 AM, Seth >>> >> > wrote: 
 >> 
 >>> I have been using list comprehensions of the form 
 >>> bar(g, a) = [Pair(x, g) for x in a] and [foo(x) for x in a] 
 >>> 
 >>> but recently evaluated bar(g, a) = map(x->Pair(x, g),a) and 
 >>> map(x->foo(x),a)as substitutes. 
 >>> 
 >>> It seems from some limited testing that map is slightly faster than 
 the 
 >>> list comprehension, but it's on the order of 3-4% so it may just be 
 noise. 
 >>> Allocations and gc time are roughly equal (380M allocations, 
 ~27000MB, ~6% 
 >>> gc). 
 >>> 
 >>> Should I prefer one approach over the other (and if so, why)? 
 >>> 
 >>> Thanks! 
 >>> 
 >> 
 >> 

Re: [julia-users] Overloading `eval`

[Yichao Yu]

On Thu, Jun 18, 2015 at 9:21 AM, Isaiah Norton  wrote:
> You can define a function called "eval" in a baremodule, but you will then
> need to explicitly import the other things you might need from Base ... what
> is the goal?
>
> On Jun 18, 2015 8:31 AM, "Christoph Ortner" 
> wrote:
>>
>> Do I understand correctly that `eval` cannot be overloaded?
>>
>> I get the following message (0.3.9):
>>
>> Warning: import of Base.eval into Lattices conflicts with an existing
>> identifier; ignored.

The eval function is defined in the module itself[1] and Core.eval is
not a generic function.

http://julia.readthedocs.org/en/release-0.3/manual/modules/?highlight=baremodule#default-top-level-definitions-and-bare-modules

>>
>> Thanks,
>> Christoph
>>
>

Re: [julia-users] Overloading `eval`

[Isaiah Norton]

You can define a function called "eval" in a baremodule, but you will then
need to explicitly import the other things you might need from Base ...
what is the goal?
On Jun 18, 2015 8:31 AM, "Christoph Ortner" 
wrote:

> Do I understand correctly that `eval` cannot be overloaded?
>
> I get the following message (0.3.9):
>
> Warning: import of Base.eval into Lattices conflicts with an existing
> identifier; ignored.
>
> Thanks,
> Christoph
>
>

Re: [julia-users] Multiple lines statement?

[Christoph Ortner]

As I said, it is "OK". I am getting used to it.
Christoph

On Thursday, 18 June 2015 13:34:14 UTC+1, Patrick O'Leary wrote:
>
> "Busier" I agree with, but it's marginal; grouping is lightweight as 
> syntax goes. Parens (1) already work, (2) consistently mean "keep these 
> things together" in a variety of computing environments, (3) have match 
> highlighting support in many editors which make it easy, given one end of 
> the parenthesized subexpression, to find the other end. So I'm not sure I 
> agree with the latter, especially if indentation is used effectively.
>
> On Thursday, June 18, 2015 at 6:53:54 AM UTC-5, Christoph Ortner wrote:
>>
>>
>> I think parenthesis are "ok", but only just. They make the code busier 
>> and more difficult to read. 
>> Christoph
>>
>>
>> On Tuesday, 16 June 2015 01:21:45 UTC+1, David Gold wrote:
>>>
>>> @Ben: as has been noted elsewhere in this thread, you can use parens to 
>>> this end:
>>>
>>> julia> function foo(a, b, c, d, e, f)
>>>if (a > b 
>>>   || c > d 
>>>   || e > f) 
>>> println("Foo for you.") 
>>>end 
>>>end 
>>> foo (generic function with 1 method) 
>>>
>>> julia> foo(1, 2, 3, 4, 6, 5) 
>>> Foo for you.
>>>
>>>
>>> Is there a reason this is significantly worse than what you described?
>>>
>>> On Monday, June 15, 2015 at 5:54:56 PM UTC-4, Ben Arthur wrote:

 in addition to adhering to mathematical typsetting conventions, 
 permitting binary operators to be on the following line would make it 
 easier to comment out sub-expressions.  for example,

 if a>b
   || c>d
   || e>f
 end

 could become

 if a>b
   # || c>d
   || e>f
 end

 i'm not advocating for a mandatory line continuation character.  that 
 would be terrible.  but changing julia to look at the preceding line if 
 the 
 current line doesn't make sense by itself would be great.

 ben



 On Monday, June 1, 2015 at 3:35:50 PM UTC-4, Christoph Ortner wrote:
>
>
> Just to reiterate a comment I made above: the convention in 
> mathematical typesetting is 
>b
> + c
> and not
>b + 
>  c
>
> this is the main reason I have (more than once) fallen into this trap. 
> Anyhow, I will try to use brackets for a while and see how I like it.
>
> Christoph
>

[julia-users] Re: pmap problems

[Chris]

Thank you, this is helpful.

On Wednesday, June 17, 2015 at 8:01:56 AM UTC-4, Lyndon White wrote:
>
> As a convention, one should not normally call `map` with a function that 
> mutates it's inputs,
> Map comes from the world of functional programming, so assumes to run on 
> pure functions  (ie those without side-effects -- such as changing the 
> inputs).
> Now in the julia implementation of map, it is basically a forloop so 
> nonput functions work fine.
>
> The implementation of pmap on the other hand is not a forloop.
> copys chunks of the input vector to other processes,
> and then asks each section to call the function on these copies, and 
> return a vector of the functions return results.
>
> So the copies are modified and then discared on each process.
> The function will return `a,a+b*c`
>
> ---
>
> On Tuesday, 16 June 2015 22:49:10 UTC+8, Chris wrote:
>>
>> Hello,
>>
>> I am having some issues using pmap(). I constructed a basic example that 
>> illustrates the problem I'm seeing:
>>
>> *in "partest.jl":*
>> module MyMod
>> type mytype
>> a::Float64
>> b::Int64
>> c::Float64
>> end
>>
>> function myfun!(a,b,c)
>> a.a += b*c
>> end
>>
>> function mywrapper!(s)
>> pmap( x->myfun!(x,1.,1.), s )
>> end
>> end
>>
>> *In the Julia REPL:*
>> include("partest.jl")
>> addprocs(4)
>> @everywhere using MyMod
>> v = [MyMod.mytype(randn(i)[1],i,0.) for i = 1:1000];
>> MyMod.mywrapper!(v);
>>
>> I expect the elements of v to be changed according to the operation in 
>> myfun!, but they are not. What am I doing wrong here?
>>
>> Thanks,
>> Chris
>>
>

Re: [julia-users] Multiple lines statement?

[Patrick O'Leary]

"Busier" I agree with, but it's marginal; grouping is lightweight as syntax 
goes. Parens (1) already work, (2) consistently mean "keep these things 
together" in a variety of computing environments, (3) have match 
highlighting support in many editors which make it easy, given one end of 
the parenthesized subexpression, to find the other end. So I'm not sure I 
agree with the latter, especially if indentation is used effectively.

On Thursday, June 18, 2015 at 6:53:54 AM UTC-5, Christoph Ortner wrote:
>
>
> I think parenthesis are "ok", but only just. They make the code busier and 
> more difficult to read. 
> Christoph
>
>
> On Tuesday, 16 June 2015 01:21:45 UTC+1, David Gold wrote:
>>
>> @Ben: as has been noted elsewhere in this thread, you can use parens to 
>> this end:
>>
>> julia> function foo(a, b, c, d, e, f)
>>if (a > b 
>>   || c > d 
>>   || e > f) 
>> println("Foo for you.") 
>>end 
>>end 
>> foo (generic function with 1 method) 
>>
>> julia> foo(1, 2, 3, 4, 6, 5) 
>> Foo for you.
>>
>>
>> Is there a reason this is significantly worse than what you described?
>>
>> On Monday, June 15, 2015 at 5:54:56 PM UTC-4, Ben Arthur wrote:
>>>
>>> in addition to adhering to mathematical typsetting conventions, 
>>> permitting binary operators to be on the following line would make it 
>>> easier to comment out sub-expressions.  for example,
>>>
>>> if a>b
>>>   || c>d
>>>   || e>f
>>> end
>>>
>>> could become
>>>
>>> if a>b
>>>   # || c>d
>>>   || e>f
>>> end
>>>
>>> i'm not advocating for a mandatory line continuation character.  that 
>>> would be terrible.  but changing julia to look at the preceding line if the 
>>> current line doesn't make sense by itself would be great.
>>>
>>> ben
>>>
>>>
>>>
>>> On Monday, June 1, 2015 at 3:35:50 PM UTC-4, Christoph Ortner wrote:


 Just to reiterate a comment I made above: the convention in 
 mathematical typesetting is 
b
 + c
 and not
b + 
  c

 this is the main reason I have (more than once) fallen into this trap. 
 Anyhow, I will try to use brackets for a while and see how I like it.

 Christoph

>>>

[julia-users] Overloading `eval`

[Christoph Ortner]

Do I understand correctly that `eval` cannot be overloaded?

I get the following message (0.3.9):

Warning: import of Base.eval into Lattices conflicts with an existing 
identifier; ignored.

Thanks,
Christoph

Re: [julia-users] Multiple lines statement?

[Christoph Ortner]

I think parenthesis are "ok", but only just. They make the code busier and 
more difficult to read. 
Christoph


On Tuesday, 16 June 2015 01:21:45 UTC+1, David Gold wrote:
>
> @Ben: as has been noted elsewhere in this thread, you can use parens to 
> this end:
>
> julia> function foo(a, b, c, d, e, f)
>if (a > b 
>   || c > d 
>   || e > f) 
> println("Foo for you.") 
>end 
>end 
> foo (generic function with 1 method) 
>
> julia> foo(1, 2, 3, 4, 6, 5) 
> Foo for you.
>
>
> Is there a reason this is significantly worse than what you described?
>
> On Monday, June 15, 2015 at 5:54:56 PM UTC-4, Ben Arthur wrote:
>>
>> in addition to adhering to mathematical typsetting conventions, 
>> permitting binary operators to be on the following line would make it 
>> easier to comment out sub-expressions.  for example,
>>
>> if a>b
>>   || c>d
>>   || e>f
>> end
>>
>> could become
>>
>> if a>b
>>   # || c>d
>>   || e>f
>> end
>>
>> i'm not advocating for a mandatory line continuation character.  that 
>> would be terrible.  but changing julia to look at the preceding line if the 
>> current line doesn't make sense by itself would be great.
>>
>> ben
>>
>>
>>
>> On Monday, June 1, 2015 at 3:35:50 PM UTC-4, Christoph Ortner wrote:
>>>
>>>
>>> Just to reiterate a comment I made above: the convention in mathematical 
>>> typesetting is 
>>>b
>>> + c
>>> and not
>>>b + 
>>>  c
>>>
>>> this is the main reason I have (more than once) fallen into this trap. 
>>> Anyhow, I will try to use brackets for a while and see how I like it.
>>>
>>> Christoph
>>>
>>

Re: [julia-users] when running julia --code-coverage, where is the *.cov file?

[Scott Jones]

It there any way to have these sorts of file go to another directory (as 
well as the .o files during a build)?
We try to keep source directories always "clean", and shared between 
different builds with different options...

On Monday, August 11, 2014 at 6:54:34 AM UTC-4, Tim Holy wrote:
>
> All the .cov files are in the same directory as the corresponding .jl 
> source 
> file. So you'll find a bunch in julia/base (given the "all"), as well as 
> any 
> other files used by your test.jl. 
>
> --Tim 
>
> On Monday, August 11, 2014 03:37:41 AM Keith Campbell wrote: 
> > Hello, 
> > When running --code-coverage, where does one find the .cov file? 
> > 
> > I tried: julia --code-coverage=all test.jl 
> > 
> > The program ran, but I couldn't find any coverage output. 
> > thanks, 
> > Keith 
> > 
> > 
> > Version 0.3.0-rc2+22 (2014-08-07 07:55 UTC) 
> > Commit 0816e99 (4 days old master) 
> > x86_64-redhat-linux 
>
>

[julia-users] Re: unable to update julianightlies - 16 days old master - ubuntu14.04

[SVAKSHA]

On Thu, Jun 18, 2015 at 6:29 AM, Tony Kelman  wrote:
> Looks like the last successful build of the package itself was on June 2nd,
> see
> https://launchpad.net/~staticfloat/+archive/ubuntu/julianightlies/+builds?build_text=&build_state=built
> (scroll down a bit). We upgraded to a newer version of PCRE on 0.4-dev which
> will need to be re-packaged before the PPA builds are happy again.

Thanks for the update :)

SVAKSHA ॥  http://about.me/svaksha  ॥

[julia-users] Re: how to move Julia packages from Ubuntu to OSX?

[Andreas Lobinger]

On Thursday, June 18, 2015 at 11:08:22 AM UTC+2, Andreas Lobinger wrote:
>
> Hello colleague,
>
> On Thursday, June 18, 2015 at 10:34:47 AM UTC+2, K leo wrote:
>>
>> BTW, does anyone know what the following message is about:
>>
>> *julia> **using Winston*
>>
>> Warning: could not import Base.Text into Tk
>>
>
> There is a activity to move Base graphics calls into Graphics as a package 
> and this shows up in related packages (like Cairo, Gtk, Tk etc.). I opened 
> an issue.
>

I forgot, this is only a warning and should not have side effects. It 
vanishes with a v0.4. 

[julia-users] Re: how to move Julia packages from Ubuntu to OSX?

[Andreas Lobinger]

Hello colleague,

On Thursday, June 18, 2015 at 10:34:47 AM UTC+2, K leo wrote:
>
> BTW, does anyone know what the following message is about:
>
> *julia> **using Winston*
>
> Warning: could not import Base.Text into Tk
>

There is a activity to move Base graphics calls into Graphics as a package 
and this shows up in related packages (like Cairo, Gtk, Tk etc.). I opened 
an issue.

[julia-users] Re: how to move Julia packages from Ubuntu to OSX?

[K leo]

Fantastic Eliot - thank you.  That problem is resolved!

BTW, does anyone know what the following message is about:

*julia> **using Winston*

Warning: could not import Base.Text into Tk

On Tuesday, June 16, 2015, Elliot Saba  wrote:

> Congratulations!  You have helped me track down a bug in Pango that I
> inadvertently introduced four days ago!  You win the "very helpful and
> patient community member" prize.
>
> The good news is, this is now fixed
> .
> The better news is, to get the fix to propagate to your machine is very
> simple:
>
> julia> using Homebrew
>
> julia> Homebrew.update()
>
> julia> Homebrew.rm("pango"); Homebrew.add("pango")
>
> Then quit Julia, reopen and you should see text in your plots.  This was
> masked on my machine due to some files laying around in just the right
> location to be loaded properly, giving me the proper text on my machine but
> not on yours.  Thank you for your patience!
> -E
>

[julia-users] Re: Set precision when printing to file

[cormullion]

You could use a type:

julia> type Out
  n::Float64
   end

julia> function Base.show(io::IO, n::Out)
   print(io, "$(round(n.n, 2))")
   end
show (generic function with 83 methods)

then you can just use Out(x) whenever you want x rounded to 2 d.p.

julia> for i in 0.7454539:1.5:5
   println("i is $i and displayed as $(Out(i))")
   end
i is 0.7454539 and displayed as 0.75
i is 2.24545392 and displayed as 2.25
i is 3.74545392 and displayed as 3.75