Re: [Zope3-dev] Testing ZODB in Python2.5.
[nikhil n] ZODB shows an error when tested with python2.5.(http://zope3.pastey.net/52960) I think Python 2.5 unified long and normal integer and this caused the error. This is actually due to changes in Python's `struct` module, more accidentally than not related to the ongoing int/long unification. Here's a little program: import struct x = struct.pack(Q, 42) print repr(struct.unpack(Q, x)) Under 2.4 that prints (42L,), under 2.5 (42,). ZODB's u64() is a wrapper around a similar struct.unpack() call, so inherits the same behavior. Is it enough that we add a renormalizer in testrunner.py? I think it's better to change the specific test that failed; e.g., change the u64(oid) part to int(u64(oid)) in the test, and change the expected output to match the new output, That way the test will pass under all versions of Python, without anything hidden in magical normalizers. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-Users] Re: [Zope3-dev] AssertionError in ZEO cache
[Dieter M] Almost surely, the code should be cur_tid = tid rather than cur_tid tid. But there is nobody that is sure about it. [Chris W] Well, as I've asked before, what needs to happen for someone to _become_ sure about it? Same answer as before: someone who understands the intended invariants during cache verification needs to stare at the mutually inconsistent code and comments, and figure out was intended. (or at least change it and see what happens? ;-) ) You could do that immediately :-) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 FreeBSD tmiddleton
[Christian Theune] Hah. Looks like BTrees can accept 2**31 on machines where maxint is a larger ... Note that accept in this case means silently loses the most-significant bits, and that's a BTree bug on platforms where sizeof(long) sizeof(int): http://www.zope.org/Collectors/Zope/1592 2**31 doesn't actually lose any bits when you store it, but it will probably misinterpret the high-order data bit as the sign bit when you fetch it again, magically changing it into -2**31. As we hardcoded the search space to 2**31, I made the test check whether btrees accept the number or not and differ in the expected results. Should work on that 64bit machine now too. Did you see my simpler suggestion for fixing the underlying bug (it was a one-liner change to the original code)? When you get tired of fighting the 64-bit BTree bug here (it will be a minor miracle if the test actually passes now on a 64-bit box, despite all you've tried ...), look that up ;-) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 FreeBSD tmiddleton
[Christian] thanks Tim, for the partial enlightenment. :) Unfortunately my BTree/C-wisdom is much much smaller than yours, so I got to check a couple of assumptions over here. :) Yup, it really helps if you have a 64-bit box to check them on. [Christian] Hah. Looks like BTrees can accept 2**31 on machines where maxint is a larger ... [Tim] Note that accept in this case means silently loses the most-significant bits, and that's a BTree bug on platforms where sizeof(long) sizeof(int): http://www.zope.org/Collectors/Zope/1592 I was able to reproduce this on an Intel 64-Bit machine (EM64T) running Linux and gcc. And I expect the same will happen on any 64-bit platform other than Win64 (which is unique, AFAICT, in leaving sizeof(long) == 4 instead of boosting it to 8). For one: I didn't see any compiler warnings. That sounds bad, right? The underlying BTree bug is assignments of the form (usually hidden in macro expansions): some_C_int = some_C_long; When sizeof(int) sizeof(long), that can silently lose information. I was really hoping that major compilers on boxes where sizeof(int) sizeof(long) would warn about that. Oh well. The problem arises because what _Python_ calls int is what C calls long, but the I-flavor BTree code stores C int, and C int doesn't correspond to any Python type (except by accident on 32-bit boxes). C int is 4 bytes on all known current 32- and 64-bit platforms, but the size of what Python calls int varies. The BTree code isn't aware of the possible mismatch, storing Python int (C long) into C int without any checking. 2**31 doesn't actually lose any bits when you store it, but it will probably misinterpret the high-order data bit as the sign bit when you fetch it again, magically changing it into -2**31. I can store 2**31 in the BTree, but the keys() method will tell you that it actually stored -2**31. Right. If it's not clear, this is because the _bit_ pattern 0x8000 is 2**31 when viewed as an 8-byte C long, but is -2**31 when viewed as a 4-byte C long. If you had, e.g., stored 2**32 instead, you would have gotten 0 back when you fetched it (the top 32 bits are simply thrown away). ... Did you see my simpler suggestion for fixing the underlying bug (it was a one-liner change to the original code)? When you get tired of fighting the 64-bit BTree bug here (it will be a minor miracle if the test actually passes now on a 64-bit box, despite all you've tried ...), look that up ;-) Nope, I didn't find your one-liner. :) Can you post it explicitly for my blind eyes? Here; it was a reply to one of the checkin messages: http://mail.zope.org/pipermail/checkins/2006-June/002395.html The key problem in the original intid code is that it used randint() instead of randrange(), theoretically allowing 2**31 to be a return value. It's _almost_ enough just to use randrange() instead. Unfortunately, that's not quite enough; see the msg for what is. It _could_ be fixed by adding 2 characters to the original, changing 2**31 to 2**31-2 (or to 0x7ffe), but that would leave it pretty mysterious ;-) I think I could have made up something that made it work, but I started looking into making the BTree behave sanely. My idea was, to modify the BTree code in a way that it actually checks after the type cast whether the casted value is equal to the requested key, or alternatively try making the CHECK_KEY macro do an exact type match instead of allowing subclasses. But that wouldn't work either as 2**31 is still an int on those platforms. I'm a bit puzzled now. :) There's potential silent information loss for both Ix-flavor BTree keys and xI-flavor BTree values. There are two robust ways to check (robust means that Python's C code has used these ways at various times for many years now without problems). Complain if: some_C_long INT_MIN || some_C_long INT_MAX or complain if (this sounds close to what you had in mind above, and is my favorite): (long)(int)some_C_long != some_C_long Because the problem is due to bogus assumptions about the relationship between C types, it's not going to help to examine Python's idea of type. Checking isn't needed (can't fail) if SIZEOF_INT == SIZEOF_LONG (Python.h supplies definitions for those macros), so there's some worth to skipping checks when that's not true. Unfortunately, C doesn't allow #if preprocessor statements _inside_ macro expansions, so the best way to do that isn't immediately clear. In short, irritiating little issues abound :-(. That's why I couldn't make time to fix it (relatively high cost with no benefit on most Zope platforms). Note that if ZODB moves to 64-bit Ix/xI BTrees on all boxes (IIRC, Jim and Fred were agitating in that direction, but suffered massive short-sighted ;-) opposition), the BTree problem would go away by magic (C int would no longer be the type of Ix keys or xI values). ___ Zope3-dev mailing list
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 FreeBSD tmiddleton
[Christian] Thanks for the clarification, Tim! You're welcome :-) Due to the possible future use of 64-bit BTrees, I'm inclined to go for the 2-character fix for now and possibly remove it once we hit 64-bit everywhere. The BTree bug and the intid bug are quite distinct. intid should be repaired regardless, and is easy to repair. The only reason the BTree bug got sucked into this is because an overly-elaborate way of repairing the intid bug bashed into the BTree bug (the elaborate initd fix reasonably assumed that Ix BTrees would complain if you tried to store a key they can't actually handle, but in fact they don't always complain). All the _simple_ ways of repairing intid avoid the BTree bug. In a 64-bit-everywhere world, presumably intid will want to change to use an id range substantially larger than 31 bits anyway. BTW, note that the simple intid fixes are essentially untestable, and for the same reason you can't actually write a convincing test now that _shows_ that the current (pre-patch) intid is buggy. There are only 2 return values (out of 2**31+1 current possible outcomes) that create a problem, so it's a one-in-a-billion chance of screwing up. The simple fixes just remove (exactly) those two problem cases. It's trivial to prove that the current intid has that bug, and substantially harder to prove that the 2-character fix repairs it (but trivial to prove that my original suggestion repairs it), but it's very much harder to write a test showing either the bug or its absence. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [ANN] win32-trunk-pyds
[Stephan Richter] Tim has not been updating them recently. After Jim updated the C code in the adapter lookup code, they were invalid. Adam has picked up Tim's work there. [Benji York] As of 5/1 Tim was still willing to build them (as stated in a message to zope3-dev). I don't think that's changed. If he happened to miss a change requiring a recompile, just drop him a line and I'm sure he'll update them. I'm no longer routinely building, or running, Zope3 on Windows, so I'll indeed only update Zope3 .pyds if/when someone emails me saying that's needed. And right, I'm happy to do so. If Adam is paying more attention to Zope3, and especially if has an automated way to keep his Windows Trunk zipfile release up to date, that's probably better all around. If that is the case, then I should remove the old pyd .zip files from my member page, and plant a link there to Adam's gimmick instead. Adam, do you intend to keep Trunk up to date now? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Windows Binaries
[Benji] ... However, it would seem that whomever was doing Windows releases hasn't done an installer for 3.2.1 (see http://www.zope.org/Products/Zope3), so we may need someone to do installers too. [Chris] OK, sounds like the problems got sorted. However, if anyone needs anything Windowsish and Zopeish built, just point me at a set of instructions and I'll see what I can do :-) Benji just said there's no Windows installer for 3.2.1. Looks like a true statement :-) I don't intend to build it. The instructions at: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeWindowsRelease would probably work for that (can't be sure without trying it, and since nobody does this routinely it's not impossible that some Windows-specific problem(s) got introduced between 3.2.0 and 3.2.1; for example, changes in zpkgtools sometimes forced backing off to an older revision of zpkgtools to build an older version of Zope3 or ZODB). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Windows Binaries
[Benji York] Is anyone interested in picking up the building of Windows binaries for the Zope 3 trunk? Presumably only the appropriate compiler (and time) are required. Hard to say -- are these instructions still correct, or has the Windows build process changed since this was written? http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeWindowsRelease ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Windows Binaries
[Tim] Nope. I used to build Zope3 routinely on Windows, and all I did was open WinZip and tell it to recursively suck up all the .pyd files. [Benji] Good to know. I'm still happy to do that when someone emails me saying it's needed Consider yourself emailed. :) OK, there are new Zope3 Windows .pyds at http://www.zope.org/Members/tim_one/Zope3-Py2.4-pyd.zip now. Note that these were compiled with Python 2.4.3 (last time I did this, it was Python 2.4.2). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Windows Binaries
[Egon Frerich] Thank you. Can you please do the same with python 2.5.a1 or a2? .pyds for 2.5a1 are already available from my member page. I haven't installed 2.5a2, and don't intend to, so sorry, no on that one. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 trunk and Python 2.5a2
[Fred Drake] I just tried building the Zope 3 trunk with the Python 2.5 alpha 2 that was released a few hours ago. Unfortunately, the testrunner dies in the standard library. This is probably related to changes in the optparse module; it was updated shortly before the release to the latest Optik release. I believe that ;-) The test runner worked with 2.5a1, so the problem you're seeing is definitely new in 2.5a2 (2.5a1 had other problems with Zope3, which should be fixed in 2.5a2 -- although that's hard to check if the tests won't run at all!). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 trunk and Python 2.5a2
[Fred Drake] I just tried building the Zope 3 trunk with the Python 2.5 alpha 2 that was released a few hours ago. Unfortunately, the testrunner dies in the standard library. This is probably related to changes in the optparse module; it was updated shortly before the release to the latest Optik release. I don't have time to look into it right now, but if someone does, it would be good to figure out if this is a problem in optparse, or in the way we're using it. I can fix it, but that's still a good question. In Zope3's testrunner.py, just change '--at-level', 1, to '--at-level', '1', in the default_setup_args list literal. At the end of your traceback, `val` was the integer 1, but optparse expects to be crunching a string at that point: File /home/fdrake/plat/linux/lib/python2.5/optparse.py, line 394, in _parse_num if val[:2].lower() == 0x: # hexadecimal TypeError: unsubscriptable object ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 trunk and Python 2.5a2
[Tim Peters, on getting the Zope3 testrunner to work w/ 2.5a2] In Zope3's testrunner.py, just change '--at-level', 1, to '--at-level', '1', in the default_setup_args list literal. After that, I don't know how well Zope3's test.py -v is expected to work on Windows these days. It was pretty bad here, ending with Ran 6553 tests with 19 failures and 179 errors A great many of those were repeats of: ... File C:\code\python\lib\linecache.py, line 14, in getline lines = getlines(filename, module_globals) TypeError: __patched_linecache_getlines() takes exactly 2 arguments (3 given) That's because this 2.5a2 patch changed the signature of linecache.getline, which doctest needs to know about, but zope.testing has its own doctest.py: r45248 | phillip.eby | 2006-04-10 21:07:43 -0400 (Mon, 10 Apr 2006) | 4 lines Updated the warnings, linecache, inspect, traceback, site, and doctest modules to work correctly with modules imported from zipfiles or via other PEP 302 __loader__ objects. Tests and doc updates are included. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Re: 64-bit BTrees
[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 it still works, people can use ZODB's analyze.py to figure that out. But supposing I flavors of BTrees are the only objects that exist, what follows from that? It's not clear. I can guarantee that multiunion() will run slower, because its workhorse radix sort will need 8 (instead of 4) passes. Beyond that, it requires someone to try it. I'm reminded that when the MEMS Exchange wrote Durus (a kind of ZODB lite ;-): http://www.mems-exchange.org/software/durus/ ) they left their entire BTree implementation coded in Python -- it was fast enough that way. The difference between ZODB's BTree C code pushing 4 or 8 bytes around at a time may well be insignificant overall. If done carefully, pickle sizes probably won't change: cPickle has a large number of ways to pickle integers, and picks the smallest one needed to hold an integer's actual value. Provided the internal getstate() functions are careful to avoid Python longs when possible, bigger pickles won't happen unless more than 32 bits are actually needed to hold an integer. There's also that ZODB's current I trees are badly broken on 64-bit boxes (except for Win64) in at least this way: http://collector.zope.org/Zope/1592 That problem would go away by magic. looks-like-a-case-of-measure-twice-cut-once-ly y'rs - tim ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] doctest: Get type of object
[Florian Lindner] I've tried: Failed example: homeFolder #doctest: +ELLIPSIS Expected: zope.app.file.file.File object at ... Got nothing I've also tried it without the #doctest Why do I get just nothing? That's expected if (and only if) `homeFolder` is bound to `None`. What happens if you change the line to: print homeFolder #doctest: +ELLIPSIS ? That added print at the front, and will display: None if homeFolder is in fact bound to None. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] December release post-mortem
... [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 often used newer versions than existed in Zope 3. We often needed enhacements to zope.testing at times that Zope 3 was feature frozen. We could have made a Zope 3 branch just to modify zope.testing, but that would have been a hassle for us and for Zope 3 developers. Note that the new test runner (from zope.testing) was used in ZODB long before it was used in Zope 3. I want to note that this was good for Zope3, too: as a willing early adopter of zope.testing, ZODB hit bugs and platform-dependent glitches first, and got them fixed before the larger Zope3 development community could be bit by them. Also want to note that ZRS needed to add new features to zope.testing, and ZRS doesn't include _any_ Zope code (ZRS builds on ZEO, not Zope). Having zope.testing be its own project without all the adminstrative overheads of having its own official releases made it very easy to add new code for ZRS's benefit without disturbing any of zope.testing's other users. In all, zope.testing is a poster child for the value of package development outside of a Zope tree. It's true that, to make changes in zope.testing, I needed to have a distinct checkout of zope.testing. I didn't feel that to be a burden, though. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Fwd: mail.zope.org listed in SORBES
[Stephan Richter, re: http://www.us.sorbs.net/lookup.shtml?63.240.213.173 ] can someone at Zope Corp. get us delisted? Frankly, I doubt it -- who has time to wrestle with SORBS? It's time-consuming just to find out from them why it's listed. At the end, I'd like to be a fly on the wall when someone suggests to Rob that Zope Corp open a PayPal account to send $50 to The Joey McNicol Legal Defense Fund 0.1 wink. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
[Dieter Maurer] If the backward compatibility period gets shorter, we will skip more and more releases because of the increased burden to get our applications running again... Well, every new release will remove features deprecated N releases ago, where N is presumably some constant whose value is being debated here. That will be so in steady state whether N is 1 or 10 (i.e., the value of N doesn't really matter to that): the pressure to recode (and your temptation to skip releases) is related more to the frequency of releases than to the length of the deprecation grace period. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.2.0b3 released
A Windows installer is also available now: http://www.zope.org/Products/Zope3/3.2.0b3 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux zc-buildbot
[Tim Peters, on the testRunIgnoresParentSignals failure] That's definitely the problem here, and is easy to reproduce by inserting a short time.sleep() inside os.rmtree(): Should have said shutil.rmtree(); anyway: I'll try to fix it later today if I can make time, and nobody else does first ... I did that yesterday, and ran the test hundreds of times after w/o problems. Yesterday and today, in spare moments I stitched rev 40792 of zdaemon into: Zope trunk Zope 2.9 branch Zope3 trunk Zope3 3.2 branch I _ think_ that covers all the places that need it for now. If anyone knows of another place (I have lazier plans to update ZODB ;-)), be my guest. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux zc-buildbot
[EMAIL PROTECTED] The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux zc-buildbot. [Benji York] This was the ever-popular... Error in test testRunIgnoresParentSignals (zdaemon.tests.testzdrun.ZDaemonTests) Traceback (most recent call last): File /usr/lib/python2.4/unittest.py, line 270, in run self.tearDown() File /home/buildbot/slave-zope.org/zc-buildbot--Linux--Zope3---trunk--2.4/build/src/zdaemon/tests/testzdrun.py, line 76, in tearDown self.assertEqual(self.expect, output) [...] AssertionError: '' != '\n\nError in test testRunIgnoresParentSignals [...] File /usr/lib/python2.4/shutil.py, line 162, in rmtree os.remove(fullname)\nOSError: [Errno 2] No such file or directory: '/tmp/tmp-7nmMV/testsock' Failure in testRunIgnoresParentSignals has been depressingly popular, but I don't think I've ever seen that _specific_ failure mode before. The one that was reportedly endlessly over recent months, and which Jim fixed, ended with this instead: AssertionError: spawned process failed to start in a minute I've restarted a test run on that machine to see if it fails consistently. And it doesn't. I think the new version of this test may be hiding the real problem, though: the shutil.rmtree() call is in a top-level `finally` clause, so if any exception is raised in the body of the test, then _before_ that exception is reported we get into the `finally` clause. Then if shutil.rmtree() raises an exception (as it did in the failing buildbot run), the original exception is lost. Hmm. Looks like that includes the case where the new test is trying to report the old symptom: self.assert_(is_started, spawned process failed to start in a minute) But I don't think that's what happened in this specific failure: os.rmtree(tmp) died with No such file or directory: '/tmp/tmp-7nmMV/testsock' but os.rmtree() wouldn't have _tried_ to delete 'testsock' to begin with unless os.listdir(tmp) said 'testsock' was in the temp directory. The sanest conclusion I can draw is that some other process (zdrun?) unlinked 'testsock' between the time os.rmtree() did its os.listdir() and the time os.rmtree() tried to unlink 'testsock' itself. If so, that's a new race condition in the new version of the test (the old version of the test didn't try to unlink 'testsock' -- I guess it left that to zdrun), and can trigger even if the body of the test passes. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux zc-buildbot
[Tim Peters, on the testRunIgnoresParentSignals failure] ... The sanest conclusion I can draw is that some other process (zdrun?) unlinked 'testsock' between the time os.rmtree() did its os.listdir() and the time os.rmtree() tried to unlink 'testsock' itself. If so, that's a new race condition in the new version of the test (the old version of the test didn't try to unlink 'testsock' -- I guess it left that to zdrun), and can trigger even if the body of the test passes. That's definitely the problem here, and is easy to reproduce by inserting a short time.sleep() inside os.rmtree(): zdrun.py and the test code are racing to delete 'testsock'. If the test code wins the race, no problem is visible, because zdrun suppresses the os.error it gets when it tries to delete 'testsock' itself. But if zdrun manages to delete it in the middle of the test code's call to rmtree(), we get the bogus test death the buildbot experienced. That's unlikely, but is bound to happen from time to time. I'll try to fix it later today if I can make time, and nobody else does first ... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ZRS version 2?
[Chris Withers] ... Was ZRS 2 ever implemented? Not yet, no. We still talk about it, but it hasn't burbled to the top of anyone's priority list yet. If you want to see it, buy lots of copies of ZRS 1 ;-) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Twisted Publisher and Zope 2
[Stephan Richter] ... Overall I agree with Jim on his comments. We have been extremely careful not to step on anyones toes and provide as smooth of a transition as possible. Impending releases always create panic. Embrace it as an opportunity for spreading joy ;-) We asked repeatedly for feedback/testing and all the tests are passing (including ZEO). The ZEO _tests_ set up their own asyncore mainloop. If you think about it, it has to be that way, else we couldn't run the ZEO tests from a standalone ZODB checkout. Alone the thought that ZEO depends on the server Zope is using, makes me worried about ZEO; but then Jim just figured out that there is no problem. ;-) There is a problem, but it in one sense it's shallow: it only takes a few lines of code to set up an asyncore mainloop ZEO is maximally happy with. The hard part for Jim will be figuring out where to put them ;-) The deeper problem is that ZEO _ever_ relied on someone else to set up a mainloop; Jim sent a note about that to zodb-dev today (ZEO should change to set up its own asyncore cruft). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.2.0 Beta 1 released
-- takes you two minutes [Craeg Strong] I probably have about 6 or seven major packages added to python including 4suite, pyrex, pyxml, etc. etc. all of which must be rebuilt, re-patched, retargetted, etc. hence my question. (yes, I am a Lazy Programmer...) You shouldn't need to rebuild anything when moving from one Python micro release to another (like 2.4.1 to 2.4.2) -- not even on Windows ;-) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] branched Zope 2.9
[Andreas Jung] ... There are no 2.9 related issues in the collector but I assume there a bunch of unreported issues. That the Zope trunk tests fail on Windows should be a 2.9 release issue, yes? Windows test failures on Zope trunk http://www.zope.org/Collectors/Zope/1931 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] test errors due to ascii defaultencoding assumption
[not Tim Peters; this part was written by Fredrik Lundh, and got misattributed in the reply] ... When the Unicode type was added, people disagreed on what the [default] encoding should be (ASCII, ISO-8859-1, or UTF-8), so the setdefaultencoding hook was added so we could play with it. Unfortunately, nobody got around to remove it before the release. (to me, arguing that it's a good thing that you can use a global setting to control what a+b does when a is an 8-bit string and b is a unicode string is about as silly as arguing that it would be a good thing to have a global setting for controlling what a+b does if a is an integer and b is a string. if you want to convert between different logical types (encoded data and text are different things), use an explicit conversion.) [Dieter Maurer] That would be true had Python already different types for text (unicode) and binary strings and would use these consistently. That's the plan, yes. Nowadays, life is hell without a sensible setdefaultencoding: Many isolated modules intersperse unicode in an otherwise string dominated world causing wide spread UnicodeDecodingErrors. And setdefaultencoding helps that? What, you set it to latin1 just to squash the exceptions? Br, if so. I suppose that's got a decent shot at working by accident, anyway. [Tim Peters] I'm sure sys.setdefaultencoding will vanish in a future Python release, since it wasn't intended to persist beyond initial development to begin with. [Dieter] Hopefully only after Python cleaned up the separation between text and binary strings. FWIW, I don't expect this before Python 3.0 (where by this I mean both having distinct text and binary string types, and losing setdefaultencoding()|). Otherwise, I would be forced to maintain my private Python version (with setdefaultencoding). Not that this is worth worrying about ;-), you could just stick to using Python 2.4.2 (or whichever stable version was current at the time). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] test errors due to ascii defaultencoding assumption
[Stefan Rank] Thanks for the clarification, sounds very reasonable. I'm now trying to think of my incentive for changing it in the first place, and my notes say that it was necessary to get some file operations to behave. Unfortunately I did not note which ones they were, but I think it was something like shutil.copytree() on Windows failing. The problem was that it *internally* did not deal correctly with unicode filenames, i.e. there was no way to influence it from the calling side. Then I found site.py, enabled the platform dependent default encoding, and did not give it another thought... (I think at that time it was py2.3, but if come across a repeatable test case I'll post a bug report.) That's the right thing to do. While I run on Windows, my filenames are all 7-bit ASCII, so I'll never bump into it. [Tim Peters] I'm sure sys.setdefaultencoding will vanish in a future Python release, since it wasn't intended to persist beyond initial development to begin with. [Stefan] In that case may I suggest changing the default to utf-8. ( I think it's about time this ascii thing died ;-) You may, but suggesting a Python change on a Zope list is like suggesting a Zope change on a Python list ;-) The long-term plan for Python is that Unicode will become the only string type, at which point the concept of a default encoding will become meaningless (there won't be any 8-bit strings then). Until then, since the default encoding has been ascii since it was introduced, I expect that an attempt to change the years-old default now would face strong opposition. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] test errors due to ascii defaultencoding assumption
[Stephan Richter] I am pretty sure that it is strongly discouraged to change the default encoding in site.py. Can anyone confirm this? I think based on this discouragement we always assume that noone changes their site.pp. If you're running a personal Python, and are willing to deal with all the problems it _might_ cause yourself, there's nothing wrong with changing the default encoding (or, at least, nobody from the PSF will arrest you). Anyone else shouldn't touch the default encoding, period -- the intended, industrial-strength way to deal with encodings is to use Unicode and explicit encode/decode operations. Fredrik Lundh explained the reality here: When the Unicode type was added, people disagreed on what the [default] encoding should be (ASCII, ISO-8859-1, or UTF-8), so the setdefaultencoding hook was added so we could play with it. Unfortunately, nobody got around to remove it before the release. (to me, arguing that it's a good thing that you can use a global setting to control what a+b does when a is an 8-bit string and b is a unicode string is about as silly as arguing that it would be a good thing to have a global setting for controlling what a+b does if a is an integer and b is a string. if you want to convert between different logical types (encoded data and text are different things), use an explicit conversion.) I'm sure sys.setdefaultencoding will vanish in a future Python release, since it wasn't intended to persist beyond initial development to begin with. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 trunk degenerating on Windows
[Stephan Richter] | what is the latest state of Zope 3 under Windows? Is it still totally whacked or are we semi-stable? :-) I'm happy to say that all the Zope3 tests pass on Windows again, as of last Friday. I haven't run them again since then myself, but the Windows buildbot box is also working again, and was still reporting success yesterday: http://buildbot.zope.org/ The middle column there (fred-win) is a Win2K box on Zope trunk. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Changes to zope3 windows binary installer
[Michael Haubenwallner] I have put up a page of questions regarding the installation process at http://zopewiki.org/Zope3OnWindowsInstaller to help writing down some answers and to create a Howto for windows users. [Stephan Richter] It would be much better to put such documentation on our Wiki, since it will got more exposure there. You also probably want to communicate with Tim on how to improve the situation. -1 on the last suggestion 0.1 wink. I build the Zope3 Windows installer because nobody else will do it (and if you disagree with that statement, _you_ build it from now on ;-)). I wasn't involved in creating it, and I don't even know how it works, beyond that it's a vanilla distutils-based installer. The text I put on: http://dev.zope.org/Zope3/ZopeWindowsRelease came from trial-and-error reverse-engineering, not from an intimate understanding of the Zope3-on-Windows vision. Because it's a standard distutils installer, and because distutils doesn't really aim at applications (let alone applications on Windows), there is no support for things like program groups or auto-install of Windows Services. The only hope for stuff like that is for someone to write MS-specific code to run from a post-installation script (which script distutils will run for you, if it's set up right) -- or move back to a wholly separate Windows-specific installer process (as Zope2 uses). The latter is high maintenance, and given how few Windows people contribute to Zope, unlikely to happen. The crushing advantage of a distutils-based installer is that some other project (namely, the Python project) does the hard work. I'll gladly answer any questions about what I wrote on the Wiki page above, but I can't volunteer more than that. If I did have time to work on it, I think I'd write a small InnoSetup script to install program groups (etc -- this is very hard to do correctly writing to the raw Windows API; that's why programs like InnoSetup are so popular), and run _that_ from the distutils post-install script. There would surely be lots of problems with that approach too. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Changes to zope3 windows binary installer
[Roger Ineichen] Tim, don't use InnoSetup, I won't -- but then I'm not doing anything here ;-) take a look at www.bitrock.com first. How does this relate to Michael Haubenwallner's list of specific Zope3-on-Windows issues? Here's his list: http://mail.zope.org/pipermail/zope-dev/2005-October/025439.html ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 trunk degenerating on Windows
[Michael Kerrin]
I have just changed the svn:external for Twisted to a more stable 2.1 branch
which should contain the fix for the Windows problem you reported. I still
haven't checked Zope on windows yet because of a problem in the with FTP but
I have being assured that it will run.
I will check the buildbot link you sent in the morning and see what the status
is then, fingers crossed.
The buildbot already reported successful test runs on Linux. The
buildbot Windows machine is still useless (still dying in its svn
step).
The unit tests on my Windows box are now down to three related errors:
Error in test testRead (zope.publisher.tests.test_http.HTTPInputStreamTests)
Traceback (most recent call last):
File C:\Python24\lib\unittest.py, line 260, in run
testMethod()
File C:\Code\Zope3\src\zope\publisher\tests\test_http.py, line 72,
in testRead
output += self.stream.read()
File C:\Code\Zope3\src\zope\publisher\http.py, line 192, in read
self.cacheStream.write(data)
IOError: (0, 'Error')
Error in test testReadLine (zope.publisher.tests.test_http.HTTPInputStreamTests)
Traceback (most recent call last):
File C:\Python24\lib\unittest.py, line 260, in run
testMethod()
File C:\Code\Zope3\src\zope\publisher\tests\test_http.py, line 79,
in testReadLine
output += self.stream.readline()
File C:\Code\Zope3\src\zope\publisher\http.py, line 197, in readline
self.cacheStream.write(data)
IOError: (0, 'Error')
Error in test testReadLines
(zope.publisher.tests.test_http.HTTPInputStreamTests)
Traceback (most recent call last):
File C:\Python24\lib\unittest.py, line 260, in run
testMethod()
File C:\Code\Zope3\src\zope\publisher\tests\test_http.py, line 90,
in testReadLines
output += ''.join(self.stream.readlines())
File C:\Code\Zope3\src\zope\publisher\http.py, line 202, in readlines
self.cacheStream.write(''.join(data))
IOError: (0, 'Error')
I believe these are errors in Zope3 unrelated to Twisted (although the
broken code was checked in as part of Merged the zope3-twisted-merge
branch 38950:38964). This is testRead() and the function before it:
def getCacheStreamValue(self):
self.stream.cacheStream.seek(0)
return self.stream.cacheStream.read()
def testRead(self):
output = ''
self.assertEqual(output, self.getCacheStreamValue())
output += self.stream.read(5)
self.assertEqual(output, self.getCacheStreamValue())
output += self.stream.read()
self.assertEqual(output, self.getCacheStreamValue())
self.assertEqual(data, self.getCacheStreamValue())
So the first assertEqual(), as a side effect, seeks to position 0 in
cacheStream then reads the whole thing. That part of the test passes.
Next it tries doing
self.stream.read(5)
But the implementation of stream.read is here:
def read(self, size=-1):
data = self.stream.read(size)
self.cacheStream.write(data)
return data
and, as a side effect, that _writes_ to cacheStream. This is an
illegal sequence of operations: in a file opened for update, all
behavior is undefined if a read is followed by a write (or vice versa)
without an intervening file-positioning operation (typically a
seek()).
The Windows implementation of C stdio happens to blow up in this case.
That's fine by the C standard. It's also fine by the standard if it
always returned an empty string, or the King James Bible, or wiped
Linux from the machine and silently upgraded you to Windows wink. I
think I know how to fix it, so enough for now.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope3 trunk degenerating on Windows
[Tim Peters] I'll attach a (long) list of current errors. Most seem related to twisted, and may ultimately stem from that there is no fcntl module on Windows. Still true. The buildbot hasn't been of any help here, since the Windows box has failed during its initial svn step non-stop since last Friday: http://buildbot.zope.org/ where every run on Windows 2000 fred-win dies in its checkout step with Failure: exceptions.AttributeError: ShellCommand instance has no attribute 'commandFailed' Still true. The Failure in test doctest_RecordingProtocol (zope.app.recorder.tests) looks unrelated to twisted; I'll take a look. I fixed that one. The profiling.txt failure is (still) due to using a Windows-buggy snapshot of zope.testing. And I fixed that one. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux tlotze
The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux tlotze. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 654 Blamelist: andreasjung,dominikhuber,helmutm,mkerrin,oestermeier,rogerineichen,tim_one,tziade BUILD FAILED: failed svn Logs are attached. That one was mine (tim_one). Should be OK now. Also replaced the zip file of precompiled .pyd files for the Windows build. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope3 HEAD test failures on Windows
I just noticed that the tests are failing on Zope3 HEAD on Windows, when run with Python 2.4.2: File C:\Code\Zope3\src\zope\testing\profiling.txt, line 35, in profiling.txt Failed example: testrunner.run(defaults) Exception raised: Traceback (most recent call last): File C:\Code\Zope3\src\zope\testing\doctest.py, line 1256, in __run compileflags, 1) in test.globs File doctest profiling.txt[8], line 1, in ? testrunner.run(defaults) File C:\Code\Zope3\src\zope\testing\testrunner.py, line 186, in run os.unlink(file_name) OSError: [Errno 13] Permission denied: 'tests_profile.zn490l.prof' This is because Zope3 is using a tag for zope.testing that baked in some Windows-specific bugs. Moving to a more recent version of zope.testing would fix it (I fixed these things in zope.testing yesterday). Note that it doesn't show up under Python 2.4.1 or 2.4.0, because the test runner takes a different path wrt profiling then. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope] Zope 3.1.0 released!
http://zope.org/Products/Zope3/ [Reinoud van Leeuwen] Is it intended that one should login before being able to access that page? Not intended, and logging in may not help either. Try it with and without the trailing slash: http://zope.org/Products/Zope3/ or http://zope.org/Products/Zope3 At the moment, the latter works for me but the former doesn't. During the time I was uploading the Windows installers for 3.1.0 (within the last hour), it's possible that login was _required_ before the UI let me publish them. Sometimes Software Release pages get into that state, refusing to let anonymous visitors view them so long as any private items remain. That's not a possible factor anymore (all items on the page are published now). During the upload process, I had the same ongoing problems with getting back login is required pages at seemingly random times despite that I was logged in the whole time. Chopping or adding a trailing slash often worms around that, and whether or not you're logged in. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.1.0 released!
[Stephan Richter] http://zope.org/Products/Zope3/ [Jim Fulton] This URL is incorrect. The correct URL is: http://zope.org/Products/Zope3 (no trailing slash) [Stephan] Both should work. Because if you click via the Webpage links, you get the slash. [Jim] Yes, they should work. Unfortunately, they don't. So is there a reason for saying that the version without the trailing slash is correct and that the other is incorrect stronger than that you tried both, and observed that one worked for you while the other didn't? I ask because we've seen this before. Unless something relevant on zope.org has changed, which of the two forms works depends both on who tries it and when they try it. We've also seen cases where neither form works for a given person at a given time. If that's still the case, then it can help for a person to try both, but doesn't help to keep banging on just one because someone else said it worked for them. BTW, the Wiki link to 3.1.0 doesn't resolve at http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Downloads I mean this part near the top: Latest Releases stable: [Zope-3.1.0]? and ZopeX3-3.0.1 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A Call for Slaves
[Tim Peters, on MS compilers] As a result, nobody uses Standard editions for serious development. The lowest (cheapest) level at which they include an optimizing compiler is usually named the Professional edition. [Chris Withers] Urg, can you provide just a link to a product name for the 6.0 and 7.0 versions? Sorry, I don't have spare time to search for you. FWIW, these are the names on the boxes I have: Microsoft Visual C++ 6.0 Professional Edition Microsoft Visual Studio.net Professional The name of the latter _may_ have changed to Visual Studio .NET 2003 Professional Special Edition since then (I guess to distinguish it from the upcoming Visual Studio 2005, which is still in beta). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A Call for Slaves
[Chris Withers] So, are these two what I'm after for 6 and 7 respectively? http://www.amazon.co.uk/exec/obidos/ASIN/B4U6ZC/qid=1127557337/sr=1-4/ref=sr_1_3_4/026-8900047-5040402 http://www.amazon.co.uk/exec/obidos/ASIN/B89GKV/qid=1127557337/sr=2-1/ref=sr_2_3_1/026-8900047-5040402 Sorry, I don't think so. It's confusing: MS has changed the names of these things since I got mine. Your links above point to Standard editions. At least the second link has text explaining why that's unsuitable: This is the Standard edition, which is primarily intended for learning. Although it has all you need to create both Windows and Web applications, the compiler is non-optimising. Professional developers should consider Visual Studio.NET Professional Edition 2003, which includes a more advanced version of Visual C++ ... As a result, nobody uses Standard editions for serious development. The lowest (cheapest) level at which they include an optimizing compiler is usually named the Professional edition. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Functional tests failing on Windows
[Tim Peters] Something that worked was to delete every file reachable from zopeskel/ that wasn't under SVN control, and start over. Maybe that's what the Makefile's `clean` target does (in part): rm -f zopeskel/etc/package-includes/*.zcml [Fred Drake] Yes, that's exactly what you need to do. We can probably make that even more automatic for the Unix user, but don't know about the Windows world. Well, I added a new Windows script (wclean.bat), which does on cmd.exe systems what the current make clean does on Linux. The obvious place to put something both automatic and x-platform is in setup.py (since that's what everyone uses to compile a checkout ...). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Functional tests failing on Windows
A release candidate for Python 2.4.2 is getting made, and I thought
I'd try it against current Zope3 trunk. The functional tests flopped,
but turns out the same thing happens with Python 2.3.5 today.
The long traceback is attached. The bottom line is
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File
C:\Code\Zope3\ftesting.zcml, line 12.2-12.63
ZopeXMLConfigurationError: File
C:\Code\Zope3\zopeskel\etc\package-includes\zope.app.pagelet-meta.zcml,
line 1.0-1.55
ConfigurationError: ('Invalid value for', 'package', 'ImportError:
Module zope.app has no global pagelet')
I did do the
setup.py build_ext -i install_data --install-dir .
bit first. I don't see this failure at http://buildbot.zope.org/.
So it's either a bug specific to my Windows box, or it's both a bug in
Zope3 _and_ a bug showing that the buildbot isn't triggering when
relevant changes get made. I doubt it's specific to my Windows box
;-)
C:\Code\Zope3\python23\python.exe test.py -vf
Configuration file found.
Running FUNCTIONAL tests at level 1
Running FUNCTIONAL tests from C:\Code\Zope3
Parsing ftesting.zcml
Traceback (most recent call last):
File test.py, line 27, in ?
zope.app.testing.test.process_args()
File C:\Code\Zope3\src\zope\app\testing\test.py, line 1170, in process_args
bad = main(MODULE_FILTERS, TEST_FILTERS, LIBDIR)
File C:\Code\Zope3\src\zope\app\testing\test.py, line 815, in main
FunctionalTestSetup(config_file)
File C:\Code\Zope3\src\zope\app\testing\functional.py, line 138, in __init__
self.app = Debugger(self.db, config_file)
File C:\Code\Zope3\src\zope\app\debug\debug.py, line 35, in __init__
config(config_file)
File C:\Code\Zope3\src\zope\app\appsetup\appsetup.py, line 52, in config
context = xmlconfig.file(file, execute=execute)
File C:\Code\Zope3\src\zope\configuration\xmlconfig.py, line 553, in file
include(context, name, package)
File C:\Code\Zope3\src\zope\configuration\xmlconfig.py, line 489, in include
processxmlfile(f, context)
File C:\Code\Zope3\src\zope\configuration\xmlconfig.py, line 344, in
processxmlfile
parser.parse(src)
File C:\python23\lib\xml\sax\expatreader.py, line 107, in parse
xmlreader.IncrementalParser.parse(self, source)
File C:\python23\lib\xml\sax\xmlreader.py, line 123, in parse
self.feed(buffer)
File C:\python23\lib\xml\sax\expatreader.py, line 207, in feed
self._parser.Parse(data, isFinal)
File C:\python23\lib\xml\sax\expatreader.py, line 348, in end_element_ns
self._cont_handler.endElementNS(pair, None)
File C:\Code\Zope3\src\zope\configuration\xmlconfig.py, line 325, in
endElementNS
self.context.end()
File C:\Code\Zope3\src\zope\configuration\config.py, line 553, in end
self.stack.pop().finish()
File C:\Code\Zope3\src\zope\configuration\config.py, line 699, in finish
actions = self.handler(context, **args)
File C:\Code\Zope3\src\zope\configuration\xmlconfig.py, line 489, in include
processxmlfile(f, context)
File C:\Code\Zope3\src\zope\configuration\xmlconfig.py, line 344, in
processxmlfile
parser.parse(src)
File C:\python23\lib\xml\sax\expatreader.py, line 107, in parse
xmlreader.IncrementalParser.parse(self, source)
File C:\python23\lib\xml\sax\xmlreader.py, line 123, in parse
self.feed(buffer)
File C:\python23\lib\xml\sax\expatreader.py, line 207, in feed
self._parser.Parse(data, isFinal)
File C:\python23\lib\xml\sax\expatreader.py, line 348, in end_element_ns
self._cont_handler.endElementNS(pair, None)
File C:\Code\Zope3\src\zope\configuration\xmlconfig.py, line 325, in
endElementNS
self.context.end()
File C:\Code\Zope3\src\zope\configuration\config.py, line 553, in end
self.stack.pop().finish()
File C:\Code\Zope3\src\zope\configuration\config.py, line 698, in finish
args = toargs(context, *self.argdata)
File C:\Code\Zope3\src\zope\configuration\config.py, line 1390, in toargs
args[str(name)] = field.fromUnicode(s)
File C:\Code\Zope3\src\zope\configuration\fields.py, line 141, in
fromUnicode
raise schema.ValidationError(v)
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File
C:\Code\Zope3\ftesting.zcml, line 12.2-12.63
ZopeXMLConfigurationError: File
C:\Code\Zope3\zopeskel\etc\package-includes\zope.app.pagelet-meta.zcml, line
1.0-1.55
ConfigurationError: ('Invalid value for', 'package', 'ImportError: Module
zope.app has no global pagelet')
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Functional tests failing on Windows
[Benji York] I think it's because your existing instance has the ZCML slug for pagelets in your package-includes directory. Remove and rebuild your instance (which is what buildbot does) and I bet it'll work. It's funny how much that resembles English ;-) I'm quite sure I've never removed or rebuilt my instance knowingly before, and I'm not sure what it means. Something that worked was to delete every file reachable from zopeskel/ that wasn't under SVN control, and start over. Maybe that's what the Makefile's `clean` target does (in part): rm -f zopeskel/etc/package-includes/*.zcml Anyway, the Zope3 tests pass on Windows w/ the Python 2.4.2 candidate code. If someone wants to try this on Linux, the code is on Python CVS's release24-maint branch. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A Call for Slaves
[Chris Withers] Oh, sorry, I meant how do you select the right version of VC++? You don't; distutils does; if you use a Python 2.3 on Windows, its distutils will use VC6 to compile C extensions; if you use a Python 2.4 on Windows, its distutils will use VC7. It's all driven by which Python you use to run setup.py. and how do you install both VC 6 and VC 7 at the same time? Just run their installers. They don't interfere with each other (well, not unless you do something bizarre, like force the installers to use the same installation directory -- accept the defaults and there's no problem). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A Call for Slaves
[Tim Peters] BTW, Microsoft no longer sells VC6. [Chris Withers] Indeed, this was my understanding... Nevertheless, does anyone know how to legally get hold of these? (Hmmm... I work in amoungst a horde of MS developers here, maybe one of them will know...) Go to http://www.google.com and enter visual studio 6 in the search box. Pay attention to the text ads you get back after you hit ENTER. Also, how can I build both 2.3 and 2.4 stuff on one machine? I do this routinely on my boxes, but I don't know anything about the build-bot environment (which would have to be strange indeed to prevent building 2.3 and 2.4 versions on the same box). Well, how would I do it manually? How would you do what manually? Install all the versions of Python you care about on Windows, and build Zope using the version of Python you want to test with. For example, \Python23\python setup.py build_ext -i install_data --install-dir . \Python23\python test.py -v from the root of a Zope3 checkout, to test Zope3 with Python 2.3.5, assuming you installed the latest release in the Python 2.3 line and accepted the default installation directory. Use the path to a different Python if you want to use a different Python. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A Call for Slaves
... [Chris Withers] Where do I get either of those versions of VC++ from? [Benji York] You can purchase them wherever fine Microsoft products are sold. Or you can fetch the compiled .pyds from my member page, as the current Windows build-bot slaves do (see the wget PYDs log and unzip PYDs log steps from the Windows 2000 fred-win column at http://buildbot.zope.org/). BTW, Microsoft no longer sells VC6. Also, how can I build both 2.3 and 2.4 stuff on one machine? I do this routinely on my boxes, but I don't know anything about the build-bot environment (which would have to be strange indeed to prevent building 2.3 and 2.4 versions on the same box). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 and ZEO
[Uwe Oestermeier] I dedected another problem: bin/runzeo doesn't start ZEO. This script calls ZEO/runzeo.py which has a main function but no if __name__ == __main__ : main() at the end. There are two instances of runzeo, one in Zope3's bin/ directory (at least in a Zope3 checkout), and another in the bin/ directory of a ZEO instance created by mkzeoinstance. The first one worked, so I figure you're talking about the second one here (which indeed did not work). There are also two instances of zeoctl (in the same two bin/ directories as above), and turns out neither of those worked. Has this already been fixed in the mentioned internal branch? Fred and I fixed the one broken runzeo instance, and both broken zeoctl instances, yesterday. These fixes are in current Zope3 trunk and 3.1 branch. Thanks for trying this! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Failing test, Zope3 trunk, Windows
[Gary Poster] This is probably what we will need to do, but since the failing tests were bogus to begin with it may be a case of incremental improvement. This is definitely a problem, though, that we should resolve one way or another. It's also worth noting that the i18n code currently relies on the localization database for much of their timezone information AFAIK. The error could be there too, even though it was Stuart's checkin that triggered this failure in a bogus test. Dunno. Sigh. Well, src/pytz/zoneinfo/EST.py contains the minus 5 hours and 20 minutes (-19200 seconds) offset the test is actually returning: _utc_transition_times = [ d(1,1,1,0,0,0), d(1908,4,22,5,19,36), ] _transition_info = [ i(-19200,0,'CMT'), i(-18000,0,'EST'), I don't know how to read this data. A zone named CMT doesn't make sense to me in a file named EST.py. -18000 is the correct offset for current EST rules, and don't know either why it's apparently using the -19200 thingie instead. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/schema/interfaces.py - add IIterableChoice and note the desire to depricate vocabularies
[Fred Drake, on returning sys.maxint from __len__ if you don't know the length, which Tim strongly advises against] Interesting. I seem to remember this coming from Guido several times in discussions. Not me. Googling on site:mail.python.org maxint __len__ guido finds 9 hits, all irrelevant. There's no instance of returning sys.maxint from a __len__ method in the Python codebase; there are instances of returning small constants. The Python community needs to settle on a recommendation for this and document it in the Language Reference. If you don't/can't know the length, return a typical size, or leave __len__() undefined (in which latter case CPython will usually guess 8). As the code example I gave before showed, returning sys.maxint creates needless problems. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope3-dev Digest, Vol 25, Issue 37
[Benji York] ... We're drifting fatally off topic here, but: Just as there are some statements that cannot be expressed as dyadic predicates, are there also those which cannot be expressed as triadic predicates? John gives a book to Mary in exchange for 5 euros If you store the relations John gives a book to Mary and Mary gives 5 euros to John how will you know that the 5 euros were payment for the book? Worse, this happened on a Sunday, in Brussels, while winds were gusting from the south, and a nearby solicitor wearing a lime green bowler hat advised them that their transaction was exempt from VAT ;-) Even allowing relations of arbitrary arity, there are some kinds of knowledge that can't be expressed in full-blown first-order logic. For example, Google will find lots of (mostly tedious wink) discussion of the Geach-Kaplan sentence: Some critics admire only one another. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] strange assertion error
[Arthur (ccube) [EMAIL PROTECTED]] ... Is it true we shouldn't run tests as root? if so, why? Because you should never run anything as root unless you have to. root has enormous privileges most things don't need, so running arbitrary programs as root opens massive security holes. One of Zope's zdaemon tests in particular doesn't get the restricted permissions it tests for if you run as root, so that test fails if you do run as root. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.1.0c1
[Antonio Beamud Montero] I have downloaded and when I've make a check: . Failure in test testUmask (zdaemon.tests.testzdrun.ZDaemonTests) Traceback (most recent call last): File /home/antonio/src/noarch/zope/Zope-3.1.0c1/build/lib.linux-i686-2.3/zdaemon/tests/testzdrun.py, line 260, in testUmask self.assert_(not os.access(path, os.W_OK)) File /usr/lib/python2.3/unittest.py, line 278, in failUnless if not expr: raise self.failureException, msg AssertionError I'm using a Debian sarge with kernel 2.6.8.1, python 2.3.5. Are you running tests as root? If so, do not run tests as root, neither run Zope as root. If you're not running tests as root, then you're seeing a problem nobody else has seen before. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] unittest failure in svn trunk
[Wichert Akkerman] | I just noticed a unittest error on the current svn trunk: Failure in test testRunIgnoresParentSignals (zdaemon.tests.testzdrun.ZDaemonTests) Traceback (most recent call last): File /local/sources/svn/zope/Zope3/src/zdaemon/tests/testzdrun.py, line 237, in testRunIgnoresParentSignals self.assert_(is_started, spawned process failed to start in a minute) File /usr/lib/python2.3/unittest.py, line 278, in failUnless if not expr: raise self.failureException, msg AssertionError: spawned process failed to start in a minute [Stephan Richter] I always ignore this one ;-) Implying that you also see it fail in current trunk? There are no collector issues open against this; I never see it (but I usually run on Windows, where this test doesn't run at all); and it hasn't failed in the overnight testrunner reports for well over a month (not since I changed this test to wait for a freaking minute for the process to start). [Wichert Akkerman] If it is something to be ignored shouldn't be disabled? Having a known failure in the unittests is kind of bad. See above. Does it fail often for you (or for Stephan)? If so, someone on a platform where it fails needs to investigate why. It certainly isn't failing for everyone. Could this issue be relevant? http://www.zope.org/Collectors/Zope3-dev/430 Note that I'm just trying to help this along here -- nobody identifiable is in charge of zdaemon, so fixing zdaemon problems has to be a community effort. Hmm. The overnight testrunner reports don't try Zope3, just assorted flavors of Zope 2. Zope and Zope3 trunks both stitch in svn://svn.zope.org/repos/main/zdaemon/tags/zdaemon-1.1 so that's not the problem. Maybe something else is unique to Zope3. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Fixing Windows bugs in asyncore trigger code
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 simultaneously. Unfortunately, the relevant code appears to have originated in Medusa, and then got copy/paste'd all over creation. ZEO's copy is in ZEO/zrpc/trigger.py, and I've fixed it for ZODBs 3.2.10, 3.4.1 and 3.5. Zope-2_7-branch is using a 3.2.10 pre-release now, but no other version of Zope has stitched in a repaired ZODB yet. The original Medusa code appears to be in lib/python/ZServer/medusa/thread/select_trigger.py I've repaired that in CVS Zope-2_7-branch, and am in the process of repairing the same file in SVN Zope trunk and SVN Zope 2.8 branch. SVN Zope trunk and Zope 2.8 branch appear to inherit yet a 3rd copy of this code, in their lib/python/zope/server/trigger.py which appears to come from an older Zope3 snapshot. Zope3 trunk does not appear to contain any Medusa code (at least not under that name), but does contain zope/server/trigger.py which appears more to be a copy of an older version of ZEO's trigger.py than of Medusa's select_trigger.py. The short course here is that I'm repairing all but only the copies of this code that do _not_ appear in anybody's zope/server/trigger.py That file appears to have been introduced in Zope3, and I've lost track of which branches of Zope3 are still active now. I'll open a Zope3 collector issue on this, and will be happy to help repair it, but because I spend most of my Zope time trying to help Zopes 2.7 and 2.8 along, those are the only Zope versions where I'm confident about changing the right stuff in the right places. I'll repair Zope3 trunk's zope/server/trigger.py unless someone can tell me it's no longer used, but someone else will have to port that change to the still-active Zope3 branches (including the one(s) used by Zope 2.8 and Zope trunk). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re[4]: [Zope3-dev] ServerControlForm.html / Restart, Shutdown does not work
[Tim Peters] ... Best guess is that the stuff above never worked in Zope3, and that's the meaning of the TODO: ... does not work yet comments in zope/app/server/servercontrol.py. [Adam Groszer] Yes, you're right. I just missed my old buddy, the Shutdown function. I think the functions were designed with a daemonic Zope in mind, but that won't on win32. Running Zope as a Windows Service plays that role on win32, and over the last year Mark Hammond contributed code intending to make Zope2 run cleanly as a Windows service. AFAIK, though, none of that code made its way into Zope3. I think it is still a better way to stop Zope3, than simply closing the command window in which it is running (ouch, that hurts). Yes, it is better. The way it's shutting down now (using the button) at least allows the C runtime libraries to flush and close files, just by virtue of allowing Python (which is a C program) to exit cleanly. What do you say, can there be any data loss if I use the Shutdown button? Does Zope write everything out to disc before it quits? It didn't look to me like there's any code in Zope3 now supporting controlled (graceful) shutdown, although this is the first time I looked at Zope3's shutdown code and may have missed something. There's elaborate (probably _overly_ elaborate) code in Zope2 trying to do controlled shutdown. Or, a better question: how to stop Zope3 cleanly (and when possible quickly, for development sessions)? Sorry, no idea here. Anyone else? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] How to shutdown Zope3 gracefully?
[Adam Groszer] Or, a better question: how to stop Zope3 cleanly (and when possible quickly, for development sessions)? [Tim Peters] Sorry, no idea here. Anyone else? [Benji York] Control-C. Adam is running on Windows. Bring up Zope3 from a DOS box, and after it's running hit Ctrl+C in the DOS box. Nothing visible happens, and the Python process keeps running, for up to 30 seconds. Unsure why. Probably because it's sitting in a select() with a 30-second timeout, and Ctrl+C doesn't interrupt that on Windows. Ctrl+Break stops it instantly, but then the C libraries don't get a chance to clean up (like Unix kill -9). The Windows Service shutdown code in Zope3 also does a very hard kill (a Win32 TerminateProcess()). Mark Hammond tried to fix the Windows Service shutdown code in Zope2, and improve Windows Ctrl+C handling, but Zope3 doesn't have his new stuff. As I said above, there is no danger of corrupting data in a stock install. There *is* the possibility of having on-going interactions with external systems that need some sort of shutdown (eg. relational databases, etc). In that case I would recommend the Python standard library module atexit. In summary: It might be nice if Z3 closed file handles and waited for outstanding requests to be handled, but the current shutdown story is perfectly safe. Well, the Z3 Windows Service shutdown code isn't wholly safe, ditto Ctrl+Break, and Ctrl+C has surprising behavior. This: from zope.app import zapi from zope.app.applicationcontrol.interfaces import IServerControl control = zapi.getUtility(IServerControl) control.shutdown(0) appears to be the same thing the Z3 Shutdown server button does, and at least lets Python exit cleanly. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] How to shutdown Zope3 gracefully?
[Tim Peters] Ctrl+Break stops it instantly, but then the C libraries don't get a chance to clean up (like Unix kill -9). The Windows Service shutdown code in Zope3 also does a very hard kill (a Win32 TerminateProcess()). [Benji York] All very true. I think you'll also agree that it doesn't pose any particular danger during development. Yes. ... Well, the Z3 Windows Service shutdown code isn't wholly safe, ditto Ctrl+Break If you're referring to the fact that Python's shutdown code (including calling atexit registered functions) don't get run in those instances, then I would agree that it isn't wholly safe. In part I was, but not mostly: the C runtime libraries don't get a chance to clean up either. In particular, it doesn't help that FileStorage writes each transaction to disk if the data is actually just sitting in some internal C library I/O buffer and the C library doesn't get a chance to flush internal buffers at shutdown time. FileStorage does a sync() call on the file descriptor after each transaction to try to minimize the chance of problems like that, but the effect of sync() doesn't seem well-defined on Windows. I'd also say that it isn't very smart to do that in a production environment, but we're talking about development, and I don't see a problem there (and haven't yet, as that's how I always shut down Zope 3 on Windows) What is? Ctrl-C, Ctrl-Break, or pulling the power cord wink? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] possible bug in catalog code
[Dieter Maurer] Restrictions are fine when they are either * enforced (I know BTrees do not enforce the no mixed key types restriction) * clearly documented I do not know whether the ZODB 3.4 BTrees interfaces document the restriction (this would be a good place, I think) Hopefully, they do ;-) No, they don't. Patches accepted 0.5 wink. There are many ways to get in trouble with BTrees (mixing key types is just one), and the ZODB Programming Guide has pages of discussion of potential pitfalls (including mixing key types) already: http://www.zope.org/Wikis/ZODB/FrontPage/guide/node6.html (and a copy of that in PDF format is shipped in every ZODB release). I don't think mixing key types is, e.g., more important than the other ways to create an insane BTree, and I don't think pages of discussion fit sanely in interface docstrings either. This is something that belongs in documentation. Since it already is covered in the only official ZODB docs, I'm not inclined to do more than that. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3 left in the dust wink
Fred Drake created a new ZConfig release, with new internet/socket
address types to overcome a longstanding Windows hangup in Zope 2.8.
He also stitched the new ZConfig into the Zope trunk. I stitched the
same thing into ZODB 3.4, and changed ZODB/ZEO to use the new address
types where appropriate.
As a result, Zope3 trunk can't use ZODB 3.4b1 (I tried -- doesn't
work) before someone stitches the new ZConfig release into Zope3. I'm
willing to if nobody else is. Ideal would be someone familar with the
uses of the ZConfig socket-address and internet-address types
currently in Zope3 code (they'll still work, but most could/should
become the more specific
{socket,internet}-{binding,connection}-address).
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] changes in persistent
[E. Frerich] do we need new .pyd-files? I don't know. Are you having problems that make you suspect you need new .pyd files? I haven't had time lately to pay much attention to Zope3. The recent changes in the package ``persistent`` were all in Python code, so no, _those_ changes don't require new .pyds. If you're having problems with Zope3's C code on Windows, tell me and I'll build new .pyds. Otherwise I'd rather spare myself the time it takes to do that. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Changes to transaction management API
[Garrett Smith] Recent changes to the transaction management API seem to have come out of the blue and without warning. Perhaps I missed an announcement. Are we to expect breakages of this sort on occasion? [Jim Fulton] Was there breakage? If there was, it was unintended. [Garrett] IDataManager was completely restructured. It might help (a lot) if you could be more specific, even about what recent means (in recent changes). The only massive restructuring I know about took place at the ZODB sprint, but I assumed you didn't mean that since it happened a month ago. A new beforeCommitHook method was added a week ago, after discussion agreement on zodb-dev (maybe that's part of this? ZODB changes generally don't get discussed first on lists other than zodb-dev). Then Jim I made many changes Wednesday, but they were mostly docstring rewrites, plus what should have been _mostly_ semantically neutral minor refactoring (IRollback got tossed then, which was not neutral). Anyone plugging into the transaction management facility will be broken by these changed. Were _you_ burned in some specific way? I'm not sure what plugging into the transaction management facility means, concretely, but it was sure easy to update all of the Zope (2.8) and Zope3 trunks to live happily with the entire last month of transaction interface changes (two spots got tripped up by the unimplemented IRollback vanishing -- that's it). For the most part, even ZODB itself still doesn't claim to implement its own small (but growing) collection of interfaces. If you don't have specific breakage to report, then I'm afraid I'm not going to take a lesson from this, cuz I just don't know what you mean here. As a pragmatic matter, I'd avoid even importing the interfaces defined in ZODB, because they're still so inadequate and crude (as above, even ZODB mostly ignores them now). ZODB was a very late starter in the interface game, and there's not enough resource to play intense interface catchup in that project -- this gets poked at in slow motion, by forcing it briefly from time to time at the expense of more urgent ZODB tasks. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
