[GRASS5] Re: IRIX Binaries

GRASS GRASS developer
1

Hello Andreas
I noticed you'd done useful work on IRIX compliance before and wondered
where you'd got to :slight_smile:

On Thu, 22 Aug 2002, Andreas Lange wrote:

Hi all,

there are some problems with the binary (which i installed and tried to
test).

It is o32 (old library format), so it is not very useful for anyone
running IRIX 6.x.

I don't understand this; I compiled it on 6.2 and it runs fine on 6.4; I
thought all later versions were backward-compatible with o32 so I compiled
it like this for maximum portability.
I can create an n32 version as well if you think it would be useful.

I think only a very small minority still uses IRIX 5.x, SGI dropped even
support for 6.2 freeware.
It is compiled for the mips-2 architecture, i think one should compile
for mips-3 architecture, as the runtime of the modules will be less.

Did you notice a substantial performance decrease? I didn't think it was
slow at all and the runtime doesn't bother me; again, I was aiming for
maximum compatibilty.

I am not able to start grass, as the keys <RET> and <ESC> do not work in
the entry screen. I think the reason is that a wrong library is

I have always had this problem using the IRIX winterm but I didn't think
it was serious enough to investigate or report as a bug (I always run
GRASS from an xterm window).

referenced (different versions of termcap/termlib and curses/ncurses on
5.x/6.x???). I tested on an Indy R5000 with IRIX 6.5 and most of the
freeware installed.

Is there anything specific you think I could look for here? I sort of
assumed it was a winterm problem and put up with it (it works OK when I
telnet in also; only in winterm the <ESC> key doesn't work).

I collected a lot information on compiling on IRIX here:
http://mitglied.lycos.de/AndreasLange/grass/irix-grass.html
(It is partly outdated and obsolete).

It was a very useful resource for me when compiling GRASS5.1; some
problems that have been fixed in the 5.0 code are still there in it
(mostly XDRIVER using sockets and NVIZ).

I will assist in preparing the binary. But i have myself no c compiler
installed currently.
I think that the binary i tested should not be distributed to the
mirrors to save bandwith.

It is very big isn't it? But, I mean, that is normal. I am confident in its
present form it would be useful to many people; otherwise I would not
have even considered submitting it.

We do have an Indy running 6.5 here but it is turned off at the minute and
doesn't have a mouse. I will get it going and give it a try on it.

But I don't see why you think it shouldn't be distributed. Everything is
there and works.

Paul

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850

2

On Thu, 22 Aug 2002, Paul Kelly wrote:

> It is o32 (old library format), so it is not very useful for anyone
> running IRIX 6.x.

I don't understand this; I compiled it on 6.2 and it runs fine on 6.4; I
thought all later versions were backward-compatible with o32 so I compiled
it like this for maximum portability.
I can create an n32 version as well if you think it would be useful.

> 5.x/6.x???). I tested on an Indy R5000 with IRIX 6.5 and most of the
> freeware installed.

We do have an Indy running 6.5 here but it is turned off at the minute and
doesn't have a mouse. I will get it going and give it a try on it.

I have now installed it on an Indy R4600 (100MHz) running IRIX 6.5 and
everything works (still have to start it from an xterm though). I was
pleasantly surprised at the speed also. Even SG3d and NVIZ were perfectly
usable on this old machine.

So I really can't understand why the binaries wouldn't work on a 6.5
machine. Was there any kind of error message? I should have mentioned the
problem with the IRIX winterm though. I am so used to always running
GRASS from an xterm that it slipped my mind. So I will have a look at this
sometime.

Paul

3

Paul Kelly wrote:

On Thu, 22 Aug 2002, Paul Kelly wrote:

> > It is o32 (old library format), so it is not very useful for anyone
> > running IRIX 6.x.
>
> I don't understand this; I compiled it on 6.2 and it runs fine on 6.4; I
> thought all later versions were backward-compatible with o32 so I compiled
> it like this for maximum portability.
> I can create an n32 version as well if you think it would be useful.
>
> > 5.x/6.x???). I tested on an Indy R5000 with IRIX 6.5 and most of the
> > freeware installed.
>
> We do have an Indy running 6.5 here but it is turned off at the minute and
> doesn't have a mouse. I will get it going and give it a try on it.
>

I have now installed it on an Indy R4600 (100MHz) running IRIX 6.5 and
everything works (still have to start it from an xterm though). I was
pleasantly surprised at the speed also. Even SG3d and NVIZ were perfectly
usable on this old machine.

So I really can't understand why the binaries wouldn't work on a 6.5
machine. Was there any kind of error message? I should have mentioned the
problem with the IRIX winterm though. I am so used to always running
GRASS from an xterm that it slipped my mind. So I will have a look at this
sometime.

