[Zope3-dev] [Fwd: Mail delivery failed: returning message to sender]
Sidnei appears to be broken :-( Any idea how to reach him? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ---BeginMessage--- This message was created automatically by mail delivery software (Exim). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mailer after STARTTLS: host mail.enfoldsystems.com [66.139.78.159]: 454 TLS missing certificate: error:02001002:system library:fopen:No such file or directory (#4.3.0): retry timeout exceeded -- This is a copy of the message, including all the headers. -- Return-path: [EMAIL PROTECTED] Received: from localhost ([127.0.0.1]) by server1.simplistix.co.uk with asmtp (Exim 3.35 #1 (Debian)) id 1EB6QA-0001XB-00; Fri, 02 Sep 2005 08:57:10 +0100 Message-ID: [EMAIL PROTECTED] Date: Fri, 02 Sep 2005 08:41:20 +0100 From: Chris Withers [EMAIL PROTECTED] User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sidnei da Silva [EMAIL PROTECTED] CC: Derrick Hudson [EMAIL PROTECTED], zope3-dev@zope.org Subject: Re: [Zope3-dev] Re: XML header and TAL interpretor References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sidnei da Silva wrote: That smells to me like we need a mime-type negotiator or something, pretty much like we have a language negotiator for deciding which language to use for translations. No really, all this thread seems to have really uncovered so far is that macros in different ZPT modes are currently reported as incompatible. Are they really? Should they be? mime-type negotiation and the like seems like an app level thing, or at the very least the responsibility of a different component. Page Templates should be kept as clean and simple as possible, that way they'll be much mroe generically useful... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ---End Message--- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope3 and ZEO
Hello, today I downloaded the Zope-3.1.0c2 release candidate and played a little bit with it. I noticed that the bin/mkzeoinstance script is broken and returns Traceback (most recent call last): File ./mkzeoinstance, line 40, in ? from ZEO.mkzeoinst import ZEOInstanceBuilder I found no hint how Zope3.1 can be run with ZEO instead. Besides that the README.txt contains still references to Zope-3.0.0 and a XXX to be written under Starting Zope Shouldn't that be fixed before the final release is out? Regards, Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [Fwd: Mail delivery failed: returning message to sender]
On Tue, Sep 06, 2005 at 09:08:02AM +0100, Chris Withers wrote: | Sidnei appears to be broken :-( | | Any idea how to reach him? Odd. I've been receiving email normally. | Sidnei da Silva wrote: | | That smells to me like we need a mime-type negotiator or something, | pretty much like we have a language negotiator for deciding which | language to use for translations. | | No really, all this thread seems to have really uncovered so far is that | macros in different ZPT modes are currently reported as incompatible. Correct, but the mime-type issue is a real issue too. | Are they really? Should they be? | | mime-type negotiation and the like seems like an app level thing, or at | the very least the responsibility of a different component. Page | Templates should be kept as clean and simple as possible, that way | they'll be much mroe generically useful... Yes, it's an app-level thing. I've never said in my email that it should be at the page template level. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Failing test, Zope3 trunk, Windows
On Sep 6, 2005, at 3:39 PM, Fred Drake wrote:
On 9/6/05, Tim Peters [EMAIL PROTECTED] wrote:
Not sure when this started to fail -- recently:
The `pytz` was recently updated to use a newer version of the Olson
timezone database. This failure appears to be fallout from that.
Not sure what the test case is testing either:
def testParseTimeZoneNames(self):
dt = self.format.parse('01.01.2003 09:48 EST', 'dd.MM.
HH:mm zzz')
self.assertEqual(dt.tzinfo.utcoffset(dt),
datetime.timedelta(hours=-6))
EST is 5 hours west of UTC, so I'm not sure why -6 would be expected.
The minus 5 hours and 20 minutes it's getting back doesn't seem right
either ;-)
The test also expects this to show up as the CST timezone, so I think
the test is completely bogus. Perhaps it got hacked up to make it
pass with some other version of the timezone database at some point?
Not sure.
Stuart Bishop: Can you look at this and determine the best way to
deal with this problem? Otherwise, we'll need to revert the pytz
update for now.
This is probably what we will need to do, but since the failing tests
were bogus to begin with it may be a case of incremental
improvement. This is definitely a problem, though, that we should
resolve one way or another.
It's also worth noting that the i18n code currently relies on the
localization database for much of their timezone information AFAIK.
The error could be there too, even though it was Stuart's checkin
that triggered this failure in a bogus test. Dunno. Sigh.
This also brings up a question: How should we deal with timezones for
historic dates? The specific set of rules that apply to a given date
or datetime value have to be determined based on both the date and the
timezone indicator (abbreviation or name), applying the new US rules
for dates in the past is wrong. Is pytz prepared for this, or do we
need to figure out how we want to deal with it still? (I do hope all
the relevant information is in the timezone database, or we'll have to
think about supporting multiple versions of the database
simultaneously.)
I can answer part of this, at least. The Olson database has *very*
detailed about when to apply what time zone, and a cursory glance at
it seems to indicate that the particular new change is right. I also
know pytz works hard to reconcile the very rich Olson data with the
datetime approach (see Stuart's email http://mail.zope.org/pipermail/
zope3-dev/2005-August/015222.html).
This may be a bit complicated. I hope Stuart--or Stephan--can shed
some light on the problem.
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Failing test, Zope3 trunk, Windows
[Gary Poster] This is probably what we will need to do, but since the failing tests were bogus to begin with it may be a case of incremental improvement. This is definitely a problem, though, that we should resolve one way or another. It's also worth noting that the i18n code currently relies on the localization database for much of their timezone information AFAIK. The error could be there too, even though it was Stuart's checkin that triggered this failure in a bogus test. Dunno. Sigh. Well, src/pytz/zoneinfo/EST.py contains the minus 5 hours and 20 minutes (-19200 seconds) offset the test is actually returning: _utc_transition_times = [ d(1,1,1,0,0,0), d(1908,4,22,5,19,36), ] _transition_info = [ i(-19200,0,'CMT'), i(-18000,0,'EST'), I don't know how to read this data. A zone named CMT doesn't make sense to me in a file named EST.py. -18000 is the correct offset for current EST rules, and don't know either why it's apparently using the -19200 thingie instead. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RC 3 for Zope 3.1 needed
Hi everyone, I just learned that we need to have a Zope 3.1 RC 3 release. I know that some people found bugs, so please check in fixes into the branch in the next couple of days. Gary, does the pytz problem affect the branch? Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RC 3 for Zope 3.1 needed
On Sep 6, 2005, at 4:29 PM, Stephan Richter wrote: Hi everyone, I just learned that we need to have a Zope 3.1 RC 3 release. I know that some people found bugs, so please check in fixes into the branch in the next couple of days. Gary, does the pytz problem affect the branch? Yes. The combination of pytz and i18n appears to have already been broken. The i18n tests seem to have been fudged to pass. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Source API
On Sep 6, 2005, at 1:08 AM, Stuart Bishop wrote: ... So the only thing I think needs changing here is the documentation suggesting returning maxint from __len__. ... While I think there is agreement on this, have we settled in on a solution? Raising NotImplementedError or some other error to indicate that the len is currently too big to calculate, as Stuart first suggested, seems reasonable to me, but I'm not one to be saying what's best for the Python internals. I don't think returning the CPython default of 8 (if I understood that correctly) meets our use cases. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
On Sep 1, 2005, at 6:05 AM, Adam Groszer wrote: Dear Gary, Maybe not too late, I have here one more thing to look at: Hi Adam. Unfortunately, we did not get to your bug issues. If you have not already, please do put your issues in the Zope 3 collector (http://www.zope.org/Collectors/Zope3-dev) and we will work on them as we can. Thanks Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 zc1
The Buildbot has detected a failed build of Zope3 trunk 2.4 zc1. Buildbot URL: http://buildbot.zope.org/ Build Reason: The web-page 'force build' button was pressed by 'Benji': Test Windows Slave Build Source Stamp: None Blamelist: BUILD FAILED: failed svn sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 zc1
The Buildbot has detected a failed build of Zope3 trunk 2.4 zc1. Buildbot URL: http://buildbot.zope.org/ Build Reason: The web-page 'force build' button was pressed by 'Benji': Test buildbot on Windows Build Source Stamp: None Blamelist: BUILD FAILED: failed svn sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RC 3 for Zope 3.1 needed
On Sep 6, 2005, at 10:27 PM, Fred Drake wrote: On 9/6/05, Stuart Bishop [EMAIL PROTECTED] wrote: Is this something I need to be aware of? Because I'm not ;) This test in the Zope 3 trunk is failing: I talked with Stuart on IRC. It appears to be a symptom of using pytz incorrectly in i18n (it needs to localize, as per the pytz README). He said he would look into the i18n package and try to address. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RC 3 for Zope 3.1 needed
On 9/6/05, Gary Poster [EMAIL PROTECTED] wrote: I talked with Stuart on IRC. It appears to be a symptom of using pytz incorrectly in i18n (it needs to localize, as per the pytz README). He said he would look into the i18n package and try to address. Excellent! Thanks for the update. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Failing test, Zope3 trunk, Windows
Gary Poster wrote: On Sep 6, 2005, at 3:39 PM, Fred Drake wrote: This also brings up a question: How should we deal with timezones for historic dates? The specific set of rules that apply to a given date or datetime value have to be determined based on both the date and the timezone indicator (abbreviation or name), applying the new US rules for dates in the past is wrong. Is pytz prepared for this, or do we need to figure out how we want to deal with it still? (I do hope all the relevant information is in the timezone database, or we'll have to think about supporting multiple versions of the database simultaneously.) I can answer part of this, at least. The Olson database has *very* detailed about when to apply what time zone, and a cursory glance at it seems to indicate that the particular new change is right. I also know pytz works hard to reconcile the very rich Olson data with the datetime approach (see Stuart's email http://mail.zope.org/pipermail/ zope3-dev/2005-August/015222.html). This may be a bit complicated. I hope Stuart--or Stephan--can shed some light on the problem. It handles historical and future timezone changes as well as can be done, and I stuffed tests in that demonstrate this (probably where they don't belong, but they are there). There is an issue if timezone definitions change. So for instance, if you pickled a datetime instance for 13:00 1st April 2007 US/Eastern with version 2005k of pytz, if you unpickled it using version 2005m of pytz it would still think it was 13:00 1st April 2007 EST. If you then converted it to UTC and back to US/Eastern (such as done by pytz's normalize() method), you would end up with 14:00 1st April 2007 EDT. This is correct or crap depending on what sort of applications you write :) -- Stuart Bishop [EMAIL PROTECTED] http://www.stuartbishop.net/ signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
