Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Milan Bouchet-Valat]

Le jeudi 22 mai 2014 à 05:49 -0700, Adam Smith a écrit :
> I'm not totally opposed to it, but my initial reaction is not to:
>  1. I don't necessarily agree about the name. I personally think
> "dot plot" has a nice ring to it, and it is a more accurate
> description of what it does (using Braille characters).
Just my two cents, "dot plot" is already the name of a type of plot
where values are represented by dots. So not the best name for your
package.

http://en.wikipedia.org/wiki/Dot_plot_%28statistics%29


Regards

Re: [julia-users] pager in the repl

[Tamas Papp]

I don't think a pager is the right solution, for the following reasons:

1. typing directly in to the REPL running in a terminal is not an
efficient way to program anything nontrivial, most users would use an
IDE (incl Emacs) that would allow scrolling and inspection of a value,

2. how many elements to print from large arrays etc could be controlled
by something like Common Lisp's *PRINT-LENGTH*, eg see
http://clhs.lisp.se/Body/v_pr_lev.htm (sorry if this already exists in
Julia, could not find it).

Best,

Tamas

On Thu, May 22 2014, Stefan Karpinski  wrote:

> Now that we have native terminal support, it would be a reasonable project
> to write a pager in Julia. Why write our own pager (you ask)? Because it
> could allow you to do things like efficiently page around a huge array
> without having to print the whole thing. You could, e.g., instantly page to
> the bottom right of a massive, distributed array, without any lag at all.
> Of course, the thing is you want to use shared infrastructure for doing
> this kind of data exploration in the terminal, IJulia, and maybe your
> editor. But the pager part could be pretty decoupled from that.
>
>
> On Thu, May 22, 2014 at 3:30 PM, Kevin Squire wrote:
>
>> Thanks!
>>
>>
>> On Thursday, May 22, 2014 11:52:12 AM UTC-7, Bob Nnamtrop wrote:
>>
>>> OK done. See https://github.com/JuliaLang/julia/issues/6921
>>>
>>>
>>> On Thu, May 22, 2014 at 12:20 PM, Kevin Squire wrote:
>>>
 I agree that that would be nice.  Would you be willing to open up an
 issue for this?


 On Thu, May 22, 2014 at 11:04 AM, Bob Nnamtrop wrote:

> I often find myself wishing for a pager in the repl when outputing
> large amount of output. I see that there is a Base.less but it is only 
> used
> on files and not for outputting other stuff in the repl. In fact, it would
> be great to have support for less, head, and tail like functionality for
> looking at arrays, hashes, etc. Thus to be able to do:
>
> arr |> less
> or
> less(arr)
> or
> arr |> tail
>
> In addition, I think having the output of show() automatically go
> through less if it longer that one page would be great. I hate seeing 
> 100's
> of pages of output fly by when, e.g., a huge hash gets "shown" at the
> prompt (I just cannot seem to get in the habit of typing the ; at the 
> right
> time). This behavior could be configurable of course.
>
> Bob
>


>>>

Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Tobias Knopp]

I think "merge" was meant as: Lets create one uniform package and join the 
efforts. Since ASCIIPlots is not actively maintained I think it would be 
really great if you could take the lead to make an awsome text plotting 
tool.

I like the name TextPlot by the way.

Am Donnerstag, 22. Mai 2014 17:42:06 UTC+2 schrieb Adam Smith:
>
> TextPlot seems like a good name.
>
> Thanks for the offer on merging, but again, there's really nothing to 
> merge. Adding scatterplots to dotplot will be trivial; I'll do that soon 
> (making dotplot's features a superset of ASCIIPlots). There is nothing 
> compatible/overlapping between these two (small) codebases for merging to 
> make sense.
>
> I would be curious what John Myles White thinks about a more complete 
> terminal plotting package for Julia. ASCIIPlots clearly imitates Matlab's 
> plotting functions ("imagesc"), and I was going for something closer to 
> Mathematica or Maple (which are more symbolic-oriented than Matlab), since 
> I think the syntax is prettier. However, I know a large portion of Julia's 
> users are also Matlab users, so if Matlab-compatibility is a goal, you may 
> want to keep the packages separate.
>
> On Thursday, May 22, 2014 11:25:01 AM UTC-4, Leah Hanson wrote:
>>
>> Maybe something like TextPlot would be a good merged name? It conveys 
>> what the package does (text plots) rather than how it does it (Braille 
>> characters).
>>
>> Having a more complete plotting package for the terminal would move 
>> towards having a way to make `plot` just work when you start up a Julia 
>> REPL, which I think is a goal. I'd be happy to help merge them, but 
>> probably won't have time for a couple weeks.
>>
>> -- Leah
>>
>>
>> On Thu, May 22, 2014 at 7:49 AM, Adam Smith wrote:
>>
>>> I'm not totally opposed to it, but my initial reaction is not to:
>>>
>>>1. I don't necessarily agree about the name. I personally think "dot 
>>>plot" has a nice ring to it, and it is a more accurate description of 
>>> what 
>>>it does (using Braille characters). This very specifically exploits 
>>> Unicode 
>>>(non-ASCII) characters, so calling it an ASCII plot would be misleading 
>>>(for those who want the restricted character set for some reason). 
>>>2. There's not really a single line of code they have in common, so 
>>>there's nothing to "merge": it would just be a rename. I didn't look at 
>>> the 
>>>code of ASCIIPlots before making it, and we chose completely different 
>>>APIs. For example, ASCIIPlots doesn't have a way to plot functions, and 
>>>DotPlot doesn't (yet) have a way to scatterplot an array. 
>>>3. They are both quite small and simple (dotplot is ~100 lines of 
>>>code, ascii is ~250); merging would probably be more work than either 
>>>originally took to create.
>>>
>>>
>>> On Thursday, May 22, 2014 1:31:10 AM UTC-4, Ivar Nesje wrote:

 Would it make sense to merge this functionality into ASCIIPlots? To me 
 that seems like a better name, and John Myles White is likely to be 
 willing 
 to transfer the repository if you want to be the maintainer. That package 
 started from code posted on the mailing list, and the author thought it 
 was 
 a joke. John packaged it for others to use.
>>>
>>>
>>

Re: [julia-users] Re: how to apply vector on diagonal of matrix ?

[Tomas Lycken]

I love reading this list. Aside from over and over again finding new ways 
in which Julia is awesome, I learn all kinds of stuff from all the side 
tracks you guys get into. If I could buy a beer everyone who's taught me 
something by expanding "a little too much" on something vaguely related to 
what we're actually talking about, I'd be a really poor guy afterwards.

Keep it up, I don't want to stop learning! =)

// T

On Thursday, May 22, 2014 6:19:05 PM UTC+2, Dahua Lin wrote:
>
> As a side note, I just cleaned up the Devectorize.jl package (tagged vs 
> 0.4). Now it works well under Julia v0.3.
>
> I am now working on a major upgrade to this package. This may lead to a 
> more transparent & extensible code generator and the support of arrays of 
> arbitrary dimensions (with the help of the ArrayViews package). 
>
> Dahua
>
>
> On Thursday, May 22, 2014 8:38:15 AM UTC-5, gael@gmail.com wrote:
>>
>>
>>
>> Le jeudi 22 mai 2014 09:51:44 UTC+2, Tobias Knopp a écrit :
>>>
>>> To give this discussions some facts I have done some benchmarking on my 
>>> own
>>>
>>> Matlab R2013a:
>>>
>>> function [ y ] = perf( )
>>>   N = 1000;
>>>   x = rand(N,1);
>>>   y = x + x .* x + x .* x;
>>> end
>>>
>>> >> tic;y=perf();toc;
>>> Elapsed time is 0.177664 seconds.
>>>
>>> Julia 0.3 prerelease
>>>
>>>  function perf()
>>>N = 1000
>>>x = rand(N)
>>>y = x + x .* x + x .* x
>>>  end
>>>
>>> julia> @time perf()
>>> elapsed time: 0.232852894 seconds (42808 bytes allocated)
>>>
>>> using Devectorize.jl
>>>
>>>  function perf_devec()
>>>N = 1000
>>>x = rand(N)
>>>@devec y = x + x .* x + x .* x
>>>  end
>>>
>>> julia> @time perf_devec()
>>> elapsed time: 0.084605794 seconds (16664 bytes allocated)
>>>
>>> So seems all pretty consistent to me. Matlab is a little better in 
>>> vectorized code as they presumely have a better memory caching. But still 
>>> explicit devectorization using the @devec macro performs best. So using 
>>> vectorized code in Julia is fine and "reasonable fast". If someone wants to 
>>> do performance tweaking I don't see the issue telling him about 
>>> devectorization.
>>>
>>  
>> Ahah !!! I was sure of it: we don't talk about the same thing. To me,
>> @devec y = x + x .* x + x .* x
>> is actually *vectorized* code :). When I'm talking about devectorizing 
>> code, I'm only talking about explicit loops. It's a shame that I only paid 
>> attention to Devectorize.jl yesterday night. This thing is awesome and it 
>> should be a great place to contribute to.
>>
>> This should be the very first answer to "this part of my code is too 
>> slow".
>>
>>
>> Regarding the benchmarks you've done, thanks. Without evidence, no 
>> discussion. I agree.
>>
>> But there are two problems with your benchmarks. Firstly, you've not 
>> repeated them and therefore can't associate an uncertainty with them. Maybe 
>> matlab code is not actually faster. Secondly, what if matlab or julia 
>> actually spend most of its time getting the random vector?
>>
>> I'd recommend  you to repeat your result and compare directly the 
>> estimated distribution function. I've done just that for your simple code. 
>> I just put N = rand(...) outside of the function each time. I also created 
>> devectorized versions of your code (I mean, with explicit loops written by 
>> myself). Once with ".*" as a multiplier and once with "*". The resulting 
>> kernel densities can be found attached.
>>
>> As you can see, the resulting functions are not even close from a 
>> Gaussian. Normality tests failed for each of those distributions. How to 
>> explain that? Easy: a typical desktop computer does nothing most of the 
>> time. Once you launch something, it spends it's time on this but from time 
>> to time very rarely, it needs to spend some CPU time on something else. 
>> Therefore, there is the mode : the most probable execution time and a tail 
>> that is bigger on the side of increasing times.
>>
>> I just go the time using tic(), toc(), so for each of the thousand 
>> repetitions of the exact same calculation, I could follow the execution 
>> time in real time. The fact that "Explicit loop (*)" has a bigger and 
>> stranger tail is directly related to the fact that I used my mouse quite 
>> intensively during that run. What does that mean? 
>>
>> 1) One must repeat calculations for benchmarking.
>> 2) Calculating the mean of the repetitions is useless because it is not a 
>> good estimator of the mode of the distribution.
>>
>> The point 1 is obvious, but not point 2 : please consider the second plot 
>> attached which is a zoomed in part of the first one. As you can see, the 
>> mode of the "Explicit loop (*)" curve is positioned slightly on the left 
>> compared to the "Explicit loop (.*)" curve. This certainly means that for 
>> scalars, "*" has less overhead than ".*" (maybe just a couple of extra 
>> "if"s or an extra function call). However, because I shook my mouse (on 
>> purpose) during that run (

Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Ivar Nesje]

Yes, that was definitely my intention to suggest. It looks to me like 
ASCIIPlots.jl and DotPlot.jl solves the same problem in a very similar way, 
and whether to use Unicode for higher resolution seems like something I 
would expect to be an option.

Anyway, the ultimate goal for ASCII art plots, would be to implement it as 
a backend for one of the normal plotting packages.

Ivar

kl. 10:06:42 UTC+2 fredag 23. mai 2014 skrev Tobias Knopp følgende:
>
> I think "merge" was meant as: Lets create one uniform package and join the 
> efforts. Since ASCIIPlots is not actively maintained I think it would be 
> really great if you could take the lead to make an awsome text plotting 
> tool.
>
> I like the name TextPlot by the way.
>
> Am Donnerstag, 22. Mai 2014 17:42:06 UTC+2 schrieb Adam Smith:
>>
>> TextPlot seems like a good name.
>>
>> Thanks for the offer on merging, but again, there's really nothing to 
>> merge. Adding scatterplots to dotplot will be trivial; I'll do that soon 
>> (making dotplot's features a superset of ASCIIPlots). There is nothing 
>> compatible/overlapping between these two (small) codebases for merging to 
>> make sense.
>>
>> I would be curious what John Myles White thinks about a more complete 
>> terminal plotting package for Julia. ASCIIPlots clearly imitates Matlab's 
>> plotting functions ("imagesc"), and I was going for something closer to 
>> Mathematica or Maple (which are more symbolic-oriented than Matlab), since 
>> I think the syntax is prettier. However, I know a large portion of Julia's 
>> users are also Matlab users, so if Matlab-compatibility is a goal, you may 
>> want to keep the packages separate.
>>
>> On Thursday, May 22, 2014 11:25:01 AM UTC-4, Leah Hanson wrote:
>>>
>>> Maybe something like TextPlot would be a good merged name? It conveys 
>>> what the package does (text plots) rather than how it does it (Braille 
>>> characters).
>>>
>>> Having a more complete plotting package for the terminal would move 
>>> towards having a way to make `plot` just work when you start up a Julia 
>>> REPL, which I think is a goal. I'd be happy to help merge them, but 
>>> probably won't have time for a couple weeks.
>>>
>>> -- Leah
>>>
>>>
>>> On Thu, May 22, 2014 at 7:49 AM, Adam Smith wrote:
>>>
 I'm not totally opposed to it, but my initial reaction is not to:

1. I don't necessarily agree about the name. I personally think 
"dot plot" has a nice ring to it, and it is a more accurate description 
 of 
what it does (using Braille characters). This very specifically 
 exploits 
Unicode (non-ASCII) characters, so calling it an ASCII plot would be 
misleading (for those who want the restricted character set for some 
reason). 
2. There's not really a single line of code they have in common, so 
there's nothing to "merge": it would just be a rename. I didn't look at 
 the 
code of ASCIIPlots before making it, and we chose completely different 
APIs. For example, ASCIIPlots doesn't have a way to plot functions, and 
DotPlot doesn't (yet) have a way to scatterplot an array. 
3. They are both quite small and simple (dotplot is ~100 lines of 
code, ascii is ~250); merging would probably be more work than either 
originally took to create.


 On Thursday, May 22, 2014 1:31:10 AM UTC-4, Ivar Nesje wrote:
>
> Would it make sense to merge this functionality into ASCIIPlots? To me 
> that seems like a better name, and John Myles White is likely to be 
> willing 
> to transfer the repository if you want to be the maintainer. That package 
> started from code posted on the mailing list, and the author thought it 
> was 
> a joke. John packaged it for others to use.


>>>

Re: [julia-users] pager in the repl

[Tomas Lycken]

Personally, I love the way Julia outputs large matrices - some rows from 
the start, followed by "..." and then some rows from the end. If the matrix 
is both wide and tall, it's truncated in both directions, but the central 
point is that it's truncated in the middle, rather than on either end. That 
lets me quickly inspect the entire thing - if it both starts and ends as I 
expect, it's probably OK even in the parts that I don't see. If i'm not 
sure, I can always use some more (or less) fine-tuned command (e.g. @show) 
to look at the entire thing.

The ideal solution to me, would be to do the same thing for all kinds of 
output: the default way of displaying it would be to truncate it in the 
middle, and if the user wants something else, they can manually request it. 
And then, of course, it would be awesome if they could also manually pipe 
it to something that works just like less, tail or whatever from the native 
terminal.

But I think making long output in the REPL paginated by default is a bad 
idea - if I type something that results in a large amount of output just 
because I forgot to add ; at the end, suddenly I have to get out of the 
paginated output view before I can type my next command. I don't feel like 
making the "read-eval-print-loop" more like a 
"read-eval-print-getoutofpaginatedview-loop"...

// T

On Friday, May 23, 2014 10:06:11 AM UTC+2, Tamas Papp wrote:
>
> I don't think a pager is the right solution, for the following reasons: 
>
> 1. typing directly in to the REPL running in a terminal is not an 
> efficient way to program anything nontrivial, most users would use an 
> IDE (incl Emacs) that would allow scrolling and inspection of a value, 
>
> 2. how many elements to print from large arrays etc could be controlled 
> by something like Common Lisp's *PRINT-LENGTH*, eg see 
> http://clhs.lisp.se/Body/v_pr_lev.htm (sorry if this already exists in 
> Julia, could not find it). 
>
> Best, 
>
> Tamas 
>
> On Thu, May 22 2014, Stefan Karpinski > 
> wrote: 
>
> > Now that we have native terminal support, it would be a reasonable 
> project 
> > to write a pager in Julia. Why write our own pager (you ask)? Because it 
> > could allow you to do things like efficiently page around a huge array 
> > without having to print the whole thing. You could, e.g., instantly page 
> to 
> > the bottom right of a massive, distributed array, without any lag at 
> all. 
> > Of course, the thing is you want to use shared infrastructure for doing 
> > this kind of data exploration in the terminal, IJulia, and maybe your 
> > editor. But the pager part could be pretty decoupled from that. 
> > 
> > 
> > On Thu, May 22, 2014 at 3:30 PM, Kevin Squire 
> > >wrote: 
>
> > 
> >> Thanks! 
> >> 
> >> 
> >> On Thursday, May 22, 2014 11:52:12 AM UTC-7, Bob Nnamtrop wrote: 
> >> 
> >>> OK done. See https://github.com/JuliaLang/julia/issues/6921 
> >>> 
> >>> 
> >>> On Thu, May 22, 2014 at 12:20 PM, Kevin Squire 
> >>> wrote: 
>
> >>> 
>  I agree that that would be nice.  Would you be willing to open up an 
>  issue for this? 
>  
>  
>  On Thu, May 22, 2014 at 11:04 AM, Bob Nnamtrop 
>  wrote: 
>
>  
> > I often find myself wishing for a pager in the repl when outputing 
> > large amount of output. I see that there is a Base.less but it is 
> only used 
> > on files and not for outputting other stuff in the repl. In fact, it 
> would 
> > be great to have support for less, head, and tail like functionality 
> for 
> > looking at arrays, hashes, etc. Thus to be able to do: 
> > 
> > arr |> less 
> > or 
> > less(arr) 
> > or 
> > arr |> tail 
> > 
> > In addition, I think having the output of show() automatically go 
> > through less if it longer that one page would be great. I hate 
> seeing 100's 
> > of pages of output fly by when, e.g., a huge hash gets "shown" at 
> the 
> > prompt (I just cannot seem to get in the habit of typing the ; at 
> the right 
> > time). This behavior could be configurable of course. 
> > 
> > Bob 
> > 
>  
>  
> >>> 
>
>

