I ran LLVM's under-development C front-end, clang
(http://clang.llvm.org), against Python today. While a ton of message
crop up thanks to lacking header files, I did come across a handful of
semi-useful warnings (e.g., the change I checked into
Python/compile.c).
One thing it picked up is that on
-On [20080207 09:05], Brett Cannon ([EMAIL PROTECTED]) wrote:
>Since both strerror() and memmove() are both in C89 (they are listed
>in K&R), can we ditch these files?
You got my vote. I am assuming the minimum needed compiler is C90 (ISO over
ANSI, sorry :P) and you might even need th
I note that in r60567 Christian checked in support for compacting the
int and float freelists.
I have no problems with the implementation, but would like to note
that I have been experimenting with an alternate approach which doesn't
require the addition of a knob to initiate the compacting.
Prob
>>> unicode('\x87\x6F', "shift jis")
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'shift_jis' codec can't decode bytes in position 0-1:
illegal multibyte sequence
Still, \x87\x6F is a valid Shift-JIS character :
http://demo.icu-project.org/icu-bin/convexp?conv=ibm-
Andrew MacIntyre wrote:
> So I've been testing with the freelists ripped out and ints and floats
> reverted to fairly standard PyObject_New allocation (retaining the small
> int interning) and thus relying on PyMalloc to do any compaction.
Nice! What do you mean with int interning? Are you talking
On Thu, 7 Feb 2008 09:08:26 -0500, "A.M. Kuchling" <[EMAIL PROTECTED]> wrote:
>On Wed, Feb 06, 2008 at 08:34:21PM -0500, Raymond Hettinger wrote:
>> Also, test_docxmlrpc hasn't been happy. One of the tests isn't
>> getting the exact response string it expected. Any ideas what is
>> causing this?
>
On Wed, Feb 06, 2008 at 08:34:21PM -0500, Raymond Hettinger wrote:
> Also, test_docxmlrpc hasn't been happy. One of the tests isn't
> getting the exact response string it expected. Any ideas what is
> causing this?
My fault; it should be fixed now.
> There is also a recurring failure in SocketSe
> UnicodeDecodeError: 'shift_jis' codec can't decode bytes in position
> 0-1: illegal multibyte sequence
As Amaury says, this is CP932 and Shift-Jis-2004, but not Shift-Jis.
The IBM database must be incorrect: it lists as "all aliases" both
csShiftJIS and csWindows31J, yet, according to
http://w
Hello,
Nicolas Dumazet :
> >>> unicode('\x87\x6F', "shift jis")
> Traceback (most recent call last):
> File "", line 1, in
> UnicodeDecodeError: 'shift_jis' codec can't decode bytes in position 0-1:
> illegal multibyte sequence
>
> Still, \x87\x6F is a valid Shift-JIS character :
> http://demo.
On 2008-02-07 14:09, Andrew MacIntyre wrote:
> Probably in response to the same stimulus as Christian it occurred to me
> that the freelist approach had been adopted long before PyMalloc was
> enabled as standard (in 2.3), and that much of the performance gains
> between 2.2 and 2.3 were in fact du
On Feb 7, 2008 5:09 AM, Andrew MacIntyre <[EMAIL PROTECTED]> wrote:
>
> So I've been testing with the freelists ripped out and ints and floats
> reverted to fairly standard PyObject_New allocation (retaining the small
> int interning) and thus relying on PyMalloc to do any compaction.
>
> The resul
> One of the hopes of having a custom allocator for Python was to be
> able to get rid off all free lists. For some reason that never happened.
> Not sure why. People were probably too busy with adding new
> features to the language at the time ;-)
Probably not. It's more that the free lists still
12 matches
Mail list logo
