[Jim Fulton]
In particular, it might have a reference to the key in an internal
BTree node.
(I don't know this to be true, but I wouldn't be surprised if it was
true.)
It was true when I was working on BTrees ... here, from
[Chris Withers]
Wondering if someone could tell me the difference between an OOSet and
an OOTreeSet?
OOSet is to OOTreeSet as OOBucket is to OOBTree. An OOTreeSet is
built out of leaf-level OOSets in exactly the same way an OOBTree is
built out of leaf-level OOBuckets. More at:
[Andreas Jung]
Who is currently in charge or who feels responsible for the Windows
builds?
[Sidnei da Silva]
Tim Peters.
[Chris Withers]
Er, no. Tim isn't even at Zope Corp anymore, as far as I know...
[Sidnei]
That shouldn't be related, should it?
Don't know about should
[Sidnei da Silva]
Seems like we are seeing a shortage of volunteers for building the
Zope Installers for Windows.
IOW, nothing has changed :-)
I haven't seen Tim Peters around for a while, and Chris Withers seems
to have stepped down now.
I'm around, but don't pay particular attention
[Sidnei da Silva[
So we need a 2.8.8 and 2.9.4 installers.
OK, I uploaded a Windows installer for 2.8.8. There were two -all
test failures:
ERROR: test_OFS_ObjectManager__importObjectFromFile_xml
(OFS.tests.test_XMLExportImport.XMLExportImportTests)
[Andreas Jung]
...
I think we should make another internal ZODB release. The current
svn:externals for the ZODB (and other modules) use a revision number
instead of a tag. This reminds me of some former discussion whether to use
revision numbers or tags...what was the result of this discussion.
[Tim]
I used tags for ZODB until I gave in to complaints about that, and
switched to using revision numbers. The real complaint about using a
tagged external is that when the tag changes, SVN isn't smart enough
to do an incremental update. Instead, when you update after an
external tag
[Tres Seaver]
...
I would guess that if you could do a census of all the OIDs in all the
Datas.fs in the world, a significant majority of them would be instances
of classes declared in IOBTree / IIBTree (certainly the bulk of
*transaction* records are going to be tied up with them).
Provided
[Chris Withers]
I notice 2.8.6 doesn't have a Windows binary either.
What's the build process for that?
Try to detect the pattern between this and previous answers ;-):
http://svn.zope.org/Zope/branches/Zope-2_8-branch/inst/WinBuilders/README.txt
I have a feeling I won't be able to help
[Chris Withers]
...
How should I run all the Zope tests once I have a candidate build?
Section Testing Zope in
http://svn.zope.org/Zope/trunk/inst/WinBuilders/README.txt
___
Zope-Dev maillist - Zope-Dev@zope.org
[Chris Withers]
I see there are no Zope 2.9 releases for Windows.
There probably should be ;-)
There's a Windows installer for Zope 2.9.0 on its download page:
http://www.zope.org/Products/Zope/2.9.0
Or do you mean 2.9.1?
What can I do to help with that?
Provoke Sidnei into responding
[Julien Anguenot]
I'm having some problems with the warnings module behavior.
(Python-2.4.2 and Zope-2.9 trunk)
[... traceback ... ]
- Line 71
Module zLOG, line 140, in LOG
Module warnings, line 61, in warn
Module warnings, line 67, in warn_explicit
TypeError: unsubscriptable
...
[Stephan Ricther]
I have seen you take a similar approach to zope.testing and I found that
painful just by watching the checkins.
[Jim Fulton]
I don't understand what you mean. Having a separate zope.testing project has
been extremely useful. For example, in our comercial apps,
we
We should distinguish between authoring the Windows
build-the-installer code, and running that code. Making a Zope 2
Windows release consists of _running_ the build-the-installer code,
and is easy. It's actually easier than building a Zope 3 Windows
release: once the Python tarball, Zope 2
[Philipp von Weitershausen]
...
Therefore, just to reduce confusion, I would move Makefile.in and
configure.py to the root (and remove the decoys). I'd also suggest we
rename 'inst' to 'installer' so that it won't be confused with
instance. Then again, this is just me and my weird sense of
[Lennart Regebro]
Only one real bug: No user is created (even though you type in name
and password).
Sorry, I'm not following this. The installer never offers to create a
user (although it does ask you to supply a password for the fixed
admin user). So you must be talking about something
[Sidnei da Silva]
Way to go Tim! You beat me to it. I was supposed to look at this soon
but got back from vacation just this tuesday. I will make sure your
installer gets testing and try to fix any eventual issues.
Excellent! This may actually work ;-)
While I'll be on vacation the next two
[Philipp von Weitershausen]
It seems that 'inst' holds nothing of value anymore except 'Makefile.in'
and 'WinBuilders'.
WRT Windows, that's certainly true on my Windows-installer branch. I
don't know whether any of it is still useful on Linux. You seem to
think Makefile.in is still useful,
[Sidnei da Silva]
I think there's a Makefile.win too, that is used by inst/configure.py
on Windows. (I know because use it).
There is a Makefile.win.in, but the build-the-Windows-installer
process no longer uses it on my branch -- the branch doesn't use
anything in the root of inst/ anymore,
Most of the last two days I've been whacking on Zope 2.9 to build a
Zope 2 style Windows installer that bundles Python 2.4.2, and
cooperates with the new zpkgtools-created tarball layout. The
build-the-Windows-installer code got simpler as a result, but ...
This work is being done on branch:
[Andreas Jung]
...
Obviously ZEO (using TRACE) runs on Zope 3 without zLOG so specific
extension can be handled locally.
ZEO also runs on Zopes 2.8 and 2.9 without zLOG -- zLOG hasn't been
used in ZODB since 3.2 (ZODBs 3.3, 3.4, 3.5, 3.6, and current trunk
contain no references to zLOG).
If
[Jeff Kowalczyk]
What does the twice-annual release policy say about bugs and/or packaging
errors that are identified and fixed within a very short time of the
official release announcement?
I think the answer you're looking for is that the policy says nothing
about that. Every-6-months
[Andreas Jung]
ZODB defines these levels but I can not see any code in the ZODB package
that actually uses these levels.
Nevertheless, grep'ing the ZODB source for TRACE and BLATHER will find them.
TRACE is used only in modules under ZEO/zrpc/, and gives extremely verbose
output about
[Fred Drake]
Nobody should be using the zLOG levels with the logging package, but
rather use the logging package levels. So in the end, there's no need
for Zope to be defining levels at all, only conventions for how the
levels are used.
The logging package supports defining as many
[Florent Guillaume]
Why not use the tag you just made?
ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0/src/ZODB
etc.
Ask Jim ;-)
(Hi have a vague feeling this may have been discussed before but I'm not
sure ;)).
I'm not sure it's been coherently discussed on a mailing list:
- While
[Andreas Jung]
I _like_ tags in externals because they are self-documenting. Dealing with
externals where you have several different revision numbers is a PIA since
you never know what version of a module is behind the revision. You always
have look through the log for the referenced
[EMAIL PROTECTED]
Not agree. Can you answer the question? Does self.all.remove(c) mean
that we WANT to destroy connection instance?
[Tim Peters]
It means that _ConnectionPool no longer has a reason to remember
anything about that Connection. Application code can continue
keeping it alive
Oops! I sent this to zope-dev instead of zodb-dev by mistake.
Nevertheless, if you can help Denis Markov, don't let my mistake
inhibit you ;-)
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts
[Florent Guillaume]
FYI test output is:
...
'zope[.]app[.])' is not recognized as an internal or external command,
operable program or batch file.
program finished with exit code 255
That was due to an ill-formed command line, which Jim repaired this
morning. Zope trunk and Zope 2.9 branch
[Tim Peters]
...
Failure in test test_checkPermission_proxy_roles_limit_access
(AccessControl.tests.testZopeSecurityPolicy.C_ZSPTests)
Traceback (most recent call last):
File c:\python24\lib\unittest.py, line 260, in run
testMethod()
File
C:\buildbot\.org\zc-bbwin--Windows2000
[Tim Peters]
...
That was the problem. Turns out `bbwin` does have a compiler, but the
buildbot recipe didn't use it. After Jim fixed that, we have another
Windows-specific failure, in new code from ChrisM (this is on Zope
trunk, of course):
Failure in test test_get_env
[Benji York]
The Zope2 unit tests have been failing for some time on
buildbot.zope.com. Looks like a Five-related problem:
http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/109/test/0
[Tres Seaver]
The failing test is a functional test, not a unit test; I don't run
[Tim]
I opened a Collector issue on this about a month ago (I always run
with `--all`, so these failures are old news to me):
http://www.zope.org/Collectors/Zope/1947
[Philipp]
Rereading that issue again, it's totally surprising to see that there's no
failure on
Windows, which makes
...
[Philipp]
Well, if you look closer you find that it uses pprint.pformat which
always outputs the
same on all machines (because it provides output sorted by the
dictionary key).
[Tres Seaver]
I see that in the implementation; it isn't documented as part of
pprint's contract, however.
[Tim]
Looks like Jim's suggested
from zope.testing.doctestunit import pprint
inherits this insecurity.
[Jim]
No, it doesn't.
from zope.testing.doctestunit import pprint
pprint({z: 1, m: 2})
{'m': 2,
'z': 1}
Note both the sorting and the wrapping.
See below.
Cool! I
...
[Tim]
Well, I understand why that works, but it's not part of pprint's
contract either.
[Jim]
What contract. :)
pprint's docs.
Aren't you always telling me to read the source?
Indeed, if you hadn't, you wouldn't have known that forcing width=1
forces dict sorting ;-) It's common as
[Jim]
...
The whole repository is only about 800 megs. There are over 8 gigs
free. Are the dump file or the file-based repo much larger in
size the the Berkeley database?
FYI, if you don't want to read the code ;-), the book says an FSFS
repository is slightly smaller than the same thing
[Stefan H. Holek]
make install does currently not work on 2.9 branch and trunk. I am
told that this is because zpkg cannot do it. I am also told that
the tarball would support make install, just not the checkout. I
never use tarballs, so I don't know for sure.
There's no longer any necessary
[Sidnei da Silva]
I've seen the following tests fail today, after updating Zope 2.8 branch
for all variants of BTrees:
==
ERROR: testUpdateFromPersistentMapping
(BTrees.tests.testBTrees.IIBucketTest)
[Sidnei]
I've seen the following tests fail today, after updating Zope 2.8 branch
...
Python 2.4.2 (#2, Nov 20 2005, 17:20:59)
...
BTW, I think the Official Story is that Python 2.4+ is still not supported
for Zope 2.8. I ran all the stuff in my reply with 2.4.2 too. Doesn't
matter, though
[Sidnei da Silva]
But, why only the 2.8 tests would fail then?
Hey, it's your machine, you figure it out ;-) Note that test.py in 2.8 has
little in common with the test.py in 2.9 or Zope trunk, and they may very
well react in different ways to quirks in your environment.
I'll try a 'make
[Andreas Jung, on zope-dev; Tim added zodb-dev to this msg]
I would like to consider the 2.7 branch closed for any kind of fixes except
security related fixes. I don't plan any further 2.7 releases.
In that case (which is fine by me), I'll stop porting fixes to the
ZODB 3.2 line too. No
[Chris McDonough]
Note that changing the transientobject conflict resolution algorithm
won't get rid of all write conflict errors, because the BTree-based
indexes in the transient object container will still conflict during a
bucket split and other situations that I can't exactly recall
A number of ZODB gimmicks were officially deprecated in ZODB 3.4, and
removed in ZODB 3.6. Zope 2.9 uses the latter. From the ZODB NEWS
file for 3.6:
Removal of Features Deprecated in ZODB 3.4
--
(3.6b2) ZODB 3.6 no longer contains features officially
[Jim Fulton]
...
BTW, This is a good example for why I want to start using time-based
deprecation.
In a world with time-based releases, is there a difference?
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
...
[Sidnei da Silva]
Simplifying a lot what the existing Zope 2 installer does, it
basically creates a 'software home', a default 'instance home' and
registers the services. All but the first part is done manually for
Zope 3, so I can see the lack of glow there.
There's also that Zope2
[Jens Vagelpohl]
In Zope 2.7 I'm using zeoup.py to check on a ZEO server. This script
can be run from anywhere as long as the PYTHONPATH is set correctly.
For Zope 2.8.4, the ZEO logging has been switched to use the logging
module. This leads to an error when running zeoup.py now:
[Tim Peters]
Also note that the code Florent pointed at is part of ZODB, not part
of Zope. Zope shouldn't use it directly. Growing its own copy would
be OK, or refactoring so that ZODB and Zope both get it from a shared
new mini-project.
[Chris Withers]
Sorry, which code are we talking
[Sidnei da Silva]
Just noticed a checkin talking about the Windows Installer builder. I
hope to find some time soon to take a look at that, since we now
require Python 2.4 and Python 2.4 uses the 'Microsoft Installer'. I
recall talking with Mark about it and he said it would take some time
to
...
[Tim]
| Possible headache: Python 2.4.2 requires msvcr71.dll, which is a
| Microsoft DLL (it's akin to msvcrt.dll for Visual Studio 6 -- it's the
| C runtime for VC 7.1), and one for which the redistribution conditions
| are unclear (at least to me). You can't assume that all Windows boxes
[Dennis Allison]
We probably want an ALL level as well which would map to the NOTSET
of the Python logging code and log everything.
Why not call it NOTSET? Then you already have it ;-) Or forget it --
TRACE gets everything anyway.
Florent, I don't see a TRACE level in this list. Did you
[Dennis Allison]
...
Conflict errors are not always errors.
At the ZODB level, an unresolved conflict always raises an exception.
Whether such an exception is considered to be an error isn't ZODB's
decision -- that's up to the app. My understanding (which may be
wrong) is that Zope tries up
[Tres Seaver]
test.py in the root is the likely culprit, as it is mucking with
sys.path. Does this patch make the Windows tests pass?
- --- test.py (revision 40087)
+++ test.py (working copy)
@@ -30,7 +30,7 @@
if shome:
shome = os.path.abspath(shome)
else:
- -
[Tres Seaver]
...
Which bugs? Sombebody needs to define this, or else risk having the
outsiders just walk away.
Insiders too ;-)
*I* know of no showstoppers: all unit tests are passing,
Not on Windows:
Windows test failures on Zope trunk
http://www.zope.org/Collectors/Zope/1931
[Tim]
Windows test failures on Zope trunk
http://www.zope.org/Collectors/Zope/1931
[Tres]
Without Windows-centric developers who are motivated to investigate and
fix those bugs, I don't know what else we can do.
[Mark Hammond]
That bugs points at
[Chris Withers]
ZCatalog still contains a commit(1) at around line 589 of ZCatalog.py,
which is causing the familiar 'Savepoints unsupported' error for us :-(
Would there be any problem changing this to a savepoint(optimistic=True)
on the 2.8 branch and trunk?
There shouldn't be any problem
[Chris Withers]
ZCatalog still contains a commit(1) at around line 589 of ZCatalog.py,
which is causing the familiar 'Savepoints unsupported' error for us :-(
Would there be any problem changing this to a savepoint(optimistic=True)
on the 2.8 branch and trunk?
[Tim Peters]
There shouldn't
[Tim Peters]
Jim redid the way Zope trunk stitches in Zope3 since you last looked
at this, and that can create some mechanical problems (of the kinds
you're seeing, in fact). The svn docs probably won't help.
Suggestion (which is repetition of what I suggested before this
happened, but we'll
[Chris McDonough]
This merge has been done.
Woo hoo! Thank you, Chris!
I since stitched in ZODB 3.6.0b2, which is the most recent 3.6
(internal) release. That didn't seem to create any new problems.
Since zopectl test ProductName no longer appears to do the right
thing
Sorry, never used
The bad news is that I don't think I'll ever put in enough time to
fully understand what went wrong here.
The good news is that the newly-released Zope 2.8.4 Windows installer, at
http://www.zope.org/Products/Zope/2.8.4
includes pywin32 build 205. If that doesn't fix PySECURITY_ATTRIBUTES
[Tim, trying to comfort a suffering Chris]
...
End of story. Unless you feel you need to make another branch. In
that case, still do the two steps above first. Then create a new
branch from Zope trunk, svn switch your merged sandbox to that new
branch, then svn checkin.
That last part
[Chris McDonough]
FWIW, I know a couple of people are depending on this, so here's an
update.
I am working on merging multidatabase support, but I'm having some
merge/update troubles (if you're interested in the symptoms, see
http://www.plope.com/Members/chrism/heres_to_cvs). I suspect I'll
I see two test failures today on Zope(2) trunk, WinXP, Python version
doesn't matter (same thing under 2.3.5 2.4.2).
Failure in test testRegisterTranslations
(zope.app.i18n.tests.testi18ndirectives.DirectivesTest)
Traceback (most recent call last):
File
[Mark Hammond]
FYI, there is a new pywin32 build out now that should solve this problem
without requiring any imports to be reordered.
Yay!
It would be great if whoever turns the crank for the next Zope/Windows
builds (which may even turn out to be me! :) uses build 205.
Andreas Jung made
[Chris Mattmann]
Okay, I have reproduced the error even with Zope 2.8.2-final on win32. The
same PySECURITY_ATTRIBUTES object error appears even with 2.8.2. Any
ideas?
Short of not using Plone wink, see this Collector item, which I
expect is the same issue:
[Chris McDonough]
There is a wrinkle about performing this merge that eluded my memory
until now.
To support multidatabases within Zope, it was reasonable to change
ZODB.config.ZODBDatabase to support the heretofore
likely-unused-by-real-world-code databases and database_name options
that
Chris, FYI, I stitched ZODB 3.6.0b1 into zodb-blobs-branch, and
changed ZopeDatabase.createDB() to plug database_name into config
instead of passing it to ZODBDatabase.open(). The checkin msg
summarizes test results; since I haven't work on this branch before,
I'm not sure what was expected here
[Tim Peters]
Log message for revision 39583:
Move to ZODB 3.6.0b1.
ZopeDatabase.createDB(): Plug database_name into config rather than
passing it to ZODBDatabase.open(). More should be done to detect
conflicting zodb_db section name and database_name, but I'm not
sure where all
[Chris McDonough]
Thanks for this!
Not required, so long as I get to thank you for finishing it ;-)
Looks like that test failure is incidental and not symptomatic of
changes made to ZODB. I think Tres may have said that it can be
fixed by merging in a fix from the Five HEAD, but I don't
[Tim Peters]
Note: sometimes _internals_ use deprecated gimmicks in order to
support deprecated gimmicks too, and then stacklevel=3 is too small.
It's happened so rarely in ZODB that I haven't tried to do something
about that yet.
[Chris Withers]
Interestingly, I've found that even
[Tim Peters]
I think it's worse, but mostly because a key with name name is also
an option in _related_ sections, but with unrelated meaning. For
example, if you had a nested zeoclient section there it could also
have specified a name key, which would have nothing to do with the
zodb key
[Chris McDonough]
| Note that I don't have a strong opinion about this either way but I will
note that at least Zope 2's subclass of the zodb config handler will
need to continue to be willing to use the section title as the database
name for backwards compatibility reasons, as people who have
[Tres Seaver -- I think; I'm missing context for this email]
Note that I have just figured out that we can make DeprecationWarnings
more useful by passing the 'stacklevel' argument to 'warnings.warn';
passing a value of 2 for that argument causes the warning to be reported
against the *caller*
[Tim Peters, on multidatabase support in Zope3]
...
Jim showed me the Zope3 implementation code and an example today. I
found the code easily (on Zope3 trunk), but can't for the life of me find
anything there that looks like his example. Jim, where is that?
[Jim Fulton]
Do you mean
...
[Chris McDonough]
Thanks for the offer! I won't be able to visit ZC world HQ tomorrow,
though unless you'd be there and willing to start around 10pm.
Alas, they're still under the delusion that 10 _am_ is late here, so
while I agree 10pm is saner on all counts, I'll be gone before then.
[Chris McDonough]
There is a wrinkle about performing this merge that eluded my memory
until now.
To support multidatabases within Zope, it was reasonable to change
ZODB.config.ZODBDatabase to support the heretofore
likely-unused-by-real-world-code databases and database_name options
that
[Andreas Jung]
all changes I made for the last hotfix release (patch for the reST ..
include problem) have disappeared from the SVN (both from 2.8 branch and
the trunk).
Are you sure? The SVN log on Zope trunk shows what I guess are the
relevant checkins, revs 39013 and 39014, on 2005-10-09,
[Chris McDonough]
This is already done on the zodb-blobs-branch. I would be happy to
create a mountpoint-branch that does not externally link the ZODB with
blob support, then merge the changes in to the Zope 2 HEAD (and 2.9
branch if one exists).
[Jim Fulton]
Ah, I had forgotten about that.
[Chris McDonough]
This is already done on the zodb-blobs-branch. I would be happy to
create a mountpoint-branch that does not externally link the ZODB with
blob support, then merge the changes in to the Zope 2 HEAD (and 2.9
branch if one exists).
[Jim Fulton]
Ah, I had forgotten about that.
[Tim]
I'm copying Fred because he may remember more about this than I do.
Fred, do you know of a reason why I can't stitch a newer ZODB into
Zope(2) trunk? I have a dim, fading memory of the last attempt
failing, and of agreeing in email to wait for the 5 guys to do
something before trying
[Andreas Jung]
I originally scheduled Zope 2.8.2 for October 12th but I have to delay the
release for some days (possibly one week) because of unforeseeable travel
and a lot of important work. I hope this is fine for everyone.
Works for me ;-)
Is Zope 2.7.8 also affected (2.7.8 was also
[Martijn Faassen]
The behavior of ZCTextIndex was intended to be able to index strings,
but also lists of strings.
[Tim Peters]
Note that there's a long discussion of this here:
http://www.zope.org/Collectors/Zope/1815
Entry #31(!) claimed the patch is also applied on the 2.7 branch
name
already exists.
You may also need to do svn cleanup and try again, if you don't
delete the directory before trying to update.
[Tim Peters]
If there are no sane wink objections, I'd like to move Zope trunk to
using ZODB 3.5 tomorrow (Friday). ...
This didn't happen. There's a chicken
on zodb-dev, Jim (Fulton) confirmed that it was his intent that making
a savepoint would trigger cache gc. It's a ZODB bug that it currently does
not; I'll fix that:
-Original Message-
From: [EMAIL PROTECTED] On behalf of Jim Fulton
Sent: Tuesday, August 23, 2005 2:53 PM
To: Tim Peters
Cc: zodb
[Martijn Pieters]
Did the conflict resolution code for BTrees.Length ever work? Because as
it stands now the code will fail
You haven't seen this fail, you're _deducing_ that it must fail, right?
as it assumes that integers are passed in, instead of state dictionaries:
def
[Paul Winkler]
I'm looking at the two patches that were uploaded for
http://www.zope.org/Collectors/Zope/1810 which is assigned to me... BUT:
1) Have we reached the end of the 2.7 line?
I expect that's Andreas's call now. I still plug away adding patches
to the ZODB 3.2 line (which is
As developed in a long thread starting at
http://mail.zope.org/pipermail/zope/2005-July/160433.html
there appears to be a race bug in the Microsoft Windows socket
implementation, rarely visible (but disastrously when so) when
multiple processes try to create an asyncore trigger
[Andreas Jung]
Just the usual reminder from the release management :-) Zope 2.8.1 b1
will be released next Wednesday
[Tim Peters]
Is this correct? Please confirm.
http://www.zope.org/Wikis/DevSite/Projects/Zope2.8/MilestonePlan
still says
2.8.1 b1: 2005/7/27
2.8.1 final
[Andreas Jung]
Just the usual reminder from the release management :-) Zope 2.8.1 b1 will
be released next Wednesday
Is this correct? Please confirm.
http://www.zope.org/Wikis/DevSite/Projects/Zope2.8/MilestonePlan
still says
2.8.1 b1: 2005/7/27
2.8.1 final: 2005/08/10
and
[Florent Guillaume]
How about boosting the default ZODB cache_size to something less
ridiculous than the default 4000 ?
I propose changing etc/zope.conf.skel to have an explicit value of
2.
[Dieter Maurer]
| That may already be a bit large:
We use 15.000 with 6 workers and our Zope
[Chris Withers]
O... is this surfaced through the Zope undo tab?
Try it. I'm sure that was Dieter's intent:
http://mail.zope.org/pipermail/zodb-dev/2003-October/006157.html
,,,'
The patch also enhances FileStorage and lets its UndoSearch._readnext
provide information
[Tim Peters]
Anyone else run on Windows routinely who's eager for glory? As
Christian learned the hard way, it doesn't really work if running on
Windows is an occasional afterthought in your daily life.
[Andy McKay]
Mark Hammond and I will take a look at this and see if we can help.
Cool
[yuppie]
http://svn.zope.org/?view=revrev=30334 changed the behavior of
undoInfo() in a way that is not backwards compatible.
That's true, or at least off-by-one different than recent ZODB 3.2s.
Rev 30334 fixed two bugs in the implementation, so that the behavior
matched what the documentation
[yuppie]
...
Don't know what other people think. I believe restoring the old undoInfo
behavior and adjusting the documentation would be the best solution.
Fixing this in undoable_transactions would fork the behavior of both
methods and fixing all products that depend on the old behavior would
[yuppie]
...
These are the two use cases I'm aware of. Both only use last 0 and
both expect slicing behavior for positive values, e.g. these conditions
should be True if we don't change undoable_transactions::
db.undoInfo(0, 20) == db.undoInfo(0, 99)[0:20]
db.undoInfo(20, 40) ==
[Yair Benita]
Reading this answer I understand that anything I store should be
persistent, even if its a list I don't plan to edit.
[Tim Peters]
I wouldn't say that. For example, for _most_ applications it would be
foolish to create a subclass of Persistent to store an integer, as
opposed
[Yair Benita]
... suppose I have two different classes and both contain a list of a objects
from a third class:
class x has the attribute x.elements = [objects of class z]
class y has the attribute y.elements = [objects of class z]
As far as I understand python the lists x.elements and
[Laurence Rowe]
...
Unless you use a special PersistentList ZODB will have no choice but
to store a new copy of the whole list when that list is modified.
Caution: that's true of a PersistentList too. The purpose of
PersistentList isn't realy to supply more-effecient storage (that's
the
[Yair Benita]
...
Reading this answer I understand that anything I store should be
persistent, even if its a list I don't plan to edit.
I wouldn't say that. For example, for _most_ applications it would be
foolish to create a subclass of Persistent to store an integer, as
opposed to just
[Tim Peters]
[...]
So, best guesses (please scream where I'm wrong):
- This is because service.py doesn't define a SvcShutdown method, just
a SvcStop method,
- It's a good idea to add a SvcShutdown method to service.py.
- It would suffice to add
SvcShutdown = SvcStop
1 - 100 of 284 matches
Mail list logo