[julia-users] Re: Waterloo Graphics for Julia?

[sigtool]

As an update to this, I have now posted 
waterlooFX
.

This is a rewrite using the new JavaFX RCP under-the-hood (which uses full 
hardware acceleration)  and requires Java 8.


   - Charts are fully customizable using CSS styling
   - Charts can be created and customized using the JavaFX 
FXML
 markup 
   language
   - Integrates fully into generic GUI designers such as Oracle JavaFX 
   Scene Builder 
2.0
   - Fully interactive charts with built-in mouse support
   - Charts can be integrated into Java desktop apps or deployed to the web 
   in HTML
   - Pure Java core library.

Tools to use this library from R, MATLAB etc are planned - most likely 
using FXML to communicate with a JavaFX app (or webpage).

Re: [julia-users] pager in the repl

[Andrea Pagnani]

The idea to have a pager that allows for browsing efficiently large data 
structures as proposed by Stefan is great but probably too far fetched. 
Also I agree that having a long output paged by default is not what I 
really need in my everyday data/program debugging. Suppose that 
``myprog()`` prints a long output on the screen, what I would really fancy 
 would be something like ``myprog()  |> less``  ( the symbol ``|>``  might 
not be the good one though) or  ``tail``, ``head`` which, I do not know for 
windows system, but at least for MAC and Linux are already available. I use 
it quite often the syntax
command|>less
and redirects you through ``less`` to the line of julia code  where 
``command`` is defined. Is there any way to redirect on the fly STDOUT from 
screen to, say less, but on the fly?

Andrea




On Friday, May 23, 2014 11:45:18 AM UTC+2, Tomas Lycken wrote:
>
> Personally, I love the way Julia outputs large matrices - some rows from 
> the start, followed by "..." and then some rows from the end. If the matrix 
> is both wide and tall, it's truncated in both directions, but the central 
> point is that it's truncated in the middle, rather than on either end. That 
> lets me quickly inspect the entire thing - if it both starts and ends as I 
> expect, it's probably OK even in the parts that I don't see. If i'm not 
> sure, I can always use some more (or less) fine-tuned command (e.g. @show) 
> to look at the entire thing.
>
> The ideal solution to me, would be to do the same thing for all kinds of 
> output: the default way of displaying it would be to truncate it in the 
> middle, and if the user wants something else, they can manually request it. 
> And then, of course, it would be awesome if they could also manually pipe 
> it to something that works just like less, tail or whatever from the native 
> terminal.
>
> But I think making long output in the REPL paginated by default is a bad 
> idea - if I type something that results in a large amount of output just 
> because I forgot to add ; at the end, suddenly I have to get out of the 
> paginated output view before I can type my next command. I don't feel like 
> making the "read-eval-print-loop" more like a 
> "read-eval-print-getoutofpaginatedview-loop"...
>
> // T
>
> On Friday, May 23, 2014 10:06:11 AM UTC+2, Tamas Papp wrote:
>>
>> I don't think a pager is the right solution, for the following reasons: 
>>
>> 1. typing directly in to the REPL running in a terminal is not an 
>> efficient way to program anything nontrivial, most users would use an 
>> IDE (incl Emacs) that would allow scrolling and inspection of a value, 
>>
>> 2. how many elements to print from large arrays etc could be controlled 
>> by something like Common Lisp's *PRINT-LENGTH*, eg see 
>> http://clhs.lisp.se/Body/v_pr_lev.htm (sorry if this already exists in 
>> Julia, could not find it). 
>>
>> Best, 
>>
>> Tamas 
>>
>> On Thu, May 22 2014, Stefan Karpinski  wrote: 
>>
>> > Now that we have native terminal support, it would be a reasonable 
>> project 
>> > to write a pager in Julia. Why write our own pager (you ask)? Because 
>> it 
>> > could allow you to do things like efficiently page around a huge array 
>> > without having to print the whole thing. You could, e.g., instantly 
>> page to 
>> > the bottom right of a massive, distributed array, without any lag at 
>> all. 
>> > Of course, the thing is you want to use shared infrastructure for doing 
>> > this kind of data exploration in the terminal, IJulia, and maybe your 
>> > editor. But the pager part could be pretty decoupled from that. 
>> > 
>> > 
>> > On Thu, May 22, 2014 at 3:30 PM, Kevin Squire wrote: 
>>
>> > 
>> >> Thanks! 
>> >> 
>> >> 
>> >> On Thursday, May 22, 2014 11:52:12 AM UTC-7, Bob Nnamtrop wrote: 
>> >> 
>> >>> OK done. See https://github.com/JuliaLang/julia/issues/6921 
>> >>> 
>> >>> 
>> >>> On Thu, May 22, 2014 at 12:20 PM, Kevin Squire 
>> >>> wrote: 
>>
>> >>> 
>>  I agree that that would be nice.  Would you be willing to open up an 
>>  issue for this? 
>>  
>>  
>>  On Thu, May 22, 2014 at 11:04 AM, Bob Nnamtrop 
>>  wrote: 
>>
>>  
>> > I often find myself wishing for a pager in the repl when outputing 
>> > large amount of output. I see that there is a Base.less but it is 
>> only used 
>> > on files and not for outputting other stuff in the repl. In fact, 
>> it would 
>> > be great to have support for less, head, and tail like 
>> functionality for 
>> > looking at arrays, hashes, etc. Thus to be able to do: 
>> > 
>> > arr |> less 
>> > or 
>> > less(arr) 
>> > or 
>> > arr |> tail 
>> > 
>> > In addition, I think having the output of show() automatically go 
>> > through less if it longer that one page would be great. I hate 
>> seeing 100's 
>> > of pages of output fly by when, e.g., a huge hash gets "shown" at 
>> the 
>> > prompt (I just cannot seem to get in the habit of typing

Re: [julia-users] pager in the repl

[Mike Innes]

Why do you say it's too far fetched? I agree that it shouldn't be the
default, but I don't see any technical issues with the idea.


On 23 May 2014 13:36, Andrea Pagnani  wrote:

> The idea to have a pager that allows for browsing efficiently large data
> structures as proposed by Stefan is great but probably too far fetched.
> Also I agree that having a long output paged by default is not what I
> really need in my everyday data/program debugging. Suppose that
> ``myprog()`` prints a long output on the screen, what I would really fancy
>  would be something like ``myprog()  |> less``  ( the symbol ``|>``  might
> not be the good one though) or  ``tail``, ``head`` which, I do not know for
> windows system, but at least for MAC and Linux are already available. I use
> it quite often the syntax
> command|>less
> and redirects you through ``less`` to the line of julia code  where
> ``command`` is defined. Is there any way to redirect on the fly STDOUT from
> screen to, say less, but on the fly?
>
> Andrea
>
>
>
>
> On Friday, May 23, 2014 11:45:18 AM UTC+2, Tomas Lycken wrote:
>>
>> Personally, I love the way Julia outputs large matrices - some rows from
>> the start, followed by "..." and then some rows from the end. If the matrix
>> is both wide and tall, it's truncated in both directions, but the central
>> point is that it's truncated in the middle, rather than on either end. That
>> lets me quickly inspect the entire thing - if it both starts and ends as I
>> expect, it's probably OK even in the parts that I don't see. If i'm not
>> sure, I can always use some more (or less) fine-tuned command (e.g. @show)
>> to look at the entire thing.
>>
>> The ideal solution to me, would be to do the same thing for all kinds of
>> output: the default way of displaying it would be to truncate it in the
>> middle, and if the user wants something else, they can manually request it.
>> And then, of course, it would be awesome if they could also manually pipe
>> it to something that works just like less, tail or whatever from the native
>> terminal.
>>
>> But I think making long output in the REPL paginated by default is a bad
>> idea - if I type something that results in a large amount of output just
>> because I forgot to add ; at the end, suddenly I have to get out of the
>> paginated output view before I can type my next command. I don't feel like
>> making the "read-eval-print-loop" more like a "read-eval-print-
>> getoutofpaginatedview-loop"...
>>
>> // T
>>
>> On Friday, May 23, 2014 10:06:11 AM UTC+2, Tamas Papp wrote:
>>>
>>> I don't think a pager is the right solution, for the following reasons:
>>>
>>> 1. typing directly in to the REPL running in a terminal is not an
>>> efficient way to program anything nontrivial, most users would use an
>>> IDE (incl Emacs) that would allow scrolling and inspection of a value,
>>>
>>> 2. how many elements to print from large arrays etc could be controlled
>>> by something like Common Lisp's *PRINT-LENGTH*, eg see
>>> http://clhs.lisp.se/Body/v_pr_lev.htm (sorry if this already exists in
>>> Julia, could not find it).
>>>
>>> Best,
>>>
>>> Tamas
>>>
>>> On Thu, May 22 2014, Stefan Karpinski  wrote:
>>>
>>> > Now that we have native terminal support, it would be a reasonable
>>> project
>>> > to write a pager in Julia. Why write our own pager (you ask)? Because
>>> it
>>> > could allow you to do things like efficiently page around a huge array
>>> > without having to print the whole thing. You could, e.g., instantly
>>> page to
>>> > the bottom right of a massive, distributed array, without any lag at
>>> all.
>>> > Of course, the thing is you want to use shared infrastructure for
>>> doing
>>> > this kind of data exploration in the terminal, IJulia, and maybe your
>>> > editor. But the pager part could be pretty decoupled from that.
>>> >
>>> >
>>> > On Thu, May 22, 2014 at 3:30 PM, Kevin Squire wrote:
>>>
>>> >
>>> >> Thanks!
>>> >>
>>> >>
>>> >> On Thursday, May 22, 2014 11:52:12 AM UTC-7, Bob Nnamtrop wrote:
>>> >>
>>> >>> OK done. See https://github.com/JuliaLang/julia/issues/6921
>>> >>>
>>> >>>
>>> >>> On Thu, May 22, 2014 at 12:20 PM, Kevin Squire 
>>> >>> wrote:
>>>
>>> >>>
>>>  I agree that that would be nice.  Would you be willing to open up
>>> an
>>>  issue for this?
>>> 
>>> 
>>>  On Thu, May 22, 2014 at 11:04 AM, Bob Nnamtrop 
>>>  wrote:
>>>
>>> 
>>> > I often find myself wishing for a pager in the repl when outputing
>>> > large amount of output. I see that there is a Base.less but it is
>>> only used
>>> > on files and not for outputting other stuff in the repl. In fact,
>>> it would
>>> > be great to have support for less, head, and tail like
>>> functionality for
>>> > looking at arrays, hashes, etc. Thus to be able to do:
>>> >
>>> > arr |> less
>>> > or
>>> > less(arr)
>>> > or
>>> > arr |> tail
>>> >
>>> > In addition, I think having the output of show() automatically go
>>> 

Re: [julia-users] pager in the repl

[Andrea Pagnani]

Too far fetched for my programming skills.  As I said, I would be already 
happy with a simple workaround to redirect STDOUT on less.

On Friday, May 23, 2014 2:45:56 PM UTC+2, Mike Innes wrote:
>
> Why do you say it's too far fetched? I agree that it shouldn't be the 
> default, but I don't see any technical issues with the idea.
>
>
> On 23 May 2014 13:36, Andrea Pagnani  >wrote:
>
>> The idea to have a pager that allows for browsing efficiently large data 
>> structures as proposed by Stefan is great but probably too far fetched. 
>> Also I agree that having a long output paged by default is not what I 
>> really need in my everyday data/program debugging. Suppose that 
>> ``myprog()`` prints a long output on the screen, what I would really fancy 
>>  would be something like ``myprog()  |> less``  ( the symbol ``|>``  might 
>> not be the good one though) or  ``tail``, ``head`` which, I do not know for 
>> windows system, but at least for MAC and Linux are already available. I use 
>> it quite often the syntax
>> command|>less
>> and redirects you through ``less`` to the line of julia code  where 
>> ``command`` is defined. Is there any way to redirect on the fly STDOUT from 
>> screen to, say less, but on the fly?
>>
>> Andrea
>>
>>
>>
>>
>> On Friday, May 23, 2014 11:45:18 AM UTC+2, Tomas Lycken wrote:
>>>
>>> Personally, I love the way Julia outputs large matrices - some rows from 
>>> the start, followed by "..." and then some rows from the end. If the matrix 
>>> is both wide and tall, it's truncated in both directions, but the central 
>>> point is that it's truncated in the middle, rather than on either end. That 
>>> lets me quickly inspect the entire thing - if it both starts and ends as I 
>>> expect, it's probably OK even in the parts that I don't see. If i'm not 
>>> sure, I can always use some more (or less) fine-tuned command (e.g. @show) 
>>> to look at the entire thing.
>>>
>>> The ideal solution to me, would be to do the same thing for all kinds of 
>>> output: the default way of displaying it would be to truncate it in the 
>>> middle, and if the user wants something else, they can manually request it. 
>>> And then, of course, it would be awesome if they could also manually pipe 
>>> it to something that works just like less, tail or whatever from the native 
>>> terminal.
>>>
>>> But I think making long output in the REPL paginated by default is a bad 
>>> idea - if I type something that results in a large amount of output just 
>>> because I forgot to add ; at the end, suddenly I have to get out of the 
>>> paginated output view before I can type my next command. I don't feel like 
>>> making the "read-eval-print-loop" more like a "read-eval-print-
>>> getoutofpaginatedview-loop"...
>>>
>>> // T
>>>
>>> On Friday, May 23, 2014 10:06:11 AM UTC+2, Tamas Papp wrote:

 I don't think a pager is the right solution, for the following reasons: 

 1. typing directly in to the REPL running in a terminal is not an 
 efficient way to program anything nontrivial, most users would use an 
 IDE (incl Emacs) that would allow scrolling and inspection of a value, 

 2. how many elements to print from large arrays etc could be controlled 
 by something like Common Lisp's *PRINT-LENGTH*, eg see 
 http://clhs.lisp.se/Body/v_pr_lev.htm (sorry if this already exists in 
 Julia, could not find it). 

 Best, 

 Tamas 

 On Thu, May 22 2014, Stefan Karpinski  wrote: 

 > Now that we have native terminal support, it would be a reasonable 
 project 
 > to write a pager in Julia. Why write our own pager (you ask)? Because 
 it 
 > could allow you to do things like efficiently page around a huge 
 array 
 > without having to print the whole thing. You could, e.g., instantly 
 page to 
 > the bottom right of a massive, distributed array, without any lag at 
 all. 
 > Of course, the thing is you want to use shared infrastructure for 
 doing 
 > this kind of data exploration in the terminal, IJulia, and maybe your 
 > editor. But the pager part could be pretty decoupled from that. 
 > 
 > 
 > On Thu, May 22, 2014 at 3:30 PM, Kevin Squire 
 > wrote: 

 > 
 >> Thanks! 
 >> 
 >> 
 >> On Thursday, May 22, 2014 11:52:12 AM UTC-7, Bob Nnamtrop wrote: 
 >> 
 >>> OK done. See https://github.com/JuliaLang/julia/issues/6921 
 >>> 
 >>> 
 >>> On Thu, May 22, 2014 at 12:20 PM, Kevin Squire 
 >>> wrote: 

 >>> 
  I agree that that would be nice.  Would you be willing to open up 
 an 
  issue for this? 
  
  
  On Thu, May 22, 2014 at 11:04 AM, Bob Nnamtrop <
 bob.nn...@gmail.com>wrote: 
  
 > I often find myself wishing for a pager in the repl when 
 outputing 
 > large amount of output. I see that there is a Base.less but it is 
 only used 
 > 

