Re: suggestions for two very minor improvements to gp user interface

[Karim Belabas <Karim.Belabas@math.u-psud.fr>]

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/