[Zope-dev] Re: Weird test failures with DateTime
Philipp von Weitershausen wrote:
I've recently been seeing weird DateTime test failures on all Zope 2
branches since 2.7 (see below). Any idea what I'm doing wrong? My system
is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My
system timezone, as you can see, is GMT+0800 (Beijing time).
I've figured this one out. The Chinese time zone is known as 'CST', but
so is 'US/Central' as well. In fact, Mac OS X itself doesn't report the
time zones to python consistently. When I set my time zone to Chicago
time, time.tzname is ('CST', 'CST') and when I set my time zone to
Shanghai time, it remains the same, even though it's a completely
different time zone. DateTime.DateTimeZone._zmap can only pick one
timezone to be mapped to the 'CST' name and it happens to choose
'US/Central' (which doesn't surprise me obviously). Running the tests
with the operating system's time zone set to, say, CET works fine.
Philipp
___
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: Weird test failures with DateTime
Jens Vagelpohl wrote: On 26 Nov 2005, at 15:07, Philipp von Weitershausen wrote: However, I am noticing that on the current Zope 2.9 branch, trying to build the software fails completely. The configure script works fine, but the make step does not seem to do anything at all. Yes it does. It compiles the C extensions. The real difference now is that I used to be able to create an empty directory from which to run configure and make, but now it only works when you sit inside the full source tree... So in order to do my usual pristine source tree under src/, build under opt/ I must now copy the full source tree over. Annoying :/ Yes, the out-of-place build functionality, as we unofficially called it, is not supported anymore. Really, I was surprised to hear that people used this feature so much for checkouts. After all, I thought you want to *work* in a sandbox, not install from it or anything (otherwise you wouldn't need a sandbox...). Philipp ___ 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: Weird test failures with DateTime
On 27 Nov 2005, at 15:49, Philipp von Weitershausen wrote: The real difference now is that I used to be able to create an empty directory from which to run configure and make, but now it only works when you sit inside the full source tree... So in order to do my usual pristine source tree under src/, build under opt/ I must now copy the full source tree over. Annoying :/ Yes, the out-of-place build functionality, as we unofficially called it, is not supported anymore. Really, I was surprised to hear that people used this feature so much for checkouts. After all, I thought you want to *work* in a sandbox, not install from it or anything (otherwise you wouldn't need a sandbox...). Define sandbox. For me it is not the checkout of the software itself, it is the built-out $SOFTWARE_HOME. It was a little easier to create several such sandboxes (e.g. one with Python 2.3.x, one with 2.4.x) using the out of place build. jens ___ 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: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the sourcecoderepository
Roger Ineichen wrote: ... And please stop telling that there will be a migration path for somthing. Please stop saying that there won't be. I guess there will never be such a path. I guess differently. Perhaps custom products can be rewriten based on Zope3 libraries, but a real migration path like known from other software will never be supported. Normaly Zope2 based projects are to highly customized and this will make it impossible for a clear migration path. Perhaps this will be different for standard use of a Plone or Silva. Butdo you really know somebody where is using Plone or Silva out of the box? I'm convinced that there will be a migration path. I don't know if it will be painless or automatic. It may take the form of Zope 2's lower-level infrastructure being replaced by Zope 3's. I think this is entirely possible and would constitute a real migration to Zope 3. It's very possible that there will be a Zope 2 in the future that supports Zope 2 paradigms and Zope 3 paradigms simultaneously. This would look very different from many pure Zope 3 applications, but perhaps no more different than a number of sucessful Zope 3 applications such as Schooltool and applications being built by Canonical. 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] Re: PermissionGeddon
Hanno Schlichting wrote at 2005-11-26 09:28 +0100: ... I hope to have tracked the ~200 failing tests down to two of your changes in OFS.CopySupport. The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. This breaks the reference implementation of Archetypes because it uses something based on BTreeFolder2 to store references and BTreeFolder2 overwrites both _setObject and _delObject with its own versions. Several Folder like classes are likely to overwrite _setObject and _delObject. Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. -- Dieter ___ 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: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 inthe sourcecoderepository
Hi Jim [...] Roger Ineichen wrote: ... And please stop telling that there will be a migration path for somthing. Please stop saying that there won't be. I guess there will never be such a path. I guess differently. Ok, accepted From now on I say, ask Jim ;-) Perhaps custom products can be rewriten based on Zope3 libraries, but a real migration path like known from other software will never be supported. Normaly Zope2 based projects are to highly customized and this will make it impossible for a clear migration path. Perhaps this will be different for standard use of a Plone or Silva. Butdo you really know somebody where is using Plone or Silva out of the box? I'm convinced that there will be a migration path. I don't know if it will be painless or automatic. It may take the form of Zope 2's lower-level infrastructure being replaced by Zope 3's. I think this is entirely possible and would constitute a real migration to Zope 3. It's very possible that there will be a Zope 2 in the future that supports Zope 2 paradigms and Zope 3 paradigms simultaneously. This would look very different from many pure Zope 3 applications, but perhaps no more different than a number of sucessful Zope 3 applications such as Schooltool and applications being built by Canonical. Yes, I know that this is possible. But are you really proposing to start a project like this? Or do you mean Five is going or should go in this direction? Regards Roger Ineichen 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ 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: PermissionGeddon
Dieter Maurer wrote: The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. This breaks the reference implementation of Archetypes because it uses something based on BTreeFolder2 to store references and BTreeFolder2 overwrites both _setObject and _delObject with its own versions. Several Folder like classes are likely to overwrite _setObject and _delObject. Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. Maybe. But on the other hand I'd rather not have object manager code slowed down and uglified to suit the negligibly small number of classes that are in this case, and that can be trivialy upgraded in a forward-compatible manner. Florent -- Florent Guillaume, Nuxeo (Paris, France) 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 )
Re: [Zope-dev] RE: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 inthe sourcecoderepository
Roger Ineichen wrote: Hi Jim [...] Roger Ineichen wrote: ... And please stop telling that there will be a migration path for somthing. Please stop saying that there won't be. I guess there will never be such a path. I guess differently. Ok, accepted From now on I say, ask Jim ;-) Perhaps custom products can be rewriten based on Zope3 libraries, but a real migration path like known from other software will never be supported. Normaly Zope2 based projects are to highly customized and this will make it impossible for a clear migration path. Perhaps this will be different for standard use of a Plone or Silva. Butdo you really know somebody where is using Plone or Silva out of the box? I'm convinced that there will be a migration path. I don't know if it will be painless or automatic. It may take the form of Zope 2's lower-level infrastructure being replaced by Zope 3's. I think this is entirely possible and would constitute a real migration to Zope 3. It's very possible that there will be a Zope 2 in the future that supports Zope 2 paradigms and Zope 3 paradigms simultaneously. This would look very different from many pure Zope 3 applications, but perhaps no more different than a number of sucessful Zope 3 applications such as Schooltool and applications being built by Canonical. Yes, I know that this is possible. But are you really proposing to start a project like this? Or do you mean Five is going or should go in this direction? It (or Zope 2 development in general, which is becoming indistinguishable from Five) is going in this direction. 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: Weird test failures with DateTime
On Sun, 27 Nov 2005 07:40:36 -0800, Philipp von Weitershausen
[EMAIL PROTECTED] wrote:
Philipp von Weitershausen wrote:
I've recently been seeing weird DateTime test failures on all Zope 2
branches since 2.7 (see below). Any idea what I'm doing wrong? My system
is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My
system timezone, as you can see, is GMT+0800 (Beijing time).
I've figured this one out. The Chinese time zone is known as 'CST', but
so is 'US/Central' as well. In fact, Mac OS X itself doesn't report the
time zones to python consistently. When I set my time zone to Chicago
time, time.tzname is ('CST', 'CST') and when I set my time zone to
Shanghai time, it remains the same, even though it's a completely
different time zone. DateTime.DateTimeZone._zmap can only pick one
timezone to be mapped to the 'CST' name and it happens to choose
'US/Central' (which doesn't surprise me obviously). Running the tests
with the operating system's time zone set to, say, CET works fine.
Welcome to the wonderful US-centric world of the Zope DateTime module. I
believe the same problem exists for Australian time zones which happen to
share abbreviations with some obscure US time zone. ;)
Posting from the US-ly yours,
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
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: Weird test failures with DateTime
Alexander Limi wrote:
Philipp von Weitershausen wrote:
I've recently been seeing weird DateTime test failures on all Zope 2
branches since 2.7 (see below). Any idea what I'm doing wrong? My system
is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My
system timezone, as you can see, is GMT+0800 (Beijing time).
I've figured this one out. The Chinese time zone is known as 'CST', but
so is 'US/Central' as well. In fact, Mac OS X itself doesn't report the
time zones to python consistently. When I set my time zone to Chicago
time, time.tzname is ('CST', 'CST') and when I set my time zone to
Shanghai time, it remains the same, even though it's a completely
different time zone. DateTime.DateTimeZone._zmap can only pick one
timezone to be mapped to the 'CST' name and it happens to choose
'US/Central' (which doesn't surprise me obviously). Running the tests
with the operating system's time zone set to, say, CET works fine.
Welcome to the wonderful US-centric world of the Zope DateTime module. I
believe the same problem exists for Australian time zones which happen to
share abbreviations with some obscure US time zone. ;)
Indeed. In fact, I think CST is one of those ;). pytz fortunately avoids these
ambiguities
by not knowing about these names. It only knows CST6CDT which seems to be the
U.S. version
of the time zone.
Philipp
This message was sent using IMP, the Internet Messaging Program.
___
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 )
