First light for PARI/GP 2.0.ALPHA

[Gerhard Niklasch <nikl@mathematik.tu-muenchen.de>]

First off, if you don't know why you're getting this:  You're getting
this because you are subscribed to the pari-dev@list.cr.yp.to (PARI
developers) mailing list.  Don't yell at me, I didn't subscribe you.
I only subscribed myself.  If you want to get off, send an empty message
to
	pari-dev-unsubscribe@list.cr.yp.to
but surely you don't want to get off now that the fun begins, do you?!?


After some direct e-mail conversations with Karim Belabas, I'm posting
herewith (with his consent) some excerpts of what has already gone on
between us.  To prevent this from getting too long, I'll be skipping
for the moment the couple of patches he has already supplied (Karim,
do you want to unearth them and post them here yourself?).  Also, I've
edited out our mutual quotes except for the odd line here and there to
provide context.  Stuff in [brackets] is comments or elision markers
I'm adding now.


---GN to KB, Sat, 15 Nov 1997 02:25:16 +0100 (MET)---8<---
Subject: PARI/GP 2.0.ALPHA

Whoarrr! Wow! Champagne everyone!  It's..... HERE!

Congratulations, kudos, celebrations, fireworks!!

Got the announcement through the NMBRTHRY list whilst logged in
from at home through the modem at this rather unholy hour of night.
(Don't ask me why.)  Pulled the tarball from megrez.  (Someone
please tell Henri to set his <*CENSORED*> FTP server to default to type
Binary like decent Linux ftpd's do. ;^)

Untarred fine, now Reading The Instructions.

Found the first `bug'.  What prize have I won?

In pari-2.0.alpha/AUTHORS, my e-mail address should NOT be
nikl@mpim-bonn.mpg.de  (which is deliverable, I've just checked it,
but for all I know acts as a perfect black hole -- mail sent there
does not seem to be forwarded to me).  It should be
nikl@mathematik.tu-muenchen.de [...]
--->8---------------------

[The former does act as a perfect black hole;  a test mail I sent to it
never got back to me.]


---GN to KB, Sat, 15 Nov 1997 06:13:24 +0100 (MET)---8<---
Subject: Phew...!

[...]
Took me 90 minutes (more or less) to get 2.0alpha running minus
readine capabilities, and again as long to get it running _with_
readline. [...] The reasons were three.  The two that annoyed me
were the modem server [...], and -- my own stubborn stupidity.
The third was the somewhat unusual platform -- geriatric
linux(1.2.8)-aout, /usr/bin/perl is 4.036 whereas /usr/local/bin/perl
is 5.003, and the readline library and headers live, guess where ----
in /usr/local/src/pari-1.39.03/readline !

After hacking the Configure script and hardcoding that path in there,
I got it at last to do exactly what I wanted it to do.  Oh, except for
one thing.  I'll recompile it once more, this time going to -O6!
[...]
--->8---------------------


---GN to KB, Sun, 16 Nov 1997 19:20:01 +0100 (MET)---8<---
Subject: 2.0.alpha on Linux

[...]
PARI/GP-2.0.alpha now installed and running nicely both on my `ancient'
Linux-1.2.8-aout box at work and on my Linux-2.0.30-ELF laptop.  That
sure adds some colour to a grey week!  ;^)

Two or three comments:
(1) Colours _do_ work on Linux text consoles;  gp doesn't have to be
running inside an xterm to get this.  (More precisely, as far as I
can tell, colours 0...7 work and 8...15 give 0...7 all over again.)
This even works when I'm sitting at the laptop at home and telnetting
via modem onto my machine at work.  Of course the X resources are then
ignored;  the colour scheme is hardwired.

[...skipping some stuff that had to do partly with sheer oversights on
my part, and partly with Linux-aout specific problems which I haven't
yet sorted out...]

(3) I think that if gp is running on a text console (equivalent to:
DISPLAY environment var not set),  ??Name might run `gphelp -d Name`
and show the result within gp's own output stream, instead of launching
TeX only to discover that xdvi cannot open a display.  Is this possible?