Re: [julia-users] pager in the repl

[Mike Innes]

Ah, I see.

Well, as it happens I began some work on a pager like this as a
proof-of-concept. If there's significant interest I could flesh it out into
something usable over the summer.


On 23 May 2014 13:58, Andrea Pagnani  wrote:

> Too far fetched for my programming skills.  As I said, I would be already
> happy with a simple workaround to redirect STDOUT on less.
>
>
> On Friday, May 23, 2014 2:45:56 PM UTC+2, Mike Innes wrote:
>
>> Why do you say it's too far fetched? I agree that it shouldn't be the
>> default, but I don't see any technical issues with the idea.
>>
>>
>> On 23 May 2014 13:36, Andrea Pagnani  wrote:
>>
>>> The idea to have a pager that allows for browsing efficiently large data
>>> structures as proposed by Stefan is great but probably too far fetched.
>>> Also I agree that having a long output paged by default is not what I
>>> really need in my everyday data/program debugging. Suppose that
>>> ``myprog()`` prints a long output on the screen, what I would really fancy
>>>  would be something like ``myprog()  |> less``  ( the symbol ``|>``  might
>>> not be the good one though) or  ``tail``, ``head`` which, I do not know for
>>> windows system, but at least for MAC and Linux are already available. I use
>>> it quite often the syntax
>>> command|>less
>>> and redirects you through ``less`` to the line of julia code  where
>>> ``command`` is defined. Is there any way to redirect on the fly STDOUT from
>>> screen to, say less, but on the fly?
>>>
>>> Andrea
>>>
>>>
>>>
>>>
>>> On Friday, May 23, 2014 11:45:18 AM UTC+2, Tomas Lycken wrote:

 Personally, I love the way Julia outputs large matrices - some rows
 from the start, followed by "..." and then some rows from the end. If the
 matrix is both wide and tall, it's truncated in both directions, but the
 central point is that it's truncated in the middle, rather than on either
 end. That lets me quickly inspect the entire thing - if it both starts and
 ends as I expect, it's probably OK even in the parts that I don't see. If
 i'm not sure, I can always use some more (or less) fine-tuned command (e.g.
 @show) to look at the entire thing.

 The ideal solution to me, would be to do the same thing for all kinds
 of output: the default way of displaying it would be to truncate it in the
 middle, and if the user wants something else, they can manually request it.
 And then, of course, it would be awesome if they could also manually pipe
 it to something that works just like less, tail or whatever from the native
 terminal.

 But I think making long output in the REPL paginated by default is a
 bad idea - if I type something that results in a large amount of output
 just because I forgot to add ; at the end, suddenly I have to get out of
 the paginated output view before I can type my next command. I don't feel
 like making the "read-eval-print-loop" more like a "read-eval-print-
 getoutofpaginatedview-loop"...

 // T

 On Friday, May 23, 2014 10:06:11 AM UTC+2, Tamas Papp wrote:
>
> I don't think a pager is the right solution, for the following
> reasons:
>
> 1. typing directly in to the REPL running in a terminal is not an
> efficient way to program anything nontrivial, most users would use an
> IDE (incl Emacs) that would allow scrolling and inspection of a value,
>
> 2. how many elements to print from large arrays etc could be
> controlled
> by something like Common Lisp's *PRINT-LENGTH*, eg see
> http://clhs.lisp.se/Body/v_pr_lev.htm (sorry if this already exists
> in
> Julia, could not find it).
>
> Best,
>
> Tamas
>
> On Thu, May 22 2014, Stefan Karpinski  wrote:
>
> > Now that we have native terminal support, it would be a reasonable
> project
> > to write a pager in Julia. Why write our own pager (you ask)?
> Because it
> > could allow you to do things like efficiently page around a huge
> array
> > without having to print the whole thing. You could, e.g., instantly
> page to
> > the bottom right of a massive, distributed array, without any lag at
> all.
> > Of course, the thing is you want to use shared infrastructure for
> doing
> > this kind of data exploration in the terminal, IJulia, and maybe
> your
> > editor. But the pager part could be pretty decoupled from that.
> >
> >
> > On Thu, May 22, 2014 at 3:30 PM, Kevin Squire 
> > wrote:
>
> >
> >> Thanks!
> >>
> >>
> >> On Thursday, May 22, 2014 11:52:12 AM UTC-7, Bob Nnamtrop wrote:
> >>
> >>> OK done. See https://github.com/JuliaLang/julia/issues/6921
> >>>
> >>>
> >>> On Thu, May 22, 2014 at 12:20 PM, Kevin Squire <
> kevin@gmail.com>wrote:
> >>>
>  I agree that that would be nice.  Would you be willing to open up
> an
>  issue for this?
>>

[julia-users] Another round of Pkg/git trouble in OS X

[Magnus Lie Hetland]

There seem to have been several rounds of trouble with Pkg calling git in 
OS X, and it may be that I've missed an existing unresolved issue here, and 
that I'm therefore reiterating known material. I also added an issue to the 
GitHub tracker (https://github.com/JuliaLang/julia/issues/6880) -- maybe I 
should have discussed it here first. Sorry.

But, yeah, the trouble is getting Pkg to work. For some reason, it *did* 
work at some point (a week ago?). I managed to install a couple of packages 
without a hitch. But then it stopped working, and I'm not sure what 
changed. I don't *think* I changed my environment variables or the 
installed version of Julia, but I'm not 100% sure.

And, yes, I'm using MacPorts -- not sure if that's part of the issue. When 
I run `which git` in Julia, it reports the MacPorts one, with version 
number 1.8.5.5. But when I try to use it via Pkg, it fails. Now even init() 
fails (after removing the .julia directory):

*julia> **Pkg.init()*

*INFO: Initializing package repository /Users/mlh/.julia/v0.3*

*INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl*

usage: git index-pack [-v] [-o ] [--keep | --keep=] 
[--verify] [--strict] ( | --stdin [--fix-thin] [])

fatal: index-pack failed

*ERROR: failed process: Process(`git clone -q -b metadata-v2 
git://github.com/JuliaLang/METADATA.jl METADATA`, ProcessExited(128)) [128]*

* in pipeline_error at process.jl:489*

* in run at process.jl:466*

* in anonymous at pkg/dir.jl:43*

* in cd at file.jl:20*

* in init at pkg/dir.jl:41*

* in init at pkg.jl:16*


*julia> *

Any suggestions for trouble-shooting?

Re: [julia-users] Releasing SharedArray Memory

[Tim Holy]

Yes, it sounds like this was indeed the problem.

I bet this could be solved automatically with a proper finalizer. Is there any 
chance you could create a small testcase that demonstrates the problem, and 
then submit an issue?
https://github.com/JuliaLang/julia/issues/new

Best,
--Tim

On Wednesday, May 21, 2014 03:04:38 PM Gustavo Camilo wrote:
> Hi Tim, thanks for answering!
> 
> I don't do any explicit passing, all memory management is  done through a
> pmap(data, x->myFunction(x,capitals))
> 
> I was able to solve(?) the problem (has been running for a while, way
> longer than the time it took to crash before) by calling instead
> 
> @everywhere capitals = 0
> capitalsRaw = 0
> gc()
> 
> That is, deallocating with an @everywhere sign. Do you think this could be
> what caused the problem before? I think that before the garbage collector
> let them stay in memory as we did not deallocate locally on each processor.
> 
>  I have not been able to do a simple testcase as I'm still using the
> machine to compute some stuff, but will try to do so soon.
> 
> Gustavo
> 
> On Monday, 19 May 2014 16:53:18 UTC-4, Tim Holy wrote:
> > I haven't tested this myself, but is there any chance that a reference to
> > the
> > SharedArray survives in one of the workers? For example, if you did a
> > 
> > rr = put!(RemoteRef(pworker), SA)
> > 
> > then you'd have to do the same tricks in the worker that you did in the
> > driver
> > process.
> > 
> > But if you've checked the obvious candidates, you might as well file an
> > issue.
> > It would be helpful if you can produce a small testcase that reproduces
> > the
> > problem.
> > 
> > --Tim
> > 
> > On Monday, May 19, 2014 10:31:41 AM Gustavo Camilo wrote:
> > > Hi all,
> > > 
> > > I've run across a memory problem that I want to know if I'm doing wrong
> > > before I open an issue:
> > > 
> > > In the function I optimize I run a large procedure that calls C code
> > > repeatedly and I end up having a huge (40^5 Float64) matrix, which I
> > 
> > want
> > 
> > > to be able to use in a function I pmap, so I run this code to compute
> > 
> > and
> > 
> > > then copy into a shared array:
> > > 
> > > 
> > > capitalsRaw = findZeroDividendsInC(privModel)
> > > capitals =
> > 
> > SharedArray(Float64,(length(privModel.vW),3,length(privModel.vK),length(pr
> > iv> 
> > > Model.vQ),
> > > length(privModel.vQ),length(privModel.vQ)),init=false,pids=workers());
> > > copy!(capitals,capitalsRaw)
> > > 
> > > I do some work with this, and then, since my memory usage was
> > 
> > increasing, I
> > 
> > > release these arrays like it says in the Performance section of the
> > 
> > manual:
> > > capitals = 0
> > > capitalsRaw = 0
> > > gc()
> > > 
> > > 
> > > However, after the function has been called a bunch of times:
> > > 
> > > exception on
> > > 
> > > From worker 17: System max size of single shmem segment(MB) :
> > 65536
> > 
> > > From worker 17: System max size of all shmem segments(MB) : 16777216
> > > From worker 17: Requested size(MB) : 1221
> > > From worker 17: Please ensure requested size is within system limits.
> > > From worker 17: If not, increase system limits and try again.
> > > ERROR: memory mapping failed: Cannot allocate memory
> > > 
> > >  in systemerror at error.jl:39
> > >  in mmap at mmap.jl:32
> > >  in mmap_array at mmap.jl:107
> > >  in shm_mmap_array at sharedarray.jl:357
> > >  in anonymous at sharedarray.jl:59
> > >  in anonymous at multi.jl:840
> > >  in run_work_thunk at multi.jl:613
> > >  in run_work_thunk at multi.jl:622
> > >  in anonymous at task.jl:6
> > > 
> > > Shouldn't releasing the shared arrays by setting them to zero and
> > 
> > calling
> > 
> > > gc() have cleaned up my usage? I don't think there is any other leak in
> > 
> > the
> > 
> > > code, and the error is from the shared memory array allocator always,
> > 
> > not
> > 
> > > for any other part of the code.
> > > 
> > > Thanks for any help!
> > > Gustavo

Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Adam Smith]

Thanks all for the feedback! I have renamed it to TextPlot.jl, added 
support for plotting just about any combination of 
functions/vectors/matrix, made the API more flexible for Gadfly 
compatibility, and greatly expanded the documentation/examples. It is now 
quite a bit more powerful than 
ASCIIPlots: https://github.com/sunetos/TextPlot.jl

Ivar: I like the idea of having this be a backend for one of the other 
plotting packages, but the dependency would need to be the other direction. 
Meaning, they would need to add support for TextPlot, not the other way 
around. Right now TextPlot has zero dependencies, so you can use it in 
basically any environment, including a console-only server connected over 
SSH. Installing Gadfly requires quite a few dependencies on other packages, 
including Cairo and other graphical packages if you want PNG charts (for 
iTerm2+IPython inline charts, a similar use case to this one). TextPlot 
would be quite useful for machines that cannot build all those other 
packages, so I don't want to make TextPlot depend on any of those packages.

I think TextPlot is pretty capable already; please let me know if you can 
think of anything it's missing!

On Friday, May 23, 2014 5:24:50 AM UTC-4, Ivar Nesje wrote:
>
> Yes, that was definitely my intention to suggest. It looks to me like 
> ASCIIPlots.jl and DotPlot.jl solves the same problem in a very similar way, 
> and whether to use Unicode for higher resolution seems like something I 
> would expect to be an option.
>
> Anyway, the ultimate goal for ASCII art plots, would be to implement it as 
> a backend for one of the normal plotting packages.
>
> Ivar
>
> kl. 10:06:42 UTC+2 fredag 23. mai 2014 skrev Tobias Knopp følgende:
>>
>> I think "merge" was meant as: Lets create one uniform package and join 
>> the efforts. Since ASCIIPlots is not actively maintained I think it would 
>> be really great if you could take the lead to make an awsome text plotting 
>> tool.
>>
>> I like the name TextPlot by the way.
>>
>> Am Donnerstag, 22. Mai 2014 17:42:06 UTC+2 schrieb Adam Smith:
>>>
>>> TextPlot seems like a good name.
>>>
>>> Thanks for the offer on merging, but again, there's really nothing to 
>>> merge. Adding scatterplots to dotplot will be trivial; I'll do that soon 
>>> (making dotplot's features a superset of ASCIIPlots). There is nothing 
>>> compatible/overlapping between these two (small) codebases for merging to 
>>> make sense.
>>>
>>> I would be curious what John Myles White thinks about a more complete 
>>> terminal plotting package for Julia. ASCIIPlots clearly imitates Matlab's 
>>> plotting functions ("imagesc"), and I was going for something closer to 
>>> Mathematica or Maple (which are more symbolic-oriented than Matlab), since 
>>> I think the syntax is prettier. However, I know a large portion of Julia's 
>>> users are also Matlab users, so if Matlab-compatibility is a goal, you may 
>>> want to keep the packages separate.
>>>
>>> On Thursday, May 22, 2014 11:25:01 AM UTC-4, Leah Hanson wrote:

 Maybe something like TextPlot would be a good merged name? It conveys 
 what the package does (text plots) rather than how it does it (Braille 
 characters).

 Having a more complete plotting package for the terminal would move 
 towards having a way to make `plot` just work when you start up a Julia 
 REPL, which I think is a goal. I'd be happy to help merge them, but 
 probably won't have time for a couple weeks.

 -- Leah


 On Thu, May 22, 2014 at 7:49 AM, Adam Smith wrote:

> I'm not totally opposed to it, but my initial reaction is not to:
>
>1. I don't necessarily agree about the name. I personally think 
>"dot plot" has a nice ring to it, and it is a more accurate 
> description of 
>what it does (using Braille characters). This very specifically 
> exploits 
>Unicode (non-ASCII) characters, so calling it an ASCII plot would be 
>misleading (for those who want the restricted character set for some 
>reason). 
>2. There's not really a single line of code they have in common, 
>so there's nothing to "merge": it would just be a rename. I didn't 
> look at 
>the code of ASCIIPlots before making it, and we chose completely 
> different 
>APIs. For example, ASCIIPlots doesn't have a way to plot functions, 
> and 
>DotPlot doesn't (yet) have a way to scatterplot an array. 
>3. They are both quite small and simple (dotplot is ~100 lines of 
>code, ascii is ~250); merging would probably be more work than either 
>originally took to create.
>
>
> On Thursday, May 22, 2014 1:31:10 AM UTC-4, Ivar Nesje wrote:
>>
>> Would it make sense to merge this functionality into ASCIIPlots? To 
>> me that seems like a better name, and John Myles White is likely to be 
>> willing to transfer the repository if you wa

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Job van der Zwan]

