On Mon, 3 Sep 2001, Kevin Buzzard wrote:
> Hi pari-users. Sorry for a long posting on such minor matters: I am
> suggesting two very minor tweaks to the gp interface which would make my
> life easier, but which I certainly wouldn't be able to program myself,
> so I thought I'd tempt others to do so...
No problem, that's what this list is for...
> The first one: I occasionally use gp to manipulate matrices / power series
> with big coefficients, "big" as in "contains 100,000 digit numbers".
> Occasionally I miss a semi-colon at the end of a line and suddenly get a
> printout of what I don't want to see, namely pages and pages of digits.
> I'm sure I'm not the only person this has happened to.
default(lines, x) does something related: print no more than x lines of
output, then a "[...]" marker to signal overflow.
Of course, you can adopt this as a permanent setting in your .gprc.
> This causes great irritation, because these kinds of printouts inevitably
> completely fill up my scrollback memory and hence I lose by far the most
> efficient method I have for looking at back at what I have just done
> recently.
I have
logfile = "~/tmp/pari/%d.%m-%T"
log = 1
in my .gprc, which creates a unique logfile for each of my pari sessions
named after the time and date upon startup :
-rw-r--r-- 1 pari users 5538 Sep 5 17:45 05.09-17:43:10
-rw-r--r-- 1 pari users 3789 Sep 5 17:46 05.09-17:46:03
-rw-r--r-- 1 pari users 2069 Sep 5 18:14 05.09-18:13:00
[...]
"grep" [if I can't identify the correct logfile, "less" otherwise] is then
much more efficient than my eyes to locate the patterns I'm looking for (esp.
among the 100+ different logfiles corresponding to a given day...)
> It seems to me hence that if gp finds that it wants to print out something
> more than 100K long, there is a chance that the user has made a slip---could
> the user perhaps not really want to look at all of such a long output? So
> why not have a flag, disabled by default, called something like
> "print_overflow_warning", which, if set to 1, triggers a warning whenever
> a huge output is about to appear: just some kind of "answer seems very long,
> do you really want me to print it (yes/no)?" prompt would be great.
> This would be very easy to do if, when gp is about to print out the
> result of calulation %107, the pari output is all 'collected up' and
> then printed out in one go---I don't know whether this is the case but
> thought that there was a chance that it might be.
It is not. Quite possibly a huge character string might have to be allocated,
which would be a problem on older systems, e.g my DOS-based 486, where the
average modern Linux PC wouldn't care. Each character is printed out as soon
as it is known (meaning mostly 9 by 9 for large integers), the OS is
responsible for the buffering.
It is nevertheless quite easy to do: before any result is printed, its size
(in bytes as a GEN object, not as in strlen(GENtostr())) could be computed,
and it it exceeds a certain threshold, trigger the warning. Of course, it's
not as precise as what you suggested [ which could be implemented by first
computing the exact number of symbols to be printed, then printing, resulting
in twice slower output ] or what "lines" provides, but as a rough measure,
it's quite tolerable I think.
Hum, how does
\\ warn before printig anything larger than 10kB in GEN representation
default(print_overflow, "10k")
look like ?
> The second thing is two little tweaks to readline that are implemented
> in MAGMA and are a *lovely* feature. I am just amazed how simple and yet
> effective these ideas are. By default, if I am using readline, and I hit
> up-arrow, this takes me to the last line I typed in. In MAGMA I can do
> more: If I type "abc" at the prompt and _then_ hit up-arrow, it takes me
> to the last line I typed that began with "abc". This is very useful if you
> want to find that long series of commands that you typed a while ago and
> is much more natural than using ctrl-R etc. But it gets even better: once
> I've found this line, if I hit return and then down-arrow, it takes me to
> the line after the "abc..." line, so if I am looking to do a multi-line
> set of commands over again, I only have to search once. As a concrete
> example of what I'm trying to explain, take a look at this sample session:
>
> a=somecomplicatedfunction();
> b=a^4+a^2+1;
> c=log(b)+2;
> print(c^2/2)
>
> (lots of lines of gp input omitted)
>
> (now decide to try another value of a)
>
> a=someothercomplicatedfunction();
>
> (now I realise that I want to compute c as above, just like before).
>
> In Pari I would now hit something like Ctrl-R b=(enter) Ctrl-R c=(enter)
> Ctrl-R print Ctrl-R Ctrl-R Ctrl-R... (until I've found the print statement
> I want!) etc etc etc.
>
> In Magma I would type
>
> b=(up-arrow) (enter) (down-arrow) (enter) (down-arrow) (enter) and that
> would be the end of it.
>
> It's perhaps hard to appreciate how nice this feature is until you've seen
> it in action, but having used MAGMA a fair amount, I now realise I really
> miss this feature in pari. Is this kind of thing possible to implement in
> gp or would it involve messing with readline?
It does involve messing with readline, I don't see any bindable command
within readline that would do this. It's certainly doable (involves creating
new bindable commands in gp/gp_rl.c to access routines in libhistory
library), but not entirely trivial.
I can add it to the TODO list.
Cheers,
Karim.
--
Karim Belabas email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France) Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://www.parigp-home.de/