FAQ
I am using Python on Itanium Windows 64 (Server 2003) with a Win32 version.

Is there a native version available or planned? Are testers needed for
this platform?

Windows 64 is a bit unusual in that "long" is not large enough to hold
an address.



From http Sun Nov 2 00:16:26 2003
From: http (Paul Rubin)
Date: 01 Nov 2003 15:16:26 -0800
Subject: Removing Unicode from Python?
References: <mailman.258.1067543038.702.python-list@python.org>
<3fa43b28$0$58698$e4fe514c@news.xs4all.nl>
Message-ID: <7xbrrvptmd.fsf@ruckus.brouhaha.com>

Irmen de Jong <irmen at -NOSPAM-REMOVETHIS-xs4all.nl> writes:
While I think I am reasonably aware of things like Unicode,
character encodings, and assorted related stuff, I still found that
article highly interesting. Thanks for the link!
Actually I think the Wikipedia article on unicode is much better.
http://www.wikipedia.org/wiki/unicode


From http Sun Nov 2 00:18:54 2003
From: http (Paul Rubin)
Date: 01 Nov 2003 15:18:54 -0800
Subject: Rekall not longer available from theKompany.com - a fabrication
References: <3fa0fd21$0$12688$fa0fcedb@lovejoy.zen.co.uk>
<c846bee4.0310311540.184f3148@posting.google.com>
<6ee58e07.0310312008.ce341ea@posting.google.com>
<87r80sdyb1.fsf@pobox.com> <7xn0bg6njb.fsf@ruckus.brouhaha.com>
<pan.2003.11.01.23.14.37.341079.18222@tampabay.rr.com>
Message-ID: <7x7k2jpti9.fsf@ruckus.brouhaha.com>

Todd Stephens <huzzah at tampabay.rr.com> writes:
Regardless of the OP's intentions, I think the word "bankrupt" is not
qualified by "basically" so much as it is qualified by "is".
I read the OP as saying TKC is basically bankrupt. I don't know what
the actual facts surrounding TKC are. I didn't see any indication
that it had legally filed bankruptcy and I don't really care since I'm
not a creditor. What I want to know is whether it's paying its
programmers and shipping product. There are conflicting claims about
whether it's paying its programmers. Which claims are correct?

Search Discussions

  • Trent Mick at Nov 2, 2003 at 2:37 am
    [Bernhard Mulder wrote]
    I am using Python on Itanium Windows 64 (Server 2003) with a Win32 version.

    Is there a native version available or planned? Are testers needed for
    this platform?
    Python should compile fine for Win64. It was ported for Win64 a few
    years back (around the time of Python 2.0/1.6 I think).

    There are no free binary packages kicking around out there that I know
    of but a number of people do compile it themselves for Win64. There was
    some discussion on this list recently about how to do that seeing as
    there is no DevStudio for Win64 (at least, that is my understanding).
    One way was to export makefiles from Python's .dsp project files and use
    the Win64 cross-compiler that is available with the platform SDK.

    Windows 64 is a bit unusual in that "long" is not large enough to hold
    an address.
    Yup. Though I would use a stronger word than "unusual". :)

    Trent

    p.s. ActiveState will provide Win64 binary installers for Python on
    contract, though I don't know if that is an option for you.

    --
    Trent Mick
    TrentM at ActiveState.com
  • Martin v. Löwis at Nov 2, 2003 at 6:56 pm

    Trent Mick <trentm at ActiveState.com> writes:

    There are no free binary packages kicking around out there that I know
    of but a number of people do compile it themselves for Win64.
    However, there are free binary packages out there that you don't know
    of :-)

    http://www.dcl.hpi.uni-potsdam.de/home/loewis/python23.msi

    See

    http://groups.google.com/groups?selm=mailman.1060265944.15612.clpa-moderators%40python.org

    for the original announcement.
    There was some discussion on this list recently about how to do that
    seeing as there is no DevStudio for Win64 (at least, that is my
    understanding).
    Again, it depends: With sf.net/projects/vsextcomp, VS 7.1 is very well
    capable of invoking the Itanium platform SDK compiler (AMD64 coming
    soon).
    Windows 64 is a bit unusual in that "long" is not large enough to hold
    an address.
    Yup. Though I would use a stronger word than "unusual". :)
    That may even be a source of bugs. I'm in the process of putting
    size_t in every place Python currently uses "int" or "long" to store a
    number of bytes. In some cases, exceeding 4GB (sometimes 2GB) will
    cause crashes in Python 2.3 (in other cases, this is somewhat overkill
    - eg. when the compiler complains that strlen(some_file_name) may not
    fit into 4 bytes).

    Regards,
    Martin
  • Mike Rovner at Nov 3, 2003 at 6:37 pm

    Martin v. L?wis wrote:

    That may even be a source of bugs. I'm in the process of putting
    size_t in every place Python currently uses "int" or "long" to store a
    number of bytes. In some cases, exceeding 4GB (sometimes 2GB) will
    cause crashes in Python 2.3 (in other cases, this is somewhat overkill
    - eg. when the compiler complains that strlen(some_file_name) may not
    fit into 4 bytes).
    Does that mean forthcoming API interface change?
    There are mostly ints for sizes (ex. PyString_AsStringAndSize
    (PyObject *obj, char **buffer, int *length)).

    Regards,
    Mike
  • Martin v. Löwis at Nov 3, 2003 at 10:28 pm

    "Mike Rovner" <mike at nospam.com> writes:

    That may even be a source of bugs. I'm in the process of putting
    size_t in every place Python currently uses "int" or "long" to store a
    number of bytes. In some cases, exceeding 4GB (sometimes 2GB) will
    cause crashes in Python 2.3 (in other cases, this is somewhat overkill
    - eg. when the compiler complains that strlen(some_file_name) may not
    fit into 4 bytes).
    Does that mean forthcoming API interface change?
    Yes. I haven't changed any structure (yet), but, after approval on
    python-dev, this is likely to happen as well.
    There are mostly ints for sizes (ex. PyString_AsStringAndSize
    (PyObject *obj, char **buffer, int *length)).
    Indeed. I don't think it matters, though: processors typically return
    results in registers. On a 64-bit processor, a single register will
    take the result, and most likely, a 32-bit return value will be
    widened appropriately. So you might actually get away with not
    recompiling the extensions in 2.4 (atleast until ob_size changes,
    which does cause incompatibilities on big-endian machines).

    Regards,
    Martin

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedNov 1, '03 at 5:39p
activeNov 3, '03 at 10:28p
posts5
users4
websitepython.org

People

Translate

site design / logo © 2022 Grokbase