Re: [Zope-dev] misterious btree issue

2008-11-06 Thread Tim Peters
[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


http://svn.zope.org/ZODB/trunk/src/BTrees/Development.txt?rev=85198view=markup

...
+ When a key is deleted, it's physically removed from the bucket
it's in, but
  this doesn't propagate back up the tree: since keys in interior nodes only
  serve to guide searches, it's OK-- and saves time --to leave
stale keys in
  interior nodes.
...

 If this is the case, we can definitely fix it.

Right, just delete that paragraph ;-)
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] difference between OOSet and OOTreeSet?

2007-03-01 Thread Tim Peters

[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:

http://wiki.zope.org/ZODB/guide/node6.html#SECTION00063


They seem to have different interfaces


?


and yet seem to be used in
similar circumstances in PluginIndexes/common/UnIndex.py...

I'm looking for a set-like data structure which will likely get pretty
large over time and so I don't want the whole data structure written to
disk each time I add a new item to the set.

What should I be using?


OOTreeSet.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Maintainer of Zope 2 Windows builds?

2006-10-09 Thread Tim Peters

[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 be, but it /is/ related ;-)  I had job-related
reasons before to make at least minimal ongoing efforts toward keeping the
Zope test suites happy on Windows, and that in turn meant I kept many full
checkouts of various Zopes current, at least ran the tests routinely, gave
real attention to discussions of possible Windows glitches, built Windows
installers routinely, and so on.

But I don't do anything related to web development anymore, and bit rot is
setting in wrt my once-encyclopedic knowledge of the umpteen quirky build
procedures for the umpteen versions of Windows Zope.  When, months ago,
someone else volunteered to take over the Zope3 Windows builds, and actually
followed up on it (yay!), I mentally resigned from these tasks.

You (ZC, ZF, the community) want someone who /uses/ Zope on Windows to make
Windows releases.  It was at best half nuts that I kept doing it after
building  testing an installer once each N weeks became my only contact
with Zope.


I built the last couple of Zope 2.9.x release, but my access to a
Windows build environment is gone now...



Odd. I believe Tim built 2.9.4 because you could not?


I don't remember, but it's possible.  I'm still willing to build an
installer when there's no alternative, but it's long past time that was
treated as a last-ditch fallback instead of business as usual.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] ZODB install time error

2006-08-16 Thread Tim Peters

[P. Nagaraj]

[ZODB3-3.4.0]# python test.py
Running tests from build/lib.linux-i686-2.3
Running unit tests:


Error in test testUmask (zdaemon.tests.testzdrun.ZDaemonTests)
Traceback (most recent call last):
  File build/lib.linux-i686-2.3/zdaemon/tests/testzdrun.py, line

75, in tearDown

self.assertEqual(self.expect, output)
  File /var/tmp/python2.3-2.3.5-root/usr/lib/python2.3/unittest.py,

line 302, in failUnlessEqual

raise self.failureException, \
AssertionError: '' != '\n\nFailure in test testUmask
(zdaemon.tests.testzdrun.ZDaemonTests)\nTraceback (most recent call
last):\n  File build/lib.linux-i686-2.3/zdaemon/tests/testzdrun.py, line
260, in testUmask\nself.assert_(not os.access(path, os.W_OK))\n  File
/var/tmp/python2.3-2.3.5-root/usr/lib/python2.3/unittest.py, line 278,
in failUnless\nif not expr: raise self.failureException,
msg\nAssertionError\n\n'


[Dieter Maurer]

I think you can ignore this failure in the testUmask test
of zdaemon. Almost surely, you will not need this feature.

For me, the above looks like a broken test (at least I have
problems to decode the 'AssertionError').


The test asks zdaemon to run the `touch` command with umask 666.
Therefore nobody (except root) should have write access to the file
`touch` creates.  The failing

   self.assert_(not os.access(path, os.W_OK))

asserts that write access is in fact not allowed.

But note the except root in the above:  if someone is running as
root, there's no chance this can work.  More recent versions of
zdaemon start the test with this check:

   if os.getuid() == 0 :
   self.fail(
I am root!
Do not run the tests as root.
Testing proper umask handling cannot be done as root.
Furthermore, it is not a good idea and strongly discouraged to run zope, the
build system (configure, make) or the tests as root.
In general do not run anything as root unless absolutely necessary.
 )

Good advice :-)
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )


[Zope-Checkins] SVN: Zope/tags/2-8-8/inst/WinBuilders/mk/ Checking into a tag is evil, but the tag was made with

2006-07-31 Thread Tim Peters
Log message for revision 69323:
  Checking into a tag is evil, but the tag was made with
  incorrect version numbers in two of the makefiles needed
  to build the Windows installer for 2.8.8.
  

Changed:
  U   Zope/tags/2-8-8/inst/WinBuilders/mk/python.mk
  U   Zope/tags/2-8-8/inst/WinBuilders/mk/zope.mk

-=-
Modified: Zope/tags/2-8-8/inst/WinBuilders/mk/python.mk
===
--- Zope/tags/2-8-8/inst/WinBuilders/mk/python.mk   2006-07-31 17:56:35 UTC 
(rev 69322)
+++ Zope/tags/2-8-8/inst/WinBuilders/mk/python.mk   2006-08-01 03:16:38 UTC 
(rev 69323)
@@ -6,7 +6,7 @@
 PYVERSION_MINOR=3
 PYVERSION_PATCH=5
 PYVERSION=$(PYVERSION_MAJOR).$(PYVERSION_MINOR).$(PYVERSION_PATCH)
-W32ALLVERSION=205
+W32ALLVERSION=207
 
 # CAUTION:  Extracting files from Wise installers doesn't really do what
 # you expect.  While a Wise installer is a zip file, the zip file

Modified: Zope/tags/2-8-8/inst/WinBuilders/mk/zope.mk
===
--- Zope/tags/2-8-8/inst/WinBuilders/mk/zope.mk 2006-07-31 17:56:35 UTC (rev 
69322)
+++ Zope/tags/2-8-8/inst/WinBuilders/mk/zope.mk 2006-08-01 03:16:38 UTC (rev 
69323)
@@ -3,7 +3,7 @@
 REQUIRED_FILES=$(PYTHON_REQUIRED_FILES)\
$(ZOPE_REQUIRED_FILES)
 
-ZOPEVERSION=2.8.7-final
+ZOPEVERSION=2.8.8-final
 ZOPEDIRNAME=Zope-$(ZOPEVERSION)
 
 MAKEZOPE=$(MAKEFILEDIR)/bin/makezope.bat $(WIN_BUILD_DIR)

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/tags/2.9.4/inst/WinBuilders/mk/common.mk Checking in on a tag is evil, but the code for finding

2006-07-31 Thread Tim Peters
Log message for revision 69324:
  Checking in on a tag is evil, but the code for finding
  Inno Setup was completely broken.
  

Changed:
  U   Zope/tags/2.9.4/inst/WinBuilders/mk/common.mk

-=-
Modified: Zope/tags/2.9.4/inst/WinBuilders/mk/common.mk
===
--- Zope/tags/2.9.4/inst/WinBuilders/mk/common.mk   2006-08-01 03:16:38 UTC 
(rev 69323)
+++ Zope/tags/2.9.4/inst/WinBuilders/mk/common.mk   2006-08-01 04:32:17 UTC 
(rev 69324)
@@ -39,8 +39,8 @@
 NMAKE=nmake
 CSCRIPT=cscript
 ECHO=echo
-ISS_DIR=$(PROGRAMFILES)\\Inno Setup 5
-ISS_COMPILER=$(ISS_DIR)\\Compil32.exe
+ISS_DIR=$(CYGROOT)/Progra~1/Inno Setup 5
+ISS_COMPILER=$(ISS_DIR)/Compil32.exe
 # We need a version that understands cygwin paths, so /bin/
 UNZIP=/bin/unzip
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


Re: [Zope-dev] Windows Installers

2006-07-31 Thread Tim Peters

[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 to all the Zope
releases.  If someone needs a Windows installer, I'm usually willing
to make one (but probably won't notice a need for one without being
poked).


I've chatted with Alan Runyan and he agreed to dedicate a person for
doing this in exchange of a little publicity. Quoting him:


Our build system has become quite extensive over the past two years.  I
would love to build the Zope installers.  I would also appreciate some
attribution on the first graphic that is displayed.  Basically at the
bottom about 20% of the graphic would say:
'[LOGO] windows installer courtesy of Enfold System'



Not sure on exactly what that means, but doubt anyone would object,
provided he's also willing to volunteer the time to produce the
graphic and wrestle with InnoSetup to get it displayed.


Another alternative would be to add the installer as build to the
buildbot @ zope.org, then we would have 'nightly' installer builds and
once a release was cut one could just take one of these installers and
declare it official.

Thoughts?


Building the installer is usually easy.  The hour or so it takes to
make a real Windows release is usually consumed by testing,
including manual testing of running as a Windows service.  Sometimes
there are also Windows-specific problems running the tests from an
installation tree that never showed up running from a checkout tree.
Of course if nobody cares about testing a release, a nightly installer
build would work fine ;-)
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Windows Installers

2006-07-31 Thread Tim Peters

[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)
--
Traceback (most recent call last):
 File C:\Code\Zope2.8\inst\build\lib\python\OFS\tests\test_XMLExportImport.py,
line 102, in test_OFS_ObjectManager__i
mportObjectFromFile_xml
   sub._importObjectFromFile(ostream.name, 0, 0)
 File C:\Code\Zope2.8\inst\build\lib\python\OFS\ObjectManager.py,
