> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4