[Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 30 Dec 2001 16:16:48 -0800
Patches item #494783, was opened at 2001-12-18 14:39
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: diffs for Windows CE - Include/Opcode.h
Initial Comment:
Attached is a diff for Include/opcode.h to allow
compilation on MS Wince using EVT 3.0
I have quite a lot of little diffs like this that I
would like to submit, but before generating and
posting all of them, I'm sending in just this one to
be sure I've done this correctly.
My original edits were made against 2.2 alpha 1, so I
am re-updating my local src tree and redoing all the
diffs.
I also will have some diffs for Novell NetWare in the
future.
I realize you may not be able to apply these diffs
anytime soon, but could you let me know if this meets
your format requirements soon so I can continue to
submit diffs.
Thanks
----------------------------------------------------------------------
>Comment By: Martin v. Löwis (loewis)
Date: 2001-12-30 16:16
Message:
Logged In: YES
user_id=21627
Attaching the opcode changes to this report is fine, also
including any other renaming problems into the same patch is
fine.
I'd appreciate if you could separate any errno patches you
may have, since I'd expect some discussion on these, which
shouldn't stop integration of the renamings. To do this, you
could try to edit the universal or context diffs (whatever
you are more familiar with) by hand. Notice that this works
only as long as you are deleting entire hunks; don't try to
modify a hunk (this will normally mess up the line numbers).
If overlapping changes are in a single hunk, you may include
them in the patch as well - I'll have to unedit them out,
then (by applying the patch to a clean copy, and manually
taking out the unrelated changes).
You may wonder about the insistence on separate patches, but
it is really a prerequisite for understanding the rationale
of a change in the coming years.
----------------------------------------------------------------------
Comment By: Brad Clements (bkc)
Date: 2001-12-30 08:51
Message:
Logged In: YES
user_id=4631
I have made the suggested changes to the enum, and the
necessary changes to compile.c and ceval.c
Should I append those three diffs to this patch entry, or
create a new entry, one for each of those diffs?
compile.c has some other unrelated changes, and some of
those changes are dependent on diffs to another include.
IE, rather than #ifdef'ing all references to errno, I know
that NetWare doesn't have errno either. So I've created
macros GetErrno(), ClearErrno() and SetErrno(). Hope that's
going to work out.
Also, lots of modules have statements like : goto finally;
which Metrowerks and EVT don't like because "finally" is a
reserved word, even when compiling .c modules. So I've had
to change all of those as well.
When I get regrtests all working, and recompile my code on
Win32 and Linux, then I'll post all my diffs.
----------------------------------------------------------------------
Comment By: Brad Clements (bkc)
Date: 2001-12-30 08:51
Message:
Logged In: YES
user_id=4631
I have made the suggested changes to the enum, and the
necessary changes to compile.c and ceval.c
Should I append those three diffs to this patch entry, or
create a new entry, one for each of those diffs?
compile.c has some other unrelated changes, and some of
those changes are dependent on diffs to another include.
IE, rather than #ifdef'ing all references to errno, I know
that NetWare doesn't have errno either. So I've created
macros GetErrno(), ClearErrno() and SetErrno(). Hope that's
going to work out.
Also, lots of modules have statements like : goto finally;
which Metrowerks and EVT don't like because "finally" is a
reserved word, even when compiling .c modules. So I've had
to change all of those as well.
When I get regrtests all working, and recompile my code on
Win32 and Linux, then I'll post all my diffs.
----------------------------------------------------------------------
Comment By: Brad Clements (bkc)
Date: 2001-12-29 10:14
Message:
Logged In: YES
user_id=4631
Yes, I will change the enum and all uses of it that I can
find to use a unique prefix as you suggested.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 14:40
Message:
Logged In: YES
user_id=21627
The patch looks fine to me. I wonder whether Python should
stop using these constant names, though, and replace them
with, say, a PyCmp_ prefix, throughout. If there is a
backwards compatibility concern (which I wouldn't expect),
it should be possible to add #defines to the old names when
there is no conflict.
Would you be willing to rewrite this patch to do so?
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-19 08:05
Message:
Logged In: YES
user_id=6380
Standard cautionary note. Sorry.
----------------------------------------------------------------------
Comment By: Brad Clements (bkc)
Date: 2001-12-19 07:39
Message:
Logged In: YES
user_id=4631
I used the win CVS "update" command on the entire source
tree yesterday. I have not specified a particular tag. Are
you saying that opcode.h rev 2.37 is not current, or
is "please use the current cvs" a standard cautionary note?
Sorry to be anal, I want this to be seamless for you so I
feel I have botched it up already.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-18 19:20
Message:
Logged In: YES
user_id=6380
That looks like a fine context diff to me.
Please be sure to use the current CVS if you can!
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470