line 592, in _importObjectFromFile
   ob=connection.importFile(
 File C:\Code\Zope2.8\inst\build\lib\python\ZODB\ExportImport.py,
line 59, in importFile
   f = open(f, 'rb')
IOError: [Errno 13] Permission denied:
'c:\\docume~1\\owner\\locals~1\\temp\\tmppr7uqt.xml'

==
ERROR: test_export_import_as_file_idempotent
(OFS.tests.test_XMLExportImport.XMLExportImportTests)
--
Traceback (most recent call last):
 File C:\Code\Zope2.8\inst\build\lib\python\OFS\tests\test_XMLExportImport.py,
line 75, in test_export_import_as_file
_idempotent
   newobj = importXML(connection, ostream.name)
 File C:\Code\Zope2.8\inst\build\lib\python\OFS\XMLExportImport.py,
line 104, in importXML
   file=open(file)
IOError: [Errno 13] Permission denied:
'c:\\docume~1\\owner\\locals~1\\temp\\tmpgj2cnm.xml'

--
Ran 6229 tests in 1765.442s

FAILED (errors=2)


Note 2.9.4 changed the build procedure to be the same as 2.8.x again. I've
made the changes, and hopefully it should work just fine.


The 2.9.4 build started failing here:

...
mkdir -p /cygdrive/c/Code/Zope2.9/inst/src
cd /cygdrive/c/Code/Zope2.9/inst/src  tar xzf ../tmp/Zope-2.9.4.tgz

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error exit delayed from previous errors
make: *** [src/Zope-2.9.4/inst/configure.py] Error 2


I renamed the Zope 2.9.4 tarball download to worm around that, and
then it failed here:

mkdir -p /cygdrive/c/Code/Zope2.9/inst/src
cd /cygdrive/c/Code/Zope2.9/inst/src  tar xzf ../tmp/Zope-2.9.4.tgz
touch src/Zope-2.9.4/inst/configure.py
touch: cannot touch `src/Zope-2.9.4/inst/configure.py': No such file
or directory
make: *** [src/Zope-2.9.4/inst/configure.py] Error 1


Again it's fatally confused about whether the Zope tarball and/or
unpacked directory root does or does not have -final in its name.  I
didn't repair this, I just wormed around it again (I have no idea what
the /intent/ is now).

Finally, the code for finding Inno Setup in common.mk was broken,
trying to feed a native Windows path to the Cygwin bash shell.  I
replaced that on the tag (but not the branch) with similar (but
working ;-)) code from the 2.8.8 build, essentially reverting this
patch:

http://svn.zope.org/Zope/branches/2.9/inst/WinBuilders/mk/common.mk?rev=69118r1=65837r2=69118

After that, everything worked fine, although the functional tests crapped out.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Zope 2.9.4

2006-07-15 Thread Tim Peters

[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. I am
very much in favor of using tag names...revision number tell you
nothing...provide at least a reasonable version information...opinions?


The things people complain about sometimes astonish me -- just as the
things I complain about sometimes astonish others :-)

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 changes:

- It wholly deletes you current checkout of the external.
 If non-version-controlled files (like .pyc) happen to be sitting in
 the directories, this leaves behind useless OLD directories.

- It does a complete checkout of the new tag.
 This generally takes more time.
 And forces a recompile too even if no C code in the external has
 actually changed,

It's true that changing an external revision number instead suffers
none of those drawbacks.Like I cared ;-)
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Zope 2.9.4

2006-07-15 Thread Tim Peters

[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 changes:


[Andreas]

What do you mean with when the tag changes?


Not what I said:  I said [when] an /external/ tag changes.  I mean
when you change an external tag _in_ project A _referencing_ the
external tagged project B.  Here A=Zope and B=ZODB, and the external
tags in question are the ones referencing ZODB from within the
svn:externals properties of various Zope directories.


A tag IMO should *never* change.


The revision number associated with a tag within project B indeed
shouldn't change.  That's not what I'm talking about.  I'm talking
about how other projects reference project B:  they have a choice of:

1. making their own copy of B
2. using svn:externals with a tag for B
3. using svn:externals with a revision number for B

Read my msg again with that in mind, and it will make much more sense
to you.  I was describing the complaints about using choice #2.

Zope Corp has tried all of those at various times.  They all have
different drawbacks, but the only one I found horribly unusable was #1
(because then N different projects have copies of B, and changes to
copies of B's code get made from N different projects, and nobody
bothers to merge those changes back into B itself -- people changing a
copy of B from a different project often don't even _know_ they're
changing conceptually external code; in effect, without absurd
effort on the part of B's maintainer(s), the world ends up with B plus
N forks of B).


...

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


[Zope-Checkins] SVN: Zope/tags/2-8-6/inst/WinBuilders/mk/python.mk Move to build 207 of pywin32 (this should have been

2006-06-21 Thread Tim Peters
Log message for revision 65842:
  Move to build 207 of pywin32 (this should have been
  done before Zope 2.8.6 was tagged).
  

Changed:
  U   Zope/tags/2-8-6/inst/WinBuilders/mk/python.mk

-=-
Modified: Zope/tags/2-8-6/inst/WinBuilders/mk/python.mk
===
--- Zope/tags/2-8-6/inst/WinBuilders/mk/python.mk   2006-03-06 20:43:04 UTC 
(rev 65841)
+++ Zope/tags/2-8-6/inst/WinBuilders/mk/python.mk   2006-03-07 01:05:37 UTC 
(rev 65842)
@@ -1,12 +1,12 @@
 # The Python and pywin32 versions.  For Python, both the source tarball
-# and the Windows installer must be in tmp/.  For pywin32 (previously known 
+# and the Windows installer must be in tmp/.  For pywin32 (previously known
 # as win32all), the Windows installer must be in tmp/.  Nothing beyond those
 # is required to build Python, and you don't even need a compiler.
 PYVERSION_MAJOR=2
 PYVERSION_MINOR=3
 PYVERSION_PATCH=5
 PYVERSION=$(PYVERSION_MAJOR).$(PYVERSION_MINOR).$(PYVERSION_PATCH)
-W32ALLVERSION=205
+W32ALLVERSION=207
 
 # CAUTION:  Extracting files from Wise installers doesn't really do what
 # you expect.  While a Wise installer is a zip file, the zip file

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/tags/2-8-6/inst/WinBuilders/README.txt Move to build 207 of pywin32 (this should have been

2006-06-21 Thread Tim Peters
Log message for revision 65843:
  Move to build 207 of pywin32 (this should have been
  done before Zope 2.8.6 was tagged).
  

Changed:
  U   Zope/tags/2-8-6/inst/WinBuilders/README.txt

-=-
Modified: Zope/tags/2-8-6/inst/WinBuilders/README.txt
===
--- Zope/tags/2-8-6/inst/WinBuilders/README.txt 2006-03-07 01:05:37 UTC (rev 
65842)
+++ Zope/tags/2-8-6/inst/WinBuilders/README.txt 2006-03-07 01:07:59 UTC (rev 
65843)
@@ -27,7 +27,7 @@
 
   - Python-2.3.5.tgz
   - Python-2.3.5.exe (used for binary modules)
-  - pywin32-205.win32-py2.3.exe (extracts binaries and sources)
+  - pywin32-207.win32-py2.3.exe (extracts binaries and sources)
   - Zope.tgz
 
 As time marches on, these version numbers will obviously change.  See/edit

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/tags/2-8-6/inst/WinBuilders/etc/zope.iss.in More installer bitmap repair.

2006-06-21 Thread Tim Peters
Log message for revision 65845:
  More installer bitmap repair.
  

Changed:
  U   Zope/tags/2-8-6/inst/WinBuilders/etc/zope.iss.in

-=-
Modified: Zope/tags/2-8-6/inst/WinBuilders/etc/zope.iss.in
===
--- Zope/tags/2-8-6/inst/WinBuilders/etc/zope.iss.in2006-03-07 01:13:23 UTC 
(rev 65844)
+++ Zope/tags/2-8-6/inst/WinBuilders/etc/zope.iss.in2006-03-07 03:53:47 UTC 
(rev 65845)
@@ -10,6 +10,10 @@
 OutputBaseFilename=Zope-VERSION-win32
 WizardImageFile=MAKEFILEDIR\etc\zlogo_left.bmp
 WizardSmallImageFile=MAKEFILEDIR\etc\zlogo_top.bmp
+; Starting w/ Inno 4.1.3, Inno decided to stretch the .bmp files in various
+; ways.  Hard to know why, but it looks terrible on my pretty vanilla box.
+; Luckily, 4.1.3 also added WizardImageStretch to turn that off.
+WizardImageStretch=no
 SolidCompression=yes
 
 SourceDir=.
@@ -69,7 +73,7 @@
   PasswordChars  : array of char;
 
   DataDirValues: array of String;
-  
+
   Password   : string;
   DataDir:  String;
 
@@ -87,7 +91,7 @@
   { set up data dir data structures }
   SetArrayLength(DataDirValues, 1);
   DataDir := '';
-  
+
   Result := True;
 end;
 
@@ -106,9 +110,9 @@
if DataDirValues[0]  '' then DataDirValues[0]:= '';
 
{ Ask for a dir until the user has approved one or clicked Back or 
Cancel }
-   
+
   Next:= InputDir(False, DataDirValues[0], DataDir);
-   
+
   if Next and FileOrDirExists(DataDir) then DirOk := False;
 
while Next and not DirOk do begin
@@ -133,7 +137,7 @@
   ScriptDlgPageSetSubCaption1('Specify administrator password');
ScriptDlgPageSetSubCaption2('The login name for your Zope administrator 
account is admin. When you first connect to the Zope management interface, 
you will need to login using the admin username and the password you specify 
below.');
Next := InputQueryArrayEx(PasswordPrompts, PasswordChars, 
PasswordValues);
-   
+
while Next and (PasswordValues[0] = '') do begin
  MsgBox('You must enter an administrator password', mbError, MB_OK)
Next := InputQueryArrayEx(PasswordPrompts, PasswordChars, 
PasswordValues);
@@ -172,7 +176,7 @@
   if ( (not BackClicked and (CurPage = wpSelectTasks)) or (BackClicked and 
(CurPage = wpReady))  )
 and DoInstanceHome() then begin
 if not BackClicked then CurSubPage:=0 else CurSubPage:=1;
- 
+
 ScriptDlgPageOpen();
 ScriptDlgPageSetCaption('Instance Setup');
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/tags/2-8-6/inst/WinBuilders/etc/zeo.iss.in Repair distorted installer bitmaps.

2006-06-21 Thread Tim Peters
Log message for revision 65844:
  Repair distorted installer bitmaps.
  

Changed:
  U   Zope/tags/2-8-6/inst/WinBuilders/etc/zeo.iss.in

-=-
Modified: Zope/tags/2-8-6/inst/WinBuilders/etc/zeo.iss.in
===
--- Zope/tags/2-8-6/inst/WinBuilders/etc/zeo.iss.in 2006-03-07 01:07:59 UTC 
(rev 65843)
+++ Zope/tags/2-8-6/inst/WinBuilders/etc/zeo.iss.in 2006-03-07 01:13:23 UTC 
(rev 65844)
@@ -10,6 +10,10 @@
 OutputBaseFilename=ZEO-VERSION-win32
 WizardImageFile=MAKEFILEDIR\etc\zlogo_left.bmp
 WizardSmallImageFile=MAKEFILEDIR\etc\zlogo_top.bmp
+; Starting w/ Inno 4.1.3, Inno decided to stretch the .bmp files in various
+; ways.  Hard to know why, but it looks terrible on my pretty vanilla box.
+; Luckily, 4.1.3 also added WizardImageStretch to turn that off.
+WizardImageStretch=no
 
 SourceDir=.
 OutputDir=.

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/inst/WinBuilders/ Merge revs 65842 65843 65844 65845 from Zope/tags/2-8-6/.

2006-06-21 Thread Tim Peters
Log message for revision 65846:
  Merge revs 65842 65843 65844 65845 from Zope/tags/2-8-6/.
  
  Move to pywin32 build 207, and repair mangling of installer bitmaps.
  These should have been done before the 2.8.6 tag was made.
  

Changed:
  U   Zope/branches/Zope-2_8-branch/inst/WinBuilders/README.txt
  U   Zope/branches/Zope-2_8-branch/inst/WinBuilders/etc/zeo.iss.in
  U   Zope/branches/Zope-2_8-branch/inst/WinBuilders/etc/zope.iss.in

-=-
Modified: Zope/branches/Zope-2_8-branch/inst/WinBuilders/README.txt
===
--- Zope/branches/Zope-2_8-branch/inst/WinBuilders/README.txt   2006-03-07 
03:53:47 UTC (rev 65845)
+++ Zope/branches/Zope-2_8-branch/inst/WinBuilders/README.txt   2006-03-07 
04:58:13 UTC (rev 65846)
@@ -27,7 +27,7 @@
 
   - Python-2.3.5.tgz
   - Python-2.3.5.exe (used for binary modules)
-  - pywin32-205.win32-py2.3.exe (extracts binaries and sources)
+  - pywin32-207.win32-py2.3.exe (extracts binaries and sources)
   - Zope.tgz
 
 As time marches on, these version numbers will obviously change.  See/edit

Modified: Zope/branches/Zope-2_8-branch/inst/WinBuilders/etc/zeo.iss.in
===
--- Zope/branches/Zope-2_8-branch/inst/WinBuilders/etc/zeo.iss.in   
2006-03-07 03:53:47 UTC (rev 65845)
+++ Zope/branches/Zope-2_8-branch/inst/WinBuilders/etc/zeo.iss.in   
2006-03-07 04:58:13 UTC (rev 65846)
@@ -10,6 +10,10 @@
 OutputBaseFilename=ZEO-VERSION-win32
 WizardImageFile=MAKEFILEDIR\etc\zlogo_left.bmp
 WizardSmallImageFile=MAKEFILEDIR\etc\zlogo_top.bmp
+; Starting w/ Inno 4.1.3, Inno decided to stretch the .bmp files in various
+; ways.  Hard to know why, but it looks terrible on my pretty vanilla box.
+; Luckily, 4.1.3 also added WizardImageStretch to turn that off.
+WizardImageStretch=no
 
 SourceDir=.
 OutputDir=.

Modified: Zope/branches/Zope-2_8-branch/inst/WinBuilders/etc/zope.iss.in
===
--- Zope/branches/Zope-2_8-branch/inst/WinBuilders/etc/zope.iss.in  
2006-03-07 03:53:47 UTC (rev 65845)
+++ Zope/branches/Zope-2_8-branch/inst/WinBuilders/etc/zope.iss.in  
2006-03-07 04:58:13 UTC (rev 65846)
@@ -10,6 +10,10 @@
 OutputBaseFilename=Zope-VERSION-win32
 WizardImageFile=MAKEFILEDIR\etc\zlogo_left.bmp
 WizardSmallImageFile=MAKEFILEDIR\etc\zlogo_top.bmp
+; Starting w/ Inno 4.1.3, Inno decided to stretch the .bmp files in various
+; ways.  Hard to know why, but it looks terrible on my pretty vanilla box.
+; Luckily, 4.1.3 also added WizardImageStretch to turn that off.
+WizardImageStretch=no
 SolidCompression=yes
 
 SourceDir=.
@@ -69,7 +73,7 @@
   PasswordChars  : array of char;
 
   DataDirValues: array of String;
-  
+
   Password   : string;
   DataDir:  String;
 
@@ -87,7 +91,7 @@
   { set up data dir data structures }
   SetArrayLength(DataDirValues, 1);
   DataDir := '';
-  
+
   Result := True;
 end;
 
@@ -106,9 +110,9 @@
if DataDirValues[0]  '' then DataDirValues[0]:= '';
 
{ Ask for a dir until the user has approved one or clicked Back or 
Cancel }
-   
+
   Next:= InputDir(False, DataDirValues[0], DataDir);
-   
+
   if Next and FileOrDirExists(DataDir) then DirOk := False;
 
while Next and not DirOk do begin
@@ -133,7 +137,7 @@
   ScriptDlgPageSetSubCaption1('Specify administrator password');
ScriptDlgPageSetSubCaption2('The login name for your Zope administrator 
account is admin. When you first connect to the Zope management interface, 
you will need to login using the admin username and the password you specify 
below.');
Next := InputQueryArrayEx(PasswordPrompts, PasswordChars, 
PasswordValues);
-   
+
while Next and (PasswordValues[0] = '') do begin
  MsgBox('You must enter an administrator password', mbError, MB_OK)
Next := InputQueryArrayEx(PasswordPrompts, PasswordChars, 
PasswordValues);
@@ -172,7 +176,7 @@
   if ( (not BackClicked and (CurPage = wpSelectTasks)) or (BackClicked and 
(CurPage = wpReady))  )
 and DoInstanceHome() then begin
 if not BackClicked then CurSubPage:=0 else CurSubPage:=1;
- 
+
 ScriptDlgPageOpen();
 ScriptDlgPageSetCaption('Instance Setup');
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


Re: [Zope3-dev] Re: [Zope-dev] Re: 64-bit BTrees

2006-04-13 Thread Tim Peters
[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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] repozo.py

2006-03-08 Thread Tim Peters
[Dennis Allison]
 We are (finally) moving to repozo for our backups.  We are running a mixed
 collection of Zopes -- mostly Zope 2.7.6, Zope 2.8.X and Zope 2.9.0.   For
 the near term we cannot move to a single release.  There are differences
 between the versions of repozo distributed with the different Zope
 systems.

 I assume that the they are backward compatible and that the repozo.py
 shipped with Zope 2.9.0 is compatible with all variations of the Data.fs
 format.

[Chris Withers]
 I would play it safe and use the repozo.py appropriate for each version
 of Zope you're using to drive each ZEO server...

It's probably safest to use the most recent version of repozo with
all:  repozo hasn't grown new features, but it has gotten bugfixes,
and pretty much regardless of the software in question the most recent
release is the one most likely to contain all bugfixes to date. 
repozo in particular doesn't know anything about the _structure_ of a
Data.fs file (it works by copying bytes -- doesn't know anything about
transactions or objects), so it wouldn't be possible for repozo to be
incompatible across ZODB releases even if the Data.fs format had
changed (which it hasn't).
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope-dev] Windows Binary for 2.8.6?

2006-03-06 Thread Tim Peters
[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 with that one since it probably
 need CV++ 6.0

Correct.

 which I don't have access to :-/

 Can someone else pick this one up?

If nobody beats me to it, I will, eventually.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 2.9 releases for Windows?

2006-03-03 Thread Tim Peters
[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
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 2.9 releases for Windows?

2006-02-26 Thread Tim Peters
[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 :-)
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Python warnings behavior and stacklevel=2

2006-02-10 Thread Tim Peters
[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 object

 It seems to be referenced on the Python tracker since Python-2.3.3. Has
 been fixed and closed but has been updated in January this year.

 https://sourceforge.net/tracker/?func=detailatid=105470aid=890010group_id=5470

I expect that referencing that bug report is just misleading here: 
none of the bad behaviors listed in that bug report occur under Python
2.4.2 (I just tried all of 'em).

 Specifying a stacklevel of  a workaround, instead of 2 within the
 zLOG/__init__.py for instance1, as works fine. (and this seems to appear
 within the Python but report)

None of the provoking code in the bug report used stacklevel.  There's
a line of _output_ in the bug report, from a pdb session, where pdb
showed the first line of the warnings.warn() function, showing that
`stacklevel` is a formal argument of `warn()`, and that it defaults to
1:

(Pdb) s
--Call--
 /usr/lib/python2.3/warnings.py(24)warn()
- def warn(message, category=None, stacklevel=1):  # this is pdb
output, not input

There's no other mention of `stacklevel` in the report.

 I actually get the same error and behavior within CPS code using the
 warnings module with a stacklevel of 2.

 Has someone a proper way to fix this from Zope and / or Python or can we
 simply change the StackLevel of the deprecation warnings to 1 waiting
 for a proper fix in Python ?

All the symptoms in the bug report are already fixed.  In the absence
of a new bug report, nothing else _will_ be fixed in Python related to
this.

The _cause_ of those bugs in the first place was an internal Python
error:  one of the internal functions didn't propagate exceptions
properly back to the eval loop.

It's possible that other cases like that exist, in Python itself or in
a C extension module (it's actually a pretty common error in extension
modules).  Progress requires a small test case demonstrating the
problem; the bug report contained several small test cases
illustrating symtpoms, but all of those have been repaired, so if
there's another bug it requires another test case to track it down.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: [Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/ Repair invocation of Inno compiler -- it doesn't ( can't) work to

2006-01-26 Thread Tim Peters
[Tim Peters]
 Log message for revision 41456:
   Repair invocation of Inno compiler -- it doesn't ( can't) work to
   stick the path and /cc in the same quoted string.  Unsure why that
   change was made (it worked fine before -- and now).

[Sidnei da Silva]
 That change was so I can run: 'ISS_COMPILER=iscc.exe
 WinBuilders/buildout', because compile32.exe fires up the gui, and
 obviously that can't work with the buildbot.

I don't see why not -- no interaction with the GUI is required, it simply
pops up a window for as long as the Inno compiler runs.  Then the window
goes away again, all by itself.

 Obviously I just tested my command and not what worked before :(

Let's leave it alone for tonight, then.  You can do anything you want with
all of it starting tomorrow ;-)


___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/tags/2.9.0/inst/WinBuilders/ Merge tim-2.9-windows-installer branch.

2006-01-26 Thread Tim Peters
Log message for revision 41458:
  Merge tim-2.9-windows-installer branch.
  
  This is the code used to build the Zope 2.9.0 Windows installer.
  
  It bundles Python 2.4.2, lives in peace with zpkgtools, moves
  to InnoSetup 5, and simplifies most parts of the build-the-
  installer process.
  

Changed:
  U   Zope/tags/2.9.0/inst/WinBuilders/README.txt
  D   Zope/tags/2.9.0/inst/WinBuilders/bin/makezope.bat
  A   Zope/tags/2.9.0/inst/WinBuilders/bin/msvcr71.dll
  U   Zope/tags/2.9.0/inst/WinBuilders/etc/zope.iss.in
  U   Zope/tags/2.9.0/inst/WinBuilders/mk/common.mk
  U   Zope/tags/2.9.0/inst/WinBuilders/mk/python.mk
  U   Zope/tags/2.9.0/inst/WinBuilders/mk/zope.mk

-=-
Modified: Zope/tags/2.9.0/inst/WinBuilders/README.txt
===
--- Zope/tags/2.9.0/inst/WinBuilders/README.txt 2006-01-27 01:31:00 UTC (rev 
41457)
+++ Zope/tags/2.9.0/inst/WinBuilders/README.txt 2006-01-27 01:39:54 UTC (rev 
41458)
@@ -1,39 +1,63 @@
 Quick instructions:
 
-The buildout has been tested under Windows 2K and XP Pro SP2.  It almost
-works on Win98SE (see bottom of file for discussion).
+The buildout has been tested under Windows 2K and XP Pro SP2.
 
 
 Setup Environment
 --
 
+Install Python 2.4.2 (or whatever is most current) by running its native
+Windows installer from python.org.
+
+Note:  Python 2.4 switched from using a Wise installer to using a
+Microsoft .msi installer, and the latter is harder to work with.  The
+buildout used to extract Python source and binaries (.exe, .pyd, .dll)
+from the Wise installer (which could be treated much like a zip file).
+Now the Python installer isn't used at all.  Instead, the Python
+source is taken from the Python tarball release, and the binaries are
+copied from your installed Python.
+
 Install Cygwin from cygwin.org (the default installation should give
 you everything you need).
 
-Install Microsoft Visual C++ 6.0 (or MSVC 7 once we get to Python 2.4)
+Install Microsoft Visual C++ 7.1 (aka Visual Studio .NET 2003).  This is
+needed to compile Zope's Python C extensions compatible with Python 2.4
+(and 2.5, when that's released).
 
-Install InnoSetup 4.2 from www.jrsofware.org (into its default location).
-Versions earlier than 4.0.11 are known to not work; any 4.2.x release
-or later should be fine.  Inno 5.x versions do *not* work (it appears the
-Inno custom dialog mechanism has changed in an incompatible way)
+Install InnoSetup 5.1.5 (or later) from www.jrsoftware.org, into its
+default location.  Inno 4.x (or earlier) cannot work:  Inno 5 introduced a
+vastly simpler way to create the custom dialog pages we want.
 
 'svn switch' to, or check out, the Zope tag for which an installer is to be
-built.  You want a native Windows checkout here, so that the text files have
-Windows-appropriate line ends.
+built.
 
-Within a Zope checkout, parent directory of this package is inst.  Make a
-tmp directory, inst/tmp.  Place the necessary pre-requisites in the tmp
-directory.  At the time of this writing, this includes:
+Within a Zope checkout, the parent directory of this package is inst.  Make
+a tmp directory, inst/tmp.  Place the necessary pre-requisites in the tmp
+directory.  At the time of this writing, these are:
 
-  - Python-2.3.5.tgz
-  - Python-2.3.5.exe (used for binary modules)
-  - pywin32-205.win32-py2.3.exe (extracts binaries and sources)
-  - Zope.tgz
+  - Python-2.4.2.tgz
+  - pywin32-205.win32-py2.4.exe
+  - Zope-2.9.0.tgz
 
 As time marches on, these version numbers will obviously change.  See/edit
 mk/python.mk and mk/zope.mk for the exact versions required.
 
+You also need to install the same Windows Python that Zope will repackage.
+There doesn't appear to be a sane way to extract binaries (.exe, .pyd,
+.dll, .lib) from an .msi installer, and building Python from source is a long
+ messy process on Windows.  So python.mk just copies them from an installed
+Python instead.  Cautions:
 
+- If you didn't accept the Python installer's default directory, or if
+  you did but it's on a different drive, you'll need to change
+  WIN_PYINSTALLEDDIR in python.mk.
+
+- The main Python DLL must live in WIN_PYINSTALLEDDIR too.  Depending on
+  how you installed Python, that may be sitting in some Windows system
+  directory instead; if so, make a copy in the root of your Python
+  installation.
+
+
 Building
 
 
@@ -85,21 +109,44 @@
 Testing Zope
 
 
-The test suite can be run from inst\build\:
+XXX This doesn't work right starting with Zope 2.9:  it's clumsier than it
+XXX should be, and the functional tests don't even try to run (just the
+XXX unit tests).
+XXX Someone who understands how Zope3 testing from a zpkgtools-tarball build
+XXX was made to work again may be able to help here.
 
+The test suite can be run from inst\build\, after building the installer.
+
 - Open a native (not Cygwin) DOS box.  We want to test with the Python the
-  Zope 

[Zope-Checkins] SVN: Zope/branches/2.9/inst/WinBuilders/ Merge tim-2.9-windows-installer branch.

2006-01-26 Thread Tim Peters
Log message for revision 41460:
  Merge tim-2.9-windows-installer branch.
  
  This is the code used to build the Zope 2.9.0 Windows installer.
  
  It bundles Python 2.4.2, lives in peace with zpkgtools, moves
  to InnoSetup 5, and simplifies most parts of the build-the-
  installer process.
  

Changed:
  U   Zope/branches/2.9/inst/WinBuilders/README.txt
  D   Zope/branches/2.9/inst/WinBuilders/bin/makezope.bat
  A   Zope/branches/2.9/inst/WinBuilders/bin/msvcr71.dll
  U   Zope/branches/2.9/inst/WinBuilders/etc/zope.iss.in
  U   Zope/branches/2.9/inst/WinBuilders/mk/common.mk
  U   Zope/branches/2.9/inst/WinBuilders/mk/python.mk
  U   Zope/branches/2.9/inst/WinBuilders/mk/zope.mk

-=-
Modified: Zope/branches/2.9/inst/WinBuilders/README.txt
===
--- Zope/branches/2.9/inst/WinBuilders/README.txt   2006-01-27 01:40:29 UTC 
(rev 41459)
+++ Zope/branches/2.9/inst/WinBuilders/README.txt   2006-01-27 01:40:46 UTC 
(rev 41460)
@@ -1,39 +1,63 @@
 Quick instructions:
 
-The buildout has been tested under Windows 2K and XP Pro SP2.  It almost
-works on Win98SE (see bottom of file for discussion).
+The buildout has been tested under Windows 2K and XP Pro SP2.
 
 
 Setup Environment
 --
 
+Install Python 2.4.2 (or whatever is most current) by running its native
+Windows installer from python.org.
+
+Note:  Python 2.4 switched from using a Wise installer to using a
+Microsoft .msi installer, and the latter is harder to work with.  The
+buildout used to extract Python source and binaries (.exe, .pyd, .dll)
+from the Wise installer (which could be treated much like a zip file).
+Now the Python installer isn't used at all.  Instead, the Python
+source is taken from the Python tarball release, and the binaries are
+copied from your installed Python.
+
 Install Cygwin from cygwin.org (the default installation should give
 you everything you need).
 
-Install Microsoft Visual C++ 6.0 (or MSVC 7 once we get to Python 2.4)
+Install Microsoft Visual C++ 7.1 (aka Visual Studio .NET 2003).  This is
+needed to compile Zope's Python C extensions compatible with Python 2.4
+(and 2.5, when that's released).
 
-Install InnoSetup 4.2 from www.jrsofware.org (into its default location).
-Versions earlier than 4.0.11 are known to not work; any 4.2.x release
-or later should be fine.  Inno 5.x versions do *not* work (it appears the
-Inno custom dialog mechanism has changed in an incompatible way)
+Install InnoSetup 5.1.5 (or later) from www.jrsoftware.org, into its
+default location.  Inno 4.x (or earlier) cannot work:  Inno 5 introduced a
+vastly simpler way to create the custom dialog pages we want.
 
 'svn switch' to, or check out, the Zope tag for which an installer is to be
-built.  You want a native Windows checkout here, so that the text files have
-Windows-appropriate line ends.
+built.
 
-Within a Zope checkout, parent directory of this package is inst.  Make a
-tmp directory, inst/tmp.  Place the necessary pre-requisites in the tmp
-directory.  At the time of this writing, this includes:
+Within a Zope checkout, the parent directory of this package is inst.  Make
+a tmp directory, inst/tmp.  Place the necessary pre-requisites in the tmp
+directory.  At the time of this writing, these are:
 
-  - Python-2.3.5.tgz
-  - Python-2.3.5.exe (used for binary modules)
-  - pywin32-205.win32-py2.3.exe (extracts binaries and sources)
-  - Zope.tgz
+  - Python-2.4.2.tgz
+  - pywin32-205.win32-py2.4.exe
+  - Zope-2.9.0.tgz
 
 As time marches on, these version numbers will obviously change.  See/edit
 mk/python.mk and mk/zope.mk for the exact versions required.
 
+You also need to install the same Windows Python that Zope will repackage.
+There doesn't appear to be a sane way to extract binaries (.exe, .pyd,
+.dll, .lib) from an .msi installer, and building Python from source is a long
+ messy process on Windows.  So python.mk just copies them from an installed
+Python instead.  Cautions:
 
+- If you didn't accept the Python installer's default directory, or if
+  you did but it's on a different drive, you'll need to change
+  WIN_PYINSTALLEDDIR in python.mk.
+
+- The main Python DLL must live in WIN_PYINSTALLEDDIR too.  Depending on
+  how you installed Python, that may be sitting in some Windows system
+  directory instead; if so, make a copy in the root of your Python
+  installation.
+
+
 Building
 
 
@@ -85,21 +109,44 @@
 Testing Zope
 
 
-The test suite can be run from inst\build\:
+XXX This doesn't work right starting with Zope 2.9:  it's clumsier than it
+XXX should be, and the functional tests don't even try to run (just the
+XXX unit tests).
+XXX Someone who understands how Zope3 testing from a zpkgtools-tarball build
+XXX was made to work again may be able to help here.
 
+The test suite can be run from inst\build\, after building the installer.
+
 - Open a native (not Cygwin) DOS box.  We want to 

RE: [Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/ Repair invocation of Inno compiler -- it doesn't ( can't) work to

2006-01-26 Thread Tim Peters
[Sidnei da Silva]
 I can surely say that it doesn't work with the buildbot. Maybe because
 it's running as a Windows Service.

Well, that's a goofy idea -- nothing runs right as a service ;-)


___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/trunk/inst/WinBuilders/ Merge tim-2.9-windows-installer branch.

2006-01-26 Thread Tim Peters
Log message for revision 41462:
  Merge tim-2.9-windows-installer branch.
  
  This is the code used to build the Zope 2.9.0 Windows installer.
  
  It bundles Python 2.4.2, lives in peace with zpkgtools, moves
  to InnoSetup 5, and simplifies most parts of the build-the-
  installer process.
  

Changed:
  U   Zope/trunk/inst/WinBuilders/README.txt
  D   Zope/trunk/inst/WinBuilders/bin/makezope.bat
  A   Zope/trunk/inst/WinBuilders/bin/msvcr71.dll
  U   Zope/trunk/inst/WinBuilders/etc/zope.iss.in
  U   Zope/trunk/inst/WinBuilders/mk/common.mk
  U   Zope/trunk/inst/WinBuilders/mk/python.mk
  U   Zope/trunk/inst/WinBuilders/mk/zope.mk

-=-
Modified: Zope/trunk/inst/WinBuilders/README.txt
===
--- Zope/trunk/inst/WinBuilders/README.txt  2006-01-27 01:47:38 UTC (rev 
41461)
+++ Zope/trunk/inst/WinBuilders/README.txt  2006-01-27 01:52:31 UTC (rev 
41462)
@@ -1,39 +1,63 @@
 Quick instructions:
 
-The buildout has been tested under Windows 2K and XP Pro SP2.  It almost
-works on Win98SE (see bottom of file for discussion).
+The buildout has been tested under Windows 2K and XP Pro SP2.
 
 
 Setup Environment
 --
 
+Install Python 2.4.2 (or whatever is most current) by running its native
+Windows installer from python.org.
+
+Note:  Python 2.4 switched from using a Wise installer to using a
+Microsoft .msi installer, and the latter is harder to work with.  The
+buildout used to extract Python source and binaries (.exe, .pyd, .dll)
+from the Wise installer (which could be treated much like a zip file).
+Now the Python installer isn't used at all.  Instead, the Python
+source is taken from the Python tarball release, and the binaries are
+copied from your installed Python.
+
 Install Cygwin from cygwin.org (the default installation should give
 you everything you need).
 
-Install Microsoft Visual C++ 6.0 (or MSVC 7 once we get to Python 2.4)
+Install Microsoft Visual C++ 7.1 (aka Visual Studio .NET 2003).  This is
+needed to compile Zope's Python C extensions compatible with Python 2.4
+(and 2.5, when that's released).
 
-Install InnoSetup 4.2 from www.jrsofware.org (into its default location).
-Versions earlier than 4.0.11 are known to not work; any 4.2.x release
-or later should be fine.  Inno 5.x versions do *not* work (it appears the
-Inno custom dialog mechanism has changed in an incompatible way)
+Install InnoSetup 5.1.5 (or later) from www.jrsoftware.org, into its
+default location.  Inno 4.x (or earlier) cannot work:  Inno 5 introduced a
+vastly simpler way to create the custom dialog pages we want.
 
 'svn switch' to, or check out, the Zope tag for which an installer is to be
-built.  You want a native Windows checkout here, so that the text files have
-Windows-appropriate line ends.
+built.
 
-Within a Zope checkout, parent directory of this package is inst.  Make a
-tmp directory, inst/tmp.  Place the necessary pre-requisites in the tmp
-directory.  At the time of this writing, this includes:
+Within a Zope checkout, the parent directory of this package is inst.  Make
+a tmp directory, inst/tmp.  Place the necessary pre-requisites in the tmp
+directory.  At the time of this writing, these are:
 
-  - Python-2.3.5.tgz
-  - Python-2.3.5.exe (used for binary modules)
-  - pywin32-205.win32-py2.3.exe (extracts binaries and sources)
-  - Zope.tgz
+  - Python-2.4.2.tgz
+  - pywin32-205.win32-py2.4.exe
+  - Zope-2.9.0.tgz
 
 As time marches on, these version numbers will obviously change.  See/edit
 mk/python.mk and mk/zope.mk for the exact versions required.
 
+You also need to install the same Windows Python that Zope will repackage.
+There doesn't appear to be a sane way to extract binaries (.exe, .pyd,
+.dll, .lib) from an .msi installer, and building Python from source is a long
+ messy process on Windows.  So python.mk just copies them from an installed
+Python instead.  Cautions:
 
+- If you didn't accept the Python installer's default directory, or if
+  you did but it's on a different drive, you'll need to change
+  WIN_PYINSTALLEDDIR in python.mk.
+
+- The main Python DLL must live in WIN_PYINSTALLEDDIR too.  Depending on
+  how you installed Python, that may be sitting in some Windows system
+  directory instead; if so, make a copy in the root of your Python
+  installation.
+
+
 Building
 
 
@@ -85,21 +109,44 @@
 Testing Zope
 
 
-The test suite can be run from inst\build\:
+XXX This doesn't work right starting with Zope 2.9:  it's clumsier than it
+XXX should be, and the functional tests don't even try to run (just the
+XXX unit tests).
+XXX Someone who understands how Zope3 testing from a zpkgtools-tarball build
+XXX was made to work again may be able to help here.
 
+The test suite can be run from inst\build\, after building the installer.
+
 - Open a native (not Cygwin) DOS box.  We want to test with the Python the
-  Zope installer includes.
-- cd to inst\build

[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/ This branch is no longer interesting -- it's been merged

2006-01-26 Thread Tim Peters
Log message for revision 41463:
  This branch is no longer interesting -- it's been merged
  to Zope trunk, 2.9 branch, and 2.9.0 tag.
  

Changed:
  D   Zope/branches/tim-2.9-windows-installer/

-=-
___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


Re: [Zope] unpickle error on Data.fs pack

2006-01-25 Thread Tim Peters
[Gerhard Schmidt]
 since three days we have problems when packing the Data.fs.

 2006-01-25T03:40:42 ERROR(200) zrpc:7266 Error raised in delayed method
 Traceback (most recent call last):
   File /usr/local/www/Zope/lib/python/ZEO/StorageServer.py, line 991, in run
 result = self._method(*self._args)
   File /usr/local/www/Zope/lib/python/ZEO/StorageServer.py, line 315, in 
 _pack_impl
 self.storage.pack(time, referencesf)
   File /usr/local/www/Zope/lib/python/ZODB/FileStorage.py, line 1582, in 
 pack
 opos = p.pack()
   File /usr/local/www/Zope/lib/python/ZODB/fspack.py, line 700, in pack
 self.gc.findReachable()
   File /usr/local/www/Zope/lib/python/ZODB/fspack.py, line 456, in 
 findReachable
 self.findReachableAtPacktime([z64])
   File /usr/local/www/Zope/lib/python/ZODB/fspack.py, line 531, in 
 findReachableAtP
 acktime
 todo.extend(self.findrefs(pos))
   File /usr/local/www/Zope/lib/python/ZODB/fspack.py, line 604, in findrefs
 return referencesf(self._file.read(dh.plen))
   File /usr/local/www/Zope/lib/python/ZODB/referencesf.py, line 38, in 
 referencesf
 raise ValueError, 'Error unpickling %r' % p
 ValueError: Error unpickling 
 '((U\x0eBTrees.OIBTreeq\x01U\x08OIBucketq\x02tq\x03Nt.((
 U\x05nchenq\x04J\xc6{a\xfeU\x0fnchen/ottobrunnq\x05J\xbd\xeby\xcfU\x04ndigq\x06J\n\xf
 0}QU\x05ndnisq\x07J\xd9\xdc\xbfIU\x02neq\x08J1!\x15\xe9U\x05nebenq\tJT]4\xc0U\x03netq
 \nJ\xf3cU\xb6U\x04net/q\x0bJ\nM\xe5\xd6U\x07networkq\x0cJ\xf5\x85!\xe5U\tnetzartigq\r
 J\xd4\xf9\x906U\x03neuq\x0eJv\xd7\xe9U\x04neueq\x0fJW\xedD\xd8U\x05neuenq\x10J0!\x0
 7U\x05neuesq\x11J\xb9\xa5\xb4sU\x08neuestenq\x12JW2\xcc-U\x07nftigenq\x13J\xd5iU\x0
 3ngeq\x14J%\xa9X\x10U\x06ngerenq\x15J\x1d\x14YU\x04ngigq\x16J\xc4\xe6\xe5\xd4U\x06ng
 igenq\x17J}\xbd\xffpU\nngigkeitenq\x18J)]\x06IU\x05nichtq\x19J\x0bgyU\x07nkungenq\x1
 aJC4\xf7\x10U\x04nnenq\x1bJU\xc4bFU\x04nochq\x1cJ\xb4\xf6\xcdUU\x07norbertq\x1dJ-\xf3
 \xd7\x8fU\x06normenq\x1eJ[\x84\xd4\xaeU\x07normungq\x1fJ\xf4\xe9\xfc\xfcU\x08notebook
 q 
 J\xf7\xf2\x9e\xf9U\x0fnotebookeinsatzq!J`\x8fRiU\tnotebooksqJ\xba\xecvU\x12notebo
 okverwendungq#J_R\x10\x9aU\x02nrq$J\xfcSg\xddU\x05nscheq%J-\x88\xf8\xccU\x06nstigeqJ
 \xa35\x0e\xcdU\x04nterq\'J\xb1\x94\x9b\xeeU\nnumerischeq(Jf\\n\xfeQ

Not that it will help much, but the \x03 on the start of the next line
is the immediate cause of the error (it's in a _position_ where a
pickle opcode is expected, but 0x03 isn't a legitimate pickle
opcode).

 \x03nurq)J\xd2\x95
 C\xf4U\x0cnutzbringendq*J\xd3\x84\x84\xeaU\x06nutzenq+J\xa7^\x86IU\tnutzungsmq,J\xc1\
 xca\xb9LU\x02obq-J\xbe\xb7e\x94U\x06objectq.J\xaaP\x14\xf9U\x04oderq/J\\0\xc2(U\x05od
 imaq0J\xcd\xf9\x0f:t(U\x08\x00\x00\x00\x00\x00%\xa5\xdaq1(U\x0eBTrees.OIBTreeq2U\x08O
 IBucketq3ttq4Qtq5.'
 --

 I've tried to recover the data.fs with fsrecover but it returns
 without error and the error remains.

This is corruption _inside_ an object pickle.  fsrecover can't do
anything about that.  See

http://zope.org/Wikis/ZODB/FileStorageBackup

for background info.

 fsrefs.py terminates with an error.

Yes, fsrefs can't load the pickle either.

 Any idea how to fix the Data.fs.

Sorry, not easily, no.  You need to exploit your application-specific
knowledge about the importance of this specific OIBucket, and couple
that with fiddly knowledge about how pickle works.

 The System is still up an running and no error shown so far.

Maybe you could locate the object in question from an fsdump (see the
link above), and delete the whole object.
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/ - Collector #2002: fixed broken 'ls -R' functionality (didn't

2006-01-21 Thread Tim Peters
[Sidnei da Silva]
 Log message for revision 41394:

 - Collector #2002: fixed broken 'ls -R' functionality (didn't
   recurse properly subclasses of OFS.Folder)


 Changed:
   U   Zope/branches/tim-2.9-windows-installer/doc/CHANGES.txt
   U   Zope/branches/tim-2.9-windows-installer/lib/python/OFS/ObjectManager.py

This certainly doesn't belong on the Windows installer branch. 
Nothing outside of inst/WinBuilders/ should change on this branch.
___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


Re: [Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/ - Collector #2002: fixed broken 'ls -R' functionality (didn't

2006-01-21 Thread Tim Peters
[Sidnei da Silva]
 Log message for revision 41394:

 - Collector #2002: fixed broken 'ls -R' functionality (didn't
   recurse properly subclasses of OFS.Folder)

[Tim Peters]
 This certainly doesn't belong on the Windows installer branch.
 Nothing outside of inst/WinBuilders/ should change on this branch.

Oops!  I see you reverted it later -- never mind ;-)
___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-dev] Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Tim Peters
...