Hi Paul,

thanks for the reply. You are correct, if i start grass from xterm it
works.
But i don't remember this problem from the distribution i created
myself. I am not able to start grass with the bash shell, grass uses ksh
instead. I can not remember the status on the other machine.

For the o32/n32 and mips-2/mips-3 discussion: I asked several people
about the lowest common denominator for IRIX (two years ago) and it was
consensus to use n32 and mips-3. I doubt that anyone uses IRIX 5.x and a
machine with mips-2 architecture (i. e. R2000/R3000 processor!) for
grass. n32 and mips-3 mean IRIX 6.2 and higher and any machine with
R4x00 processor and up. mips-4 will exclude users of R4K and R5K
processors, the 64-bit ABI does not really work with grass.
Speed is important if you run interpolations on big raster data sets,
but i never did any comparisons.

It is my belief that we should try to avoid compatibility problems as
far as possible and not to change decisions already made.

But it is your build and your decision.

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850

4

On Thu, 22 Aug 2002, Andreas Lange wrote:

Hi Paul,

thanks for the reply. You are correct, if i start grass from xterm it
works.
But i don't remember this problem from the distribution i created
myself. I am not able to start grass with the bash shell, grass uses ksh

I believe I have found the problem; it is in src/libes/vask (VASKLIB). CVS
shows in May 2001 changes were made to the way it uses the curses library.
I got the older versions of the files from before then and compiled and it
works all right; I can press <Esc> and <Return> in winterm. Probably
somebody should put in a workaround for IRIX then but I don't understand
it enough at the minute.

instead. I can not remember the status on the other machine.

For the o32/n32 and mips-2/mips-3 discussion: I asked several people
about the lowest common denominator for IRIX (two years ago) and it was
consensus to use n32 and mips-3. I doubt that anyone uses IRIX 5.x and a
machine with mips-2 architecture (i. e. R2000/R3000 processor!) for
grass. n32 and mips-3 mean IRIX 6.2 and higher and any machine with
R4x00 processor and up. mips-4 will exclude users of R4K and R5K
processors, the 64-bit ABI does not really work with grass.
Speed is important if you run interpolations on big raster data sets,
but i never did any comparisons.

Well I haven't asked anybody so I will go along with what you have
discovered. I will learn from the mistakes and compile a new improved version
after 5.0.0 stable comes out. But I think the version available now is useful
enough to be kept available; only I suspect the disk space it uses on the
server is certainly not proportional to the demand for it!

Thank you very much for the feedback

Paul

5

Paul Kelly wrote:

> thanks for the reply. You are correct, if i start grass from xterm it
> works.
> But i don't remember this problem from the distribution i created
> myself. I am not able to start grass with the bash shell, grass uses ksh

I believe I have found the problem; it is in src/libes/vask (VASKLIB). CVS
shows in May 2001 changes were made to the way it uses the curses library.
I got the older versions of the files from before then and compiled and it
works all right; I can press <Esc> and <Return> in winterm. Probably
somebody should put in a workaround for IRIX then but I don't understand
it enough at the minute.

I made the changes to which you are referring.

The old version tried to process extended keys (those which generate
escape sequences, e.g. cursor keys) manually, by recognising
hard-coded sequences (e.g. ESC-[-A for up).

I changed it to call the curses keypad() function, which causes curses
to process the escape sequences for extended keys internally, and
return special codes (e.g. KEY_UP for up).

The curs_getch(3) manpage (from ncurses) says:

       If keypad is TRUE, and a function key is pressed, the
       token for that function key is returned instead of the raw
       characters. Possible function keys are defined in
       <curses.h> as macros with values outside the range of
       8-bit characters whose names begin with KEY_. Thus, a
       variable intended to hold the return value of a function
       key must be of short size or larger.

       When a character that could be the beginning of a function
       key is received (which, on modern terminals, means an
       escape character), curses sets a timer. If the remainder
       of the sequence does not come in within the designated
       time, the character is passed through; otherwise, the
       function key value is returned. For this reason, many
       terminals experience a delay between the time a user
       presses the escape key and the escape is returned to the
       program.

If this works with xterm, that suggests that it isn't a problem with
the curses library itself.

The keypad() function sends the sequence associated with the "smkx"
terminfo entry to the terminal to enable the extended keys (on xterm,
this selects "application mode"; note the ticks on the Ctrl+Button2
menu). It's possible that the terminfo entry for winterm has the wrong
sequence.

It wouldn't be that hard to (conditionally) disable the call to
keypad(); that would allow ESC to be received, but extended keys won't
work.

--
Glynn Clements <glynn.clements@virgin.net>