Dieter Maurer wrote:
Jean-Marc Orliaguet wrote at 2005-12-4 22:28 +0100:
...
In the log flle I'd like to be informed about events that are
unexpected. Conflict errors of this kind occur by design.
This argument is not convincing:
In a similar way, I could argue that MemoryErrors
Paul Winkler wrote:
To the other respondents: Thanks for the suggestions, but I do not
consider making AcceleratedHTTPCacheManager more flexible to be a test
turd. Tres outlined a real use case for changing the code (see below).
I don't understand why you guys consider this more invasive than
Andreas Jung wrote:
Log message for revision 40580:
Zope 2.9.0 b1
Changed:
A Zope/tags/2.9.0b1/2.9/
-=-
Copied: Zope/tags/2.9.0b1/2.9 (from rev 40579, Zope/branches/2.9)
Huh, did you really want to do that?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
Florent Guillaume wrote:
Just because you don't see the use in something doesn't mean it has to
go away.
There's nothing to stop you defining your own log levels with the python
logging module. I regularly (eg: MailingLogger) define a report level
that is 1 above INFO.
In my book BLATHER
Dieter Maurer wrote:
In a similar way, I could argue that MemoryErrors are there
by design.
While it is true that *occational* ConflictErrors are nothing
to worry about, a higher rate indicates that you soon
may come into trouble -- because the risk increases that
the automatic
Dieter Maurer wrote:
A colleague of mine will be very happy:
The hundreds of (mostly stupid deprecation) warnings prevent him
to efficiently find the true problems in the test runner reports.
In principle, he could fix the warnings -- but they (mostly) come
not from our code but third
Philipp von Weitershausen wrote:
This would probably best be handled by one person, so if you are willing to do
all the
grepping and updating, making zLOG deprecated would just be a minor operation
:).
...but one i don't know how to perform. What code would I insert and where?
I'm happy to
Tim Peters wrote:
[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.
Yeah, what he said ;-)
Also note that
Jean-Marc Orliaguet wrote:
But aren't you looking for some sort of application profiler?
The point is that you need information to build a profile...
sort of benchmarker? One could argue that slowly rendered pages are sign
that the application is badly designed too,
Indeed!
still you
1. Do you want these ConflictErrors retried logs to be at level:INFO
2. In addition, please specify if you feel those retriedConflictErrors should have their full traceback logged?
no, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be
retried (and are returned to
How about adding a URL to the logged message? Something like
See http://zope.org/ConflictError;
detailing the difference between a retried and unresovled
ConflictErrors and how to recognise them in the event.log.
___
Zope-Dev maillist -
Summary of messages to the zope-tests list.
Period Mon Dec 5 12:01:01 2005 UTC to Tue Dec 6 12:01:01 2005 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: Mon Dec 5 22:24:18 EST
Andreas Jung wrote:
Log message for revision 40469:
deprecated FastCGI
Changed:
U Zope/branches/2.9/doc/CHANGES.txt
U Zope/branches/2.9/doc/WEBSERVER.txt
U Zope/branches/2.9/lib/python/ZServer/datatypes.py
[snip]
Modified:
Philipp von Weitershausen wrote:
Andreas Jung wrote:
make sdist:
[EMAIL PROTECTED]:~/sandboxes/Zope-2.9/2.9.0b1: make sdist
zpkg -C /develop/sandboxes/Zope-2.9/2.9.0b1/releases/Zope2.cfg
'version.txt' doesn't match any files in collection
(in
Philipp von Weitershausen wrote:
this checkin made the tests fail for the build-bot
(http://mail.zope.org/pipermail/zope-tests/2005-December/003728.html).
Since you didn't use stacklevel=2 in the warnings.warn() call, it's hard
to see where FCGIServerFactory() is called from. Maybe tests?
I
1. Do you want these ConflictErrors retried logs to be at level:
INFO
2. In addition, please specify if you feel those retried
ConflictErrors should have their full traceback logged?
no traceback
3. Finally, please tell us if the ConflictErrors that *can't* be
retried (and are returned
Philipp von Weitershausen wrote:
Philipp von Weitershausen wrote:
this checkin made the tests fail for the build-bot
(http://mail.zope.org/pipermail/zope-tests/2005-December/003728.html).
Since you didn't use stacklevel=2 in the warnings.warn() call, it's hard
to see where FCGIServerFactory()
Philipp von Weitershausen wrote:
Jim Fulton wrote:
This is a very recent problem and a result of Jim's inconsistent
handling of the version.txt matter yesterday.
http://dev.zope.org/Zope3/MakingARelease says that
zope.app/version.txt should be created on a tag and
zope.app/PACKAGE.cfg
Jim Fulton wrote:
This is a very recent problem and a result of Jim's inconsistent
handling of the version.txt matter yesterday.
http://dev.zope.org/Zope3/MakingARelease says that
zope.app/version.txt should be created on a tag and
zope.app/PACKAGE.cfg should also be modified to include
Philipp von Weitershausen wrote:
Jim Fulton wrote:
...
Buildbot is awesome and Stephan's suggestion is a excellent one.
However, I consider buildbot a good safety-belt, not more. It's
definitely not an excuse for not testing things properly in a local
sandbox before checking in.
There's a
Jim Fulton wrote:
This is a very recent problem and a result of Jim's inconsistent
handling of the version.txt matter yesterday.
http://dev.zope.org/Zope3/MakingARelease says that
zope.app/version.txt should be created on a tag and
zope.app/PACKAGE.cfg should also be modified to include
[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
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.
[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
On Tue, Dec 06, 2005 at 12:35:49PM -0500, Tim Peters wrote:
| [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
|
...
[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
Jean-Marc Orliaguet wrote at 2005-12-6 10:59 +0100:
...
But aren't you looking for some sort of application profiler? or some
sort of benchmarker? One could argue that slowly rendered pages are sign
that the application is badly designed too, still you wouldn't want to
see in the log file:
Jean-Marc Orliaguet wrote at 2005-12-6 21:45 +0100:
...
You err: I do want to see them in the logfile and
I stole Florents idea to use threadframe (in his DeadlockDebugger)
to include a traceback for long running requests in the logfile.
This way, it is
easy not only to identify long running
28 matches
Mail list logo
