- 22 Apr, 2003 4 commits
-
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
- 21 Apr, 2003 2 commits
-
-
Fred Drake authored
-
Phillip J. Eby authored
the 'name' attr is '#PCDATA' not '#NMTOKEN', because name fields need to allow the '*' or '+' sign in the content.
-
- 17 Apr, 2003 1 commit
-
-
Guido van Rossum authored
recursively to avoid blowing up when a tuple contains a really long string (e.g. 100 MB in size).
-
- 16 Apr, 2003 1 commit
-
-
Tim Peters authored
-
- 11 Apr, 2003 3 commits
-
-
Tim Peters authored
-
Tim Peters authored
states when the value passed in was of the wrong type (for example, doing b[obj] = 3.7 when b is an OIBTree). This manifested as a refcount leak in the test suite, but could have been much worse (most likely in real life is that a seemingly arbitrary existing key would "go missing").
-
Tim Peters authored
bucket when deleting the first child of a BTree node with more than one child. This caused >600 int objects to leak in the OI and OO flavors of testRemoveSucceeds.
-
- 10 Apr, 2003 1 commit
-
-
Tim Peters authored
BTree_lastBucket(). In unusual cases, this could cause a chain of buckets to leak (the DegenerateBTree tests appeared to be the only ones that provoked this, and there it leaked 285 IISet buckets). Other uses of BTree_lastBucket() appear to be refcount-correct.
-
- 09 Apr, 2003 3 commits
-
-
Jeremy Hylton authored
Don't know what happened, but the tests started running very slowly with Python2.3. Fixed by checking _ready at the start of the loop in _wait() instead of at the bottom. Most of the time _ready is set by the time we start, and no more I/O is going to occur until the client connects; as a result, the tests always sat in pending() until it timed out at 30 seconds.
-
Jeremy Hylton authored
There's a race between closing the storage and shutting down the ConnectThread. If we return here, the ConnectThread does no harm.
-
Jeremy Hylton authored
-
- 08 Apr, 2003 5 commits
-
-
Barry Warsaw authored
-
Barry Warsaw authored
-
Barry Warsaw authored
FileStorage. Fixed this and then had to no-op all the tests that MappingStorage can't possibly pass. I think there may still be problems with BDB which I'll follow up on next.
-
Jeremy Hylton authored
You never need an __del__ to close a file. A file closes itself when it is deallocated. Don't give an object a magic __del__ attribute. It won't work with new-style classes, and it's obscure anyway.
-
Jeremy Hylton authored
The DB's invalidate() method takes a set of oids corresponding to all the changes from a data manager for one transaction. All the objects are invalidated at once. Add a few tests in testZODB of the new code. The tests just cover corner cases, because I can't think of a sensible way to test the atomicity. When it has failed in the past, it's been caused by nearly-impossible to reproduce data races. This fix needs to be backported to Zope 2.6, but only after assessing how significant an impact the API change will have.
-
- 07 Apr, 2003 3 commits
-
-
Jeremy Hylton authored
-
Barry Warsaw authored
bytesread accumulator, not the chunklen which is the number of bytes we wanted to read.
-
Jeremy Hylton authored
-
- 04 Apr, 2003 3 commits
-
-
Jeremy Hylton authored
XXX Not sure where this macro is used or what kind of failures this bug caused.
-
Richard Jones authored
-
Richard Jones authored
I've fixed the various scripts etc. in the CVS so that I can now install a ZEO client/server setup. The way it actually ended up working is: - runzope.py and zopectl.py are moved to Zope/Startup/run.py and Zope/zdaemon/zopectl.py respectively - bin/mkzopeinstance now takes a "-z/--zeo host:port" which sets up a custom_zodb.py in the new zope instance home - bin/mkzeoinstance now overrides less, because... - ZEO/mkzeoinst.py generates an additional script, runzeo, which is the "runner" for the ZEO server. Both it an the zeoctl script need to know about the ZOPE_HOME, so that's been added to the scripts (via the params) - fixed setup.py so it installed ZEO/schema.xml
-
- 03 Apr, 2003 1 commit
-
-
Richard Jones authored
- the scripts won't be in the user's $PATH, so override that lookup in from mkzeoinst.py in the mkzeoinstance script - the scripts won't be executable, so prepend commands with $python
-
- 02 Apr, 2003 1 commit
-
-
Jeremy Hylton authored
The implementation is to make the reference in the cache "ring" a new reference rather than a borrowed reference. It is the intent of the cache to keep N recently used objects in memory, regardless of whether they are currently referenced. The goal is to avoid the cost of recreating the objects, based on the assumption that they are likely to be used again soon.
-
- 01 Apr, 2003 11 commits
-
-
Jeremy Hylton authored
The cache behaves differently now; it doesn't keep objects alive artificially. We should write some new tests that verify behavior with objects that are kept alive by external references.
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Jeremy Hylton authored
details.
-
Jeremy Hylton authored
The cache is intended to keep weak references to objects. An object should be deallocated when the only references to it are in the cache. If an object is unghostified and added to the list of live objects, the list should have a borrowed reference. Otherwise, the cache will keep the object alive after all other references have disappeared.
-
Jeremy Hylton authored
time. Instead use std PyDict_GetItem() and incref only when necessary.
-
Jeremy Hylton authored
The cache decrefed it in percachedel.
-
Jeremy Hylton authored
PyDict_DelItem() will undo the other INCREF.
-
Jeremy Hylton authored
-
Jeremy Hylton authored
Decref its reference to the cache. In a debug build, account for the two bogus additions to _Py_RefTotal. Also, reindent initcPickleCache().
-
Barry Warsaw authored
-
- 31 Mar, 2003 1 commit
-
-
Jeremy Hylton authored
-