Re: [Zope-dev] Re: Extend specification of how to maintain the changelog
On Jun 18, 2008, at 20:30 , yuppie wrote: The current Zope 2 policy doesn't make sure the change history of unreleased versions is complete. But that's no essential part of that policy. And working with unreleased versions you might use subversion anyway. See, I think that's bad. The change log should reflect all changes, be it in a released version or from Subversion. Or be it a release branch or the trunk. Note that you don't need to note the fix in the CHANGES.txt on the trunk if you don't want to. At the time a new feature release is made, we merge the items in CHANGES.txt from the trunk and current release branch so that for any given release it notes the actual changes as of that release. http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess I think I have done some of that merging once in a while, but always in a haphazard fashion and did not know about the URL you provided. I personally dislike that, and would strongly favor noting every change on the trunk as it is checked in, just like you would do on the branch. Well. I don't like the if you don't want to part of the current policy because it just creates chaos. If everybody follows the same policy, the merging is not that much work. It is much work if you have more than a single release branch. With the CMF, we have had times recently where stuff is updated on up to 3 branches plus trunk. Having to consult all those branches to synthesize the change log on the trunk is a major PITA and I don't see how that can be sane. 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: Extend specification of how to maintain the changelog
Hi, On Wed, Jun 18, 2008 at 11:09:17PM +0200, Martijn Faassen wrote: [...] If I know I normally only have to check the bottom (or top) of each section to see whether something got added since last time I checked, there's less chance I'll miss it and make a mistake. It's not a major point, but it'd be nice if everybody acted more or less the same instead of changelog sections growing from both ends. Sure. It's not the major target group either. During development I tend to use SVN to find the changes since last time I looked. Between releases the ordering is mostly important on the release level, not inside as releases are the atomic step for people to update to. My preference would be to have more important changes first. Christian -- Christian Theune · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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: Extend specification of how to maintain the changelog
On Jun 19, 2008, at 09:51 , Christian Theune wrote: On Thu, Jun 19, 2008 at 09:08:54AM +0200, Jens Vagelpohl wrote: See, I think that's bad. The change log should reflect all changes, be it in a released version or from Subversion. Or be it a release branch or the trunk. Please note that our use of the CHANGES.txt is more that of `release notes` meaning it should have a more condensed form of what would be available using `svn log`. I wouldn't see the point maintaining a text file that has identical information that could be retrieved from SVN. The condensed form is intended to provide better usability than to wade through hundreds of commits. I meant the same thing, yes. The main point was simply that all branches and the trunk should always have a complete change log and no merging or picking stuff from one or more branches to get to the complete change history should be necessary. 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 )
[Zope-dev] Re: [ZODB-Dev] Re: Advice on ZODB with large datasets
It's helpful to post your responses to the mailing list, that way when someone else has a similar problem in the future they'll be able to find the information. Inheriting from Persistent is also necessary to control the granularity of the database. Persistent objects are saved as separate `records` by ZODB. Other objects do not have a _p_oid attribute and have to be saved as part of their parent record. Laurence 2008/6/19 [EMAIL PROTECTED]: Laurence Rowe wrote: [EMAIL PROTECTED] wrote: Does your record class inherit from persistent.Persistent? 650k integers + object pointers should only be of the order 10 Mb or so. It sounds to me like the record data is being stored in the btrees bucket directly. No, it does not. It's just a simple dictionary for the time being. I assumed the BTree bucket would itself know to load the values only when they are explicitly requested, and that the Persistence of the objects just merely meant that the database didn't keep track of changes of nonpersistent objects. I will try copying my dictionaries to Persistent Mappings for now. Something like this should lead to smaller bucket objects where the record data is only loaded when you access the values of the btree: from BTrees.IOBTree import IOBTree bt = IOBTree() from persistent import Persistent class Record(Persistent): ... def __init__(self, data): ... super(Record, self).__init__() ... self.data = data ... rec = Record(my really long string data) bt[1] = rec ___ 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: [ZODB-Dev] Re: Advice on ZODB with large datasets
Sorry, wrong list. ___ 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: Extend specification of how to maintain the changelog
Hi! Second try. My first response to this lead to a discussion about immediate or delayed syncing of CHANGES.txt. That was not my point. Christian Theune wrote: On Wed, Jun 18, 2008 at 11:20:17AM -0400, Fred Drake wrote: On Wed, Jun 18, 2008 at 10:21 AM, Christophe Combelles [EMAIL PROTECTED] wrote: The risk is that people will think the bug is fixed in 3.6.0 and not in the 3.5 branch. That's a general documentation risk, and I don't think anyone else has come up with a better way to deal with this. If you can find an example that solves this without excess burden on the maintainers, that would be really good to hear about. The problem here is in managing the release notes in a single file within version control is easy to do. Everything else that makes this more clear either requires tedious manual tasks or really hard automation. Additionally, if you're bound to a branch, I guess it would be really easy to see what's changed there -- the release notes of that branch will tell you. The issue is that providing a 'correct' flat view of a tree structure is really hard in this case. The version numbering does not imply a time line! There is always *one* well defined current maintenance branch. Version numbering *does* imply a time line if you ignore old maintenance branches. It's not hard at all to get this right. Even when merging all the release notes, one would see the same change appear in 3.5.3, 3.6.4 and 3.7.0 eventually. Now, as you would read it from top to bottom, you might also think that it wasn't fixed in 3.5, even if you look there. You don't have to make things more complicated than they are right now. Nobody wants to merge release notes from old maintenance branches to newer branches. Changes on those branches are just backports. (Agreed, the lookup would be much simpler.) I think it is important to make it simple to look up what's new. I guess that merging release notes automatically would actually be easier in the format that I proposed ... I doubt that. In the format you propose the change note has to be placed in a different context. If we group changes on the trunk the same way as on the current maintenance branch, the context will always be the same. Cheers, Yuppie ___ 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: 5 OK
Summary of messages to the zope-tests list. Period Wed Jun 18 11:00:00 2008 UTC to Thu Jun 19 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Wed Jun 18 20:53:49 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009725.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jun 18 20:55:19 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009726.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jun 18 20:56:50 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009727.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jun 18 20:58:23 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009728.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Wed Jun 18 20:59:54 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009729.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 )
Re: [Zope-dev] Re: Extend specification of how to maintain the changelog
On Jun 19, 2008, at 12:32 , yuppie wrote: There is always *one* well defined current maintenance branch. Version numbering *does* imply a time line if you ignore old maintenance branches. It's not hard at all to get this right. I don't think that assumption holds true. Again, using the CMF as an example, there were times when we had 3 release branches. I don't want to start a discussion why that was or how to prevent that from happening, I'm just saying it's not correct to say you always have just one maintenance branch. And that's where all those fancy schemes fall down. 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 )
[Zope-dev] Re: View component registration
Malthe Borch wrote: Martijn Faassen wrote: There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B? It deserves consideration, but I don't think code will be prone to break since we're merely providing more information to lookup a view component, not less. Hm, you're right, I think, good point. I think it will lead to trouble as old code doesn't get updated and excepts to get a view when actually it'll get something entirely different. Regards, Martijn ___ 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: Extend specification of how to maintain the changelog
Jens Vagelpohl wrote: On Jun 19, 2008, at 12:32 , yuppie wrote: There is always *one* well defined current maintenance branch. Version numbering *does* imply a time line if you ignore old maintenance branches. It's not hard at all to get this right. I don't think that assumption holds true. Again, using the CMF as an example, there were times when we had 3 release branches. I don't want to start a discussion why that was or how to prevent that from happening, I'm just saying it's not correct to say you always have just one maintenance branch. And that's where all those fancy schemes fall down. You did get me wrong :( I tried to make a distinction between the current maintenance branch (= branch for maintaining the *current* release) and old maintenance branches (= branches for maintaining older release). If someone knows better terms, please let me know. The *current* version of CMF is 2.1.1. If you release CMF 1.6.5 with some backports from the 2.1 branch, it will not become the *current* CMF release. As soon as CMF 2.2.0 is released it will become the current release and the 2.2 branch the current maintenance branch. No? Cheers, Yuppie ___ 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: Extend specification of how to maintain the changelog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: Hi, On Wed, Jun 18, 2008 at 11:09:17PM +0200, Martijn Faassen wrote: [...] If I know I normally only have to check the bottom (or top) of each section to see whether something got added since last time I checked, there's less chance I'll miss it and make a mistake. It's not a major point, but it'd be nice if everybody acted more or less the same instead of changelog sections growing from both ends. Sure. It's not the major target group either. During development I tend to use SVN to find the changes since last time I looked. Between releases the ordering is mostly important on the release level, not inside as releases are the atomic step for people to update to. My preference would be to have more important changes first. Please don't make it a judgement call: keep it time-descending order, just like the releases. Among other things, this makes merge conflicts more obvious, and easier to to fix. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIWkxr+gerLs4ltQ4RApoNAKC6VhA15+0d5DbVsPiukfs6rnYKEgCgx9eX 91xqaqN1cPcy0ZTI4ed+QX0= =7VXA -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] Re: Extend specification of how to maintain the changelog
On Jun 19, 2008, at 13:36 , yuppie wrote: Jens Vagelpohl wrote: On Jun 19, 2008, at 12:32 , yuppie wrote: There is always *one* well defined current maintenance branch. Version numbering *does* imply a time line if you ignore old maintenance branches. It's not hard at all to get this right. I don't think that assumption holds true. Again, using the CMF as an example, there were times when we had 3 release branches. I don't want to start a discussion why that was or how to prevent that from happening, I'm just saying it's not correct to say you always have just one maintenance branch. And that's where all those fancy schemes fall down. You did get me wrong :( I tried to make a distinction between the current maintenance branch (= branch for maintaining the *current* release) and old maintenance branches (= branches for maintaining older release). If someone knows better terms, please let me know. The *current* version of CMF is 2.1.1. If you release CMF 1.6.5 with some backports from the 2.1 branch, it will not become the *current* CMF release. As soon as CMF 2.2.0 is released it will become the current release and the 2.2 branch the current maintenance branch. No? Sorry, you're right, I realized I did get you wrong after sending my reply. As always ;-) I do have one last question, though (unless I misunderstand something, again): In my understanding, we're now down to a single policy difference, about the point in time when you want the trunk CHANGES file updated. You're still saying it will only ever be fully updated when the current release branch changes are merged in, probably just before creating a new release branch, right? I still don't see an advantage in pushing this CHANGES maintenance on the trunk to the release manager as opposed to every developer maintaining it concurrently with the release branch CHANGES file. I personally would much rather see all changes that are on the trunk to be reflected in its CHANGES file at all times. 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 )
[Zope-dev] Re: Extend specification of how to maintain the changelog
Tres Seaver wrote: Christian Theune wrote: [snip] My preference would be to have more important changes first. Please don't make it a judgement call: keep it time-descending order, just like the releases. Among other things, this makes merge conflicts more obvious, and easier to to fix. With time-descending order you mean add more recent fixes to the top of the section, right? Where 'section' is probably the 'bug fixes' or 'features' section per release. Regards, Martijn ___ 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: Extend specification of how to maintain the changelog
On Jun 19, 2008, at 14:41 , Martijn Faassen wrote: Tres Seaver wrote: Christian Theune wrote: [snip] My preference would be to have more important changes first. Please don't make it a judgement call: keep it time-descending order, just like the releases. Among other things, this makes merge conflicts more obvious, and easier to to fix. With time-descending order you mean add more recent fixes to the top of the section, right? Where 'section' is probably the 'bug fixes' or 'features' section per release. I'd vote for the simple time-based order with the newest entries at the top as well. Matter of fact, unless there's such a large amount of entries for a release that you need more order, I would do away with sub-sections like bug fixes, features etc as well. I'd put a simple prefix at the front: - BUG: Fixed behavior of foobar widget - FEATURE: Added new bar widget for handling baz values. - ... 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 )
[Zope-dev] Re: Extend specification of how to maintain the changelog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Tres Seaver wrote: Christian Theune wrote: [snip] My preference would be to have more important changes first. Please don't make it a judgement call: keep it time-descending order, just like the releases. Among other things, this makes merge conflicts more obvious, and easier to to fix. With time-descending order you mean add more recent fixes to the top of the section, right? Where 'section' is probably the 'bug fixes' or 'features' section per release. Right. If we were really strict about the existing policy, then bug fixes wouldn't be recorded on the trunk, only features, and there would never be features added on maintenance / release branches. That policy also strongly suggests doing the initial fix on the oldest maintained branch which has the bug, and then forward-porting it to newer branches and the trunk. Specifically, we don't backport bug fixes, we forward-port them. I've found that doing the fixes in that order has two advantages: - Fixing it on the oldest branch first makes for a better diagnostic mode, with fewer assumptions about the code (because one isn't working in it regularly). - The fix stays minimal / conservative, because we don't make arbitrary cleanups / rearrangements to the code on the branches. - It is usually much easier to merge the minimal fix forward, even if a later branch has been tidied / refactored, than to merge backward. If we change the policy to record all bugfixes in the trunk's changelog, then I would still advocate grouping them: it makes the release manager's job simpler, since the groupings are more informative in an announcement. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIWluv+gerLs4ltQ4RAkQXAJ98umZ2EFMbbvH3xYobJlwhDReWSQCfUGwc m991vofVbLRHJFrP+1KEj9c= =/4Lz -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 )
[Zope-dev] Re: Extend specification of how to maintain the changelog
Jens Vagelpohl wrote: On Jun 19, 2008, at 13:36 , yuppie wrote: Jens Vagelpohl wrote: On Jun 19, 2008, at 12:32 , yuppie wrote: There is always *one* well defined current maintenance branch. Version numbering *does* imply a time line if you ignore old maintenance branches. It's not hard at all to get this right. I don't think that assumption holds true. Again, using the CMF as an example, there were times when we had 3 release branches. I don't want to start a discussion why that was or how to prevent that from happening, I'm just saying it's not correct to say you always have just one maintenance branch. And that's where all those fancy schemes fall down. You did get me wrong :( I tried to make a distinction between the current maintenance branch (= branch for maintaining the *current* release) and old maintenance branches (= branches for maintaining older release). If someone knows better terms, please let me know. The *current* version of CMF is 2.1.1. If you release CMF 1.6.5 with some backports from the 2.1 branch, it will not become the *current* CMF release. As soon as CMF 2.2.0 is released it will become the current release and the 2.2 branch the current maintenance branch. No? Sorry, you're right, I realized I did get you wrong after sending my reply. As always ;-) I do have one last question, though (unless I misunderstand something, again): In my understanding, we're now down to a single policy difference, about the point in time when you want the trunk CHANGES file updated. You're still saying it will only ever be fully updated when the current release branch changes are merged in, probably just before creating a new release branch, right? And you did get me wrong again ;) My first mail today started with these sentences: Second try. My first response to this lead to a discussion about immediate or delayed syncing of CHANGES.txt. That was not my point. I'm fine with keeping CHANGES.txt on the trunk always up to date. The policy difference I'd like to discuss is something completely different: How are the change notes grouped on the trunk? The proposed new policy is to put everything in one big section: Forward-ports from the current maintenance branch and trunk only changes are mixed together. CHANGES.txt just shows the difference between pre-releases of major versions. The old policy, which I like better in this point, solves this differently: Change notes for forward-ports are grouped by release versions from the current maintenance branch. CHANGES.txt helps you to figure out differences between any two versions in the series of 'current' versions, not only between major versions. Note that the policies are the same for CHANGES.txt files on all branches. They are only different for CHANGES.txt on the trunk. Cheers, Yuppie ___ 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: View component registration
David Glick wrote: On Jun 18, 2008, at 1:44 PM, Malthe Borch wrote: Martijn Faassen wrote: There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B? It deserves consideration, but I don't think code will be prone to break since we're merely providing more information to lookup a view component, not less. Exactly. The interface passed to getMultiAdapter or queryMultiAdapter is a minimum requirement. Making views provide IView won't stop them from providing Interface, which is the default. Well, true, view *lookup* for Interface will still work if we register views for a more specific interface. But if Zope's browser publication now starts looking up views with the more specific interface and there are still views around that haven't been registered for that but for Interface, we'll run into backward compatibility problems. I suppose the browser publication would have to be smart about it and do a legacy lookup for Interface if it can't find a view for the specific one. Either way, it's not *that* simple... ___ 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: View component registration
On Jun 19, 2008, at 9:37 AM, Philipp von Weitershausen wrote: David Glick wrote: On Jun 18, 2008, at 1:44 PM, Malthe Borch wrote: Martijn Faassen wrote: There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B? It deserves consideration, but I don't think code will be prone to break since we're merely providing more information to lookup a view component, not less. Exactly. The interface passed to getMultiAdapter or queryMultiAdapter is a minimum requirement. Making views provide IView won't stop them from providing Interface, which is the default. Well, true, view *lookup* for Interface will still work if we register views for a more specific interface. But if Zope's browser publication now starts looking up views with the more specific interface and there are still views around that haven't been registered for that but for Interface, we'll run into backward compatibility problems. I suppose the browser publication would have to be smart about it and do a legacy lookup for Interface if it can't find a view for the specific one. Either way, it's not *that* simple... I suggest: - decide on and advertise the new interface - continue to do look ups the way we do now - update relevant zcml directives (view, page, resource. etc.) to use the new interface - issue informative deprecation warnings when we register adapters providing Interface. - Later, switch to looking up using the new interface. Maybe make this an application option so that people can choose to use the new interface sooner. Jim -- Jim Fulton Zope Corporation ___ 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: View component registration
On Thu, Jun 19, 2008 at 09:46:35AM -0400, Jim Fulton wrote: I suggest: - decide on and advertise the new interface - continue to do look ups the way we do now - update relevant zcml directives (view, page, resource. etc.) to use the new interface - issue informative deprecation warnings when we register adapters providing Interface. - Later, switch to looking up using the new interface. Maybe make this an application option so that people can choose to use the new interface sooner. +1 Would it be reasonable to also issue a warning if someone does a lookup for Interface? Christian -- Christian Theune · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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: View component registration
On Jun 19, 2008, at 10:46 AM, Christian Theune wrote: On Thu, Jun 19, 2008 at 09:46:35AM -0400, Jim Fulton wrote: I suggest: - decide on and advertise the new interface - continue to do look ups the way we do now - update relevant zcml directives (view, page, resource. etc.) to use the new interface - issue informative deprecation warnings when we register adapters providing Interface. - Later, switch to looking up using the new interface. Maybe make this an application option so that people can choose to use the new interface sooner. +1 Would it be reasonable to also issue a warning if someone does a lookup for Interface? No, because clients have to look up using Interface as long as the component they need might be registered with it. Jim -- Jim Fulton Zope Corporation ___ 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: View component registration
On Thu, Jun 19, 2008 at 10:50:00AM -0400, Jim Fulton wrote: Would it be reasonable to also issue a warning if someone does a lookup for Interface? No, because clients have to look up using Interface as long as the component they need might be registered with it. Is that an argument for a grace period? I wondered about the case in general or in the long run. -- Christian Theune · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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: View component registration
On Jun 19, 2008, at 10:53 AM, Christian Theune wrote: On Thu, Jun 19, 2008 at 10:50:00AM -0400, Jim Fulton wrote: Would it be reasonable to also issue a warning if someone does a lookup for Interface? No, because clients have to look up using Interface as long as the component they need might be registered with it. Is that an argument for a grace period? I wondered about the case in general or in the long run. The grace period. Jim -- Jim Fulton Zope Corporation ___ 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] made zope.sqlalchemy work with SA 0.5beta1
Hi there, I've made zope.sqlalchemy work with SQLAlchemy 0.5 beta 1, recently released. This involved: * the 'transactional=True' argument has become 'autocommit=False' * various accesses that the tests were doing to get query.table and such didn't work anymore. I replaced them with direct accesses to the mapped classes. I've also added a CHANGES.txt and a CREDITS.txt, and made it so that the CHANGES.txt information is also uploaded to the cheeseshop. We'll be using the official guidelines for svn.zope.org management of this package for version numbers, and I've made adjustments there too. The official guidelines are only actually hosted on grok.zope.org to my knowledge, and they're here: http://grok.zope.org/documentation/how-to/releasing-software All of this work is on a branch: svn+ssh://svn.zope.org/repos/main/zope.sqlalchemy/branches/sqlalchemy-0.5-support I'd like to merge the branch to the trunk as soon as possible, but I need Laurence's go first. Laurence, any chance we'll be doing a release for 0.4* from the trunk? Or we could delegate that work to a maintenance branch (if necessary) and aim for SA 0.5 support on the trunk now? Let me know and I'll merge the branch. Regards, Martijn ___ 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] created z3c.saconfig
Hi there, I'd like to announce my contribution for the expanding list of options for SQLAlchemy integration for Zope 3. I've just implemented a package called z3c.saconfig which implements a utility-based way to set up SQLAlchemy's scoped session, as discussed recently on this. The package currently offers a way to configure SQLAlchemy sessions with a utility. This allows SQLAlchemy sessions to potentially differ per application. Currently if you would want to implement such utilities you're still on your own, but I intend to add support for this soon. Hermann What is in there already is support for a global utility as discussed with Brian Sutherland. I intend to add support for a local utility soon, inspired by some code sent to me by Hermann Himmelbauer. Anyway, the README.txt should explain more: http://svn.zope.org/z3c.saconfig/trunk/src/z3c/saconfig/README.txt Feedback is welcome! Regards, Martijn ___ 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: made zope.sqlalchemy work with SA 0.5beta1
Martijn Faassen wrote: Hi there, I've made zope.sqlalchemy work with SQLAlchemy 0.5 beta 1, recently released. This involved: * the 'transactional=True' argument has become 'autocommit=False' * various accesses that the tests were doing to get query.table and such didn't work anymore. I replaced them with direct accesses to the mapped classes. I've also added a CHANGES.txt and a CREDITS.txt, and made it so that the CHANGES.txt information is also uploaded to the cheeseshop. We'll be using the official guidelines for svn.zope.org management of this package for version numbers, and I've made adjustments there too. The official guidelines are only actually hosted on grok.zope.org to my knowledge, and they're here: http://grok.zope.org/documentation/how-to/releasing-software All of this work is on a branch: svn+ssh://svn.zope.org/repos/main/zope.sqlalchemy/branches/sqlalchemy-0.5-support I'd like to merge the branch to the trunk as soon as possible, but I need Laurence's go first. Laurence, any chance we'll be doing a release for 0.4* from the trunk? Or we could delegate that work to a I've made the branch backwards compatible with 0.4 and merged to trunk. I'd like to keep compatibility while we can. Laurence ___ 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: made zope.sqlalchemy work with SA 0.5beta1
Hey, Laurence Rowe wrote: [snip] I've made the branch backwards compatible with 0.4 and merged to trunk. I'd like to keep compatibility while we can. Yeah, looks good, thanks! Regards, Martijn ___ 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: created z3c.saconfig
Hey, Martijn Faassen wrote: I intend to add support for a local utility soon, inspired by some code sent to me by Hermann Himmelbauer. This is now in there. It only looks faintly like Hermann's code, but it was still very useful. You can register an engine factory globally or locally. This engine factory can be called to create an engine, but it'll return the same engine again when called again. This way, engines are shared and engine pooling works. To make this work for your application/framework you need to subclass SiteScopedSession and implement siteScopeFunc. You can then register an instance of that subclass globally (or locally if you should so desire, but globally is usually enough). The README was updated to reflect the new situation: http://svn.zope.org/z3c.saconfig/trunk/src/z3c/saconfig/README.txt This now works against the trunk of zope.sqlalchemy as well, as Laurence merged my branch. I do think my code currently requires SQLAlchemy 0.5beta1 or higher. Overall I'm quite pleased by this code. It's straightforward, and leaves to SQLAlchemy as much as possible, and just passes configuration parameters for engines and sessions along if you define them for the utilities. It doesn't offer any user interface code or schemas itself; that's up to the application or framework developer. It's also flexible. Configuration information could be retrieved from any place a developer would like; hardcoded in Python, or the ZODB. I think it wouldn't be hard to write custom utilities that look up configuration in configuration files such as zope.conf or ZCML as well. One thing I'm not sure about is using _v_engine to store the engine in a persistent local utility. What if the local utility gets evicted from the ZODB cache? It'd need to recreate the engine. Anyway, I've left the policy on how to cache the engine overridable. I'm curious about better ideas. I considered using a global dictionary with the cached engines in there, as nothing could get just disappear from that, but I'm not entirely sure that'd be thread safe. There is a chance that an engine gets recreated if two threads were to be writing to it at the same time. Perhaps some thread locking code is required. Opinions? Feedback is again welcome! Regards, Martijn ___ 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: [ZWeb] zope.org migration
--On 15. Juni 2008 13:25:51 +0200 Andreas Jung [EMAIL PROTECTED] wrote: --On 15. Juni 2008 06:16:52 -0500 Jens Vagelpohl [EMAIL PROTECTED] wrote: On Jun 15, 2008, at 06:09 , Andreas Jung wrote: --On 15. Juni 2008 06:04:37 -0500 Jens Vagelpohl [EMAIL PROTECTED] wrote: IMHO seeing some caching-related issues in exchange for enjoying a redundantly configured caching tier is a good tradeoff for the current site. The current caching makes it impossible to edit anything on zope.org in a reasonable way. I have always been able to work with it using force-reload where necessary, using Camino or Firefox. I know some other browsers like Safari don't seem to be able to send a real force-reload, so I gave up on those for zope.org editing work. I have to admit I have not done any editing work after this move, but I have been able to log in and get to folder content views etc with all logged-in options intact and visible. If you are using a suitable browser that can issue real forced reloads and you still see a problem let us know, David (or some other ZC SA) will have to look into it then. I am always using suitable tools :-) Using Firefox here. I am logged in as ajung. http://zope.org/Products/Zope/2.11.0 shows up with all Plohn edit options. http://zope.org/Products/Zope/2.10.6/ does not. Even worser: wget http://zope.org/Products/Zope/2.11.0/folder_contents; returns the page from the cache rendered within _my_ user context. That's totally broken :-) What is the current status of this issue? It can not be that personalized content (of authenticated users) is being cached and delivered to the outside world. I still can not do anything on zope.org :- Andreas pgphenAMkisHS.pgp Description: PGP signature ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
Re: [ZWeb] zope.org migration
On Jun 19, 2008, at 20:53 , Andreas Jung wrote: I am logged in as ajung. http://zope.org/Products/Zope/2.11.0 shows up with all Plohn edit options. http://zope.org/Products/Zope/2.10.6/ does not. Even worser: wget http://zope.org/Products/Zope/2.11.0/folder_contents; returns the page from the cache rendered within _my_ user context. That's totally broken :-) What is the current status of this issue? It can not be that personalized content (of authenticated users) is being cached and delivered to the outside world. I still can not do anything on zope.org :- I do not know what the status is since I can't touch the caching tier and have to rely on ZC admins to fix it. I'm CCing Dave Lawson. Dave, is there a way to go back to the caching configuration that existed before the move? The current caching is way too aggressive and prevents people from doing any content creation and editing on zope.org. Thanks! jens ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
Re: [ZWeb] zope.org migration
On Jun 19, 2008, at 2:59 PM, Jens Vagelpohl wrote: On Jun 19, 2008, at 20:53 , Andreas Jung wrote: I am logged in as ajung. http://zope.org/Products/Zope/2.11.0 shows up with all Plohn edit options. http://zope.org/Products/Zope/2.10.6/ does not. Even worser: wget http://zope.org/Products/Zope/2.11.0/folder_contents; returns the page from the cache rendered within _my_ user context. That's totally broken :-) What is the current status of this issue? It can not be that personalized content (of authenticated users) is being cached and delivered to the outside world. I still can not do anything on zope.org :- I do not know what the status is since I can't touch the caching tier and have to rely on ZC admins to fix it. I'm CCing Dave Lawson. Dave, is there a way to go back to the caching configuration that existed before the move? The current caching is way too aggressive and prevents people from doing any content creation and editing on zope.org. Well. I had a look and I can certainly see why you've noticed a difference. zope.org, prior to the move, was essentially un-cached. It had a very small cache configured on the children and the parents were configured not to cache anything for zope.org at all. We can certainly go back to that configuration if you'd like, it's a pretty minimal change. --Dave Systems Administrator Zope Corp. 540-361-1722 [EMAIL PROTECTED] ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
[Zope] ZODB and Zope Database Adapters
Hi all. In the doc/ZODB3.txt of Zope 2.8 (and Zope 2.9) I've found the following paragraph. ZODB 3 and Zope Database Adapters Most database adapters are *currently* likely to be problematic unless the underlying extensions and libraries: - allow multiple simultaneous database connections, - are thread safe, - give up the Python global interpreter lock when making database calls. This is only a problem when running Zope 2 with multiple threads. I would like to know if anyone has experience of some of these problems with psycopg 1.1 and ZPsycopgDA Regards Marco -- Marco Bizzarri http://iliveinpisa.blogspot.com/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Open an HTML file in zope
Thanks a lot..It worked..
Andreas Jung [EMAIL PROTECTED] wrote:
--On 18. Juni 2008 10:14:10 +0100 sujitha mary
wrote:
Hi,
I need to open and display an HTML file in zope.For that I uploaded the
file as DTML document and tried to retrieve it from a page template.this
is code which i wrote for this:
tal:replace=here/PH226this will
'PH226' is the name of my uploaded file.
This will only work if the PH226 can be _aquired_ from your current context
object (check with The Zope Book 2.7 edition about _ACQUISITION_ - one of
the Zope core concepts.
If i need to display more than one file at a time wht should i do?i
tried to modify my code for displaying the files which is selected by the
user thru' a form.But it didn't work: This is the piece of code which i
used
this
will
Acquisition also applies here.
tal:replace=python: getattr(context, x)
An alternative to acquisition for getting an object is traveral
(restrictedTraverse('/path/to/object').
I strongly recommend reading the basic Zope documentation first in order to
understand how acquistion works.
-aj
-
Bollywood, fun, friendship, sports and more. You name it, we have it.___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: record count in catalog
Tres Seaver wrote at 2008-6-15 16:18 -0400:
...
The Catalog tab in my catalog says this:
The catalog mycatalog contains 30,345 record(s) in the path /.
But when I sort and return a list of cataloged objects I only have 19,881.
Here is the script call to retrieve the records:
context.mycatalog.search( {}, sort_index='lastname' )
Why don't the numbers match up?
Some of your objects don't have a 'lastname' attribute, and so when
sorting, they get dropped.
Should we not consider this a bug and fix it?
--
Dieter
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: record count in catalog
--On 19. Juni 2008 20:35:29 +0200 Dieter Maurer [EMAIL PROTECTED] wrote:
Tres Seaver wrote at 2008-6-15 16:18 -0400:
...
The Catalog tab in my catalog says this:
The catalog mycatalog contains 30,345 record(s) in the path /.
But when I sort and return a list of cataloged objects I only have
19,881.
Here is the script call to retrieve the records:
context.mycatalog.search( {}, sort_index='lastname' )
Why don't the numbers match up?
Some of your objects don't have a 'lastname' attribute, and so when
sorting, they get dropped.
Should we not consider this a bug and fix it?
+1 for the bug prospective :-)
Andreas
pgpDCuaDnFWCF.pgp
Description: PGP signature
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] help debugging a can't pickle error deep within a catalog reindex
Rob Miller wrote at 2008-6-17 15:47 -0700: ... Traceback (most recent call last): /home/rob/topp/14000/builds/20080611/opencore/lib/zope/lib/python/ZODB/serialize.py, line 407, in serialize return self._dump(meta, obj.__getstate__()) File /home/rob/topp/14000/builds/20080611/opencore/lib/zope/lib/python/ZODB/serialize.py, line 416, in _dump self._p.dump(state) File copy_reg.py, line 69, in _reduce_ex raise TypeError, can't pickle %s objects % base.__name__ TypeError: can't pickle instancemethod objects Reproduce the problem in an interactive Python interpreter (bin/zopectl debug on *nix; alternatives for Win*). Call pdb.pm() (or probably better dm.pdb.zpdb.pm() (dm.pdb can be found on PyPI)) and go up two call frames. Look at obj. With a bit of looks, you see which objects this is and where it comes from. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