By the way, no discussion about data visualisation tools is complete 
without this design prototype by Bret Victor:

https://vimeo.com/66085662

and Victor's written addendum:

http://worrydream.com/DrawingDynamicVisualizationsTalkAddendum/

On Saturday, 17 May 2014 18:51:37 UTC+2, Simon Danisch wrote:
>
> Hi, 
> I'm currently in the planning phase for my GSOC 3D Visualization project, 
> which also means, that I need to define what the most important 
> visualization forms are.
> I must admit, that I haven't done much plotting myself, so I would have to 
> guess what the really important bits are.
> Instead of slavishly  
> imitating 
> Matlabs plot functions with some mix-ins from my side, I thought we can do 
> better, by getting feedback off the people, that actually plan to use 3D 
> plotting in Julia!
> It would help me a lot, if you could specify what you need exactly in 
> great detail.
> Just tell me what you hate about current solutions, what features you 
> really like, the format of your data, how you like to work, etc...
> Like this, I can find out what needs to be done in order to visualize your 
> data, rate the importance and difficulty and than decide in which order I 
> implement the different plotting capabilities.
> Any feedback, ideas and comments are welcome!
>
> Best wishes,
> Simon
>

Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Mike Innes]

Incidentally, interop with other packages without a hard dependency is
something that's around the corner, so you will be able to do this soon.


On 23 May 2014 15:32, Adam Smith  wrote:

> Thanks all for the feedback! I have renamed it to TextPlot.jl, added
> support for plotting just about any combination of
> functions/vectors/matrix, made the API more flexible for Gadfly
> compatibility, and greatly expanded the documentation/examples. It is now
> quite a bit more powerful than ASCIIPlots:
> https://github.com/sunetos/TextPlot.jl
>
> Ivar: I like the idea of having this be a backend for one of the other
> plotting packages, but the dependency would need to be the other direction.
> Meaning, they would need to add support for TextPlot, not the other way
> around. Right now TextPlot has zero dependencies, so you can use it in
> basically any environment, including a console-only server connected over
> SSH. Installing Gadfly requires quite a few dependencies on other packages,
> including Cairo and other graphical packages if you want PNG charts (for
> iTerm2+IPython inline charts, a similar use case to this one). TextPlot
> would be quite useful for machines that cannot build all those other
> packages, so I don't want to make TextPlot depend on any of those packages.
>
> I think TextPlot is pretty capable already; please let me know if you can
> think of anything it's missing!
>
>
> On Friday, May 23, 2014 5:24:50 AM UTC-4, Ivar Nesje wrote:
>>
>> Yes, that was definitely my intention to suggest. It looks to me like
>> ASCIIPlots.jl and DotPlot.jl solves the same problem in a very similar way,
>> and whether to use Unicode for higher resolution seems like something I
>> would expect to be an option.
>>
>> Anyway, the ultimate goal for ASCII art plots, would be to implement it
>> as a backend for one of the normal plotting packages.
>>
>> Ivar
>>
>> kl. 10:06:42 UTC+2 fredag 23. mai 2014 skrev Tobias Knopp følgende:
>>>
>>> I think "merge" was meant as: Lets create one uniform package and join
>>> the efforts. Since ASCIIPlots is not actively maintained I think it would
>>> be really great if you could take the lead to make an awsome text plotting
>>> tool.
>>>
>>> I like the name TextPlot by the way.
>>>
>>> Am Donnerstag, 22. Mai 2014 17:42:06 UTC+2 schrieb Adam Smith:

 TextPlot seems like a good name.

 Thanks for the offer on merging, but again, there's really nothing to
 merge. Adding scatterplots to dotplot will be trivial; I'll do that soon
 (making dotplot's features a superset of ASCIIPlots). There is nothing
 compatible/overlapping between these two (small) codebases for merging to
 make sense.

 I would be curious what John Myles White thinks about a more complete
 terminal plotting package for Julia. ASCIIPlots clearly imitates Matlab's
 plotting functions ("imagesc"), and I was going for something closer to
 Mathematica or Maple (which are more symbolic-oriented than Matlab), since
 I think the syntax is prettier. However, I know a large portion of Julia's
 users are also Matlab users, so if Matlab-compatibility is a goal, you may
 want to keep the packages separate.

 On Thursday, May 22, 2014 11:25:01 AM UTC-4, Leah Hanson wrote:
>
> Maybe something like TextPlot would be a good merged name? It conveys
> what the package does (text plots) rather than how it does it (Braille
> characters).
>
> Having a more complete plotting package for the terminal would move
> towards having a way to make `plot` just work when you start up a Julia
> REPL, which I think is a goal. I'd be happy to help merge them, but
> probably won't have time for a couple weeks.
>
> -- Leah
>
>
> On Thu, May 22, 2014 at 7:49 AM, Adam Smith wrote:
>
>> I'm not totally opposed to it, but my initial reaction is not to:
>>
>>1. I don't necessarily agree about the name. I personally think
>>"dot plot" has a nice ring to it, and it is a more accurate 
>> description of
>>what it does (using Braille characters). This very specifically 
>> exploits
>>Unicode (non-ASCII) characters, so calling it an ASCII plot would be
>>misleading (for those who want the restricted character set for some
>>reason).
>>2. There's not really a single line of code they have in common,
>>so there's nothing to "merge": it would just be a rename. I didn't 
>> look at
>>the code of ASCIIPlots before making it, and we chose completely 
>> different
>>APIs. For example, ASCIIPlots doesn't have a way to plot functions, 
>> and
>>DotPlot doesn't (yet) have a way to scatterplot an array.
>>3. They are both quite small and simple (dotplot is ~100 lines of
>>code, ascii is ~250); merging would probably be more work than either
>>originally took to create.
>>
>>
>> On Thursday, May

Re: [julia-users] pager in the repl

[Stefan Karpinski]

On Fri, May 23, 2014 at 9:06 AM, Mike Innes  wrote:

> Well, as it happens I began some work on a pager like this as a
> proof-of-concept. If there's significant interest I could flesh it out into
> something usable over the summer.


+100

A pager like this and better infrastructure for matrix-like printing is
something I've been meaning to tackle for a long time. Something that
DataFrames and other structures (Dicts, Lists of Lists, etc.) can easily
hook into and automatically get the same kind of nice truncated printing as
matrices, but also automatically get efficient printing in a built-in pager
(appropriate display widgets in IJulia would be great too).

The interface to paging could be the same as in the shell. I.e. you would
do this:

julia> arr |> less


and it would pop up a pager for you. Of course, you could also call it as
less(arr).

Re: [julia-users] pager in the repl

[Mike Innes]

Cool, I'll add this to my ever-growing list :)

Perhaps less could emit some kind of Scrollable wrapper type, which would
display itself in the REPL as a pager, or in IJulia as an HTML scroll pane?
I've been meaning to try out  display of arrays anyway, so this
would tie in neatly with that.

Re: [julia-users] pager in the repl

[Stefan Karpinski]

Yes, that might be a good way to do it. Basically the display methods of
the Scrollable object (the thing returned by less) could do whatever it
needed to do, including show the object in a pager or start a Task that
answers questions from a widget about the object to be displayed and return.


On Fri, May 23, 2014 at 11:45 AM, Mike Innes  wrote:

> Cool, I'll add this to my ever-growing list :)
>
> Perhaps less could emit some kind of Scrollable wrapper type, which would
> display itself in the REPL as a pager, or in IJulia as an HTML scroll pane?
> I've been meaning to try out  display of arrays anyway, so this
> would tie in neatly with that.
>

[julia-users] Re: Run Julia job on several workers on a cluster

[Thibaut Lamadon]

looks good, I guess we should wrap this code into a ClusterManager. I am 
going to look into this.

On Wednesday, 7 May 2014 20:52:17 UTC+1, ken...@sdsc.edu wrote:
>
>
> I've run parallel julia on a Torque cluster with Infiniband.  I start an 
> interactive session with qsub -I,
> look for allocated nodes in $PBS_NODEFILE, convert to IB interface names, 
> and addprocs.
>
> filestream = open(ENV["PBS_NODEFILE"])
> seekstart(filestream)
> linearray = readlines(filestream)
> strippedarray = similar(linearray)
> for i in 1:length(linearray)
> strippedarray[i] = strip(linearray[i]) * "-ipoib.ipoib"
> end
> for i in 1:length(strippedarray)
>  singlearray = [strip(strippedarray[i])]
>  addprocs(singlearray)
> end
> print(workers())
>
> To start an interactive job, depending on your node configuration and 
> queue names:
> qsub -I -l nodes=2:ppn=32,walltime=00:30:00 -q normal
>
> When you get your nodes, start julia with the above setup file with:
> julia --load setupfilename
>
> This should addprocs then give you the julia prompt.
>
> But it looks like something is wrong with your modules?
>
> On Friday, April 25, 2014 5:09:57 AM UTC-7, Isaac wrote:
>>
>> Hi All,
>>  
>>  I also tried to submit the julia jobs on the cluster but failed. I wrote 
>> the job script as follows:
>> f
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *or((i = 1; i < 10; i++))doecho "# cd /data#PBS -l 
>> walltime=00:10:00module add gcc/4.7.2module add julia/0.2.0module load 
>> juliainclude("test.jl")test($i)">test1job$i;qsub test1job$i;done*
>> I got the errors: 
>> julia/0.2.0(16):ERROR:151: Module 'julia/0.2.0' depends on one of the 
>> module(s) 'gcc/4.7.2'
>> julia/0.2.0(16):ERROR:102: Tcl command execution failed: prereq gcc/4.7.2
>>
>> /cm/local/apps/torque/current/mom_priv/jobs/1053.cluster.SC: line 7: 
>> syntax error near unexpected token `a0d0.jl'
>> /cm/local/apps/torque/current/mom_priv/jobs/1053.cluster.SC: line 7: 
>> `include(a0d0.jl)'
>>
>> Does anybody know how to write the job script to submit julia job on a 
>> cluster? Could you give an example?
>> Thanks in advance.
>>
>> Isaac
>>
>>  
>>
>>
>>

[julia-users] Re: Problems with the scheduling example in the docs

[Peter Simon]

I haven't seen any other answers to these questions, so I'll take a shot at 
providing some.  Corrections are welcome.

Answer 1)  The purpose of the @sync block is to prevent execution (of the 
main julia process) from proceeding beyond the block until the tasks 
launched by all enclosed @async blocks have completed.

Answer 2)  Your understanding of for loops is correct.  The loop over p 
iterates 
over the values p = 1,2,3 once only, and in that order.  Let's examine what 
happens during each iteration.  Bear in mind that for your example np = 3  
and myid() returns 1, since the call to myid() is executed on the main 
julia process. On the first loop iteration, when p=1, the predicate of the 
if statement is false, so nothing is done.  On the second loop iteration, 
the @async block is executed with p=2.  This launches a task (coroutine) on 
the main (p=1) julia process.  Note that once launched, this task runs 
simultaneously (asynchronously) with the main julia process thread of 
execution.  *The main process immediately continues on, without needing to 
wait for the task to complete*. That means that another (p=3) iteration 
will begin while the @async task initiated in the p=2 iteration is still 
running. The p=3 iteration will execute the @async code block again, 
launching another task.  Since this is the final for loop iteration, 
execution of the main julia thread will fall through to the end of the @sync 
block, 
where it will wait until both of the previously launched @async tasks are 
complete.  What do these tasks do?  Each executes a while loop over and 
over. On each iteration of the while loop, the value of the function-scope 
(for the pmap2 function) variable i,a counter for which element of lst is 
to be treated, is obtained, assigned to the local idx variable and then 
incremented.  Note that both of these tasks are manipulating the value of 
the same function-scope variable i; thus, there is effectively 
communication between the tasks.   For each task, the while loop terminates 
if there are no more elements of lst to treat, which completes execution of 
the @async block.  Because the loop over p is a for loop, the p variable is 
freshly allocated on each iteration (see 
for-loops-and-comprehensions),
 
so that the two tasks are provided with two distinct p values 2 and 3. 
 Thus, the calls to remotecall_fetch in the p=2 and p=3 tasks will 
send work to julia worker instances 2 and 3, respectively.  Invocation of 
remotecall_fetch is a blocking call, so each time it is executed, the 
calling task waits for the worker julia process to complete its assigned 
work and return the result.  So each task feeds work to its dedicated julia 
worker process in a loop, as fast as the worker can handle, incrementing 
the "shared" variable i so that either worker always knows which is the 
next element of the lst collection to be treated.  Each task waits for its 
worker to be ready for more work, independent of how quickly or slowly the 
other worker can finish its own work.  That is why sometimes you see the 
same p value in consecutive lines of your printout.  One worker (p=3, for 
your printout) happens to finish its SVD computation before the other, so 
it is the first one ready to go to work on the next SVD calculation.

Hope this helps,

--Peter

On Friday, May 16, 2014 6:33:11 AM UTC-7, St Elmo Wilken wrote:
>
> Hi,
>
> I'm struggling to understand the scheduling subsection (in the parallel 
> computation section) of the docs; specifically how the pmap function as 
> shown there works. I've copy-pasted the code I used below my questions.
>
> Question 1) Is the purpose of the @sync block just to wait for all the 
> processes to finish before returning the variable results i.e. so that no 
> incomplete references are returned?
>
> Question 2) If you run the code below (I added 2 other processes) you'll 
> see the following output:
>
> In @async, p = 2, idx = 1
> In @async, p = 3, idx = 2
> In @async, p = 3, idx = 3
> In @async, p = 2, idx = 4
> In @async, p = 3, idx = 5
>
> How does p go from 2 to 3 to 2 etc.? I thought a for loop runs through 
> its iterations sequentially? Clearly @async does something exotic but I 
> don't get it?
>
> Any help appreciated!
>
>
> The code:
>
> M = {rand(800,800), rand(800,800), rand(600,600), rand(600,600), 
> rand(500,500)} 
>
>
> function pmap2(f, lst)
>
>np = nprocs()  # determine the number of processes available
>
>n = length(lst)
>
>results = cell(n)
>
>i = 1
>
># function to produce the next work item from the queue.
>
># in this case it's just an index.
>
>nextidx() = (idx=i; i+=1; idx)
>
>@sync begin
>
>  for p=1:np
>
>  if p != myid() || np == 1
>
>  @async begin
>
>while true
>
>idx = nextidx()
>
>

[julia-users] Globbing

[Jameson Nash]

Since @ramp on IRC was looking for glob functionality recently, it is now
available in the Glob.jl package.

Re: [julia-users] Globbing

[Stefan Karpinski]

Cool. Once this has settled in and seems solid it's a good candidate for
moving into Base.


On Fri, May 23, 2014 at 1:21 PM, Jameson Nash  wrote:

> Since @ramp on IRC was looking for glob functionality recently, it is now
> available in the Glob.jl package.
>

Re: [julia-users] Globbing