[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.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] zeopack: No handlers could be found for logger ZEO.zrpc

2006-01-19 Thread Tim Peters
[Cameron Beattie]
 When I run the following:
 python /usr/lib/zope/bin/zeopack.py -d 20 -h localhost -p 8100

 I get an error:
 No handlers could be found for logger ZEO.zrpc

As Dieter said, that's not an error in and of itself, it's just
Python's logging module whining at you.  ZEO.zrpc is trying to log a
message of some sort, but the logging module hasn't been set up to
accept the request.  The message ZEO.zrpc is _trying_ to log may or
may not be important.  To find out, we'll have to see the message.

 I have searched around and found a similar message at
 http://mail.zope.org/pipermail/zope-dev/2005-December/026097.html (relating
 to zeoup.py) but I didn't understand what needs to be done to remedy the
 problem.

Is it true that you don't know how to edit Python code?  The first
response to that message suggested adding:

import logging
logging.basicConfig()

to the code, and it's hard to know what to say if you don't know how
to do that.  If you know how to use an editor, add those two lines to
your copy of zeopack.py, for example immediately following its:

if __name__ == __main__:

line.  If those instructions don't make sense, show them to someone else ;-)

 In the case of zeopack, the database is not packed i.e. the script doesn't
 work.

Finding out what the log message is may or may not reveal a cause for
that.  You should also look at your ZEO server's log file, since
problems with the database will be logged there by the ZEO server
code.  In fact, if there _is_ a problem with the database file (e.g.,
it's corrupted in some way), the only useful information you're going
to get will be in the server's log file, and ZEO.zrpc on the client
side would just try to log a message saying that the server was
unhappy.  It's possible that's what's happening here, but not enough
info to say for sure.

 I am running Zope 2.8.2 with python 2.4.1.
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


[Zope-dev] Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Tim Peters
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 tarball, and pywin32
installer are downloaded, building a Zope 2 release consists of typing
one command in a Cygwin shell:

WinBuilders/buildout zope

That's it.

_Authoring_ the Zope 2 build-the-installer code has been a royal PITA,
but work is needed there only when packaging gimmicks change.  Like
moving to zpkgtools, or moving away from them again, or moving to a
different packaging system for one of the components (like Python
moving from a Wise installer to an MSI installer for 2.4, or pywin32
earlier moving from a Wise installer to a distutils installer). 
Across the long life of Zope 2.7, those things changed very little,
and as a result very little needed to change in the
build-the-installer code across 2.7's life.  2.7 Windows releases
remained easy to build across that time (granting that Mark Hammond
did the work to adjust to pywin32's packaging changes).

2.8 Windows releases were/are similarly easy to build.

A lot of new work was needed for 2.9, due to Python and zpkgtools
changes.  I also took the opportunity to upgrade from InnoSetup 4 to
version 5, which introduced a much easier scheme for managing the
custom dialog screens in the Zope installer.

All of that ended up making the build-the-installer code substantially
simpler, to the point where it now seems kinda goofy to use makefiles
at all in the process.  Makefile mazes are inscrutable, and are
particularly ill-suited to the true nature of this task:  unpack
various tarballs, and rearrange them like so.

Finishing a Windows release of Zope 2 or Zope 3 takes much longer than
just minutes, unless you skip testing.  If you do skip testing, then
it's minutes for both.  Testing Zope as a Windows service is harder
for Zope 3, because the Zope 3 installer doesn't (but the Zope 2
installer does) install or start the service, or auto-stop and remove
the service when Zope is uninstalled.  BTW, Zope3 _could_ do that too
with a suitable post-install/pre-uninstall script, which is something
InnoSetup automates for Zope2.

It can take a Windows expert some days to author Zope2
build-the-installer changes when packaging fashions change (whether
Zope's or the repackaged components').  InnoSetup is the least of the
problems there, and while MSI is the coming fashion, slinging MSI code
appears to require much more knowledge than slinging InnoSetup
declarations.

The idea that it takes Windows expertise to write an InnoSetup
declaration is wrong:  such lines merely say take the files you find
_here_ now, and put them _there_ when the installer runs.  For
example, this is the entire Inno code needed to install Zope 2's lib/
directory:

Source:lib\*.*; DestDir: {app}\lib; Flags: ignoreversion recursesubdirs

That kind of stuff is truly trivial.  It does take Inno expertise to
create and manage the installer's dialog screens (manage == e.g., if
the user chooses not to have the installer create an instance home,
then the dialog asking for the instance home's directory shouldn't be
shown), but those typically don't change across releases.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Removing 'inst'

