hi,
test mail list :)
致
礼！
Frank
[EMAIL PROTECTED]
2005-11-25
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Hi,
I found a bug in bz2 python module. Example:
import bz2
bz2.BZ2File("test.bz2","r")
bz2.seek(0,2)
assert bz2.tell() != 0
Details and *patch* at:
http://sourceforge.net/tracker/index.php?func=detail&aid=1366000&group_id=5470&atid=105470
Please CC-me for all your answers.
Bye, Victor
--
This is probably OT for [Python-dev]
I suspect that your problem is not the GIL but is due to something else.
Rather than dorking with the interpreter's threading, you probably would
be better off rethinking your problem and finding a better way to
accomplish your task.
On Thu, 24 Nov 2005, Du
Martin v. Löwis wrote:
> Travis Oliphant wrote:
>
>> As verified by removing usage of the Python PyObject_MALLOC function,
>> it was the Python memory manager that was performing poorly. Even
>> though the array-scalar objects were deleted, the memory manager
>> would not re-use their memory
Martin v. Löwis wrote:
> Travis Oliphant wrote:
>
>> So, I now believe that his code (plus the array scalar extension
>> type) was actually exposing a real bug in the memory manager itself.
>> In theory, the Python memory manager should have been able to re-use
>> the memory for the array-scal
There are still a few reference leaks I've been able to identify. I
didn't see an obvious solution to these (well, I saw one obvious
solution which crashed, so obviously I was wrong).
When running regrtest with -R here are the ref leaks reported:
test_codeccallbacks leaked [2, 2, 2, 2] reference
Duncan Grisby wrote:
> Is there any fundamental reason why the re module cannot release the
> interpreter lock, for at least some of the time it is running? The
> ideal situation for me would be if it could do most of its work with
> the lock released, since the software is running on a multi proc
Hi Travis,
On Thu, Nov 24, 2005 at 10:17:43AM -0700, Travis E. Oliphant wrote:
> Why doesn't the int32
> type inherit its tp_free from the early types first?
In your case I suspect that the tp_free is inherited from the tp_base
which is probably 'int'. I don't see how to "fix" typeobject.c, bec
Neal Norwitz wrote:
> On 11/24/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>>>Should users have access to the search path (through a
>>>codecs.unregister())?
>>
>>Maybe, but why would you want to unregister a search function ?
>>
>>
>>>If so, should it search from the end of the
>>>list to the
On 11/24/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
> > Should users have access to the search path (through a
> > codecs.unregister())?
>
> Maybe, but why would you want to unregister a search function ?
>
> > If so, should it search from the end of the
> > list to the beginning to remove an i
Neal Norwitz wrote:
> While running regrtest with -R to find reference leaks I found a usage
> issue. When a codec is registered it is stored in the interpreter
> state and cannot be removed. Since it is stored as a list, if you
> repeated add the same search function, you will get duplicates in
While running regrtest with -R to find reference leaks I found a usage
issue. When a codec is registered it is stored in the interpreter
state and cannot be removed. Since it is stored as a list, if you
repeated add the same search function, you will get duplicates in the
list and they can't be r
Armin Rigo wrote:
> Hi,
>
> Ok, here is the reason for the leak...
>
> There is in scipy a type called 'int32_arrtype' which inherits from both
> another scipy type called 'signedinteger_arrtype', and from 'int'.
> Obscure! This is not 100% officially allowed: you are inheriting from
> two C typ
Armin Rigo wrote:
> Hi,
>
> Ok, here is the reason for the leak...
>
> There is in scipy a type called 'int32_arrtype' which inherits from both
> another scipy type called 'signedinteger_arrtype', and from 'int'.
> Obscure! This is not 100% officially allowed: you are inheriting from
> two C typ
Armin Rigo wrote:
> Hi,
>
> Ok, here is the reason for the leak...
>
> There is in scipy a type called 'int32_arrtype' which inherits from both
> another scipy type called 'signedinteger_arrtype', and from 'int'.
> Obscure! This is not 100% officially allowed: you are inheriting from
> two C typ
[Martin v. Löwis]
> One way (I think the only way) this could happen if:
> - the objects being allocated are all smaller than 256 bytes
> - when allocating new objects, the requested size was different
> from any other size previously deallocated.
>
> So if you first allocate 1,000,000 objects of
Donovan Baarda wrote:
> I don't know if this will help, but in my experience compiling re's
> often takes longer than matching them... are you sure that it's the
> match and not a compile that is taking a long time? Are you using
> pre-compiled re's or are you dynamically generating strings and us
On Thursday 24 November, Donovan Baarda wrote:
> I don't know if this will help, but in my experience compiling re's
> often takes longer than matching them... are you sure that it's the
> match and not a compile that is taking a long time? Are you using
> pre-compiled re's or are you dynamically
On Thu, 2005-11-24 at 14:11 +, Duncan Grisby wrote:
> Hi,
>
> I posted this to comp.lang.python, but got no response, so I thought I
> would consult the wise people here...
>
> I have encountered a problem with the re module. I have a
> multi-threaded program that does lots of regular express
Hi,
I posted this to comp.lang.python, but got no response, so I thought I
would consult the wise people here...
I have encountered a problem with the re module. I have a
multi-threaded program that does lots of regular expression searching,
with some relatively complex regular expressions. Occas
Phillip J. Eby wrote:
> This isn't hard to implement per se; setuptools for example has a
> 'get_importer' function, and going from importer to loader is simple:
Thanks, I think I'll definitely be able to build something out of that.
> So with the above function you could do something like:
>
>
Hi,
Ok, here is the reason for the leak...
There is in scipy a type called 'int32_arrtype' which inherits from both
another scipy type called 'signedinteger_arrtype', and from 'int'.
Obscure! This is not 100% officially allowed: you are inheriting from
two C types. You're living dangerously!
N
Hi,
On Thu, Nov 24, 2005 at 01:59:57AM -0800, Robert Kern wrote:
> You can get the version of scipy_core just before the fix that Travis
> applied:
Now we can start debugging :-)
> http://projects.scipy.org/scipy/scipy_core/changeset/1490
This changeset alone fixes the small example you provi
On Tue, 2005-11-22 at 23:04 -0600, Paul Jimenez wrote:
> It is my assertion that urlparse is currently broken. Specifically, I
> think that urlparse breaks an abstraction boundary with ill effect.
>
> In writing a mailclient, I wished to allow my users to specify their
> imap server as a url, su
Martin v. Löwis wrote:
> That the code is complex would not so much be a problem: we often
> analyse complex code here. It is a problem that the code is not
> available, and it would be a problem if the problem was not
> reproducable even if you had the code (i.e. if the problem would
> sometimes
Martin v. Löwis wrote:
> One way (I think the only way) this could happen if:
> - the objects being allocated are all smaller than 256 bytes
> - when allocating new objects, the requested size was different
>from any other size previously deallocated.
>
> So if you first allocate 1,000,000 obj
Travis Oliphant wrote:
> So, I now believe that his code (plus the array scalar extension type)
> was actually exposing a real bug in the memory manager itself. In
> theory, the Python memory manager should have been able to re-use the
> memory for the array-scalar instances because they are al
Travis Oliphant wrote:
> As verified by removing usage of the Python PyObject_MALLOC function, it
> was the Python memory manager that was performing poorly. Even though
> the array-scalar objects were deleted, the memory manager would not
> re-use their memory for later object creation. Inste
Travis Oliphant wrote:
> In the long term, what is the status of plans to re-work the Python
> Memory manager to free memory that it acquires (or improve the detection
> of already freed memory locations).
The Python memory manager does reuse memory that has been deallocated
earlier. There are p
29 matches
Mail list logo