[Stefan Karpinski]

Looking at this, it occurs to me that since all the tests are just in the
test/runtests.jl file, and this is probably a pretty common case, maybe the
name of that file is a little unfortunate. It's a good name if there are a
ton of tests in lots of files and ways to run various subsets of them, but
it's probably pretty common, especially initially, for a package to just
have one test file like this. Calling it test/tests.jl might be better?


On Fri, May 23, 2014 at 2:03 PM, Stefan Karpinski wrote:

> Cool. Once this has settled in and seems solid it's a good candidate for
> moving into Base.
>
>
> On Fri, May 23, 2014 at 1:21 PM, Jameson Nash  wrote:
>
>> Since @ramp on IRC was looking for glob functionality recently, it is now
>> available in the Glob.jl package.
>>
>
>

Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Stefan Karpinski]

There's a convention to name packages plurally – i.e. TextPlots rather than
TextPlot. This is nice partly because using TextPlots reads more naturally
than using TextPlot, but more importantly because if you, as is likely, end
up having a type called TextPlot, then you don't get a name collision.

On Fri, May 23, 2014 at 10:56 AM, Mike Innes  wrote:

> Incidentally, interop with other packages without a hard dependency is
> something that's around the corner, so you will be able to do this soon.
>
>
> On 23 May 2014 15:32, Adam Smith  wrote:
>
>> Thanks all for the feedback! I have renamed it to TextPlot.jl, added
>> support for plotting just about any combination of
>> functions/vectors/matrix, made the API more flexible for Gadfly
>> compatibility, and greatly expanded the documentation/examples. It is now
>> quite a bit more powerful than ASCIIPlots:
>> https://github.com/sunetos/TextPlot.jl
>>
>> Ivar: I like the idea of having this be a backend for one of the other
>> plotting packages, but the dependency would need to be the other direction.
>> Meaning, they would need to add support for TextPlot, not the other way
>> around. Right now TextPlot has zero dependencies, so you can use it in
>> basically any environment, including a console-only server connected over
>> SSH. Installing Gadfly requires quite a few dependencies on other packages,
>> including Cairo and other graphical packages if you want PNG charts (for
>> iTerm2+IPython inline charts, a similar use case to this one). TextPlot
>> would be quite useful for machines that cannot build all those other
>> packages, so I don't want to make TextPlot depend on any of those packages.
>>
>> I think TextPlot is pretty capable already; please let me know if you can
>> think of anything it's missing!
>>
>>
>> On Friday, May 23, 2014 5:24:50 AM UTC-4, Ivar Nesje wrote:
>>>
>>> Yes, that was definitely my intention to suggest. It looks to me like
>>> ASCIIPlots.jl and DotPlot.jl solves the same problem in a very similar way,
>>> and whether to use Unicode for higher resolution seems like something I
>>> would expect to be an option.
>>>
>>> Anyway, the ultimate goal for ASCII art plots, would be to implement it
>>> as a backend for one of the normal plotting packages.
>>>
>>> Ivar
>>>
>>> kl. 10:06:42 UTC+2 fredag 23. mai 2014 skrev Tobias Knopp følgende:

 I think "merge" was meant as: Lets create one uniform package and join
 the efforts. Since ASCIIPlots is not actively maintained I think it would
 be really great if you could take the lead to make an awsome text plotting
 tool.

 I like the name TextPlot by the way.

 Am Donnerstag, 22. Mai 2014 17:42:06 UTC+2 schrieb Adam Smith:
>
> TextPlot seems like a good name.
>
> Thanks for the offer on merging, but again, there's really nothing to
> merge. Adding scatterplots to dotplot will be trivial; I'll do that soon
> (making dotplot's features a superset of ASCIIPlots). There is nothing
> compatible/overlapping between these two (small) codebases for merging to
> make sense.
>
> I would be curious what John Myles White thinks about a more complete
> terminal plotting package for Julia. ASCIIPlots clearly imitates Matlab's
> plotting functions ("imagesc"), and I was going for something closer to
> Mathematica or Maple (which are more symbolic-oriented than Matlab), since
> I think the syntax is prettier. However, I know a large portion of Julia's
> users are also Matlab users, so if Matlab-compatibility is a goal, you may
> want to keep the packages separate.
>
> On Thursday, May 22, 2014 11:25:01 AM UTC-4, Leah Hanson wrote:
>>
>> Maybe something like TextPlot would be a good merged name? It conveys
>> what the package does (text plots) rather than how it does it (Braille
>> characters).
>>
>> Having a more complete plotting package for the terminal would move
>> towards having a way to make `plot` just work when you start up a Julia
>> REPL, which I think is a goal. I'd be happy to help merge them, but
>> probably won't have time for a couple weeks.
>>
>> -- Leah
>>
>>
>> On Thu, May 22, 2014 at 7:49 AM, Adam Smith 
>> wrote:
>>
>>> I'm not totally opposed to it, but my initial reaction is not to:
>>>
>>>1. I don't necessarily agree about the name. I personally think
>>>"dot plot" has a nice ring to it, and it is a more accurate 
>>> description of
>>>what it does (using Braille characters). This very specifically 
>>> exploits
>>>Unicode (non-ASCII) characters, so calling it an ASCII plot would be
>>>misleading (for those who want the restricted character set for some
>>>reason).
>>>2. There's not really a single line of code they have in common,
>>>so there's nothing to "merge": it would just be a rename. I didn't 
>>> look at
>>>the code o

[julia-users] Add new field to a type - repl error

[Kuba Roth]

Hi there,
In repl I define a custom composite type such as:
julia> type qqq
  rx::Float32
  ry::Float32
  rz::Float32
  end

and then I add another field which throws the following error:
ERROR: invalid redefinition of constant qqq

Could someone please explain why this is not allowed?

Thanks,
kuba

Re: [julia-users] Add new field to a type - repl error

[Stefan Karpinski]

You can't redefine types in Julia. That's one of the limitations that lets
Julia generate fast code.


On Fri, May 23, 2014 at 2:21 PM, Kuba Roth  wrote:

> Hi there,
> In repl I define a custom composite type such as:
> julia> type qqq
>   rx::Float32
>   ry::Float32
>   rz::Float32
>   end
>
> and then I add another field which throws the following error:
> ERROR: invalid redefinition of constant qqq
>
> Could someone please explain why this is not allowed?
>
> Thanks,
> kuba
>

[julia-users] Re: Add new field to a type - repl error

[Patrick O'Leary]

Let's say after you defined qqq, you defined/used a function with an 
argument of type qqq. The JIT has now compiled and cached a function 
specialized for the original definition of qqq. If qqq can be redefined, 
that function needs to be thrown away, but the system can't track those 
dependencies (yet, see #2385).

There is a workaround: 
http://docs.julialang.org/en/latest/manual/faq/#how-can-i-modify-the-declaration-of-a-type-immutable-in-my-session

On Friday, May 23, 2014 1:21:57 PM UTC-5, Kuba Roth wrote:
>
> Hi there,
> In repl I define a custom composite type such as:
> julia> type qqq
>   rx::Float32
>   ry::Float32
>   rz::Float32
>   end
>
> and then I add another field which throws the following error:
> ERROR: invalid redefinition of constant qqq
>
> Could someone please explain why this is not allowed?
>
> Thanks,
> kuba
>
>

[julia-users] What's with the Nothing type?

[Dom Luna]

I just have general curiosity about the Nothing type, is there anything one 
should particularly know about it? Is it similar to a None type that one 
would typically find in pattern matching, ex. an Option type where it can 
be either Something or None, etc.

I feel like Nothing and patterns for its use aren't well documented to this 
point.

Dom

[julia-users] Re: Add new field to a type - repl error

[Kuba Roth]

This limits productivity in the early stage of code developement, when the 
types may change quite a bit.  At he moment every change to a custom type 
requires either repl restart or type rename. 

I run into this problem in sublime-iJulia initially were whole buffer (which 
has a type definition) can be evaluated only once. The next time type section 
needs to be commented out. But this is more a plugin specific issue.
Thanks for a quick feedback,
Kuba

[julia-users] Re: Add new field to a type - repl error

[Kuba Roth]

Thanks Patrick for the link. So the answer to my problem is to define types 
externally and reload a module each time type is changed. 
Soods good, let me test that...
Cheers,
kuba

Re: [julia-users] pager in the repl

[Andrea Pagnani]

And what about paging the STDOUT produced by program from the repl?

I often would like to do something like

julia> myprog() |> less

and piping the STDOUT of myprog() on the pager. Would it be possible?

Andrea  

On Friday, May 23, 2014 6:04:58 PM UTC+2, Stefan Karpinski wrote:
>
> Yes, that might be a good way to do it. Basically the display methods of 
> the Scrollable object (the thing returned by less) could do whatever it 
> needed to do, including show the object in a pager or start a Task that 
> answers questions from a widget about the object to be displayed and return.
>
>
> On Fri, May 23, 2014 at 11:45 AM, Mike Innes 
> > wrote:
>
>> Cool, I'll add this to my ever-growing list :)
>>
>> Perhaps less could emit some kind of Scrollable wrapper type, which would 
>> display itself in the REPL as a pager, or in IJulia as an HTML scroll pane? 
>> I've been meaning to try out  display of arrays anyway, so this 
>> would tie in neatly with that.
>>  
>
>

Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Adam Smith]

Sigh, I had a nagging feeling it was supposed to be plural. I did one more 
(hopefully final) rename to 
TextPlots.jl: https://github.com/sunetos/TextPlots.jl and updated the 
source/readme and such.

On Friday, May 23, 2014 2:18:54 PM UTC-4, Stefan Karpinski wrote:
>
> There's a convention to name packages plurally – i.e. TextPlots rather 
> than TextPlot. This is nice partly because using TextPlots reads more 
> naturally than using TextPlot, but more importantly because if you, as is 
> likely, end up having a type called TextPlot, then you don't get a name 
> collision.
>
> On Fri, May 23, 2014 at 10:56 AM, Mike Innes 
> > wrote:
>
>> Incidentally, interop with other packages without a hard dependency is 
>> something that's around the corner, so you will be able to do this soon.
>>
>>
>> On 23 May 2014 15:32, Adam Smith >wrote:
>>
>>> Thanks all for the feedback! I have renamed it to TextPlot.jl, added 
>>> support for plotting just about any combination of 
>>> functions/vectors/matrix, made the API more flexible for Gadfly 
>>> compatibility, and greatly expanded the documentation/examples. It is now 
>>> quite a bit more powerful than ASCIIPlots: 
>>> https://github.com/sunetos/TextPlot.jl
>>>
>>> Ivar: I like the idea of having this be a backend for one of the other 
>>> plotting packages, but the dependency would need to be the other direction. 
>>> Meaning, they would need to add support for TextPlot, not the other way 
>>> around. Right now TextPlot has zero dependencies, so you can use it in 
>>> basically any environment, including a console-only server connected over 
>>> SSH. Installing Gadfly requires quite a few dependencies on other packages, 
>>> including Cairo and other graphical packages if you want PNG charts (for 
>>> iTerm2+IPython inline charts, a similar use case to this one). TextPlot 
>>> would be quite useful for machines that cannot build all those other 
>>> packages, so I don't want to make TextPlot depend on any of those packages.
>>>
>>> I think TextPlot is pretty capable already; please let me know if you 
>>> can think of anything it's missing!
>>>
>>>
>>> On Friday, May 23, 2014 5:24:50 AM UTC-4, Ivar Nesje wrote:

 Yes, that was definitely my intention to suggest. It looks to me like 
 ASCIIPlots.jl and DotPlot.jl solves the same problem in a very similar 
 way, 
 and whether to use Unicode for higher resolution seems like something I 
 would expect to be an option.

 Anyway, the ultimate goal for ASCII art plots, would be to implement it 
 as a backend for one of the normal plotting packages.

 Ivar

 kl. 10:06:42 UTC+2 fredag 23. mai 2014 skrev Tobias Knopp følgende:
>
> I think "merge" was meant as: Lets create one uniform package and join 
> the efforts. Since ASCIIPlots is not actively maintained I think it would 
> be really great if you could take the lead to make an awsome text 
> plotting 
> tool.
>
> I like the name TextPlot by the way.
>
> Am Donnerstag, 22. Mai 2014 17:42:06 UTC+2 schrieb Adam Smith:
>>
>> TextPlot seems like a good name.
>>
>> Thanks for the offer on merging, but again, there's really nothing to 
>> merge. Adding scatterplots to dotplot will be trivial; I'll do that soon 
>> (making dotplot's features a superset of ASCIIPlots). There is nothing 
>> compatible/overlapping between these two (small) codebases for merging 
>> to 
>> make sense.
>>
>> I would be curious what John Myles White thinks about a more complete 
>> terminal plotting package for Julia. ASCIIPlots clearly imitates 
>> Matlab's 
>> plotting functions ("imagesc"), and I was going for something closer to 
>> Mathematica or Maple (which are more symbolic-oriented than Matlab), 
>> since 
>> I think the syntax is prettier. However, I know a large portion of 
>> Julia's 
>> users are also Matlab users, so if Matlab-compatibility is a goal, you 
>> may 
>> want to keep the packages separate.
>>
>> On Thursday, May 22, 2014 11:25:01 AM UTC-4, Leah Hanson wrote:
>>>
>>> Maybe something like TextPlot would be a good merged name? It 
>>> conveys what the package does (text plots) rather than how it does it 
>>> (Braille characters).
>>>
>>> Having a more complete plotting package for the terminal would move 
>>> towards having a way to make `plot` just work when you start up a Julia 
>>> REPL, which I think is a goal. I'd be happy to help merge them, but 
>>> probably won't have time for a couple weeks.
>>>
>>> -- Leah
>>>
>>>
>>> On Thu, May 22, 2014 at 7:49 AM, Adam Smith 
>>> wrote:
>>>
 I'm not totally opposed to it, but my initial reaction is not to:

1. I don't necessarily agree about the name. I personally think 
"dot plot" has a nice ring to it, and it is a more accurate 
 descript

Re: [julia-users] Globbing

[Iain Dunning]

On the other hand, putting it in runtests.jl lets you organically grow 
(i.e. seperate out into files) without fiddling with Travis, and Pkg.test() 
always "just works"

On Friday, May 23, 2014 2:13:00 PM UTC-4, Stefan Karpinski wrote:
>
> Looking at this, it occurs to me that since all the tests are just in the 
> test/runtests.jl file, and this is probably a pretty common case, maybe the 
> name of that file is a little unfortunate. It's a good name if there are a 
> ton of tests in lots of files and ways to run various subsets of them, but 
> it's probably pretty common, especially initially, for a package to just 
> have one test file like this. Calling it test/tests.jl might be better?
>
>
> On Fri, May 23, 2014 at 2:03 PM, Stefan Karpinski 
> 
> > wrote:
>
>> Cool. Once this has settled in and seems solid it's a good candidate for 
>> moving into Base.
>>
>>
>> On Fri, May 23, 2014 at 1:21 PM, Jameson Nash 
>> > wrote:
>>
>>> Since @ramp on IRC was looking for glob functionality recently, it is 
>>> now available in the Glob.jl package.
>>>
>>
>>
>

Re: [julia-users] What's with the Nothing type?

[Stefan Karpinski]

This FAQ entry may answer the question:

http://docs.julialang.org/en/latest/manual/faq/#nothingness-and-missing-values

If not, maybe we can expand it or clarify whatever's not clear.


On Fri, May 23, 2014 at 2:40 PM, Dom Luna  wrote:

> I just have general curiosity about the Nothing type, is there anything
> one should particularly know about it? Is it similar to a None type that
> one would typically find in pattern matching, ex. an Option type where it
> can be either Something or None, etc.
>
> I feel like Nothing and patterns for its use aren't well documented to
> this point.
>
> Dom
>

Re: [julia-users] Globbing

[Steven G. Johnson]

On Friday, May 23, 2014 2:13:00 PM UTC-4, Stefan Karpinski wrote:
>
> Looking at this, it occurs to me that since all the tests are just in the 
> test/runtests.jl file, and this is probably a pretty common case, maybe the 
> name of that file is a little unfortunate. It's a good name if there are a 
> ton of tests in lots of files and ways to run various subsets of them, but 
> it's probably pretty common, especially initially, for a package to just 
> have one test file like this. Calling it test/tests.jl might be better?
>

Shorter is better, but I don't care all that much. 

Re: [julia-users] pager in the repl

[Steven G. Johnson]

On Friday, May 23, 2014 4:06:11 AM UTC-4, Tamas Papp wrote:
>
> 2. how many elements to print from large arrays etc could be controlled 
> by something like Common Lisp's *PRINT-LENGTH*, eg see 
> http://clhs.lisp.se/Body/v_pr_lev.htm (sorry if this already exists in 
> Julia, could not find it). 


It can be controlled in Julia by changing the LINES and COLUMNS environment 
variables (which can be set within Julia by assigning to ENV["LINES"] and 
ENV["COLUMNS"]).

Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Stefan Karpinski]

This is so cool:

julia> plot(cumsum(randn(1000)))

 2.73641 ⡤⢤
 ⡇⡼⠇⠀⠀⢸
 ⡇⡇⢃⠀⠀⢸
 ⡇⠀⢈⡀⠀⠀⠀⣀⡀⢸
 ⡇⠀⠐⡇⠀⠀⡀⠀⠀⠀⠠⡴⡄⠀⡀⡾⠅⢸
 ⡇⠀⠀⠚⢀⢠⢣⠀⠀⠀⠄⠀⠀⠀⣬⠋⣧⠀⣰⠁⠄⢀⠀⠀⠀⢸
 ⡇⠀⠀⢈⣃⢘⠙⠦⠀⢀⡇⠀⠀⠀⠠⠀⠀⠀⡁⠀⠈⣦⡖⠀⢃⣺⠀⠀⠀⢸
 ⡇⠀⠀⠸⢕⡏⠨⢛⢰⡸⢻⣄⢀⢀⣒⣖⠀⠄⠘⣧⡅⠐⠇⠀⠀⠮⠀⠀⠹⠃⠆⠀⠀⢸
 ⡇⠀⠀⠀⠐⠃⠀⠨⣶⠏⠀⠛⣅⠀⠀⢰⢼⣨⡻⢛⢬⠃⡅⢹⢩⠘⠀⠀⠈⠀⣄⠀⠀⢸
 ⡇⠀⠀⠀⠈⠁⠀⠀⢣⠐⣦⡄⠀⠀⠀⡊⡍⠇⠁⠐⡝⢷⠃⠀⠘⡕⢹⡿⣃⠀⣀⠀⠀⢸
 ⡇⠀⠀⠀⢈⡆⢀⠀⠘⡸⠛⣳⠄⢀⠀⠆⠀⠀⠀⡃⠁⠘⠀⠀⠀⠋⠈⠀⢸⣾⡷⠀⠀⢸
 ⡇⠀⠀⠀⠘⠁⠀⠀⠀⢠⠀⠀⢐⢇⣨⢈⡞⠏⠀⠙⣣⣺⣞⡅⠀⠀⢀⠃⠀⠋⠘⡄⡀⢸
 ⡇⢧⣴⣅⣆⣜⢆⠀⢸⠘⡳⡾⢈⡱⢱⢩⠀⠀⠸⠁⠀⠀⠀⣡⠀⢸
 ⡇⠸⠏⠿⢫⠍⢹⡄⡖⢠⠁⠁⠈⠁⠀⢨⣄⣨⡮⠙⠀⢸
 ⡇⠀⠀⠇⡆⠐⠀⠐⠋⠛⠀⠀⠀⢸
 ⡇⠀⠀⠺⠀⢸
 ⡇⠀⠀⠈⠀⢸
-35.0016 ⠓⠚
 1
1000




On Fri, May 23, 2014 at 3:02 PM, Adam Smith
wrote:

> Sigh, I had a nagging feeling it was supposed to be plural. I did one more
> (hopefully final) rename to TextPlots.jl:
> https://github.com/sunetos/TextPlots.jl and updated the source/readme and
> such.
>
>
> On Friday, May 23, 2014 2:18:54 PM UTC-4, Stefan Karpinski wrote:
>
>> There's a convention to name packages plurally – i.e. TextPlots rather
>> than TextPlot. This is nice partly because using TextPlots reads more
>> naturally than using TextPlot, but more importantly because if you, as
>> is likely, end up having a type called TextPlot, then you don't get a
>> name collision.
>>
>> On Fri, May 23, 2014 at 10:56 AM, Mike Innes  wrote:
>>
>>> Incidentally, interop with other packages without a hard dependency is
>>> something that's around the corner, so you will be able to do this soon.
>>>
>>>
>>> On 23 May 2014 15:32, Adam Smith  wrote:
>>>
 Thanks all for the feedback! I have renamed it to TextPlot.jl, added
 support for plotting just about any combination of
 functions/vectors/matrix, made the API more flexible for Gadfly
 compatibility, and greatly expanded the documentation/examples. It is now
 quite a bit more powerful than ASCIIPlots: https://github.
 com/sunetos/TextPlot.jl

 Ivar: I like the idea of having this be a backend for one of the other
 plotting packages, but the dependency would need to be the other direction.
 Meaning, they would need to add support for TextPlot, not the other way
 around. Right now TextPlot has zero dependencies, so you can use it in
 basically any environment, including a console-only server connected over
 SSH. Installing Gadfly requires quite a few dependencies on other packages,
 including Cairo and other graphical packages if you want PNG charts (for
 iTerm2+IPython inline charts, a similar use case to this one). TextPlot
 would be quite useful for machines that cannot build all those other
 packages, so I don't want to make TextPlot depend on any of those packages.

 I think TextPlot is pretty capable already; please let me know if you
 can think of anything it's missing!


 On Friday, May 23, 2014 5:24:50 AM UTC-4, Ivar Nesje wrote:
>
> Yes, that was definitely my intention to suggest. It looks to me like
> ASCIIPlots.jl and DotPlot.jl solves the same problem in a very similar 
> way,
> and whether to use Unicode for higher resolution seems like something I
> would expect to be an option.
>
> Anyway, the ultimate goal for ASCII art plots, would be to implement
> it as a backend for one of the normal plotting packages.
>
> Ivar
>
> kl. 10:06:42 UTC+2 fredag 23. mai 2014 skrev Tobias Knopp følgende:
>>
>> I think "merge" was meant as: Lets create one uniform package and
>> join the efforts. Since ASCIIPlots is not actively maintained I think it
>> would be really great if you could take the lead to make an awsome text
>> plotting tool.
>>
>> I like the name TextPlot by the way.
>>
>> Am Donnerstag, 22. Mai 2014 17:42:06 UTC+2 schrieb Adam Smith:
>>>
>>> TextPlot seems like a good name.
>>>
>>> Thanks for the offer on merging, but again, there's really nothing
>>> to merge. Adding scatterplots to dotplot will be trivial; I'll do that 
>>> soon
>>> (making dotplot's features a superset of ASCIIPlots). There is nothing
>>> compatible/overlapping between these two (small) codebases for merging 
>>> to
>>> make sense.
>>>
>>> I would be curious

Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Adam Smith]

Sweet, that one turns out surprisingly well! When I get further on the main 
project I'm building in Julia, I want to add a watchdog process that dumps 
graphs of various app metrics (cpu usage over time, etc.) with TextPlots. 
Is there a good ncurses-type package for re-drawing a UI in the terminal? I 
couldn't find one yet.

On Friday, May 23, 2014 3:56:59 PM UTC-4, Stefan Karpinski wrote:
>
> This is so cool:
>
> julia> plot(cumsum(randn(1000)))
>
>  2.73641 ⡤⢤
>  ⡇⡼⠇⠀⠀⢸
>  ⡇⡇⢃⠀⠀⢸
>  ⡇⠀⢈⡀⠀⠀⠀⣀⡀⢸
>  ⡇⠀⠐⡇⠀⠀⡀⠀⠀⠀⠠⡴⡄⠀⡀⡾⠅⢸
>  ⡇⠀⠀⠚⢀⢠⢣⠀⠀⠀⠄⠀⠀⠀⣬⠋⣧⠀⣰⠁⠄⢀⠀⠀⠀⢸
>  ⡇⠀⠀⢈⣃⢘⠙⠦⠀⢀⡇⠀⠀⠀⠠⠀⠀⠀⡁⠀⠈⣦⡖⠀⢃⣺⠀⠀⠀⢸
>  ⡇⠀⠀⠸⢕⡏⠨⢛⢰⡸⢻⣄⢀⢀⣒⣖⠀⠄⠘⣧⡅⠐⠇⠀⠀⠮⠀⠀⠹⠃⠆⠀⠀⢸
>  ⡇⠀⠀⠀⠐⠃⠀⠨⣶⠏⠀⠛⣅⠀⠀⢰⢼⣨⡻⢛⢬⠃⡅⢹⢩⠘⠀⠀⠈⠀⣄⠀⠀⢸
>  ⡇⠀⠀⠀⠈⠁⠀⠀⢣⠐⣦⡄⠀⠀⠀⡊⡍⠇⠁⠐⡝⢷⠃⠀⠘⡕⢹⡿⣃⠀⣀⠀⠀⢸
>  ⡇⠀⠀⠀⢈⡆⢀⠀⠘⡸⠛⣳⠄⢀⠀⠆⠀⠀⠀⡃⠁⠘⠀⠀⠀⠋⠈⠀⢸⣾⡷⠀⠀⢸
>  ⡇⠀⠀⠀⠘⠁⠀⠀⠀⢠⠀⠀⢐⢇⣨⢈⡞⠏⠀⠙⣣⣺⣞⡅⠀⠀⢀⠃⠀⠋⠘⡄⡀⢸
>  ⡇⢧⣴⣅⣆⣜⢆⠀⢸⠘⡳⡾⢈⡱⢱⢩⠀⠀⠸⠁⠀⠀⠀⣡⠀⢸
>  ⡇⠸⠏⠿⢫⠍⢹⡄⡖⢠⠁⠁⠈⠁⠀⢨⣄⣨⡮⠙⠀⢸
>  ⡇⠀⠀⠇⡆⠐⠀⠐⠋⠛⠀⠀⠀⢸
>  ⡇⠀⠀⠺⠀⢸
>  ⡇⠀⠀⠈⠀⢸
> -35.0016 ⠓⠚
>  1 
> 1000
>
>
>
>
> On Fri, May 23, 2014 at 3:02 PM, Adam Smith 
> 
> > wrote:
>
>> Sigh, I had a nagging feeling it was supposed to be plural. I did one 
>> more (hopefully final) rename to TextPlots.jl: 
>> https://github.com/sunetos/TextPlots.jl and updated the source/readme 
>> and such.
>>
>>
>> On Friday, May 23, 2014 2:18:54 PM UTC-4, Stefan Karpinski wrote:
>>
>>> There's a convention to name packages plurally – i.e. TextPlots rather 
>>> than TextPlot. This is nice partly because using TextPlots reads more 
>>> naturally than using TextPlot, but more importantly because if you, as 
>>> is likely, end up having a type called TextPlot, then you don't get a 
>>> name collision.
>>>  
>>> On Fri, May 23, 2014 at 10:56 AM, Mike Innes wrote:
>>>
 Incidentally, interop with other packages without a hard dependency is 
 something that's around the corner, so you will be able to do this soon.


 On 23 May 2014 15:32, Adam Smith  wrote:

> Thanks all for the feedback! I have renamed it to TextPlot.jl, added 
> support for plotting just about any combination of 
> functions/vectors/matrix, made the API more flexible for Gadfly 
> compatibility, and greatly expanded the documentation/examples. It is now 
> quite a bit more powerful than ASCIIPlots: https://github.
> com/sunetos/TextPlot.jl
>
> Ivar: I like the idea of having this be a backend for one of the other 
> plotting packages, but the dependency would need to be the other 
> direction. 
> Meaning, they would need to add support for TextPlot, not the other way 
> around. Right now TextPlot has zero dependencies, so you can use it in 
> basically any environment, including a console-only server connected over 
> SSH. Installing Gadfly requires quite a few dependencies on other 
> packages, 
> including Cairo and other graphical packages if you want PNG charts (for 
> iTerm2+IPython inline charts, a similar use case to this one). TextPlot 
> would be quite useful for machines that cannot build all those other 
> packages, so I don't want to make TextPlot depend on any of those 
> packages.
>
> I think TextPlot is pretty capable already; please let me know if you 
> can think of anything it's missing!
>
>
> On Friday, May 23, 2014 5:24:50 AM UTC-4, Ivar Nesje wrote:
>>
>> Yes, that was definitely my intention to suggest. It looks to me like 
>> ASCIIPlots.jl and DotPlot.jl solves the same problem in a very similar 
>> way, 
>> and whether to use Unicode for higher resolution seems like something I 
>> would expect to be an option.
>>
>> Anyway, the ultimate goal for ASCII art plots, would be to implement 
>> it as a backend for one of the normal plotting packages.
>>
>> Ivar
>>
>> kl. 10:06:42 UTC+2 fredag 23. mai 2014 skrev Tobias Knopp følgende:
>>>
>>> I think "merge" was meant as: Lets create one uniform package and 
>>> join the efforts. Since ASCIIPlots is not actively maintained I think 
>>> it 
>>> would be really great if yo

Re: [julia-users] pager in the repl

[Steven G. Johnson]

You can already just write arbitrary data to "less" if you want.  For 
example:

function less(f::Function)
io, P = writesto(`less`, STDOUT)
try
f(io)
close(io)
wait(P)
finally
kill(P)
end
end

function less(A::Union(AbstractMatrix,AbstractVector))
less() do io
Base.print_matrix(io, A, typemax(Int), typemax(Int))
end
end

less(rand(200))

 

less() do io
 for i = 1:200
 println(io, i)
 end
end

Re: [julia-users] pager in the repl

[Steven G. Johnson]

On Friday, May 23, 2014 4:15:26 PM UTC-4, Steven G. Johnson wrote:
 

> finally
> kill(P)
> end
>
>
>
(This should be catch, not finally, and should rethrow().) 

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Adam Smith]

If you're looking for UI ideas, Mathematica's CDF Viewer makes for some 
slick interactive 3d plots:
http://demonstrations.wolfram.com/symbol.html?symbol=Plot3D

On Friday, May 23, 2014 10:49:05 AM UTC-4, Job van der Zwan wrote:
>
> By the way, no discussion about data visualisation tools is complete 
> without this design prototype by Bret Victor:
>
> https://vimeo.com/66085662
>
> and Victor's written addendum:
>
> http://worrydream.com/DrawingDynamicVisualizationsTalkAddendum/
>
> On Saturday, 17 May 2014 18:51:37 UTC+2, Simon Danisch wrote:
>>
>> Hi, 
>> I'm currently in the planning phase for my GSOC 3D Visualization project, 
>> which also means, that I need to define what the most important 
>> visualization forms are.
>> I must admit, that I haven't done much plotting myself, so I would have 
>> to guess what the really important bits are.
>> Instead of slavishly  
>> imitating 
>> Matlabs plot functions with some mix-ins from my side, I thought we can do 
>> better, by getting feedback off the people, that actually plan to use 3D 
>> plotting in Julia!
>> It would help me a lot, if you could specify what you need exactly in 
>> great detail.
>> Just tell me what you hate about current solutions, what features you 
>> really like, the format of your data, how you like to work, etc...
>> Like this, I can find out what needs to be done in order to visualize 
>> your data, rate the importance and difficulty and than decide in which 
>> order I implement the different plotting capabilities.
>> Any feedback, ideas and comments are welcome!
>>
>> Best wishes,
>> Simon
>>
>

[julia-users] Re: Globbing

[Jameson Nash]

Are we really going to bike shed the name of the test file? Although I'll
admit tests.jl seems like a more tradional sort of name. I didn't change
much from the Julia-created package framework.

Relatedly, it would have been nice if the default travis file worked on
Julia-0.2, since I had done the work to get everything else working there.


