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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>> > <[email protected]>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 < >>>>> [email protected]>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 < >>>>> [email protected]>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 >>>>> >>>>> >>>>> >>>> >>>>> >>>> >>>>> >>> >>>>> >>>>> >>