2006-01-15 Thread Tim Peters
[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 aesthetics ;).

That all sounds good to me, assuming people still find a Makefile to
be useful (I've been on Windows for a lng time now ;-)).
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Where oh where is Repozo

2006-01-15 Thread Tim Peters
[Jonathan Cyr]
 Where is the latest version of Repozo, the backup tool, kept?

 Is there a reason, that it's not included with the Zope
 install/utilities (at least the 2.7.x I'm using).

[... time passes ...]

 Thanks for the quick response, I noticed that the my WinXP Zope
 (sandbox) doesn't have it, but my production SuSE Linux does.

It's in my WinXP Zope-2_7-branch sandbox:

C:\Code\Zope-2_7-branchdir/b utilities\ZODBTools\rep*
repozo.py

It's also in Zope 2.8 branch, 2.9 branch, and current Zope trunk.

For some reason (oversight?), Zope3 does not include ZODB tools, but
you should find them in every flavor of Zope2 (and of course a CVS or
SVN sandbox gets you the same stuff no matter which platform you use
to do the checkout).
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk Removed long-broken `test_zope` target.

2006-01-14 Thread Tim Peters
Log message for revision 41312:
  Removed long-broken `test_zope` target.
  

Changed:
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk

-=-
Modified: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk 
2006-01-13 23:26:31 UTC (rev 41311)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk 
2006-01-14 15:28:53 UTC (rev 41312)
@@ -6,13 +6,6 @@
 REQUIRED_FILES=$(PYTHON_REQUIRED_FILES)\
$(ZOPE_REQUIRED_FILES)
 
-# run the Zope tests
-# XXX This is out of date and can't work.
-test_zope:
-   $(CD) $(BASE_DIR)/src/Zope
-   $(PYPCBUILDDIR)/python.exe utilities/testrunner.py -a
-   $(CD) $(BASE_DIR)
-
 clean_zope:
$(RMRF) src/$(ZOPEDIRNAME)
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


Re: [Zope-dev] Re: Seeking brave souls to try Zope 2.9 Windows installer

2006-01-14 Thread Tim Peters
[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 else, but I
don't know what.  For example, when logged in to the installed Zope as
admin, I had no problems creating new users from the acl_users
thingie.

 And of course zopectl doesn't work, so zopectl adduser
 is out of the question. Luckily creating an inituser still works! :-)

 Also, installing the shell files runzope and zopectl is kinda
 pointless.

I'm sure the Zope 2.8 (etc) Windows installers did the same here. 
This is controlled by the content of the top-level (in a Zope
checkout) skel/ directory:

C:\Code\Zope2.9dir/b skel\bin
runzope.bat.in
runzope.in
zopectl.in
zopeservice.py.in

So (exactly) those 4 things (without the .in suffix) get created in
an instance home's bin/ directory, regardless of platform.

Someone may wish to change Zope's utilities/mkzopeinstance.py to do
different things on different platforms, but that's out of scope for
this little project (which makes changes only under Zope's
inst/WinBuilders/:  the Windows installer-builder code).

 Minor, I know, but it means you have to typetab twice when
 tab expanding to run runzope in from a commandline. ;-)

?  Assuming you're running a native Windows NT+ shell (cmd.exe), you
set tab as your file completion character, and you're using NTFS as
the filesystem (so that tab completion suggests possibilities in
alphabetical order), then the sequence

r TAB

in an instance's bin directory completes to

runzope

and that's what you want. That doesn't actually run the file named
runzope, it actually runs the file named runzope.bat on Windows. 
I'm starting to suspect you don't normally use Windows, Lennart ;-)  I
certainly agree there's no _reason_ to create the runzope file to
begin with on Windows (except perhaps to keep mkzopeinstance.py
simple), but it doesn't actually get in the way of using tab
completion.

 When you run the instance creation you get a commandline, but you have
 no idea where the current directory is, so if you just type in a
 relative path, you don't know where the directory was created. (Turns
 out it's in C:\Documents And Settings\username\ )

I'm sure all earlier Zope Windows installers created stuff that did
the same here too.  If that isn't wanted, then Zope's
utilities/mkzopeinstance.py is again the thing that would need to be
changed.

 That's it so far! Great job!

Thank you for trying it!  I'm just relieved it didn't melt your hard drive ;-)
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/README.txt Partially-working new instructions for running the tests.

2006-01-13 Thread Tim Peters
Log message for revision 41300:
  Partially-working new instructions for running the tests.
  
  The functional tests don't even try to run, but at least this
  exercises 6724 of the unit tests.
  
  Someone who understands how Zope3 testing was changed to work
  from a zpkgtools-based install should be able to figure out
  how to improve this.
  

Changed:
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/README.txt

-=-
Modified: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/README.txt
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/README.txt 
2006-01-13 15:10:42 UTC (rev 41299)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/README.txt 
2006-01-13 15:25:28 UTC (rev 41300)
@@ -110,21 +110,44 @@
 Testing Zope
 
 
-The test suite can be run from inst\build\:
+XXX This doesn't work right starting with Zope 2.9:  it's clumsier than it
+XXX should be, and the functional tests don't even try to run (just the
+XXX unit tests).
+XXX Someone who understands how Zope3 testing from a zpkgtools-tarball build
+XXX was made to work again may be able to help here.
 
+The test suite can be run from inst\build\, after building the installer.
+
 - Open a native (not Cygwin) DOS box.  We want to test with the Python the
-  Zope installer includes.
-- cd to inst\build
-- Copy log.ini from the root of the Zope checkout.  This isn't necessary for
-  the tests to pass, but if you don't do it a great many spurious log
-  messages will be displayed on the console, some of which look like
-  errors (some of the tests deliberately provoke errors).
-- Enter
+  Zope installer includes, in an all-native environment, to match what
+  the installer-installed code will do as closely as possible.
 
-  bin\python bin\test.py -v --all
+- cd inst\build
 
+- Copy log.ini from the root of the Zope _checkout_ -- it's not included
+  in the tarball::
+
+  copy ..\..\log.ini .
+
+  Copying log.ini isn't necessary for the tests to pass, but if you don't
+  do it a great many spurious log messages will be displayed on the
+  console, some of which look like errors (some of the tests deliberately
+  provoke errors).
+
+- Copy test.py from the unpacked tarball::
+
+  copy ..\src\$(ZOPE_VERSION)\test.py .
+
+- Enter::
+
+  bin\python test.py -vv -m !^zope[.]app[.] --all
+
   or whatever variation you like best.  All tests should pass.
 
+  Note that zope.app tests should be excluded because not all of them _can_
+  pass (this isn't a Windows thing, it's a temporary all-platform wart
+  due to missing bits from Zope3).
+
 Also run the Windows installer, and play with the Zope it installs.
 
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk Stop hiding the line that builds version.txt.

2006-01-13 Thread Tim Peters
Log message for revision 41301:
  Stop hiding the line that builds version.txt.
  
  Don't know why it was hidden before, but can't think of a
  reason, and the lack of makefile output showing its creation
  just confused the heck out of me for 10 minutes ;-).
  

Changed:
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk

-=-
Modified: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk 
2006-01-13 15:25:28 UTC (rev 41300)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk 
2006-01-13 15:46:50 UTC (rev 41301)
@@ -65,7 +65,7 @@
cd $(SRC_DIR)/$(ZOPEDIRNAME)  \
$ install.py install --no-compile --home=../../build \
--install-headers=../../build/bin/Include/nonsense
-   @echo Zope $(ZOPEVERSION)  $@
+   echo Zope $(ZOPEVERSION)  $@
$(TOUCH) $@
 
 # This merely unpacks the Zope tarball.

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/bin/makezope.bat Remove unused file.

2006-01-13 Thread Tim Peters
Log message for revision 41307:
  Remove unused file.
  
  The build-the-Windows-installer dance used to use it.
  

Changed:
  D   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/bin/makezope.bat

-=-
Deleted: 
Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/bin/makezope.bat
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/bin/makezope.bat   
2006-01-13 17:03:38 UTC (rev 41306)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/bin/makezope.bat   
2006-01-13 17:08:27 UTC (rev 41307)
@@ -1,4 +0,0 @@
-cd %1%
-set MAKEFLAGS=
-nmake build
-nmake install

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-dev] Re: Seeking brave souls to try Zope 2.9 Windows installer

2006-01-13 Thread Tim Peters
[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 weeks, I'll check email each
day, and will be happy to give minor wink help with mysteries.  The
build-the-installer code got substantially simpler, but I think it's
hard to jump in cold and understand it (in part because the
makefile-maze infrastructure is better suited to more complicated jobs
than this one has become).  WinBuilders/README.txt is the best place
to start, and I tried to leave it telling only truths on the branch.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Removing 'inst'

2006-01-13 Thread Tim Peters
[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, but if that's true then I expect
inst/configure.py is also still useful (it looks like configure.py is
the intended way to create an actual makefile from the Makefile.in
template).

One thing for sure is that it will be helpful to get rid of as many
decoys as possible; e.g., I burned several hours staring at the stuff
in inst/ wondering how to make it work again, then digging in to why
it existed at all, and finally concluding that everything it ever did
is of no use on Windows anymore ;-).

 I propose moving those two items to the root and remove 'inst'.

I'd rather just remove the decoys.  The process of building a Windows
installer needs/creates three not-checked-in directories that are
siblings of WinBuilders, and it's nicer to have those hiding under
inst/ than cluttering the root of a checkout.

The Windows stuff will have no use for anything other than
WinBuilders/, so if Makefile.in's Linux purpose would be better served
by moving that elsewhere, that would be fine.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Removing 'inst'

2006-01-13 Thread Tim Peters
[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, except for the
inst/WinBuilders/ subdirectory.

(Note that I haven't removed inst/Makefile.win.in on the branch,
because I promised to change only stuff under inst/WinBuilders/ on
that branch.)
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/ Pain, pain, and more pain.

2006-01-12 Thread Tim Peters
Log message for revision 41291:
  Pain, pain, and more pain.
  
  The build-the-installer process now completes, and running
  the installer creates something that may or may not be a
  working Zope.  It starts fine as a Windows Service, and at
  least looks like a Zope ;-)
  
  Nothing in the build-the-Windows-installer process here
  uses anything in the root of the inst/ directory anymore.
  Instead the WinBuilders zope.mk builds Zope all by itself,
  using the Python created by python.mk.  Everything these
  used to use in the root of the inst/ directory was so out
  of whack with current reality that there was no point even
  trying to reverse-engineer what it thought it was doing.
  
  Note that comments in the code highlight what look like
  bugs in distutils, and in the Windows xcopy command (that
  last one took hours to track down -- sheesh).
  

Changed:
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/etc/zope.iss.in
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/common.mk
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk

-=-
Modified: 
Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/etc/zope.iss.in
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/etc/zope.iss.in
2006-01-12 19:36:15 UTC (rev 41290)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/etc/zope.iss.in
2006-01-12 23:38:13 UTC (rev 41291)
@@ -31,13 +31,13 @@
 Source: MAKEFILEDIR\etc\README.html; DestDir: {app}; Flags: 
ignoreversion
 Source:bin\*.*; DestDir: {app}\bin; Flags: ignoreversion recursesubdirs
 Source:doc\*.*; DestDir: {app}\doc; Flags: ignoreversion recursesubdirs
-Source:import\*.*; DestDir: {app}\import; Flags: ignoreversion 
recursesubdirs
 Source:lib\*.*; DestDir: {app}\lib; Flags: ignoreversion recursesubdirs
 Source:skel\*.*; DestDir: {app}\skel; Flags: ignoreversion recursesubdirs
+Source:zopeskel\*.*; DestDir: {app}\zopeskel; Flags: ignoreversion 
recursesubdirs
 ; these are required to be put into the bin directory for proper function of 
NT services
 Source:bin\Lib\site-packages\win32\PythonService.exe; DestDir: {app}\bin; 
Flags: ignoreversion
-Source:bin\Lib\site-packages\pywin32_system32\PyWinTypes23.dll; DestDir: 
{app}\bin; Flags: ignoreversion
-Source:bin\Lib\site-packages\pywin32_system32\PythonCOM23.dll; DestDir: 
{app}\bin; Flags: ignoreversion
+Source:bin\Lib\site-packages\pywin32_system32\PyWinTypes24.dll; DestDir: 
{app}\bin; Flags: ignoreversion
+Source:bin\Lib\site-packages\pywin32_system32\PythonCOM24.dll; DestDir: 
{app}\bin; Flags: ignoreversion
 ; This is a helper module for manging registry entries at uninstall time
 Source: MAKEFILEDIR\bin\fixreg.py; DestDir: {app}\bin; Flags: 
ignoreversion
 

Modified: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/common.mk
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/common.mk   
2006-01-12 19:36:15 UTC (rev 41290)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/common.mk   
2006-01-12 23:38:13 UTC (rev 41291)
@@ -17,7 +17,17 @@
 RMRF=rm -rf
 CD=cd
 
-XCOPY=xcopy /i /s /e /y
+# xcopy args:
+# /i = if dest doesn't exist and source has more than one file, assume
+#  dest shoud be a directory
+# /y = don't prompt about overwriting dest if it exists -- just do it
+# /s = recurse, copying non-empty subdirectories too
+# CAUTION:  don't use /e unless you have to!  /e copies empty subdirectories
+# too, but has another truly bizarre behavior:  if you use xcopy to copy
+# a single file, and use /e, it creates empty subdirectories in the target's
+# directory with the same names as the subdirectories in the source's
+# directory.  This is worse than useless.
+XCOPY=xcopy /i /s /y
 
 CPR=cp -r
 CP=cp

Modified: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk   
2006-01-12 19:36:15 UTC (rev 41290)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk   
2006-01-12 23:38:13 UTC (rev 41291)
@@ -112,8 +112,7 @@
$(XCOPY) $(WIN_PYINSTALLEDDIR)\$(PYMAJORMINOR).dll \
$(WIN_BUILD_DIR)\bin
$(XCOPY) $(WIN_MAKEFILEDIR)\bin\msvcr71.dll $(WIN_BUILD_DIR)\bin
-   $(XCOPY) $(WIN_PYINSTALLEDDIR)\libs\$(PYMAJORMINOR).lib \
-   $(WIN_BUILD_DIR)\bin\libs
+   $(XCOPY) $(WIN_PYINSTALLEDDIR)\libs $(WIN_BUILD_DIR)\bin\libs
$(XCOPY) $(WIN_PYINSTALLEDDIR)\DLLs\*.pyd \
$(WIN_BUILD_DIR)\bin\DLLs
 

Modified: 

[Zope-dev] Seeking brave souls to try Zope 2.9 Windows installer

2006-01-12 Thread Tim Peters
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:

//svn.zope.org/repos/main/Zope/branches/tim-2.9-windows-installer

which was branched off the 2.9 tag.  All changes on the branch are
under inst/WinBuilders/, so the idea is that when this works, it can
be merged into the 2.9 tag as well as the trunk (the stuff under
WinBuilders/ isn't used for anything except building a Windows
installer, and on the 2.9 tag the WinBuilders/ part is wholly broken).

It's in a state now where it's not obviously broken to my eyes, but I
have little experience running Zope2 so my eyes aren't reliable here. 
People on Windows who want to try it, knowing in advance that it may
be broken in various ways, can download an experimental installer:

Zope-Experimental-2.9.0-win32.exe

from my member page:

http://www.zope.org/Members/tim_one

Please report problems to zope-dev, not to me directly.  After
tomorrow, I'll be on vacation for 2 weeks, and won't be terribly
responsive :-)

