Porting 2.1 to 2.7 without source

[Paulo Levi]

There is a rather old game, "Vampire the Masquerade: Bloodlines" that used a
cut down python 2.1 for scripts. I am trying (and failing) to port it to a
more complete python version, and thought 2.7 would be a nice target being
the last same major version.

Well, anyway, i only need to add 3 missing functions (troika original),
expose "void _PyObject_Del(PyObject *op)" that appears to have been hidden
around 2.3, set a new home based on the dll path and the game starts up
(full of errors of course).

One error in special is bothering me, since it appears to be caused by
changes to the PyTypeObject struct. Whenever one of the "cvar" objects that
troika binded to the half life 2 engine gets to a certain level of the
scripting engine, a pagefault is almost inevitable. These happen in the
"PyType_Ready(PyTypeObject *type)" function for the base class (that
bizarrely appears neither to be PyBaseObject_Type or NULL, but 8), and when
adding methods to the dict, and i stopped trying to fix it there here.

Strangely tp_name is "cvar" as expected.


Is this a impossible dream?

[Lennart Regebro]

Post by Paulo Levi
One error in special is bothering me, since it appears to be caused by
changes to the PyTypeObject struct. Whenever one of the "cvar" objects that
troika binded to the half life 2 engine gets to a certain level of the
scripting engine, a pagefault is almost inevitable.

Wild guess: Could this have something to do with the changes to
conform with aliasing rules?

http://www.python.org/dev/peps/pep-3123/

[Paulo Levi]