Also, the temporary directory used by gphelp to hold the .tex and .dvi
files should be configurable (from some central place rather than by
editing gphelp.in).  E.g., I prefer /var/tmp over /tmp.  Configure could
ask the user to express a preference.

[...]

(5) The ioctl call in the function term_width() in src/gp/gp.c seems
to return 0 for the screen width when I'm logged into the work box
through telnet & modem.  The result is that the internal help messages
are printed one word per line!  (It works correctly when I'm running
gp locally on a text console.)  It might be worthwhile checking the
returned value  (and similarly for the height),  and also glancing
at the environment variables COLUMNS and ROWS if the returned value
is <= 1  (they are set correctly in my telnet session),  and if that
doesn't help either, falling back to the defaults, instead of using
a ridiculously small width.  (Hm, a height of 1 might be useless
from a practical point of view but could possibly be accepted, but
certainly not a height of zero.)

(6) When running gp in an xterm, I always launch the xterm with
'-name gp', so it picks up any X resources under the application
name "gp" from my .Xdefaults.  This allows me to give the gp windows
their own characteristics and distinctive colourings, independently
of the other five dozen xterms on my screen.  This hint could go
into a comment into lib/color.defaults.  (Of course one should
then replace 'XTerm' with 'gp' in all those resources before copying
them into one's .Xresources or .Xdefaults .)

(7) Another hint that might be useful could go into lib/gprc.default.
At the moment, the distributed version turns compatibility on to 2.
I once succeeded in editing/uncommenting a 'read "~/.gpalias"' but
overlooked the compatibility setting, and got all sorts of weird errors.
An explicit statement to the effect that most of the settings suggested
in gprc.default actually depend on compatibility mode being switched
off would be helpful  (use LARGE LETTERS!).

Haven't done a lot of maths with it _yet_, but this will certainly
change!

Merry digging through the hundreds of mails you must be getting ;^),
all the best, Gerhard
[...]
--->8---------------------


---KB to GN, Mon, 17 Nov 1997 12:57:58 +0100---8<---
Subject: Re: 2.0.alpha on Linux

Hi Gerhard, thanks for (all) the feedback ! 

[...]
> (1) Colours _do_ work on Linux text consoles; [...]

Good. I was hoping something like that might be true. But couldn't test it so
far ...

[...skip patch for (3) above, fixes both issues from within perl/gphelp.in,
works -- see below. :^]
[See below re (5);  items (6) and (7) were noted for later attention]

> Merry digging through the hundreds of mails you must be getting ;^),

You're the only one so far... (let's keep it that way for a moment !!!)

Best,
   Karim.
--->8---------------------


---GN to KB, Mon, 17 Nov 1997 13:48:40 +0100 (MET)---8<---
Subject: Re: 2.0.alpha on Linux [remains constant from now on]

> Hi Gerhard, thanks for (all) the feedback !
You're most welcome, and thanks for en providing the raisons d'etre ! ;)

[...]
Found something nice yesterday.  I know that old factoreddiscf() sometimes
crashes, after `discovering' another squared factor of the discriminant
the hard way (by asking for an impossible modular inverse).  I tried to
reproduce this behaviour with new nfinit(f,1,[...]), but it seems to work
ok now.  If this is one of the things fixed then I for one am glad it is. :^)

(In this context -- would there be a way of telling gp to increase the
stack silently  (probably in arithmetic rather than geometric progression)
up to an outer limit, and continue, instead of interrupting when it runs
out of VM?  Would be useful for programming.  In the very long run, it
might be desirable to have a `catch errors' mechanism like the one in
Perl's eval, but I wouldn't propose this as an urgent desire.)

Another thing -- just a question really:  I tried increasing and lowering
default(compatible,...) within one and the same session.  Going up from
0 to 1 to 2 and back to 1 had the effect that oldstyle functions (disc
in my case) were hiding aliases of the same name.  Going just from 0 to 1
leaves the aliases in force.  I understand how this happens, but it was
still a bit surprising.