Note that I'm copying Sidnei in the hope that he can be persuaded to
take up the slack.  If there are problems, they're likely to be in the
layout of the code:  missing pieces, wrong directories, stuff like
that.  The 2.9 tarball's install.py installed everything it was told
to install, and if there are problems there they're in Zope 2.9, not
in the chain of code building the Windows installer.  Nevertheless,
the Windows installer could be taught to patch over them.  And, of
course, the build-the-installer dance may introduce new errors of its
own.

I hope it works for someone ;-)
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/ Zope 2.9 went out without working code to build a Windows installer.

2006-01-11 Thread Tim Peters
Log message for revision 41263:
  Zope 2.9 went out without working code to build a Windows installer.
  This is a branch from the 2.9 tag to try to repair that.
  Changes here will be limited to the WinBuilder stuff.
  

Changed:
  A   Zope/branches/tim-2.9-windows-installer/

-=-
Copied: Zope/branches/tim-2.9-windows-installer (from rev 41262, 
Zope/tags/2.9.0)

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk For whatever reason, the tarball for 2.9.0 dropped -final from its name.

2006-01-11 Thread Tim Peters
Log message for revision 41268:
  For whatever reason, the tarball for 2.9.0 dropped -final from its name.
  The makefile has to know the actual name.
  

Changed:
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk

-=-
Modified: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk 
2006-01-11 16:42:09 UTC (rev 41267)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk 
2006-01-11 16:47:01 UTC (rev 41268)
@@ -3,7 +3,7 @@
 REQUIRED_FILES=$(PYTHON_REQUIRED_FILES)\
$(ZOPE_REQUIRED_FILES)
 
-ZOPEVERSION=2.9.0-final
+ZOPEVERSION=2.9.0
 ZOPEDIRNAME=Zope-$(ZOPEVERSION)
 
 MAKEZOPE=$(MAKEFILEDIR)/bin/makezope.bat $(WIN_BUILD_DIR)

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk Python 2.4.2 is needed now.

2006-01-11 Thread Tim Peters
Log message for revision 41277:
  Python 2.4.2 is needed now.
  

Changed:
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk

-=-
Modified: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk   
2006-01-11 19:13:44 UTC (rev 41276)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk   
2006-01-11 19:20:13 UTC (rev 41277)
@@ -1,10 +1,10 @@
 # The Python and pywin32 versions.  For Python, both the source tarball
-# and the Windows installer must be in tmp/.  For pywin32 (previously known 
+# and the Windows installer must be in tmp/.  For pywin32 (previously known
 # as win32all), the Windows installer must be in tmp/.  Nothing beyond those
 # is required to build Python, and you don't even need a compiler.
 PYVERSION_MAJOR=2
-PYVERSION_MINOR=3
-PYVERSION_PATCH=5
+PYVERSION_MINOR=4
+PYVERSION_PATCH=2
 PYVERSION=$(PYVERSION_MAJOR).$(PYVERSION_MINOR).$(PYVERSION_PATCH)
 W32ALLVERSION=205
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk Untested first stab at moving to Python 2.4.2.

2006-01-11 Thread Tim Peters
Log message for revision 41278:
  Untested first stab at moving to Python 2.4.2.
  

Changed:
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk

-=-
Modified: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk   
2006-01-11 19:20:13 UTC (rev 41277)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/python.mk   
2006-01-11 19:56:27 UTC (rev 41278)
@@ -1,65 +1,60 @@
-# The Python and pywin32 versions.  For Python, both the source tarball
-# and the Windows installer must be in tmp/.  For pywin32 (previously known
-# as win32all), the Windows installer must be in tmp/.  Nothing beyond those
-# is required to build Python, and you don't even need a compiler.
-PYVERSION_MAJOR=2
-PYVERSION_MINOR=4
-PYVERSION_PATCH=2
-PYVERSION=$(PYVERSION_MAJOR).$(PYVERSION_MINOR).$(PYVERSION_PATCH)
-W32ALLVERSION=205
-
-# CAUTION:  Extracting files from Wise installers doesn't really do what
-# you expect.  While a Wise installer is a zip file, the zip file
-# structure is flat (Wise reconstructs the intended directory structure
-# from metadata stored in proprietary FILE.DAT files also in the
-# zip file).  Consequently, the package structure of Python packages is
-# lost, and if there's more than one file with the same name, you only
-# get the last one to be extracted (all files are extracted to the
-# same directory).
+# The Python and pywin32 versions.
 #
-# For Python, this doesn't matter, because we're only sucking out the
-# precompiled .pyd and .exe files from the Python installer -- there
-# are no name clashes in that set, and it's a pretty safe bet there never
-# will be (else Python wouldn't be able to decide which to use!).  We
-# use the Python source tarball to get all the non-executable parts we
-# need.
+# For Python, the source tarball must be in tmp/.  You must also install the
+# appropriate Python on Windows, and set WIN_PYINSTALLEDDIR here to its root
+# directory.  A copy of the main Python DLL must also be in the root (you
+# may need to copy it from your Windows system directory).  Earlier versions
+# of this extracted .dll, .exe, and .pyd files from Python's Wise installer,
+# but Python 2.4 uses an .msi installer, and there doesn't appear to be a
+# way to _just_ extract files from one of those.
 #
-# pywin32 doesn't have this problem as it now uses
-# a standard distutils 'bdist_wininst' installation .exe. These executables are
-# valid .zip files with a PLATLIB directory being the complete directory
-# structure as installed into site-packages. These recent pywin32 builds have
-# no dependencies on registry settings etc so will work directly as copied out 
of
-# the .exe. The only concerns are the pywintypes/pythoncom dlls, which is
-# handled by the Inno installer
+# For pywin32 (previously known as win32all), the Windows installer must be
+# in tmp/.
+#
+# Nothing beyond those is required to build Python, and you don't even need
+# a compiler.
+PYVERSION_MAJOR := 2
+PYVERSION_MINOR := 4
+PYVERSION_PATCH := 2
+W32ALLVERSION := 205
 
-PYDIRNAME=Python-$(PYVERSION)
-# Standard bdist_wininst name - eg: pywin32-203.win32-py2.3[.exe]
-W32ALLDIRNAME=pywin32-$(W32ALLVERSION).win32-py$(PYVERSION_MAJOR).$(PYVERSION_MINOR)
-W32EXCLUDE=*.chm
+PYVERSION := $(PYVERSION_MAJOR).$(PYVERSION_MINOR).$(PYVERSION_PATCH)
 
+PYMAJORMINOR := python$(PYVERSION_MAJOR)$(PYVERSION_MINOR)
+
+# This is the default directory into which a Python installs.
+WIN_PYINSTALLEDDIR := \$(PYMAJORMINOR)
+
+# pywin32 now uses a standard distutils 'bdist_wininst' installation .exe.
+# These executables are valid .zip files with a PLATLIB directory being
+# the complete directory structure as installed into site-packages.  These
+# recent pywin32 builds have no dependencies on registry settings etc so
+# will work directly as copied out of the .exe.  The only concerns are the
+# pywintypes/pythoncom dlls, which are handled by the Inno installer.
+
+PYDIRNAME := Python-$(PYVERSION)
+# Standard bdist_wininst name - eg: pywin32-203.win32-py2.3
+W32ALLDIRNAME := 
pywin32-$(W32ALLVERSION).win32-py$(PYVERSION_MAJOR).$(PYVERSION_MINOR)
+W32EXCLUDE := *.chm
+
 # The Python tarball is extracted to PYSRCDIR.
-# The contents of the Python installer get extracted to PYEXTRACTDIR.
-# The  win32all  W32EXTRACTDIR.
-PYSRCDIR=$(BASE_DIR)/src/$(PYDIRNAME)
-PYEXTRACTDIR=$(BASE_DIR)/src/$(PYDIRNAME)-extract
-W32EXTRACTDIR=$(BASE_DIR)/src/$(W32ALLDIRNAME)
+# pywin32 is extracted to W32EXTRACTDIR.
+PYSRCDIR := $(BASE_DIR)/src/$(PYDIRNAME)
+W32EXTRACTDIR := $(BASE_DIR)/src/$(W32ALLDIRNAME)
 
-WIN_PYSRCDIR=$(shell cygpath -w $(PYSRCDIR))
-WIN_PYEXTRACTDIR=$(shell cygpath -w $(PYEXTRACTDIR))
-WIN_W32EXTRACTDIR=$(shell cygpath -w $(W32EXTRACTDIR))
+WIN_PYSRCDIR := $(shell cygpath -w $(PYSRCDIR))
+WIN_W32EXTRACTDIR := 

[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/common.mk Use immediate assignment to (greatly) speed the

2006-01-11 Thread Tim Peters
Log message for revision 41282:
  Use immediate assignment to (greatly) speed the
  heavily used utility variables that call out to a shell.
  

Changed:
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/common.mk

-=-
Modified: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/common.mk
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/common.mk   
2006-01-11 20:17:37 UTC (rev 41281)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/common.mk   
2006-01-11 20:24:37 UTC (rev 41282)
@@ -1,12 +1,13 @@
-BASE_DIR=$(shell pwd)
-WIN_BASE_DIR=$(shell cygpath -w $(BASE_DIR))
-BUILD_DIR=$(BASE_DIR)/build
-WIN_BUILD_DIR=$(shell cygpath -w $(BUILD_DIR))
-SRC_DIR=$(BASE_DIR)/src
-WIN_SRC_DIR=$(shell cygpath -w $(SRC_DIR))
-TMP_DIR=$(BASE_DIR)/tmp
-WIN_TMP_DIR=$(shell cygpath -w $(TMP_DIR))
-WIN_MAKEFILEDIR=$(shell cygpath -w $(MAKEFILEDIR))
+# Use immediate assignment to avoid calling out to the shell a zillion times.
+BASE_DIR := $(shell pwd)
+WIN_BASE_DIR := $(shell cygpath -w $(BASE_DIR))
+BUILD_DIR := $(BASE_DIR)/build
+WIN_BUILD_DIR := $(shell cygpath -w $(BUILD_DIR))
+SRC_DIR := $(BASE_DIR)/src
+WIN_SRC_DIR := $(shell cygpath -w $(SRC_DIR))
+TMP_DIR := $(BASE_DIR)/tmp
+WIN_TMP_DIR := $(shell cygpath -w $(TMP_DIR))
+WIN_MAKEFILEDIR := $(shell cygpath -w $(MAKEFILEDIR))
 
 # Root of the Windows drive you're working on.  The setting here is for
 # the C: drive and using a default out-of-the-box Cygwin.
@@ -63,4 +64,4 @@
$(CP) $ $@
unix2dos $@
$(TOUCH) $@
-endef
\ No newline at end of file
+endef

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk Moved version number to top of file.

2006-01-11 Thread Tim Peters
Log message for revision 41284:
  Moved version number to top of file.
  

Changed:
  U   Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk

-=-
Modified: Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk
===
--- Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk 
2006-01-11 20:29:07 UTC (rev 41283)
+++ Zope/branches/tim-2.9-windows-installer/inst/WinBuilders/mk/zope.mk 
2006-01-11 21:02:46 UTC (rev 41284)
@@ -1,3 +1,6 @@
+ZOPEVERSION := 2.9.0
+ZOPEDIRNAME := Zope-$(ZOPEVERSION)
+
 ZOPE_REQUIRED_FILES=tmp/$(ZOPEDIRNAME).tgz
 
 REQUIRED_FILES=$(PYTHON_REQUIRED_FILES)\
@@ -3,7 +6,4 @@
$(ZOPE_REQUIRED_FILES)
 
-ZOPEVERSION=2.9.0
-ZOPEDIRNAME=Zope-$(ZOPEVERSION)
-
 MAKEZOPE=$(MAKEFILEDIR)/bin/makezope.bat $(WIN_BUILD_DIR)
 # run the Zope tests

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


Re: [ZODB-Dev] Re: [Zope-dev] Re: zLOG module deprecated

2006-01-10 Thread Tim Peters
[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 Zope folk generally want more than the 5 logging levels that come
built in to Python's logging module, that's easy to supply, but then
it's also important that they define them with the same names and
numeric values.  ZODB's loglevels.py does so, and is the only
extension to Python's logging module ZODB made.  This is the code in
its entirety (but skipping the copyright boilerplate at the top --
Copyright (c) 2004 Zope Corporation and Contributors):


import logging

__all__ = [BLATHER, TRACE]

# In the days of zLOG, there were 7 standard log levels, and ZODB/ZEO used
# all of them.  Here's how they map to the logging package's 5 standard
# levels:
#
#zLOG logging
#----
#PANIC (300)  FATAL, CRITICAL (50)
#ERROR (200)  ERROR (40)
#WARNING, PROBLEM (100)   WARN (30)
#INFO (0) INFO (20)
#BLATHER (-100)   none -- defined here as BLATHER (15)
#DEBUG (-200) DEBUG (10)
#TRACE (-300) none -- defined here as TRACE (5)
#
# TRACE is used by ZEO for extremely verbose trace output, enabled only
# when chasing bottom-level communications bugs.  It really should be at
# a lower level than DEBUG.
#
# BLATHER is a harder call, and various instances could probably be folded
# into INFO or DEBUG without real harm.

BLATHER = 15
TRACE = 5
logging.addLevelName(BLATHER, BLATHER)
logging.addLevelName(TRACE, TRACE)


When ZODB wants to use BLATHER or TRACE, it imports the symbolic name
from ZODB.loglevels instead of from logging.  That's all there is to
it -- it's trivial.  If Zope decided to keep BLATHER and TRACE too,
then a future ZODB release would presumably change to import BLATHER
and TRACE from the same place Zope gets them.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Twice-annual releases and bugfixes?

2006-01-09 Thread Tim Peters
[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 applies to the 'j' position in i.j.k (like
moving from Zope 2.9 to Zope 2.10).  Those can introduce new features.
 Changes only in the 'k' position are bugfix-only releases, and in
theory there could another one of those every day ;-).
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] RE: [ZODB-Dev] Re: zLOG module deprecated

2006-01-09 Thread Tim Peters
[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 bare-metal ZEO communications.  Only someone trying to debug
low-level ZEO socket or protocol problems would want to use TRACE.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: zLOG module deprecated

2006-01-09 Thread Tim Peters
[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 additional named levels
as you feel like adding, and ZODB added BLATHER and TRACE
zLOG-workalike levels at the time ZODB was converted to use the
logging package.  People may want to restrict themselves to using
logging's built-in levels, but logging was designed to be extended in
this way, so there's no technical barrier here.  In particular, nobody
would want to get ZEO's voluminous but micro-purpose TRACE output at
debug level.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Zope 2.8.5 install

2006-01-09 Thread Tim Peters
[Robert Conner]
 Thanks for compiling that and setting up the windows installer.
 However, I don't believe it works. Sorry it took me so long to get
 back to you. I wanted to try installing this on a second computer
 before I wrote back. On both of them it

What is it?  Please spell out exactly what you did.  The installer
was tested on Win XP Pro SP2 and worked fine there.  I just downloaded
it again, and had no problems:

- Ran the installer, and accepted all the defaults.

- In particular, accepting all the defaults runs Zope as a Windows service, so
  Zope starts automatically, and the installer brings up the

 Zope Windows Binary Post-Installation QuickStart

  page in a broswer.

- I clicked on Zope Management Interface in that, and entered the admin
  password I gave to the installer when it asked for one.

- I was then logged in to the ZMI, in a running Zope 2.8.5.

I have no idea what you did, because you really didn't say ;-)

 starts the cmd window and displays the command called to run,

Sorry, I'm not picturing what you did at all.  Needs more words.

 and then fails to finish the load up or start the server. Possibly it does 
 work
 and both of my systems are configured wrong, but I couldn't get either install
 to run.

So I'll try something else:

- I stopped the Zope service (by using the Windows Services applet).

- Opened a DOS box and cd'ed to the root of the instance home (\Zope-Instance,
  the default created by the installer).

- Typed bin\runzope and hit ENTER.  This is exactly what was displayed in
  the console then:

C:\Zope-Instancebin\runzope

C:\Zope-InstanceC:\Program Files\Zope-2.8.5-final\bin\python.exe
C:\Program Files\Zope-2.8.5-final\lib\python\Zope2\
Startup\run.py -C C:\Zope-Instance\etc\zope.conf

There isn't more output, and more isn't expected.

- Waited a while ;-), then opened a browser and typed

  http://localhost:8080/manage

  in the address bar.

- Once again I was then logged in to the ZMI, in a running Zope 2.8.5.

Or another way (something I'd never do in real life, but I guess some
people do):

- Shut down Zope from the last try.

- Clicked Start - All Programs - Zope 2.8.5-final - Run Zope In Console
  That should be the same as typing bin\runzope by hand as in the last try,
  and indeed it worked the same way.

Did you try one of those ways?  If so, which one?  If not, what did
you try?  If you tried the third way and the goofy little DOS box
vanished, try the second way instead.  You may get to see a relevant
error message then.  Also look in your instance's var\log\event.log. 
If you're running as a Windows service, look in the Windows
Application and System event logs too.  One particular problem when
running as a service is that Windows Firewall will _not_ prompt you if
it blocks a socket started from a service.  Instead the service hangs
or dies.

 Also, Zope 2.9 is out, if you had planned to make a Windows binary for
 that also.

At this point it's unclear what will happen for that.  Zope 2.9
switches from Python 2.3.5 to Python 2.4.2, and uses zpkgtools for the
first time to package the distribution.  Consequences include that the
code used to build pre-2.9 Zope Windows installers can't work to build
one for 2.9 too.  An unknown amount of new work is needed there, and
AFAICT nobody is working on it.
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Zope 2.8.5 install

2006-01-09 Thread Tim Peters
[Robert Conner]
 Well color me purple, it does work.

Good!  How could anything on Windows fail to work ;-)?

 I was just so used to seeing the Zope Ready to handle Requests
 message that when it never appeared I just assumed it was not working
 at all. I've broken Zope on my computer 100 times and always when its
 broken it does not display Zope Ready to handle Requests. I won't
 make any more excuses for myself here, they don't help anything. Man,
 I'm sorry for the inconvenience.

