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 lon
Dieter Maurer wrote:
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
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:
...
[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 box
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
| >
[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
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.
[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 tal
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 t
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 l
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 modi
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 shou
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 FCGIServerFa
> 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 return
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?
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
(in /develop/sandboxes/Zope-2.9/2.9.0b1/lib/python/zope/app/PACKA
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: Zope/branches/2.9/lib/python/ZServe
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 2
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 - Zope-Dev@zo
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 t
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 woul
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 t
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 s
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 party
Dieter Maurer wrote:
In a similar way, I could argue that "MemoryError"s are there
by design.
While it is true that *occational* "ConflictError"s are nothing
to worry about, a higher rate indicates that you soon
may come into trouble -- because the risk increases that
the automatic r
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 is
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 R&D
+3
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
m
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 "MemoryError"
29 matches
Mail list logo
