[Python-Dev] HP-UX clean-up

[Cameron Laird]

> From tim.one at comcast.net Sat Jan 03 19:31:55 2004
> > ...
> > Has anyone been in contact with the HP-UX Porting Center
> > folks recently?  I wonder if I should enlist their help ...

> If and only if they know something about HP-UX <0.5 wink>.  Nobody here
> really seems to.  Have you tried their port?  2.3.1 appears to be the most
> recent:

>     http://hpux.cs.utah.edu/hppd/hpux/Languages/python-2.3.1/

> By memory, in the past we've gotten complaints from HP-UX users about
> previous Porting Center Pythons in two areas:

> 1. Apparently some (all?) of their Python ports were built with
>    threading disabled entirely.

> 2. Flaky floating-point behavior.

> An example of the latter complaint is here (not a particularly good example,
> just the first I bumped into via Googling):

>     http://www.ifost.org.au/Software/

>     The python for HP-UX 11 that is found at the HP public domain
>     software porting centre has buggy floating point problems.  I
>     recompiled it with gcc 3 and while there are some round-off
>     issues, at least it's not totally deranged... [a link to
>     python-211-hpux11-gcc.gz]

I'm far enough along to begin reporting to python-dev and soliciting
the group as what Guido called a "crutch".

Issues:
A.  Threading:  first, congratulations to Guido et al.,
    for bringing it along this far.  I think you've done
    the best possible.

    Lots of HP-UX people seem to be building --without-threads.
    I can imagine that the Porting Center will continue to do 
    so.  We can help them do better, or at least more; I don't
    know yet when that'll be the most important chore.

    I want to make changes in threading's configuration.  I
    want first to collect more information, so I can explain
    myself with precision.
B.  Version:  I'd like good support to go back at least to
    10.20.  If someone thinks, "Nah, 11.01 and higher is good
    enough," I'd like to know now.
C.  curses:  I find this hairy.

    Is there a clean way to build without curses?  The only way
    I know to advance without it is to hack up setup.py, speci-
    fically to comment out the blocks that involve curses.

    Here are the symptoms:  curses involves a
      cc -Ae -DNDEBUG -O +z -I. \
	-I$SRC_ROOT/./Include \
	-I/tmp/test4/include -I/usr/local/include \
	-I$SRC_ROOT/Include \
	-I$SRC_ROOT -c \
	$SRC_ROOT/Modules/_cursesmodule.c
    This tosses
      cc: "$SRC_ROOT/Modules/_cursesmodule.c", line 306: error 1000: \
			 Unexpected symbol: "}".
      cc: error 2017: Cannot recover from earlier errors, terminating.
    The source in _cursesmodule.c in that vicinity is
	  ...
      #define Window_NoArg2TupleReturnFunction(X, TYPE, ERGSTR) \
      static PyObject * PyCursesWindow_ ## X (PyCursesWindowObject *self) \
      { \
	TYPE arg1, arg2; \
	X(self->win,arg1,arg2); return Py_BuildValue(ERGSTR, arg1, arg2); }
	  ...
      Window_NoArg2TupleReturnFunction(getyx, int, "ii")
      Window_NoArg2TupleReturnFunction(getbegyx, int, "ii")
      Window_NoArg2TupleReturnFunction(getmaxyx, int, "ii")
      Window_NoArg2TupleReturnFunction(getparyx, int, "ii")
	  ...

    /usr/include/curses.h defines
      #define getyx(__win,__y,__x)    { WINDOW *__wi; \
				       __wi = __win;  \
				       ((__y) = __getcury(__wi), \
				       (__x) = __getcurx(__wi)) }
    so the pre-processed form of the source is
	   /* Re-formatted for ease in reading white space. */
       static PyObject * PyCursesWindow_getyx (PyCursesWindowObject *self)
       {
           int arg1, arg2;
           { WINDOW *__wi; __wi = self->win;
             ((arg1) = __getcury(__wi), (arg2) = __getcurx(__wi))
           };
           return Py_BuildValue("ii", arg1, arg2);
        }
    which is, indeed, a fatal error.

    Does anyone see the right fix?  I sure haven't, yet.
D.  Other:  there are others.  I don't yet have good diagnoses.