Not a problem:  if one person doesn't understand what they're seeing,
then at least a hundred more won't understand it either, and it's very
good to have a discussion about it archived on a public mailing list
then.

FWIW, I don't know why Zope doesn't display anything useful in the
console anymore, and I don't even know whether that's unique to
Windows.

 Or another way (something I'd never do in real life, but I guess some
 people do)

 I always run Zope in the console.

So do I, but there's difference:  I open a DOS box and type
bin\runzope myself.  What I never do is use the Start menu
shortcut.  A DOS box you open yourself stays visible even if Zope
dies ungracefully, and after the first time you type bin\runzope you
only have to hit two keys (up-arrow ENTER) to start it again.

 The only reason I even use the Windows version is for development. As far as 
 I can
 tell the fastest way for me to stop and restart Zope if to close down the 
 command
 window and then start it back up again. When I develop, I restart Zope
 all the freeking time, so the faster the restart, the better.

Doesn't the ZMI have a restart Zope button?  If you open your own
DOS box, then a sloppy all-keyboard restart dance is Ctrl+Break
up-arrow ENTER, and a careful all-keyboard restart dance is Ctrl+C
up-arrow ENTER.  The latter gives Zope a chance to close files
gracefully, but by the same token it takes longer for Zope to shut
down.  Ctrl+Break kills the process instantly (and runs some risk of
leaving data in I/O buffers without writing it to disk).
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope-dev] Re: SVN: Zope/branches/2.9/ Move to ZODB 3.6 final.

2006-01-06 Thread Tim Peters
[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 a tag is conceptually read-only, sometimes people do make changes
  on tags.  You can't cheat (or get screwed by someone else cheating) with
  -r N, though,

- Updates to a different revision on the same SVN path typically go much faster,
  replacing only the files that have changed.  When the SVN path changes (as
  was true when stitching in ZODB by tag), the entire project is
refetched.  When
  moving from ZODB 3.6.0b6 to 3.6.0 final, that's the difference between getting
  all the ZODB code again, or just getting the 3 (or so) files that
changed (more
  files than that _did_ change in ZODB 3.6 final, but Zope doesn't
include them --
  the others are part of the standalone ZODB release).

- When the SVN path changes, people who leave old .pyc (or other not-checked-in)
  files behind end up with OLD.n directories created by SVN too.

Overall, I like tags better myself:

- They're self-documenting.

- I never leave old .pyc (etc) files around, always recompile everything, and
  do something else while `svn up` is running, so in all I just don't notice any
  of the bad aspects of using tags.

- It's less error-prone to edit svn:externals to change a character or two in a
  mnemonically-named tag path than to replace an arbitrary-looking revision
  number.

For example, I stitched ZODB 3.6 into 4 Zopes yesterday, doing
propedit on 8 directories total.  I screwed it up at first but didn't
notice until after running tests, and then had to repair it and run
them all over again:  it turned out that the older -r 41065 wasn't
unique to ZODB in all of them.  s/41065/41153/g was semantically
wrong, unintentionally updating some _non_-ZODB externals to rev 41553
too.  If we had stuck to using tags, s/3.6.0b6/3.6.0/g would been
right the first time around.

So there are tradeoffs, and people won't agree on which is best
overall.  Jim has a strong preference for -r N, and much stronger
than my will to argue about it ;-)
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: SVN: Zope/branches/2.9/ Move to ZODB 3.6 final.

2006-01-06 Thread Tim Peters
[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 module...that's very time
 consuming. I see this as a major risk factor when working on releases.

If you want the tag style for ZODB in Zope 2.9 and Zope trunk, I doubt
anyone would yell at you if you changed them to use the ZODB 3.6 tag
instead (pieces of ZODB are stitched in under lib/python/, doc/, and
utilities/ in Zope 2, so that requires propedit'ing 3 directories).

Because ZODB has its own advertised version number (ZODB.__version__,
ZEO.version, and src/ZEO/version.txt), I always make a new tag for a
new ZODB release (whether internal or external).  ZODB isn't like,
e.g., zope.testing in that way (and I understand why Jim would think
it a pain to make a new tag of zope.testing for every little change
there).
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-Checkins] SVN: Zope/branches/2.9/ Move to ZODB 3.6.0b6.

2006-01-01 Thread Tim Peters
Log message for revision 41069:
  Move to ZODB 3.6.0b6.
  

Changed:
  _U  Zope/branches/2.9/doc/
  _U  Zope/branches/2.9/lib/python/
  _U  Zope/branches/2.9/utilities/

-=-

Property changes on: Zope/branches/2.9/doc
___
Name: svn:externals
   - ZEO  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/doc/ZEO

   + ZEO  -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/doc/ZEO



Property changes on: Zope/branches/2.9/lib/python
___
Name: svn:externals
   - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ZopeUndo
zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   -r 40992 
svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/pytz
zodbcode   -r 40992 
svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/zodbcode
ClientCookie   -r 40992 
svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/ClientCookie
mechanize  -r 40992 
svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/mechanize

   + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees -r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/BTrees
persistent -r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/persistent
ThreadedAsync  -r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ThreadedAsync
transaction-r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/transaction
ZEO-r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZEO
ZODB   -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZODB
ZopeUndo   -r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZopeUndo
zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   -r 40992 
svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/pytz
zodbcode   -r 40992 
svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/zodbcode
ClientCookie   -r 40992 
svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/ClientCookie
mechanize  -r 40992 
svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/mechanize



Property changes on: Zope/branches/2.9/utilities
___
Name: svn:externals
   - ZODBTools  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/scripts

   + ZODBTools  -r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/scripts


___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/trunk/ Move to ZODB 3.6.0b6.

2006-01-01 Thread Tim Peters
Log message for revision 41070:
  Move to ZODB 3.6.0b6.
  

Changed:
  _U  Zope/trunk/doc/
  _U  Zope/trunk/lib/python/
  _U  Zope/trunk/utilities/

-=-

Property changes on: Zope/trunk/doc
___
Name: svn:externals
   - ZEO  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/doc/ZEO

   + ZEO   -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/doc/ZEO



Property changes on: Zope/trunk/lib/python
___
Name: svn:externals
   - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ZopeUndo
zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   -r 40903 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz
zodbcode   -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode
ClientCookie   -r 40549 
svn://svn.zope.org/repos/main/Zope3/trunk/src/ClientCookie
mechanize  -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/mechanize


   + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees -r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/BTrees
persistent -r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/persistent
ThreadedAsync  -r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ThreadedAsync
transaction-r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/transaction
ZEO-r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZEO
ZODB   -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZODB
ZopeUndo   -r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZopeUndo
zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   -r 40903 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz
zodbcode   -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode
ClientCookie   -r 40549 
svn://svn.zope.org/repos/main/Zope3/trunk/src/ClientCookie
mechanize  -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/mechanize




Property changes on: Zope/trunk/utilities
___
Name: svn:externals
   - ZODBTools  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/scripts

   + ZODBTools -r 41065 
svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/scripts


___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-dev] RE: [ZODB-Dev] Re: Connection pool makes no sense

2005-12-29 Thread Tim Peters
[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 forever, though.

[Denis Markov]
 But what about RDB-Connection what stay in cache forever?

Sorry, I don't know anything about how your app uses RDB connections.  ZODB
isn't creating them on its own ;-)

 On the next peak load we get some next ZODB-Connections with
 RDB-Connection  After repush() old ZODB-Connections will be killed
 (if   pool_size)

I don't like the word killed here, because it seems highly misleading.
ZODB doesn't destroy any Connections or any caches.  ZODB destroys all its
strong references to old Connections, and that's all.  Nothing can be done
to _force_ Connections to go away forever.  It's ZODB's job here to make
sure it isn't forcing Connections (beyond the pool_size limit) to stay
alive, and it's doing that job.  It can't kill Connections.

 but RDB-Connection stay in cache forever
 And so on

There's one cache per Connection.  If and when a Connection goes away, its
cache goes away too.  So when you say something stays in cache forever, I
don't know what you mean -- you apparently have many (hundreds? thousands?)
of Connections, in which case you also have many (hundreds or thousands) of
caches.  I don't know how an RDB-Connection gets into even one of those
caches to begin with.

 as a result we get many RDB-Connections what will never use but hang our
 RDB

At this point I have to hope that someone else here understands what you're
doing.  If not, you may have better luck on the zope-db list (which is
devoted to using other databases with Zope):

http://mail.zope.org/mailman/listinfo/zope-db

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RE: [ZODB-Dev] Re: Connection pool makes no sense

2005-12-29 Thread Tim Peters
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 or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: buildbot failure in Zope branches 2.9 2.4 Windows 2000 zc-bbwin

2005-12-21 Thread Tim Peters
[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 are still failing on Windows,
though, with different symptoms now:


Failure in test test_checkPermission_proxy_role_scope
(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--Windows
2000--Zope---trunk--2.4\build\lib\python\AccessControl\tests\testZopeSecurityPolicy.py,
line 326, in test_checkPermission_proxy_role_scope
self.failUnless(self.policy.checkPermission('Kill', r_subitem, context))
  File c:\python24\lib\unittest.py, line 309, in failUnless
if not expr: raise self.failureException, msg
AssertionError

.

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--Windows
2000--Zope---trunk--2.4\build\lib\python\AccessControl\tests\testZopeSecurityPolicy.py,
line 302, in test_checkPermission_proxy_roles_limit_access
self.failIf(self.policy.checkPermission('Foo', r_item, context))
  File c:\python24\lib\unittest.py, line 305, in failIf
if expr: raise self.failureException, msg
AssertionError

.

Failure in test test_checkPermission_respects_proxy_roles
(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--Windows
2000--Zope---trunk--2.4\build\lib\python\AccessControl\tests\testZopeSecurityPolicy.py,
line 291, in test_checkPermission_respects_proxy_roles
self.failUnless(self.policy.checkPermission('View', r_item, context))
  File c:\python24\lib\unittest.py, line 309, in failUnless
if not expr: raise self.failureException, msg
AssertionError


I don't have time to look at it.  Since the Windows buildbot slave
`bbwin` doesn't have a C compiler, I suppose it's possible that the
old, canned .pyd files it uses are out of synch with the current C
code.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: buildbot failure in Zope branches 2.9 2.4 Windows 2000 zc-bbwin

2005-12-21 Thread Tim Peters
[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--Zope---trunk--2.4\build\lib\python\AccessControl\tests\testZopeSecurityPolicy.py,
 line 302, in test_checkPermission_proxy_roles_limit_access
 self.failIf(self.policy.checkPermission('Foo', r_item, context))
   File c:\python24\lib\unittest.py, line 305, in failIf
 if expr: raise self.failureException, msg
 AssertionError
 ...
 I don't have time to look at it.  Since the Windows buildbot slave
 `bbwin` doesn't have a C compiler, I suppose it's possible that the
 old, canned .pyd files it uses are out of synch with the current C
 code.

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 (ZServer.tests.test_clockserver.ClockServerTests)
Traceback (most recent call last):
  File c:\python24\lib\unittest.py, line 260, in run
testMethod()
  File C:\buildbot\.org\zc-bbwin--Windows
2000--Zope---trunk--2.4\build\lib\python\ZServer\tests\test_clockserver.py,
line 87, in test_get_env
self.assertEqual(env['PATH_TRANSLATED'], '/a /b')
  File c:\python24\lib\unittest.py, line 333, in failUnlessEqual
raise self.failureException, \
AssertionError: '\\a \\b' != '/a /b'
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: buildbot failure in Zope branches 2.9 2.4 Windows 2000 zc-bbwin

2005-12-21 Thread Tim Peters
[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
 (ZServer.tests.test_clockserver.ClockServerTests)
 Traceback (most recent call last):
   File c:\python24\lib\unittest.py, line 260, in run
 testMethod()
   File C:\buildbot\.org\zc-bbwin--Windows
 2000--Zope---trunk--2.4\build\lib\python\ZServer\tests
 \test_clockserver.py,
 line 87, in test_get_env
 self.assertEqual(env['PATH_TRANSLATED'], '/a /b')
   File c:\python24\lib\unittest.py, line 333, in failUnlessEqual
 raise self.failureException, \
 AssertionError: '\\a \\b' != '/a /b'

[Chris McDonough]
 Hmmm... I *think* I just fixed this.

Luckily for us, the buildbot doesn't give a rip what either of us
think.  Its judgment is that you _did_ fix it, and there's not a court
in the land that will convict you given that perfect defense.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Unit Test Failures

2005-12-19 Thread Tim Peters
[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
 them by default when I check in.  I see a couple of problem points:  the
 biggest is the use in the output of 'checkSiteManager.html' of a repr'ed
 dict, which might render differently between different machines (or even
 the same machine across Python versions).  This is a classic case where
 the doctest does *not* provide clarity over a traditional 'unittest'
 style test, IMNSHO.

Possibly, but that clearly doesn't apply to the specific failures
we're seeing (True versus False outcomes, and getting lots more
output than expected).

 I'm not sure what it is testing, either;  CC'ing Phillip, whose
 fingerprints are on it, according the 'svn blame', for clarification.

These tests have always failed, and Phillip doesn't know why. 
Because they were failing, he changed them to run at level 2.  That's
not what level 2 is for, though, and the failures became visible to
everyone when the buildbot was changed to pass `--all` to test.py
(--all runs tests at all levels, level 2 among them ;-)).

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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Unit Test Failures

2005-12-19 Thread Tim Peters
[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 its source even harder to debug.

No, these tests fail on Windows too.  In fact, the problem was
orginally reported against Windows:  see entry #2 in:

http://www.zope.org/Collectors/Zope/1931

What does not fail on Windows is the specific variation you asked me
to try in your comment #2 on issue 1947:

When you run it by itself, it passes, though. Maybe you can confirm that.

In my comment #3 on issue 1947, I confirmed that:  when I ran the
functional.txt test _by itself_ on Windows, it passed.

 I wouldn't know where to start (having tried to debug this problem in the 
 past).
 Anyone got an idea?

For a start, disabuse yourself of the illusion that it acts
differently on Windows than on Linux ;-)
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Unit Test Failures

2005-12-19 Thread Tim Peters
...

[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.

It's not part of the implementation either.  For example,

 d = {z: 1, m: 2}
 pprint.pprint(d)
{'z': 1, 'm': 2}

That is, it's not true that pprint always sorts a dict for display. 
Looks like Jim's suggested

from zope.testing.doctestunit import pprint

inherits this insecurity.

In the example above, two things conspire to give unsorted output:

1. pprint(dict) doesn't try to sort at all if _repr(dict) is short.

2. On my 32-bit box, hash('z')  hash('m'), which leads to platform accidents
   in dict insertion putting 'z' before 'm' in the natural dict
iteration order:

 d
{'z': 1, 'm': 2}

   Because of #1, pprint passes on that order.

On a 64-bit box, the order may differ (or across Python versions on
one box if the string hash, or dict insertion, algorithms change).
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Unit Test Failures

2005-12-19 Thread Tim Peters
[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 confess that the 'width' fiddling in:

def pprint(ob, **opts):
if 'width' not in opts:
opts['width'] = 1
return PrettyPrinter(**opts).pprint(ob)

was incomprehensible to me just now -- you might want to add a comment
to that ;-)

 zope.doctestunit.pprint creates and uses a pretty printer with width
 set to 1, so all dicts are long and thus sorted.

Well, I understand why that works, but it's not part of pprint's
contract either.

 Note that, in Python 2.4, you can now pass a width to pprint without creating
 a separate pretty printer:

   from pprint import pprint
   pprint({z: 1, m: 2})
 {'z': 1, 'm': 2}
   pprint({z: 1, m: 2}, width=1)
 {'m': 2,
   'z': 1}

 So maybe we can phase out the use of docutestunit's pprint.)

 Perhaps we should push to get the sorting behavior of pprint
 documented to allay your concerns.

I think it's harder than you yet realize:  dicts don't require that
keys be orderable, so pprint can't promise to sort dict displays. 
As-is, pprint simply blows up if, e.g., you pass it a big dict using
complex numbers as keys.  Could be nobody has noticed that yet, but
since the trend in Python is to raise exceptions for non-equality
comparisons of objects of different types, this kind of failure is
bound to become more common.  In the end, I wouldn't be surprised if
pprint(dict) got changed to sort on the repr of the keys instead of on
the keys themselves.

 Better yet, perhaps we can get all dicts to be sorted.

As above.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Unit Test Failures

2005-12-19 Thread Tim Peters
...

[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 mud to close a bug report in
Pythonland too when it's just griping about changes in undocumented
behavior.

...

 I think it's harder than you yet realize:  dicts don't require that
 keys be orderable, so pprint can't promise to sort dict displays.
 As-is, pprint simply blows up if, e.g., you pass it a big dict using
 complex numbers as keys.  Could be nobody has noticed that yet, but
 since the trend in Python is to raise exceptions for non-equality
 comparisons of objects of different types, this kind of failure is
 bound to become more common.

 That's fine.  In practice, when we do this sort of thing, the keys
 are almost always strings.

My point is that you're relying on undocumented behavior now, and so
there's no guarantee it will continue to behave that way.  To the
contrary, because sorting dicts _started_ creating problems when
Python gave up its original any pair of objects can be compared
behavior, and Python continues moving away from that, there's reason
to worry that pprint may give up sorting dict displays entirely. 
Sorting isn't free, is currently a source of bugs in pprint, and adds
a large memory burden (to materialize a giant dict.items() list) when
pprint'ing a large dict.  An obvious alternative is for pprint to
change to do dict.iteritems() when building a display, which is much
better on all those counts.

If I have anything to say about it, it will continue to sort, but
nobody listens to me anymore ;-)

 In the end, I wouldn't be surprised if pprint(dict) got changed to
sort on the repr of
 the keys instead of on the keys themselves.

 That wouldn't be bad.

It's debatable for sure.

 Anyway, I guess we should make an issue of this on python-dev,
 so that either we can count on documented behavior
 going forward or so that we write our pwn pretty printer for
 use in doctest.

I'll try to make time for this next week (I'm on vacation then).
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: svn.zope.org borked

2005-12-19 Thread Tim Peters
[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 under BDB:

http://svnbook.red-bean.com/en/1.1/ch05.html
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-Checkins] SVN: Zope/branches/2.9/ Move to ZODB 3.6.0b5.

2005-12-18 Thread Tim Peters
Log message for revision 40874:
  Move to ZODB 3.6.0b5.
  

Changed:
  _U  Zope/branches/2.9/doc/
  _U  Zope/branches/2.9/lib/python/
  _U  Zope/branches/2.9/utilities/

-=-

Property changes on: Zope/branches/2.9/doc
___
Name: svn:externals
   - ZEO  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/doc/ZEO

   + ZEO  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/doc/ZEO



Property changes on: Zope/branches/2.9/lib/python
___
Name: svn:externals
   - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZopeUndo
zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/pytz
zodbcode   
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/zodbcode
ClientCookie   
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/ClientCookie
mechanize  
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/mechanize

   + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/ZopeUndo
zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/pytz
zodbcode   
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/zodbcode
ClientCookie   
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/ClientCookie
mechanize  
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/mechanize



Property changes on: Zope/branches/2.9/utilities
___
Name: svn:externals
   - ZODBTools  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/scripts

   + ZODBTools  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b5/src/scripts


___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


Re: [Zope-dev] zope-2.9 r40780 make install doesn't finish, files missing from bin

2005-12-18 Thread Tim Peters
[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 relationship between the shape or
contents of a checkout tree and the shape or contents of a
distribution tree (tarball).  How the two relate now is defined by
input to zpkgtools, and it's possible to create multiple kinds of
distributions from the same checkout tree now (by giving zpkgtools
different input).  Plain setup.py build no longer necessarily works
from a checkout tree either, BTW.  This is all in line with
zpkgtools's goals:

 
http://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/Zope3PackagingProposal

I guess that the process for making a Zope3 release applies to Zope 2.9 now too:

 
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/MakingARelease

ZODB's release process also had to change similarly when it moved to zpkgtools.

 I'd very much like to see the canonical ./configure; make; make
 install continue to work as it did in 2.7 and 2.8. Sysadmins go
 crazy if Zope's installation procedure changes with every other release.

Nobody should be installing from a checkout to begin with, right?  The
comfortable old dance should continue to work from a distribution. 
checkout != distribution.

Arguments about zpkgtools design probably need to involve Jim.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-Checkins] SVN: Zope/trunk/lib/python/ New zdaemon.

2005-12-16 Thread Tim Peters
Log message for revision 40813:
  New zdaemon.
  
  This fixes an intermittent test-killing race in
  testRunIgnoresParentSignals, which was introduced
  the last time a new zdaemon got stitched in.
  

Changed:
  _U  Zope/trunk/lib/python/

-=-

Property changes on: Zope/trunk/lib/python
___
Name: svn:externals
   - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZopeUndo
zdaemon-r 39732 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz
zodbcode   -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode
ClientCookie   -r 40549 
svn://svn.zope.org/repos/main/Zope3/trunk/src/ClientCookie
mechanize  -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/mechanize

   + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZopeUndo
zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz
zodbcode   -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode
ClientCookie   -r 40549 
svn://svn.zope.org/repos/main/Zope3/trunk/src/ClientCookie
mechanize  -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/mechanize


___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-dev] RE: [ZODB-Dev] Test Failures

2005-12-16 Thread Tim Peters
[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)
 --
 Traceback (most recent call last):
   File /usr/lib/python2.4/unittest.py, line 260, in run
 testMethod()
   File
   /home/sidnei/src/zope/2.8/lib/python/BTrees/tests/testBTrees.py,
   line 353, in testUpdateFromPersistentMapping
 self.t.update(pm)
 TypeError: Sequence must contain 2-item tuples

 This is on a Powerbook running Ubuntu Breezy PPC.

 Python 2.4.2 (#2, Nov 20 2005, 17:20:59)
 [GCC 4.0.3 20051023 (prerelease)
 (Ubuntu 4.0.2-3ubuntu1)] on linux2
 Type help, copyright, credits or license for more information.

Works for me:

[EMAIL PROTECTED]:~/Zope2.8$ svn info
Path: .
URL: svn://svn.zope.org/repos/main/Zope/branches/Zope-2_8-branch
Repository UUID: 62d5b8a3-27da-0310-9561-8e5933582275
Revision: 40815
Node Kind: directory
Schedule: normal
Last Changed Author: sidnei
Last Changed Rev: 40805
Last Changed Date: 2005-12-16 07:28:10 -0500 (Fri, 16 Dec 2005)
Properties Last Updated: 2005-10-04 14:30:34 -0400 (Tue, 04 Oct 2005)

[EMAIL PROTECTED]:~/Zope2.8$ svn up
Fetching external item into 'doc/ZEO'
External at revision 40815.
Fetching external item into 'lib/python/zope'
External at revision 40815.
Fetching external item into 'lib/python/ZConfig'
External at revision 40815.
Fetching external item into 'lib/python/BTrees'
External at revision 40815.
Fetching external item into 'lib/python/Persistence'
External at revision 40815.
Fetching external item into 'lib/python/persistent'
External at revision 40815.
Fetching external item into 'lib/python/ThreadedAsync'
External at revision 40815.
Fetching external item into 'lib/python/transaction'
External at revision 40815.
Fetching external item into 'lib/python/ZEO'
External at revision 40815.
Fetching external item into 'lib/python/ZODB'
External at revision 40815.
Fetching external item into 'lib/python/ZopeUndo'
External at revision 40815.
Fetching external item into 'lib/python/zdaemon'
External at revision 40815.
Fetching external item into 'utilities/ZODBTools'
External at revision 40815.
At revision 40815.

[EMAIL PROTECTED]:~/Zope2.8$ python2.4
Python 2.4.2 (#1, Dec  2 2005, 10:17:25)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)] on linux2
...

[EMAIL PROTECTED]:~/Zope2.8$ python2.4 setup.py build_ext -i
running build_ext
running build_ext

[EMAIL PROTECTED]:~/Zope2.8$ python2.4 test.py -vv . 
testUpdateFromPersistentMapping
Running unit tests at level 1
Running unit tests from /home/tim/Zope2.8/lib/python
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IIBucketTest) ...
ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IIBTreeTest) ... ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IFBucketTest) ...
ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IFBTreeTest) ... ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IOBucketTest) ...
ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IOBTreeTest) ... ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.OOBucketTest) ...
ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.OOBTreeTest) ... ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.OIBucketTest) ...
ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.OIBTreeTest) ... ok

--
Ran 10 tests in 0.007s

OK

No idea why it failed for you.  The only thing that rings a bell here is
that this test was added in ZODB 3.4.2b1, corresponding to this ZODB news
entry:


BTrees
--

- (3.4.2b1) Collector 1873.  It wasn't possible to construct a BTree
  or Bucket from, or apply their update() methods to, a PersistentMapping
  or PersistentDict.  This works now.


So my only guesses are that you have some older (than 3.4.2) version of ZODB
on your PYTHONPATH, or that your checkout is screwed up.  Here are the
externals you _should_ have:

[EMAIL PROTECTED]:~/Zope2.8$ svn propget svn:externals lib/python
zope
svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope
ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/BTrees
Persistencesvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/Persistence
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/persistent
ThreadedAsync
svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZopeUndo
zdaemon  

[Zope-dev] RE: [ZODB-Dev] Test Failures

2005-12-16 Thread Tim Peters
 [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 -- I got the same results (no problems) with Python 2.3.5.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] RE: [ZODB-Dev] Test Failures

2005-12-16 Thread Tim Peters
[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 clean' before running the tests and see if it helps.

Probably not, but who knows.  If that doesn't help, add code to dump
sys.path and stare at it.  And/or add code to import ZODB and print
ZODB.__version__, to see which version you're really getting during the
tests.

Ah, since the fix for Collector 1873 required changing C code, I do expect
those tests would fail if you didn't recompile Zope 2.8 since the time the C
code changed.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Retiring ZODB 3.2 (was: Re: [Zope-dev] FTP Upload killing Zope)

2005-12-16 Thread Tim Peters
[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 changes have been made to that since ZODB
3.2.10 was released on 12-Oct-2005, corresponding to the ZODB shipped
with Zope 2.7.8.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-Checkins] SVN: zdaemon/trunk/src/zdaemon/tests/testzdrun.py testRunIgnoresParentSignals(): Try to fix an

2005-12-15 Thread Tim Peters
Log message for revision 40791:
  testRunIgnoresParentSignals():  Try to fix an
  intermittent test-killing race between this test
  and zdrun.py fighting over who deletes the
  test socket first.
  

Changed:
  U   zdaemon/trunk/src/zdaemon/tests/testzdrun.py

-=-
Modified: zdaemon/trunk/src/zdaemon/tests/testzdrun.py
===
--- zdaemon/trunk/src/zdaemon/tests/testzdrun.py2005-12-15 16:58:31 UTC 
(rev 40790)
+++ zdaemon/trunk/src/zdaemon/tests/testzdrun.py2005-12-15 20:30:13 UTC 
(rev 40791)
@@ -248,7 +248,22 @@
 # Kill the process.
 send_action('exit\n', zdrun_socket)
 finally:
-shutil.rmtree(tmp)
+# Remove the tmp directory.
+# Caution:  this is delicate.  The code here used to do
+# shutil.rmtree(tmp), but that suffers a sometimes-fatal
+# race with zdrun.py.  The 'testsock' socket is created
+# by zdrun in the tmp directory, and zdrun tries to
+# unlink it.  If shutil.rmtree sees 'testsock' too, it
+# will also try to unlink it, but zdrun may complete
+# unlinking it before shutil gets to it (there's more
+# than one process here).  So, in effect, we code a
+# 1-level rmtree inline here, suppressing errors.
+for fname in os.listdir('.'):
+try:
+os.unlink(os.path.join(tmp, fname))
+except os.error:
+pass
+os.rmdir(tmp)
 
 def testUmask(self):
 # people have a strange tendency to run the tests as root

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/branches/2.9/lib/python/ New zdaemon.

2005-12-15 Thread Tim Peters
Log message for revision 40794:
  New zdaemon.
  
  Should repair the latest intermittent failures in
  testRunIgnoresParentSignals.
  

Changed:
  _U  Zope/branches/2.9/lib/python/

-=-

Property changes on: Zope/branches/2.9/lib/python
___
Name: svn:externals
   - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZopeUndo
zdaemon-r 39732 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/pytz
zodbcode   
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/zodbcode
ClientCookie   
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/ClientCookie
mechanize  
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/mechanize

   + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZopeUndo
zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/pytz
zodbcode   
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/zodbcode
ClientCookie   
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/ClientCookie
mechanize  
svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.0b1/src/mechanize


___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


RE: [ZODB-Dev] Re: [Zope-dev] Re: sessions in the presence of conflicts

2005-12-15 Thread Tim Peters
[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
 (they're documented in the BTrees source code).

A more readable account is here:

http://www.zope.org/Wikis/ZODB/BTreeConflictResolution

BTrees are mappings too, and looks like Dennis is trying to apply similar
conflict-resolution rules to session mapping objects.

 Conflict resolution algorithms are difficult and any algorithm will
 have DWIM-y tradeoffs, so it's useful to keep it as simple as possible.

Or no more complex as is actually helpful ;-)

 ...

[Dennis Allison]
 I have yet to figure out how to map a TransientObject state back
 to the object it represents, but it clearly is possible.

I didn't see a response to that bit yet, so:  the state of an object P is
whatever P.__getstate__() returns.  Given such a return value `state`, and
some object Q of the same type as P, Q.__setstate__(state) gives Q the same
state P had.  What state means is entirely up to the type's __setstate__()
and __getstate__() implementations (if any).  Objects deriving from
Persistent inherit (by default) implementations that retrieve and update an
instance's __dict__.  BTrees.Length is a good example of a class that
overrides these methods, using an integer as the state.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-Checkins] SVN: Zope/branches/2.9/ Collector #1965: 'get_transaction' missing from builtins without sufficient deprecation notice

2005-12-12 Thread Tim Peters
[Tres Seaver]
 Log message for revision 40728:
  Collector #1965: 'get_transaction' missing from builtins without sufficient 
 deprecation notice

  o ZODB 3.6 properly removed it, but Zope needs to keep it for another release
because ZODB released *twice* during the Zope 2.9 release cycle.


 Changed:
  U   Zope/branches/2.9/doc/CHANGES.txt
  U   Zope/branches/2.9/lib/python/Zope2/App/startup.py

 -=-
...
 --- Zope/branches/2.9/lib/python/Zope2/App/startup.py   2005-12-12 14:55:28 
 UTC (rev 40727)
 +++ Zope/branches/2.9/lib/python/Zope2/App/startup.py   2005-12-12 15:06:09 
 UTC (rev 40728)
...

 +def get_transaction():
 +_GET_TRANSACTION_DEPRECATED = \
 +The 'get_transaction' utility function in __builtin__ is deprecated, and
 +will be removed in Zope 2.10 (May 2006).
 +
 +Please import the transaction module, and use transaction.get() instead of
 +get_transaction().  transaction.commit() is a shortcut spelling of
 +transaction.get().commit(), and transaction.abort() of
 +transaction.get().abort().
 +
 +warnings.warn(_GET_TRANSACTION_DEPRECATED, DeprecationWarning)

Tres, you probably want to supply a stacklevel=2 argument here, so
that the warning points to the code _calling_ get_transaction()
instead of to the warnings.warn() line itself.
___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


Re: [Zope-dev] New ways of getting transactions?

2005-12-11 Thread Tim Peters
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 deprecated in the
ZODB 3.4 release.  These include:

- ``get_transaction()``.  Use ``transaction.get()`` instead.
  ``transaction.commit()`` is a shortcut spelling of
  ``transaction.get().commit()``, and ``transaction.abort()``
  of ``transaction.get().abort()``.  Note that importing ZODB no longer
  installs ``get_transaction`` as a name in Python's ``__builtin__``
  module either.

- The ``begin()`` method of ``Transaction`` objects.  Use the ``begin()``
  method of a transaction manager instead.  ``transaction.begin()`` is
  a shortcut spelling to call the default transaction manager's ``begin()``
  method.

- The ``dt`` argument to ``Connection.cacheMinimize()``.

- The ``Connection.cacheFullSweep()`` method.  Use ``cacheMinimize()``
  instead.

- The ``Connection.getTransaction()`` method.  Pass a transaction manager
  to ``DB.open()`` instead.

- The ``Connection.getLocalTransaction()`` method.  Pass a transaction
  manager to ``DB.open()`` instead.

- The ``cache_deactivate_after`` and ``version_cache_deactivate_after``
  arguments to the ``DB`` constructor.

- The ``temporary``, ``force``, and ``waitflag`` arguments
  to ``DB.open()``.  ``DB.open()`` no longer blocks (there's no longer
  a fixed limit on the number of open connections).

- The ``transaction`` and ``txn_mgr``arguments to ``DB.open()``.  Use
  the ``transaction_manager`` argument instead.

- The ``getCacheDeactivateAfter``, ``setCacheDeactivateAfter``,
  ``getVersionCacheDeactivateAfter`` and ``setVersionCacheDeactivateAfter``
  methods of ``DB``.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] New ways of getting transactions?

2005-12-11 Thread Tim Peters
[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
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Windows Installer for Zope 2.9+

2005-12-09 Thread Tim Peters
...

[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 sticks Python inside of Zope, but Zope3 sticks
Zope inside of Python.  A consequence is that you can't install more
than one instance of Zope3 under a single Windows account, but can
install any number of Zope2s.  In the other direction, it's always a
puzzle for Zope2 Windows users to figure out how to give their Zope
access to packages installed in their (own, separate) Python.  For
Zope3 that's a no-brainer.

 Supposing there is a existing python installation, how difficult is it
 to get a distutils-based windows installer to be extracted to a random
 directory outside site-packages?

distutils has no support for that.

 My guess is that it's basically unzip it.

What are you trying to accomplish?  (I know you're trying to push code
into some directory other than under Lib/site-packages, but I don't
know which code or why.)

 If that's the case, we can simplify the Zope 2 inno installer to:

 1. include a distutils-based windows installer for the Zope 2 source
 2. include some setup scripts

 Then on installation

 1. find or install according python

Note that Zope also needs pywin32 to be installed.

 2. unpack the distutils-based windows installer into Program
   Files\Zope

OK, so you're trying to preserve that ... what?  You're neither
sticking Python inside Zope nor Zope inside Python?

BTW,  _how_ do you unpack this at install time?  You can't, for
example, assume that a Windows box has any unzip utility (let alone
some specific one).  So this part would probably be simpler if you
point Inno at a Zope tree and let _it_ package it and unpack it. 
Maybe the way to get such a tree is to build a distutils installer for
Zope and run it on your own box, pointing Inno at the tree it creates,
then throw the distutils installer away 0.3 wink.

 3. create a default 'instance home', pointing to the installed python

An instance home _certainly_ doesn't belong inside the user's Python
-- but maybe I don't know what you mean by these words (I'm probably
misreading pointing to).  It should be possible to create any number
of distinct instance homes.

 4. register the services

 Steps 2-4 are reasonably simple to me, the tricky one is 1.

Maybe somone will hit me for this ;-), but we have Inno code for #1 in
one of our other installers.  It goes like this:

[Code]
var
// Path to the user's Python installation, found from the registry.
// Procedure SetPythonInstallPath deduces this.
gPythonInstallPath: String;

function InitializeSetup(): boolean;
begin
gPythonInstallPath := '';   // don't know yet
Result := True;
end;

...

// Look up Python's install path in the registry.  Use HKCU first, because
// a user-only instance is supposed to take precedence.  If no Python is
// installed, this will leave gPythonInstallPath as an empty string.
procedure SetPythonInstallPath();
begin
RegQueryStringValue(HKCU,
'Software\Python\PythonCore\2.4\InstallPath',
 '',
 gPythonInstallPath);
if gPythonInstallPath = '' then // not in HKCU, so try HKLM
RegQueryStringValue(HKLM,
'Software\Python\PythonCore\2.4\InstallPath',
'',
gPythonInstallPath);
end;

// Expose gPythonInstallPath to {code:...} clauses.
function GetPythonDir(Default: String): String;
begin
Result := gPythonInstallPath;
end;

...

procedure SetupDependencies();
var
PythonSetupFile: String;
PyWin32SetupFile: String;
...
begin
PythonSetupFile := 'python-2.4.2.msi';
PyWin32SetupFile := 'pywin32-205.win32-py2.4.exe';
...
// Setup python, unless it is already installed.
SetPythonInstallPath();
if gPythonInstallPath = '' then begin
if not ShellExec('open', ExpandConstant('{tmp}\files\' +
PythonSetupFile),
 '', '', SW_SHOW, ewWaitUntilTerminated, ErrorCode) then
   FatalError('Unable to install python');
// Try again to find the install path.
SetPythonInstallPath();
if gPythonInstallPath = '' then
// This shouldn't happen ... but if it does, we dare not leave this
// variable empty:  the installer blithely goes on to copy files
// into the Windows system32 directory if we do.  That should never
// be allowed.
gPythonInstallPath := ExpandConstant('{tmp}\NoPython\');
end;

// Setup pywin32
if not Exec(ExpandConstant('{tmp}\files\' + PyWin32SetupFile), '', '',
 SW_SHOW, ewWaitUntilTerminated, ErrorCode) then
FatalError('Unable to install PythonWin32');

...

The key is that the Python installer creates a registry entry, so you
can guess whether Python is installed by looking at that.  

Re: [Zope-dev] Logging changes in ZEO break zeoup.py

2005-12-08 Thread Tim Peters
[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:

 
 CRITICAL - zeoup status 1: No handlers could be found for logger
 ZEO.zrpc.Connection(C)
 ClientDisconnected
 

The logging module is just trying to drive you mad by saying someone
is _trying_ to log a CRITICAL problem, but I'm not going to show it to
you.  This is an informative msg, not an exception.  It looks like
you've got pieces of stdout and stderr scrambled together there, BTW.

 Can anyone advise me how to make this work under Zope 2.8.4?

I expect zeoup.py needs to be changed.  I did a similar thing for
runzeo.py some time ago, and I bet the latter's
setup_default_logging() method could be mostly reused.

To get unstuck quickly, try adding just this:

import logging
logging.basicConfig()

That always helps me in a pinch, but I never understood why (neither
why logging insists that you call _something_ before it will stop
annoying you, nor why the docs that seem to claim that logging will
itself call basicConfig() (if you don't) appear to be telling fibs).
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Zope refusing to serve ... i am an idiot

2005-12-08 Thread Tim Peters
[Chris Wilton]
 Whoops. Sorry.
 Error log tells me it's a 'no space left on device' error:

 2005-12-08T19:33:30 ERROR(200) SiteError
 http://ekhidna.biocenter.helsinki.fi/dali/downloads/180M.tar/index_html
 Traceback (most recent call last):
  File /data/backup/Zope-2.7.0/lib/python/ZPublisher/Publish.py, line 100, 
 in publish
request, bind=1)
  File /data/backup/Zope-2.7.0/lib/python/ZPublisher/mapply.py, line 88, in 
 mapply
if debug is not None: return debug(object,args,context)
  File /data/backup/Zope-2.7.0/lib/python/ZPublisher/Publish.py, line 40, in 
 call_object
result=apply(object,args) # Type scr to step into published object.
  File /data/backup/Zope-2.7.0/lib/python/OFS/Image.py, line 384, in 
 index_html
RESPONSE.write(data.data)
  File /data/backup/Zope-2.7.0/lib/python/ZServer/HTTPResponse.py, line 190, 
 in write
t.write(data)
 IOError: [Errno 28] No space left on device

 I assume this means there's a max cache size set somewhere. There's
 plenty of room left on our fs (hundreds of GB) so Zope isn't being
 allowed to use it at the moment. I'm asuming this is a Zope rather
 than local filesystem issue, but maybe I'm wrong; if it is a Zope
 issue, how I can increase standard cache size? We're not using a cache
 manager, yet...

None of the above ;-)  It's most likely that your temp directory is
mounted on a small partition.  Trying setting the envar TMPDIR to
point at a directory on a large partition before starting Zope. 
That is, you're not running into a cache size problem, you're running
into that Zope is creating a large temp file on a partition without
enough space to hold it.
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope-dev] Re: zLOG deprecation?

2005-12-06 Thread Tim Peters
[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 about here?

Sorry, it wasn't Florent, it was Philipp; you replied to it:

http://mail.zope.org/pipermail/zope-dev/2005-December/026039.html

As he says there, the comment block was taken from ZODB/loglevels.py,
which (besides just documenting this mess) implements TRACE and
BLATHER levels for ZODB's use.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Windows Installer for Zope 2.9+

2005-12-06 Thread Tim Peters
[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 fix the build process.

I just asked Andreas (off-list) what his Windows plans were for 2.9 --
for various reasons I assumed someone else was already looking at
this, but that assumption may be wrong (and given the lack of relevant
checkins recently, almost certainly wrong frown).

WRT Python 2.4, I never found a sane way to just _extract_ files from
an .msi installer, so that part of the build process is dead meat now.
 In other bundle everything Windows installers at Zope Corp (such as
for ZRS), I copy Python .pyd. .dll and .exe files from my own Python
2.4.2 installation instead.  These binary files are all the
build-Zope-installer process really needs from the Python Windows
installer; the rest (like .py and .h files) can be taken from a Python
tarball.  You can avoid wrestling with .msi entirely this way.

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
already have this DLL.

Another:  I have no idea how the new zpkg-based build process will
work with a Zope2-style installer.  A Zope3-style installer is
different in many ways (it's a plain distutils-based installer, and
requires that the end user get and install Python  pywin32 first). 
Plan on pain-time here.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Windows Installer for Zope 2.9+

2005-12-06 Thread Tim Peters
...

[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
| already have this DLL.

[Sidnei]
 Indeed. From reading around, seems like the saner thing is to make it
 a bold warning in the installer that the said dll is required instead
 of shipping it.

If you go the Zope3-route, it becomes a non-issue:  the Windows Python
installer will install msvcr71.dll if needed.  Redistribution there
isn't a problem because the PSF builds the binaries using a duly
licensed Microsoft compiler.  It's much fuzzier for derivative works
(do the PSF's redistribution rights pass through to them?  ask two
lawyers, get four answers).  Zope Corp could presumably invoke the
same rights because parts of Zope are compiled with a legitimately
licensed VC 7.1 -- but that might depend on who does the compliing.

| Another:  I have no idea how the new zpkg-based build process will
| work with a Zope2-style installer.  A Zope3-style installer is
| different in many ways (it's a plain distutils-based installer, and
| requires that the end user get and install Python  pywin32 first).
| Plan on pain-time here.

 That's something I can play with :)

Feedback from users hasn't been exactly glowing, but it's much easier
to build an installer that way (no externals, no makefiles, no Cygwin
involved, ...).  Here's how it's done for Zope3; I don't know / can't
guess what would need to change for Zope2:

http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeWindowsRelease
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: zLOG deprecation?

2005-12-05 Thread Tim Peters
[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 think one was
 needed?

See Florent's original message; Chris chopped TRACE away in his reply.

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.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-Checkins] SVN: Zope/branches/2.9/ Move to ZODB 3.6.0b4.

2005-12-04 Thread Tim Peters
Log message for revision 40533:
  Move to ZODB 3.6.0b4.
  

Changed:
  _U  Zope/branches/2.9/doc/
  _U  Zope/branches/2.9/lib/python/
  _U  Zope/branches/2.9/utilities/

-=-

Property changes on: Zope/branches/2.9/doc
___
Name: svn:externals
   - ZEO  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/doc/ZEO

   + ZEO  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/doc/ZEO



Property changes on: Zope/branches/2.9/lib/python
___
Name: svn:externals
   - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ZopeUndo
zdaemon-r 39732 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   -r 40369 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz
zodbcode   -r 40369 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode
ClientCookie   -r 40369 
svn://svn.zope.org/repos/main/Zope3/trunk/src/ClientCookie
mechanize  -r 40369 svn://svn.zope.org/repos/main/Zope3/trunk/src/mechanize

   + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZopeUndo
zdaemon-r 39732 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   -r 40369 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz
zodbcode   -r 40369 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode
ClientCookie   -r 40369 
svn://svn.zope.org/repos/main/Zope3/trunk/src/ClientCookie
mechanize  -r 40369 svn://svn.zope.org/repos/main/Zope3/trunk/src/mechanize



Property changes on: Zope/branches/2.9/utilities
___
Name: svn:externals
   - ZODBTools  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/scripts

   + ZODBTools  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/scripts


___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


Re: [Zope] Re: Zope 2.8.4 strange behavior

2005-11-30 Thread Tim Peters
[Dieter Maurer]
 ...
 I think, Tim wanted to implement such a keep alive mechanism
 inside ClientStorage (to reliably detect disconnects) but
 in ZODB 3.4 it seems not yet available.

Right on all counts:  I would like to add that, because it's currently
possible for ZEO to run forever without noticing a connection is
dead (when the OS/whatever doesn't inform it of socket death); this is
especially damning for clients that normally don't try to commit
changes, as they can continue serving stale cached content
indefinitely.  And it's not in ZODB 3.4.  It's not in ZODBs 3.5 or 3.6
either -- haven't had time to work on it.
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Zope 2.8.4 strange behavior

2005-11-29 Thread Tim Peters
[Chris McDonough]
 The symptom you're describing has happened to me in the past.  Zope
 stops serving requests and my CPU is not pegged (it's not hitting the
 CPU hard via an infinept loop I've made).  I usually end up tracking  it
 down to the fact that my instance is somehow leaking database
 connections.

[Chris Withers]
 I thought Jim solved this for 2.8 by not having a hard limit on the
 connection pool?

This was implemented for ZODB 3.4.  See:

http://www.zope.org/Wikis/ZODB/SimplifyConnectionManagement

and ZODB NEWS.

 (iirc, you now get errors in the log when you go over the pool limit)

Messages at warning or critical level, depening on how much you've gone over.

 This was 'cos you used to get the crappy situation running unit tests when
 lots of test fail that things hang and you get no feedback apart from 7 E's
 because the connection pool is exhausted.

Not really (see the Wiki page referenced above).

 That said, I don't know for sure that Jim _did_ end up implementing
 this, I might just be imagine it.

It was released in ZODB 3.4a1:


What's new in ZODB3 3.4a1?
==
Release date: 01-Apr-2005

...

DB
--

- There is no longer a hard limit on the number of connections that
  ``DB.open()`` will create.  In other words, ``DB.open()`` never blocks
  anymore waiting for an earlier connection to close, and ``DB.open()``
  always returns a connection now (while it wasn't documented, it was
  possible for ``DB.open()`` to return ``None`` before).

  ``pool_size`` continues to default to 7, but its meaning has changed:
  if more than ``pool_size`` connections are obtained from ``DB.open()``
  and not closed, a warning is logged; if more than twice ``pool_size``, a
  critical problem is logged.  ``pool_size`` should be set to the maximum
  number of connections from the ``DB`` instance you expect to have open
  simultaneously.

  In addition, if a connection obtained from ``DB.open()`` becomes
  unreachable without having been explicitly closed, when Python's garbage
  collection reclaims that connection it no longer counts against the
  ``pool_size`` thresholds for logging messages.

  The following optional arguments to ``DB.open()`` are deprecated:
  ``transaction``, ``waitflag``, ``force`` and ``temporary``.  If one
  is specified, its value is ignored, and ``DeprecationWarning`` is
  raised.  In ZODB 3.6, these optional arguments will be removed.


And for ZODB 3.6, they were removed.
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope-dev] How bad _are_ ConflictErrors

2005-11-21 Thread Tim Peters
[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 to 3 times to perform  commit a given
transaction, suppressing any conflict exceptions for the duration,
before giving up.

 As I understand it, Zope retries when a conflict occurs and usually is able
 to commit both sides of the conflicting transaction.

Right (although note that there may be more than two sides).

 Sometimes Zope cannot commit conflicting transactions--and it is at that
 point that an error occurs.

Right, Zope eventually gives up on a transaction that keeps on raising
conflict exceptions.

 There are supposed to be significant changes in the Zope 2.8.4/ZODB 3.4.2
 system.

There are.  ZODB 3.3 introduced multiversion concurrency control
(MVCC), which eliminates read conflicts in normal operation.

 Read-read conflicts no longer generate conflict errors

Not really:  under MVCC, there simply aren't any read conflicts. 
There may still be write conflicts.

 and the retry mechanism has been reworked at the ZODB level to retry once
 and then raise a POSKEY exception.

Nope, no version of ZODB ever retries a transaction on its own.  If an
application (like Zope) wants to retry, it's entirely up to it do so.

 The optimistic locking used by Zope

ZODB's transactional approach is optimistic, precisely because it
_doesn't_ lock objects modified by a transaction.  Any number of
transactions are free to modify the same object at the same time -- no
locking mechanism attempts to stop that.  If multiple transactions do
modify the same object at the same time, and that object doesn't
implement conflict resolution, then only the first transaction to
commit its changes to that object can succeed.

 can cause problems, particularly when the conflicting method changes external
 state.

Yes -- but do note it's not a transactional system then (ZODB can roll
back all changes _it_ makes, so that a failure to commit does no harm
to the database state; external resources that can't take back
provisional changes are indeed challenging to use in a transactional
system).
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Reminder: feature freeze November 1.

2005-11-14 Thread Tim Peters
[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:
 - -shome = os.path.join(zhome, 'lib/python')
 +shome = os.path.join(zhome, 'lib', 'python')
  elif shome:
 shome = os.path.abspath(shome)
 zhome = os.path.dirname(os.path.dirname(shome))

Well spotted!  It (plus the later patch) does fix the checkDuplicate
test failure on Windows, and I closed issue 1931.

Turns out the Five tests that were failing on Windows also fail on
Linux, but the failing tests don't run unless you pass ``--all`` to
test.py (which I normally do, but I guess most people don't, in which
case most people wouldn't see these failures).  I opened a new issue
about that:

http://www.zope.org/Collectors/Zope/1947
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Reminder: feature freeze November 1.

2005-11-13 Thread Tim Peters
[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

 CMF-trunk runs fine on the Zope trunk, etc.

Certainly agree it would help to have a specific list of what (if
anything) still needs to fixed.  FWIW, I don't expect Windows test
failures to hold up a beta release (note that I didn't say that's a
policy I agree with ;-)).
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Reminder: feature freeze November 1.

2005-11-13 Thread Tim Peters
[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
 http://mail.zope.org/pipermail/zope-dev/2005-October/025512.html, which
 quotes Tim as saying:

 : No idea where this slash-vs-backslash confusion ultimately comes from,
 : though.  Who recently checked code in hard-coding / as a path
 : separator?

 So in this specific example, the problem seems less a lack of Windows
 centric developers, but more an abundance of non-Windows-centric developers
 :)

 These test failures appear at first glance to not be windows specific at
 all - just possibly pointing at non-portable code written by others.  As a
 Windows developer, I'm afraid I have no idea where I would start looking for
 this bug.

Alas, I was directed not to work on this bug report on the clock,
and I haven't had spare time to donate to it (of course there's the
usually irony with that:  by now I've probably spent 3x as long typing
about these bugs as it would have taken to fix them :-( ...).

Because I'm sure I noticed the bug within a day or two of its first
appearance, the obvious approach is to revert back to earlier
revisions of the trunk until finding the checkin that caused it.  I
thought I wrote up enough clues on zope-dev at the time that whoever
checked in the responsible change would think ah, that's related to
what I did! at once.  Alas again, nobody noticed.

So that's a clear path to fixing this one:  pinning the blame should
be sufficient ;-)  In the absence of the guilty party noticing they
were to blame, it takes someone on Windows to do the binary search
required (because someone on Linux won't see the failure).

BTW, notice that the Python tracebacks had exactly the same \ vs /
mixup in the same place (between lib and python) as the two
originally failing tests.  That suggests (but doesn't prove) that a
change to sys.path is the ultimate cause.

BTW2, I have no idea why the later-failing Five test started failing
on Windows, and didn't spend any time investigating that one.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] commit(1) in ZCatalog

2005-11-08 Thread Tim Peters
[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 -- go for it.  I see that the 2.8
branch already uses transaction.savepoint() here, but should probably
use transaction.savepoint(optimistic=True) instead.

In the other direction, I see that zope/app/file/file.py still
contains two subtxn commits on 2.8 branch, but not anymore on the
trunk.  That should also be changed on 2.8 branch.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


  1   2   3   4   5   >