*beep* another mail from you coming in...
[...]
--->8---------------------


---KB to GN, Mon, 17 Nov 1997 13:32:08 +0100---8<---
Subject: Re: 2.0.alpha on Linux

Does this address correctly your terminal size problem through modem
connection ?
[Patch to src/gp/gp.c skipped.  Don't know yet whether it does since
I haven't been home since.  I'm pretty sure it will.  :^]
--->8---------------------


---GN to KB, Mon, 17 Nov 1997 14:02:34 +0100 (MET)---8<---
Subject: Re: 2.0.alpha on Linux

Patches gone in cleanly, recompiling now. [...]

...A minute later:  Inline ??Set works (in an xterm with DISPLAY throttled
out of the exports).  Good!
--->8---------------------


---KB to GN, Mon, 17 Nov 1997 14:36:32 +0100---8<---
Subject: Re: 2.0.alpha on Linux

> (In this context -- would there be a way of telling gp to increase the
> stack silently [...] and continue [...]

  Trivial under NextStep (Michael Stoll pointed that to me some time ago),
very hard to make it portable. Basically, one needs to have a realloc() that
does not change address of existing pointers (vm_allocate() under NextStep,
I'm sure Linux provides something like that as well).  Then you can just have
err(errpile) allocate a new stack, then return.

  Otherwise, the only way out is to allocate a new stack when the need arise,
take it into account in the gerepiles, and discard it when it can safely be
done. Of course it would break many of the most hatable memory hacks in the
existing PARI code...

  Maybe I will just go for the trivial thing and do it for those systems that
support vm_allocate() (except that none of the systems I have easy access to
do it...).

[This was followed by an exchange of Linux and SunOS manpage contents.
The gist of it was that reallocate() should usually work on Linux
_provided that_ (necessary condition, but not sufficient) there's
enough room in virtual address space so that the (virtual) starting
address of the chunk of memory doesn't need to change.  And reallocate()
on Linux is very fast _even_ when virtual addresses change;  it does its
thing by changing the virtual to physical mapping, instead of copying.]

>  In the very long run, it might be desirable to have a `catch errors'
>  mechanism like the one in Perl's eval, but I wouldn't propose this as an
>  urgent desire.

You have a primitive handler for signals, you could have that for other
functions. But returning from most errors should be rather tough. It's in the
TODO list (very low priority...)
[...]
--->8---------------------

[skipping a msg or two here]


---GN to KB, Mon, 17 Nov 1997 16:42:54 +0100 (MET)---8<---
[...]
* Any objections to me setting up some WWW pages?
* - to me archiving patches on same?
* - to me archiving the mailing lists there?
* - to me designing a logo to go with them?  (I have something in mind...)

There's of course no compelling reason why PARI-2.0 should have pages
on the Hasse server, it's just that my fingers are itching.  ;^)

Also, do you think a posting to sci.math.research might be appropriate
at this stage?
--->8---------------------

Well... Henri, Dan, all of you out there:  any objections to me beginning
to archive these lists on the WWW?  (If anybody has _personal_ concerns
about this, I'll honour `X-No-Archive: Yes' when found spelt reasonably
closely to this in the headers or in the body.  Or even `X-Archive: No',
meaning the same thing, in case you're wondering. ;^)

BTW I'm quite pleased with the logo I've come up with.  No doubt it
won't fit all tastes...
<url:http://hasse.mathematik.tu-muenchen.de/icons/pari-gp-large.gif>
Web pages to surround this have been heavily under construction all
afternoon and evening!

Enjoy, Gerhard
-- 
* Gerhard Niklasch <nikl@mathematik.tu-muenchen.de> * spam totally unwelcome
* http://hasse.mathematik.tu-muenchen.de/~nikl/ ******* all browsers welcome
* This .signature now fits into 3 lines and 77 columns * newsreaders welcome