On Friday, May 23, 2014, Steven G. Johnson  wrote:

>
>
> On Friday, May 23, 2014 2:13:00 PM UTC-4, Stefan Karpinski wrote:
>>
>> Looking at this, it occurs to me that since all the tests are just in the
>> test/runtests.jl file, and this is probably a pretty common case, maybe the
>> name of that file is a little unfortunate. It's a good name if there are a
>> ton of tests in lots of files and ways to run various subsets of them, but
>> it's probably pretty common, especially initially, for a package to just
>> have one test file like this. Calling it test/tests.jl might be better?
>>
>
> Shorter is better, but I don't care all that much.
>

[julia-users] Re: Another round of Pkg/git trouble in OS X

[Adam Smith]

I have been having the exact same issue pop up, 3 or 4 times now. You can 
workaround it by pasting that exact git clone command from the error into 
your own terminal session, and it usually succeeds when run manually. Now 
if you re-try the Julia Pkg.whatever(), it will continue with the one that 
you cloned manually.

On Friday, May 23, 2014 6:24:10 AM UTC-4, Magnus Lie Hetland wrote:
>
> There seem to have been several rounds of trouble with Pkg calling git in 
> OS X, and it may be that I've missed an existing unresolved issue here, and 
> that I'm therefore reiterating known material. I also added an issue to the 
> GitHub tracker (https://github.com/JuliaLang/julia/issues/6880) -- maybe 
> I should have discussed it here first. Sorry.
>
> But, yeah, the trouble is getting Pkg to work. For some reason, it *did* 
> work at some point (a week ago?). I managed to install a couple of packages 
> without a hitch. But then it stopped working, and I'm not sure what 
> changed. I don't *think* I changed my environment variables or the 
> installed version of Julia, but I'm not 100% sure.
>
> And, yes, I'm using MacPorts -- not sure if that's part of the issue. When 
> I run `which git` in Julia, it reports the MacPorts one, with version 
> number 1.8.5.5. But when I try to use it via Pkg, it fails. Now even init() 
> fails (after removing the .julia directory):
>
> *julia> **Pkg.init()*
>
> *INFO: Initializing package repository /Users/mlh/.julia/v0.3*
>
> *INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl 
> *
>
> usage: git index-pack [-v] [-o ] [--keep | --keep=] 
> [--verify] [--strict] ( | --stdin [--fix-thin] [])
>
> fatal: index-pack failed
>
> *ERROR: failed process: Process(`git clone -q -b metadata-v2 
> git://github.com/JuliaLang/METADATA.jl 
>  METADATA`, ProcessExited(128)) 
> [128]*
>
> * in pipeline_error at process.jl:489*
>
> * in run at process.jl:466*
>
> * in anonymous at pkg/dir.jl:43*
>
> * in cd at file.jl:20*
>
> * in init at pkg/dir.jl:41*
>
> * in init at pkg.jl:16*
>
>
> *julia> *
>
> Any suggestions for trouble-shooting?
>

[julia-users] Re: Metaprogramming weirdness

[Adam Smith]

I find it quite helpful to use dump() on expressions to see the first few 
levels of the parsed AST. That makes it easier to see what Julia is doing 
with your expressions.

On Thursday, May 22, 2014 5:17:13 PM UTC-4, Andrew McKinlay wrote:
>
> I have been trying to grok Julia macros, so I've dived into the 
> metaprogramming docs. Whilst playing around with the interpreter, I've run 
> into some peculiarities that I don't quite understand.
>
> julia> versioninfo()
> Julia Version 0.3.0-prerelease+2690
> Commit e4c2f68* (2014-04-20 12:15 UTC)
> ...
>
>
>1. Why is typeof( :(:(1+2)) ) == Expr, but typeof( :(:(1)) ) == 
>QuoteNode?
>2. Why is typeof( :(1) ) == Int64, but again typeof( :(:(1)) ) == 
>QuoteNode?
>3. Why is typeof( :(1+:($1+2)).args[3].args[1] ) == TopNode?
>
>
> I was assuming that quoting was just a shorthand way for constructing 
> expressions, since the docs say:
>
>> There is special syntax for “quoting” code (analogous to quoting strings) 
>> that makes it easy to create expression objects without explicitly 
>> constructing Expr objects. 
>
> But the types of objects constructed by quoting do not always take the 
> form of an Expr, as above.
>
> What is going on here?
>

Re: [julia-users] pager in the repl

[Andrea Pagnani]

Wow this is most amazing 

I'm struggling to understand writesto. I wonder if it would be possible to 
intercept the STDOUT of a function, e.g
function f(N::Int)
   for i=1:N
println(i)
   end
end


julia> f(100) |> less 

But probably it is impossible ... I am already happy!

Thanks Steven

Andrea


On Friday, May 23, 2014 10:28:33 PM UTC+2, Steven G. Johnson wrote:
>
> On Friday, May 23, 2014 4:15:26 PM UTC-4, Steven G. Johnson wrote:
>  
>
>> finally
>> kill(P)
>> end
>>
>>
>>
> (This should be catch, not finally, and should rethrow().) 
>

Re: [julia-users] What's with the Nothing type?

[Dom Luna]

That cleared it up, thanks! Do functions that don't explicitly return 
anything then implicitly return Nothing?

Sorry I didn't catch the FAQ section, might it be better to have that as a 
short section in types?

Dom

On Friday, May 23, 2014 3:19:35 PM UTC-4, Stefan Karpinski wrote:
>
> This FAQ entry may answer the question:
>
>
> http://docs.julialang.org/en/latest/manual/faq/#nothingness-and-missing-values
>
> If not, maybe we can expand it or clarify whatever's not clear.
>
>
> On Fri, May 23, 2014 at 2:40 PM, Dom Luna 
> > wrote:
>
>> I just have general curiosity about the Nothing type, is there anything 
>> one should particularly know about it? Is it similar to a None type that 
>> one would typically find in pattern matching, ex. an Option type where it 
>> can be either Something or None, etc.
>>
>> I feel like Nothing and patterns for its use aren't well documented to 
>> this point.
>>
>> Dom
>>
>
>  

Re: [julia-users] What's with the Nothing type?

[Leah Hanson]

Functions return the value that the final expression in them evaluated to.

function foo(x)
  x +=2
  5
end # => always returns 5

function bar(x)
  # blah blah ...
  println("hello world")
end # => always returns nothing, because that's what println returns

-- Leah


On Fri, May 23, 2014 at 5:00 PM, Dom Luna  wrote:

> That cleared it up, thanks! Do functions that don't explicitly return
> anything then implicitly return Nothing?
>
> Sorry I didn't catch the FAQ section, might it be better to have that as a
> short section in types?
>
> Dom
>
>
> On Friday, May 23, 2014 3:19:35 PM UTC-4, Stefan Karpinski wrote:
>
>> This FAQ entry may answer the question:
>>
>> http://docs.julialang.org/en/latest/manual/faq/#
>> nothingness-and-missing-values
>>
>> If not, maybe we can expand it or clarify whatever's not clear.
>>
>>
>> On Fri, May 23, 2014 at 2:40 PM, Dom Luna  wrote:
>>
>>> I just have general curiosity about the Nothing type, is there anything
>>> one should particularly know about it? Is it similar to a None type that
>>> one would typically find in pattern matching, ex. an Option type where it
>>> can be either Something or None, etc.
>>>
>>> I feel like Nothing and patterns for its use aren't well documented to
>>> this point.
>>>
>>> Dom
>>>
>>
>>

Re: [julia-users] Re: Metaprogramming weirdness

[Isaiah Norton]

parse("...codez...") can be helpful too.

For (1) & (2), the single-quoted numbers are interpreted as literals rather
than symbols. It is possible to create a Symbol called `:1` with
`symbol("1")`, if needed, but that seems strange. The entry syntax `:1`
might be disallowed for efficiency and disambiguation - I'm not sure.

For (3), in general, a TopNode tells the compiler to resolve any names to
the current base module. It might be illustrative to look at the difference
between these expressions:

julia> a = 1
1

julia> :($a + 1)
:(1 + 1)

julia> :(1+:(a+2))
:(1 + :(a + 2))

julia> :(1+:($a+2))
:(1 + top(Expr)(:call,:+,a,2))

The last case asks for an interpolation which cannot be expanded at parse
time, because the interpolation is quoted. The `top(Expr)` and `call` are
generated to guarantee that `foo` - whatever the value of `foo` ends up as
in the Top module namespace - is used when the expression is evaluated.

(as an aside, eval'ing those last two examples will give errors, because it
is not possible to add an Int and an Expr)





On Fri, May 23, 2014 at 3:53 PM, Adam Smith
wrote:

> I find it quite helpful to use dump() on expressions to see the first few
> levels of the parsed AST. That makes it easier to see what Julia is doing
> with your expressions.
>
>
> On Thursday, May 22, 2014 5:17:13 PM UTC-4, Andrew McKinlay wrote:
>>
>> I have been trying to grok Julia macros, so I've dived into the
>> metaprogramming docs. Whilst playing around with the interpreter, I've run
>> into some peculiarities that I don't quite understand.
>>
>> julia> versioninfo()
>> Julia Version 0.3.0-prerelease+2690
>> Commit e4c2f68* (2014-04-20 12:15 UTC)
>> ...
>>
>>
>>1. Why is typeof( :(:(1+2)) ) == Expr, but typeof( :(:(1)) ) ==
>>QuoteNode?
>>2. Why is typeof( :(1) ) == Int64, but again typeof( :(:(1)) ) ==
>>QuoteNode?
>>3. Why is typeof( :(1+:($1+2)).args[3].args[1] ) == TopNode?
>>
>>
>> I was assuming that quoting was just a shorthand way for constructing
>> expressions, since the docs say:
>>
>>> There is special syntax for “quoting” code (analogous to quoting
>>> strings) that makes it easy to create expression objects without explicitly
>>> constructing Expr objects.
>>
>> But the types of objects constructed by quoting do not always take the
>> form of an Expr, as above.
>>
>> What is going on here?
>>
>

Re: [julia-users] Re: OT: entering Unicode characters

[Carlo Baldassi]

Update: the vim plug-in now includes this feature. If you press Tab after a 
valid latex sequence, it substitutes it, otherwise it falls-back to 
whatever was previously mapped for Tab. Or at least that's what it's 
supposed to do.

On Thursday, May 22, 2014 10:03:39 PM UTC+2, Stefan Karpinski wrote:
>
> No true vim user types so slowly that this is a problem.
>
>
> On Thu, May 22, 2014 at 3:59 PM, Steven G. Johnson 
> 
> > wrote:
>
>>
>>
>> On Thursday, May 22, 2014 3:03:39 PM UTC-4, Miguel Bazdresch wrote:
>>>
>>> In vim, you can do something like
>>>
>>> imap \alpha u03b1
>>>
>>> to reproduce this behavior.
>>>
>>
>> This works, sort of, but I find it a bit annoying.   If you are too slow 
>> in typing "\alpha" then it doesn't perform the substitution.  If you type 
>> it quickly, it works, but you have to type it blindly because vim doesn't 
>> move the cursor (the characters "\alpha" fall on top of one another as you 
>> type).  Worse, it makes it harder t
>>
>> I find it much nicer to be able to type \alpha, see what I'm doing, and 
>> then type  at any later point in time, only when I'm ready to make the 
>> substitution.   Presumably you can program vim to do this, but it may not 
>> be as simple as "imap"?
>>
>> On the other hand, I'm not a vi user.  Maybe an editing mode that 
>> requires rapid, blind typing would fit right in with that editor. ;-)
>>
>
>

Re: [julia-users] pager in the repl

[Carlo Baldassi]

On Thursday, May 22, 2014 9:01:11 PM UTC+2, Bob Nnamtrop wrote:
>
> But julia often does show large screen dumps. Try:
>
> julia> h={1=>1}; for i=2:10 h[i]=i end; h
>
>
Off-topic tip: this kind of thing should be better written like this:
julia> h=[i=>i for i = 1:10]

Re: [julia-users] pager in the repl

[Steven G. Johnson]

On Friday, May 23, 2014 5:36:40 PM UTC-4, Andrea Pagnani wrote:

> I'm struggling to understand writesto.
>

I have a patch pending to make this a lot easier, so that it looks like 
writing to an ordinary file with "open": 
https://github.com/JuliaLang/julia/pull/6948
 

> I wonder if it would be possible to intercept the STDOUT of a function, e.g
>

Technically yes, it is possible: you use the redirect_stdout() 
function.
   
This will even capture STDOUT from external C programs etcetera  it is 
how IJulia captures standard output and sends it to the browser.

However, most native Julia I/O functions will accept an IO argument so that 
you can send their output to something other than STDOUT without resorting 
to redirection tricks.

Re: [julia-users] What's with the Nothing type?

[John Myles White]

To finish this off, if your function ends with `return` by itself, that means 
that your function effectively returns the value `nothing`.

 — John

On May 23, 2014, at 3:09 PM, Leah Hanson  wrote:

> Functions return the value that the final expression in them evaluated to.
> 
> function foo(x)
>   x +=2
>   5
> end # => always returns 5
> 
> function bar(x)
>   # blah blah ...
>   println("hello world")
> end # => always returns nothing, because that's what println returns
> 
> -- Leah
> 
> 
> On Fri, May 23, 2014 at 5:00 PM, Dom Luna  wrote:
> That cleared it up, thanks! Do functions that don't explicitly return 
> anything then implicitly return Nothing?
> 
> Sorry I didn't catch the FAQ section, might it be better to have that as a 
> short section in types?
> 
> Dom
> 
> 
> On Friday, May 23, 2014 3:19:35 PM UTC-4, Stefan Karpinski wrote:
> This FAQ entry may answer the question:
> 
> http://docs.julialang.org/en/latest/manual/faq/#nothingness-and-missing-values
> 
> If not, maybe we can expand it or clarify whatever's not clear.
> 
> 
> On Fri, May 23, 2014 at 2:40 PM, Dom Luna  wrote:
> I just have general curiosity about the Nothing type, is there anything one 
> should particularly know about it? Is it similar to a None type that one 
> would typically find in pattern matching, ex. an Option type where it can be 
> either Something or None, etc.
> 
> I feel like Nothing and patterns for its use aren't well documented to this 
> point.
> 
> Dom
> 
> 

Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Isaiah Norton]

If the name is still up for debate, I'd like to nominate SteamPunkPlot.jl


On Fri, May 23, 2014 at 3:56 PM, Stefan Karpinski wrote:

> This is so cool:
>
> julia> plot(cumsum(randn(1000)))
>
>  2.73641 ⡤⢤
>  ⡇⡼⠇⠀⠀⢸
>  ⡇⡇⢃⠀⠀⢸
>  ⡇⠀⢈⡀⠀⠀⠀⣀⡀⢸
>  ⡇⠀⠐⡇⠀⠀⡀⠀⠀⠀⠠⡴⡄⠀⡀⡾⠅⢸
>  ⡇⠀⠀⠚⢀⢠⢣⠀⠀⠀⠄⠀⠀⠀⣬⠋⣧⠀⣰⠁⠄⢀⠀⠀⠀⢸
>  ⡇⠀⠀⢈⣃⢘⠙⠦⠀⢀⡇⠀⠀⠀⠠⠀⠀⠀⡁⠀⠈⣦⡖⠀⢃⣺⠀⠀⠀⢸
>  ⡇⠀⠀⠸⢕⡏⠨⢛⢰⡸⢻⣄⢀⢀⣒⣖⠀⠄⠘⣧⡅⠐⠇⠀⠀⠮⠀⠀⠹⠃⠆⠀⠀⢸
>  ⡇⠀⠀⠀⠐⠃⠀⠨⣶⠏⠀⠛⣅⠀⠀⢰⢼⣨⡻⢛⢬⠃⡅⢹⢩⠘⠀⠀⠈⠀⣄⠀⠀⢸
>  ⡇⠀⠀⠀⠈⠁⠀⠀⢣⠐⣦⡄⠀⠀⠀⡊⡍⠇⠁⠐⡝⢷⠃⠀⠘⡕⢹⡿⣃⠀⣀⠀⠀⢸
>  ⡇⠀⠀⠀⢈⡆⢀⠀⠘⡸⠛⣳⠄⢀⠀⠆⠀⠀⠀⡃⠁⠘⠀⠀⠀⠋⠈⠀⢸⣾⡷⠀⠀⢸
>  ⡇⠀⠀⠀⠘⠁⠀⠀⠀⢠⠀⠀⢐⢇⣨⢈⡞⠏⠀⠙⣣⣺⣞⡅⠀⠀⢀⠃⠀⠋⠘⡄⡀⢸
>  ⡇⢧⣴⣅⣆⣜⢆⠀⢸⠘⡳⡾⢈⡱⢱⢩⠀⠀⠸⠁⠀⠀⠀⣡⠀⢸
>  ⡇⠸⠏⠿⢫⠍⢹⡄⡖⢠⠁⠁⠈⠁⠀⢨⣄⣨⡮⠙⠀⢸
>  ⡇⠀⠀⠇⡆⠐⠀⠐⠋⠛⠀⠀⠀⢸
>  ⡇⠀⠀⠺⠀⢸
>  ⡇⠀⠀⠈⠀⢸
> -35.0016 ⠓⠚
>  1
> 1000
>
>
>
>
> On Fri, May 23, 2014 at 3:02 PM, Adam Smith  > wrote:
>
>> Sigh, I had a nagging feeling it was supposed to be plural. I did one
>> more (hopefully final) rename to TextPlots.jl:
>> https://github.com/sunetos/TextPlots.jl and updated the source/readme
>> and such.
>>
>>
>> On Friday, May 23, 2014 2:18:54 PM UTC-4, Stefan Karpinski wrote:
>>
>>> There's a convention to name packages plurally – i.e. TextPlots rather
>>> than TextPlot. This is nice partly because using TextPlots reads more
>>> naturally than using TextPlot, but more importantly because if you, as
>>> is likely, end up having a type called TextPlot, then you don't get a
>>> name collision.
>>>
>>> On Fri, May 23, 2014 at 10:56 AM, Mike Innes wrote:
>>>
 Incidentally, interop with other packages without a hard dependency is
 something that's around the corner, so you will be able to do this soon.


 On 23 May 2014 15:32, Adam Smith  wrote:

> Thanks all for the feedback! I have renamed it to TextPlot.jl, added
> support for plotting just about any combination of
> functions/vectors/matrix, made the API more flexible for Gadfly
> compatibility, and greatly expanded the documentation/examples. It is now
> quite a bit more powerful than ASCIIPlots: https://github.
> com/sunetos/TextPlot.jl
>
> Ivar: I like the idea of having this be a backend for one of the other
> plotting packages, but the dependency would need to be the other 
> direction.
> Meaning, they would need to add support for TextPlot, not the other way
> around. Right now TextPlot has zero dependencies, so you can use it in
> basically any environment, including a console-only server connected over
> SSH. Installing Gadfly requires quite a few dependencies on other 
> packages,
> including Cairo and other graphical packages if you want PNG charts (for
> iTerm2+IPython inline charts, a similar use case to this one). TextPlot
> would be quite useful for machines that cannot build all those other
> packages, so I don't want to make TextPlot depend on any of those 
> packages.
>
> I think TextPlot is pretty capable already; please let me know if you
> can think of anything it's missing!
>
>
> On Friday, May 23, 2014 5:24:50 AM UTC-4, Ivar Nesje wrote:
>>
>> Yes, that was definitely my intention to suggest. It looks to me like
>> ASCIIPlots.jl and DotPlot.jl solves the same problem in a very similar 
>> way,
>> and whether to use Unicode for higher resolution seems like something I
>> would expect to be an option.
>>
>> Anyway, the ultimate goal for ASCII art plots, would be to implement
>> it as a backend for one of the normal plotting packages.
>>
>> Ivar
>>
>> kl. 10:06:42 UTC+2 fredag 23. mai 2014 skrev Tobias Knopp følgende:
>>>
>>> I think "merge" was meant as: Lets create one uniform package and
>>> join the efforts. Since ASCIIPlots is not actively maintained I think it
>>> would be really great if you could take the lead to make an awsome text
>>> plotting tool.
>>>
>>> I like the name TextPlot by the way.
>>>
>>> Am Donnerstag, 22. Mai 2014 17:42:06 UTC+2 schrieb Adam Smith:

 TextPlot seems like a good name.

 Thanks for the offer on merging, but again, there's really nothing
 to merge. Adding scatterplo

Re: [julia-users] Shameless plug for DotPlot.jl - plots in your terminal

[Keno Fischer]

Do you mean StreamPunkPlot.jl?


On Sat, May 24, 2014 at 6:44 AM, Isaiah Norton wrote:

> If the name is still up for debate, I'd like to nominate SteamPunkPlot.jl
>
>
> On Fri, May 23, 2014 at 3:56 PM, Stefan Karpinski wrote:
>
>> This is so cool:
>>
>> julia> plot(cumsum(randn(1000)))
>>
>>  2.73641 ⡤⢤
>>  ⡇⡼⠇⠀⠀⢸
>>  ⡇⡇⢃⠀⠀⢸
>>  ⡇⠀⢈⡀⠀⠀⠀⣀⡀⢸
>>  ⡇⠀⠐⡇⠀⠀⡀⠀⠀⠀⠠⡴⡄⠀⡀⡾⠅⢸
>>  ⡇⠀⠀⠚⢀⢠⢣⠀⠀⠀⠄⠀⠀⠀⣬⠋⣧⠀⣰⠁⠄⢀⠀⠀⠀⢸
>>  ⡇⠀⠀⢈⣃⢘⠙⠦⠀⢀⡇⠀⠀⠀⠠⠀⠀⠀⡁⠀⠈⣦⡖⠀⢃⣺⠀⠀⠀⢸
>>  ⡇⠀⠀⠸⢕⡏⠨⢛⢰⡸⢻⣄⢀⢀⣒⣖⠀⠄⠘⣧⡅⠐⠇⠀⠀⠮⠀⠀⠹⠃⠆⠀⠀⢸
>>  ⡇⠀⠀⠀⠐⠃⠀⠨⣶⠏⠀⠛⣅⠀⠀⢰⢼⣨⡻⢛⢬⠃⡅⢹⢩⠘⠀⠀⠈⠀⣄⠀⠀⢸
>>  ⡇⠀⠀⠀⠈⠁⠀⠀⢣⠐⣦⡄⠀⠀⠀⡊⡍⠇⠁⠐⡝⢷⠃⠀⠘⡕⢹⡿⣃⠀⣀⠀⠀⢸
>>  ⡇⠀⠀⠀⢈⡆⢀⠀⠘⡸⠛⣳⠄⢀⠀⠆⠀⠀⠀⡃⠁⠘⠀⠀⠀⠋⠈⠀⢸⣾⡷⠀⠀⢸
>>  ⡇⠀⠀⠀⠘⠁⠀⠀⠀⢠⠀⠀⢐⢇⣨⢈⡞⠏⠀⠙⣣⣺⣞⡅⠀⠀⢀⠃⠀⠋⠘⡄⡀⢸
>>  ⡇⢧⣴⣅⣆⣜⢆⠀⢸⠘⡳⡾⢈⡱⢱⢩⠀⠀⠸⠁⠀⠀⠀⣡⠀⢸
>>  ⡇⠸⠏⠿⢫⠍⢹⡄⡖⢠⠁⠁⠈⠁⠀⢨⣄⣨⡮⠙⠀⢸
>>  ⡇⠀⠀⠇⡆⠐⠀⠐⠋⠛⠀⠀⠀⢸
>>  ⡇⠀⠀⠺⠀⢸
>>  ⡇⠀⠀⠈⠀⢸
>> -35.0016 ⠓⠚
>>  1
>>   1000
>>
>>
>>
>>
>> On Fri, May 23, 2014 at 3:02 PM, Adam Smith <
>> swiss.army.engin...@gmail.com> wrote:
>>
>>> Sigh, I had a nagging feeling it was supposed to be plural. I did one
>>> more (hopefully final) rename to TextPlots.jl:
>>> https://github.com/sunetos/TextPlots.jl and updated the source/readme
>>> and such.
>>>
>>>
>>> On Friday, May 23, 2014 2:18:54 PM UTC-4, Stefan Karpinski wrote:
>>>
 There's a convention to name packages plurally – i.e. TextPlots rather
 than TextPlot. This is nice partly because using TextPlots reads more
 naturally than using TextPlot, but more importantly because if you, as
 is likely, end up having a type called TextPlot, then you don't get a
 name collision.

 On Fri, May 23, 2014 at 10:56 AM, Mike Innes wrote:

> Incidentally, interop with other packages without a hard dependency is
> something that's around the corner, so you will be able to do this soon.
>
>
> On 23 May 2014 15:32, Adam Smith  wrote:
>
>> Thanks all for the feedback! I have renamed it to TextPlot.jl, added
>> support for plotting just about any combination of
>> functions/vectors/matrix, made the API more flexible for Gadfly
>> compatibility, and greatly expanded the documentation/examples. It is now
>> quite a bit more powerful than ASCIIPlots: https://github.
>> com/sunetos/TextPlot.jl
>>
>> Ivar: I like the idea of having this be a backend for one of the
>> other plotting packages, but the dependency would need to be the other
>> direction. Meaning, they would need to add support for TextPlot, not the
>> other way around. Right now TextPlot has zero dependencies, so you can 
>> use
>> it in basically any environment, including a console-only server 
>> connected
>> over SSH. Installing Gadfly requires quite a few dependencies on other
>> packages, including Cairo and other graphical packages if you want PNG
>> charts (for iTerm2+IPython inline charts, a similar use case to this 
>> one).
>> TextPlot would be quite useful for machines that cannot build all those
>> other packages, so I don't want to make TextPlot depend on any of those
>> packages.
>>
>> I think TextPlot is pretty capable already; please let me know if you
>> can think of anything it's missing!
>>
>>
>> On Friday, May 23, 2014 5:24:50 AM UTC-4, Ivar Nesje wrote:
>>>
>>> Yes, that was definitely my intention to suggest. It looks to me
>>> like ASCIIPlots.jl and DotPlot.jl solves the same problem in a very 
>>> similar
>>> way, and whether to use Unicode for higher resolution seems like 
>>> something
>>> I would expect to be an option.
>>>
>>> Anyway, the ultimate goal for ASCII art plots, would be to implement
>>> it as a backend for one of the normal plotting packages.
>>>
>>> Ivar
>>>
>>> kl. 10:06:42 UTC+2 fredag 23. mai 2014 skrev Tobias Knopp følgende:

 I think "merge" was meant as: Lets create one uniform package and
 join the efforts. Since ASCIIPlots is not actively maintained I think 
 it
 would be really great if you could take the lead to make an awsome text
 plotting tool.

 I like the name TextPlot by the wa

Re: [julia-users] linear algebra speed comparisons with MATLAB

[Andreas Noack Jensen]

Unfortunately, it is not that clear cut. In the thread I linked you can see
some discussion and timings. It is correct that OpenBLAS is faster for
large problems, but it is slower for small problems.


2014-05-22 23:17 GMT+02:00 Thomas Covert :

> By the way, switching to Homebrew and compiling a recent git pull solved
> the problem.  Now my matrix inversions occur at MATLAB speeds or faster.
>
>
> On Monday, May 19, 2014 7:58:06 AM UTC-5, Andreas Noack Jensen wrote:
>
>> Thanks. Julia is calling the correct method.
>>
>> However, I didn't read your last email carefully enough. You are pointing
>> to the problem. The pre-build binary for Mac does not use OpenBLAS but
>> Apple's Accelerate which apparently is slower. I have filed an issue
>>
>> https://github.com/JuliaLang/julia/issues/6887
>>
>>
>> 2014-05-19 14:06 GMT+02:00 Thomas Covert :
>>
>> Here's what I get:
>>>
>>> julia> K = randn(2500,2500);
>>>
>>> julia> K = K' * K;
>>>
>>> julia> @which inv(lufact(K))
>>> inv{T<:Union(Float64,Complex{Float64},Complex{Float32},
>>> Float32),S<:Union(DenseArray{T,2},SubArray{T,2,A<:
>>> DenseArray{T,N},I<:(Union(Range{Int64},Int64)...,)})}(A:
>>> :LU{T<:Union(Float64,Complex{Float64},Complex{Float32},
>>> Float32),S<:Union(DenseArray{T,2},SubArray{T,2,A<:
>>> DenseArray{T,N},I<:(Union(Range{Int64},Int64)...,)})}) at
>>> linalg/lu.jl:145
>>>
>>>
>>> On Monday, May 19, 2014 3:25:30 AM UTC-5, Andreas Noack Jensen wrote:
>>>
 In generaI, I don't think most people experience that MKL is faster
 that OpenBLAS. On my MacBook, Julia with OpenBLAS and Matlab performs very
 similar on the symmetric inversion problem.

 Some time ago, there used to be a problem with inv falling back on a
 slower method. I should be fixed now, but maybe the difference you see is
 my fault and not OpenBLAS'. What do you see if you type

 @which inv(lufact(K))


 2014-05-19 1:46 GMT+02:00 Thomas Covert :

> Thanks for sending that along - might go down that route once it's
> clear that MKL would do the trick and that the fixed costs of building it
> myself are worth it.
>
> Are there other mac users using the pre-built binaries that see these
> same performance differences?  Why do the mac binaries report libgfortblas
> and liblapack when the windows and Linux binaries report libopenblas?
>
>
> On Sunday, May 18, 2014, Leah Hanson  wrote:
>
>> There are instructions in the Julia README and on Intel's website for
>> running Julia with MKL:
>>
>> https://github.com/JuliaLang/julia#intel-math-kernel-libraries
>> https://software.intel.com/en-us/articles/julia-with-intel-m
>> kl-for-improved-performance
>>
>> -- Leah
>>
>>
>> On Sun, May 18, 2014 at 3:59 PM, Thomas Covert > > wrote:
>>
>>> Seems like the windows and Mac versions of Julia call different
>>> blas/lapack routines.  Might that be the cause?  Is it possible for me 
>>> to
>>> ask julia to use a different blas/lapack?
>>>
>>>
>>> On Sunday, May 18, 2014, J Luis  wrote:
>>>
 Funny, in a similar machine (but running Windows) I get the opposite

 Matlab 2012a (32 bits)
 >> tic; inv(K); toc
 Elapsed time is 3.837033 seconds.


 julia> tic(); inv(K); toc()
 elapsed time: 1.157727675 seconds
 1.157727675

 julia> versioninfo()
 Julia Version 0.3.0-prerelease+3081
 Commit eb4bfcc* (2014-05-16 15:12 UTC)
 Platform Info:
   System: Windows (x86_64-w64-mingw32)
   CPU: Intel(R) Core(TM) i7 CPU   M 620  @ 2.67GHz
   WORD_SIZE: 64
   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
   LAPACK: libopenblas
   LIBM: libopenlibm

 Domingo, 18 de Maio de 2014 19:16:48 UTC+1, Thomas Covert escreveu:
>
> I am finding that MATLAB is considerably faster than Julia for
> simple linear algebra work on my machine (mid-2009 macbook pro).  Why 
> might
> this be?  Is this an OpenBLAS vs Intel MKL issue?
>
> For example, on my machine, matrix inversion of a random,
> symmetric matrix is more than twice as fast in MATLAB as it is in 
> Julia:
>
> MATLAB code:
> K = randn(2500,2500);
> K = K' * K;
> tic; inv(K); toc
> Elapsed time is 2.182241 seconds.
>
> Julia code:
> K = convert(Array{Float32},randn(2500,2500));
> K = K' * K;
> tic(); inv(K); toc()
> elapsed time: 6.249259727 seconds
>
> I'm running a fairly recent MATLAB release (2014a), and
> versioninfo() in my Julia install reads:
> Julia Version 0.3.0-prerelease+2918
> Commit 104568c* (2014-05-06 22:29 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin12.5.0