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] > <javascript:>>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 >>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >
