[Zope-dev] Re: Zope tests: 6 OK, 2 Failed

2006-01-16 Thread Florent Guillaume

The problem is that when I do:
  bin/zopectl test -s AccessControl
everything works fine.

However the buildbots do:
  python test.py -s AccessControl
and this fails.

I included a workaround, sigh.

Florent


Stefan H. Holek wrote:
AFAIK the default configuration used by tests does not have a dbtab. See 
lib/python/App/config.py.


Stefan


On Jan 14, 2006, at 16:45, Florent Guillaume wrote:



I'll look at it.

Florent

Tres Seaver wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This failure is tie up with Florent's recent checkin:


Log message for revision 41303:
 When a database is created by hand from a custom_zodb.py during
 startup, we still want to put it in the dbtab multidatabases dict.
  This happens when unit tests call Zope2.startup(), because Testing 
has a

 specific custom_zodb.py loaded at startup that uses a DemoStorage.


Zope tests summarizer wrote:


Summary of messages to the zope-tests list.
Period Fri Jan 13 12:01:01 2006 UTC to Sat Jan 14 12:01:01 2006 UTC.
There were 8 messages: 8 from Zope Unit Tests.


Test failures
-

Subject: FAILED : Zope-2_9-branch Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Fri Jan 13 21:10:37 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004008.html

Subject: FAILED : Zope-trunk Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Fri Jan 13 21:12:07 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004009.html






--
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
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] Zope tests: 6 OK, 2 Failed

2006-01-16 Thread Zope tests summarizer
Summary of messages to the zope-tests list.
Period Sun Jan 15 12:01:02 2006 UTC to Mon Jan 16 12:01:02 2006 UTC.
There were 8 messages: 8 from Zope Unit Tests.


Test failures
-

Subject: FAILED : Zope-2_9-branch Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Sun Jan 15 21:10:28 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004024.html

Subject: FAILED : Zope-trunk Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Sun Jan 15 21:11:58 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004025.html


Tests passed OK
---

Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux
From: Zope Unit Tests
Date: Sun Jan 15 21:01:27 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004018.html

Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux
From: Zope Unit Tests
Date: Sun Jan 15 21:02:57 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004019.html

Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux
From: Zope Unit Tests
Date: Sun Jan 15 21:04:27 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004020.html

Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Sun Jan 15 21:05:57 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004021.html

Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux
From: Zope Unit Tests
Date: Sun Jan 15 21:07:27 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004022.html

Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Sun Jan 15 21:08:58 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004023.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-dev] Strange traceback or Error in the traceback ?

2006-01-16 Thread Godefroid Chapelle

Hi,

While seaching for objects of all types containing some text through the 
ZMI find tab, I got the traceback hereunder. (Zope 2.7.8-final on

windows)

Traceback (innermost last):
  Module ZPublisher.Publish, line 101, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 39, in call_object
  Module Shared.DC.Scripts.Bindings, line 306, in __call__
  Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec
  Module App.special_dtml, line 175, in _exec
  Module DocumentTemplate.DT_With, line 61, in render
  Module DocumentTemplate.DT_Util, line 198, in eval
   - __traceback_info__: _
  Module string, line 0, in ?
  Module OFS.FindSupport, line 151, in ZopeFind
  Module OFS.FindSupport, line 151, in ZopeFind
  Module OFS.FindSupport, line 113, in ZopeFind
  Module OFS.Image, line 425, in PrincipiaSearchSource
AttributeError: content_typestartswith

I went to the code and found the following :

def PrincipiaSearchSource(self):
 Allow file objects to be searched.

if self.content_type.startswith('text/'):
return str(self.data)
return ''

IOW, the traceback is really strange.

Anybody with a clue ?

--
Godefroid Chapelle (aka __gotcha)http://bubblenet.be

___
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] Strange traceback or Error in the traceback ?

2006-01-16 Thread Leonardo Rochael Almeida
Hi,

Em Seg, 2006-01-16 às 16:20 +0100, Godefroid Chapelle escreveu:
 Hi,
 
 While seaching for objects of all types containing some text through the 
 ZMI find tab, I got the traceback hereunder. (Zope 2.7.8-final on
 windows)
 
 Traceback (innermost last):
[...]
Module OFS.Image, line 425, in PrincipiaSearchSource
 AttributeError: content_typestartswith
 
 I went to the code and found the following :
 
 [...]
  if self.content_type.startswith('text/'):
 [...]
 
 IOW, the traceback is really strange.
 
 Anybody with a clue ?

I've seen this happen a few times before. In your case, content_type is
probably a standard python function (or method). When an unknown
attribute is looked up in a std python function like that, somehow you
get an AttributeError with the name of the function and the looked up
attribute concatenated, instead of separated by a dot (or more commonly,
instead of the attribute name alone).

Don't know if this is a bad interaction between
ExtensionClass/AttributeError and python, or a python bug.

Cheers, Leo


___
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] buildbot failure in Zope trunk 2.4 Linux zc-buildbot

2006-01-16 Thread buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot.

Buildbot URL: http://buildbot.zope.org/

Build Reason: changes
Build Source Stamp: 2775
Blamelist: efge,jim

BUILD FAILED: failed test

sincerely,
 -The Buildbot

___
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] Deprecation process issues

2006-01-16 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've noticed a couple of problems with recent deprecation decisions (for
OFS.content_types and zLOG).  The major one is that the deprecation
warning waw added without removing the code in the core which depends on
the deprecated feature.  The most obvious sign of this is that the tests
no longer run clean, but are cluttered up with warning output.

Another issue is that at least one of those choices (the zLOG one)
seemed to land without accounting for the legitimate use cases which the
new blessed method doesn't address (e.g, logging levels not offered by
the standard 'logging' module).

I'm about to check in changes which clean out the use of
OFS.content_types, but am less willing to clean up the zLOG uses until
the other use cases are addressed.


Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDy9kb+gerLs4ltQ4RAiPBAJ0RD0HF3r0GhOm9JqTtsF/o1M/z3ACeNJTs
37iQ0WGsxgCYBOQ81xw9XnE=
=+CgN
-END PGP SIGNATURE-

___
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] Deprecation process issues

2006-01-16 Thread Jim Fulton

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've noticed a couple of problems with recent deprecation decisions (for
OFS.content_types and zLOG).  The major one is that the deprecation
warning waw added without removing the code in the core which depends on
the deprecated feature.  The most obvious sign of this is that the tests
no longer run clean, but are cluttered up with warning output.

Another issue is that at least one of those choices (the zLOG one)
seemed to land without accounting for the legitimate use cases which the
new blessed method doesn't address (e.g, logging levels not offered by
the standard 'logging' module).

I'm about to check in changes which clean out the use of
OFS.content_types, but am less willing to clean up the zLOG uses until
the other use cases are addressed.


I haven't been following these issues, counting on y'all to figure it out. :)

I'll just note that:

- I agree with your point about deprecation warnings.  IOW
  we should not check in new deprecation warnings on the trunk
  that cause warnings to be output when running the standard tests.
  We should correct any code that needs to be updated first.
  (Personally, I add the deprecation warning, making sure that I
  get the expected warnings, and then I make the warnings go away.)

- I think that dropping functionality should be considered carefully.
  I'm inclined to accept your judgement that the use cases need to be
  addressed.

Of course, we do want to move away from zLOG, as we want to leverage
the standard logging framework.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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] Deprecation process issues

2006-01-16 Thread Andreas Jung



--On 16. Januar 2006 13:08:31 -0500 Jim Fulton [EMAIL PROTECTED] wrote:

I'll just note that:

- I agree with your point about deprecation warnings.  IOW
   we should not check in new deprecation warnings on the trunk
   that cause warnings to be output when running the standard tests.
   We should correct any code that needs to be updated first.
   (Personally, I add the deprecation warning, making sure that I
   get the expected warnings, and then I make the warnings go away.)


But you can only correct code when you have a reasonable replacement. In 
case we should use my current ZPT replacement based on the Z3 
implementation we would deprecate lib/python/TALES and have deprecation 
warnings for two major releases. But we can't replace lib/python/TALES with 
the Z3 tal|tales
packages since we can expect incompatibilities which are not acceptable for 
backward compatibility issues. One could write fascades for such modules 
(Philipp already wrote one for STX) but I doubt that they will be 100% 
compatible. I would prefer to keep such modules in place and to just remove 
them after the deprecation period.




Of course, we do want to move away from zLOG, as we want to leverage
the standard logging framework.


Has there ever been the need/demand for additional log levels in Z3?

-aj



pgpO4ad33XNks.pgp
Description: PGP signature
___
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] ZPT backward compatibility

2006-01-16 Thread Jim Fulton

Andreas Jung wrote:



--On 16. Januar 2006 13:08:31 -0500 Jim Fulton [EMAIL PROTECTED] wrote:


I'll just note that:

- I agree with your point about deprecation warnings.  IOW
   we should not check in new deprecation warnings on the trunk
   that cause warnings to be output when running the standard tests.
   We should correct any code that needs to be updated first.
   (Personally, I add the deprecation warning, making sure that I
   get the expected warnings, and then I make the warnings go away.)



But you can only correct code when you have a reasonable replacement. In 
case we should use my current ZPT replacement based on the Z3 
implementation we would deprecate lib/python/TALES and have deprecation 
warnings for two major releases. But we can't replace lib/python/TALES 
with the Z3 tal|tales
packages since we can expect incompatibilities which are not acceptable 
for backward compatibility issues. One could write fascades for such 
modules (Philipp already wrote one for STX) but I doubt that they will 
be 100% compatible. I would prefer to keep such modules in place and to 
just remove them after the deprecation period.


There are two separate issues here:

1. ZPT backward compatibility.

   Are we introdcuting ZPT backward incompatibilities? (Aside from module
   paths)?  If so, then I think we need to have a proposal. (Maybe you already
   made one and I wasn't paying attention.  I don't see one at:
   http://www.zope.org/Wikis/DevSite/Proposals/FrontPage.

2. If we decide to change something, even if it's backward incompatible,
   we need to change Zope itself to do things the new way before we expect
   other people to and before we introduce the deprecation warning.
   If there isn't a valid new way of doing something, then we can't deprecate
   the old way.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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: ZPT backward compatibility

2006-01-16 Thread Andreas Jung



--On 16. Januar 2006 13:36:32 -0500 Jim Fulton [EMAIL PROTECTED] wrote:




There are two separate issues here:

1. ZPT backward compatibility.

Are we introdcuting ZPT backward incompatibilities? (Aside from module
paths)?


My original implementation  would introduce incompatibilities definitely.
However I've just checked in a relaxed implementation that defaults to the 
current behaviour. Enforcing unicode is now an optinal feature which might 
be used for application that are interested to use unicode for ZPTs 
starting Zope 2.10.




If so, then I think we need to have a proposal. (Maybe you
already
made one and I wasn't paying attention.  I don't see one at:
http://www.zope.org/Wikis/DevSite/Proposals/FrontPage.


Well, I brought this issue up on zope-dev to discuss this issue directly.
but with almost zero feedback :-) Also another related posting to zope-zpt 
got _zero_ anwers. Also other changes happened are part of a (pending) 
proposal written by Philipp.




2. If we decide to change something, even if it's backward incompatible,
we need to change Zope itself to do things the new way before we
expect
other people to and before we introduce the deprecation warning.


Nothing else happened so far (except the issue with OFS.content_types in 
Zope 2.9. I just forgot to change the code for the 2.9 final release. There 
was something to hinder me from doing that for 2.9b2).


-aj



pgpHL6IJ8WlKJ.pgp
Description: PGP signature
___
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 )