Well, i just used python source 2.1.3 (supposedly one minor version above
what troika used, and the same problem occurs though probably not on the
same place (i haven't bothered to track it down here, since it doesn't occur
on typeobject.c anymore). Anyway to disable that optimization in visual
studio c++ 6.0 to be sure it's not that?

Post by Lennart Regebro

Post by Paulo Levi
One error in special is bothering me, since it appears to be caused by
changes to the PyTypeObject struct. Whenever one of the "cvar" objects

that

Post by Paulo Levi
troika binded to the half life 2 engine gets to a certain level of the
scripting engine, a pagefault is almost inevitable.

Wild guess: Could this have something to do with the changes to
conform with aliasing rules?
http://www.python.org/dev/peps/pep-3123/

[Paulo Levi]

Also a interesting incompatibility occurred that i've just noticed. The game
didn't recognize the bool type as a int (as it expected the expression)
although bool is a subtype of int.

When i put this in PyRun_String that went away:

r = PyRun_StringFlags(str, s, g, l, NULL);
if(r != NULL && PyBool_Check(r)){
if(r == Py_True)
return PyInt_FromLong(1L);
else
return PyInt_FromLong(0L);
}
return r;

[Lennart Regebro]

Received: from localhost (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 13 Mar 2011 12:44:23 +0100
Received: from mail-vw0-f46.google.com (mail-vw0-f46.google.com
[209.85.212.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
(No client certificate requested)
by mail.python.org (Postfix) with ESMTPS
for <python-porting-+ZN9ApsXKcEdnm+***@public.gmane.org>; Sun, 13 Mar 2011 12:44:23 +0100 (CET)
Received: by vws1 with SMTP id 1so1731970vws.19
for <python-porting-+ZN9ApsXKcEdnm+***@public.gmane.org>; Sun, 13 Mar 2011 04:44:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=KTA05GlD8wOA9AgNK03ZRcoVT4REr1xJd0qT+8LFd+k=;
b=VwBl4h5H+NHUvyiIIWQVAeTMcVqXAq8j3ET1h+d66zxI1j3HUEj6thbplSGGxUOQiI
ex5Rrr1kMfMXgOb6IkCwuvR4CX4fnAUhOIIIvoLW4RgqmY2rRO3rGTzFS6EVOjMvAtye
A9uzlRZyE8k5ZUJT3GsuVMS1X7z+ImC/vndzM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
b=I1gvnzphF95yFrU5aMGlqeQAxuj+EACVJMKwW+G+79HRyH+gKkabZvGCYvxIt1Bjbj
QRwjCpvisyfh2AGOD6sba2aMyXiPA+uYbQWPLDFKtNpT7ojzVyjh2Xnp7Dk//DYyP4A3
a3fHJdCzRTBUSCZ7meNrV+c+dL7MhZDoSgshY=
Received: by 10.52.173.38 with SMTP id bh6mr2265428vdc.296.1300016662107; Sun,
13 Mar 2011 04:44:22 -0700 (PDT)
Received: by 10.52.92.180 with HTTP; Sun, 13 Mar 2011 04:44:02 -0700 (PDT)
In-Reply-To: <AANLkTikHJyO6m9eb6Ov=tE0acH8T2bjdsoEHeXVOixV=@mail.gmail.com>
X-BeenThere: python-porting-+ZN9ApsXKcEdnm+***@public.gmane.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion about porting Python code \(mainly 2.x -> 3.x\)"
<python-porting.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-porting>,
<mailto:python-porting-request-+ZN9ApsXKcEdnm+***@public.gmane.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-porting>
List-Post: <mailto:python-porting-+ZN9ApsXKcEdnm+***@public.gmane.org>
List-Help: <mailto:python-porting-request-+ZN9ApsXKcEdnm+***@public.gmane.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-porting>,
<mailto:python-porting-request-+ZN9ApsXKcEdnm+***@public.gmane.org?subject=subscribe>
Sender: python-porting-bounces+gcpp-python-porting=m.gmane.org-+ZN9ApsXKcEdnm+***@public.gmane.org
Errors-To: python-porting-bounces+gcpp-python-porting=m.gmane.org-+ZN9ApsXKcEdnm+***@public.gmane.org
Archived-At: <http://permalink.gmane.org/gmane.comp.python.porting/181>

Post by Paulo Levi
Well, i just used python source 2.1.3 (supposedly one minor version above
what troika used, and the same problem occurs though probably not on the
same place (i haven't bothered to track it down here, since it doesn't occur
on typeobject.c anymore). Anyway to disable that optimization in visual
studio c++ 6.0 to be sure it's not that?

I don't know, but you can change

PyObject_HEAD_INIT(NULL)
0, /* ob_size */

to

PyVarObject_HEAD_INIT(NULL, 0)

That won't work on Python 2.5 or earlier, but it should work under
Python 2.6 and 2.7. I don't have any real reason to believe this to be
the problem, but it could be worth a try.

[Paulo Levi]

I'm confused. Isn't that only possible if you can control the source (or
have enough debugging skill)? I don't actually have a compilable form of the
source for the c extension, and i only see those structs initializations on
them.

Post by Lennart Regebro

Post by Paulo Levi
Well, i just used python source 2.1.3 (supposedly one minor version above
what troika used, and the same problem occurs though probably not on the
same place (i haven't bothered to track it down here, since it doesn't

occur

Post by Paulo Levi
on typeobject.c anymore). Anyway to disable that optimization in visual
studio c++ 6.0 to be sure it's not that?

I don't know, but you can change
PyObject_HEAD_INIT(NULL)
0, /* ob_size */
to
PyVarObject_HEAD_INIT(NULL, 0)
That won't work on Python 2.5 or earlier, but it should work under
Python 2.6 and 2.7. I don't have any real reason to believe this to be
the problem, but it could be worth a try.

[Lennart Regebro]

Post by Paulo Levi
I'm confused. Isn't that only possible if you can control the source (or
have enough debugging skill)? I don't actually have a compilable form of the
source for the c extension, and i only see those structs initializations on
them.

I'm sorry, I didn't take the "without source" comment seriously in
your topic, because that is obviously impossible. I thought you meant
something else. You can not support any new Python version without the
C-extensions source. It needs to be recompiled.