[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open dreamcatcher - setChainForPortalTypes doesn't allow to set default chain, [Accepted] http://www.zope.org/Collectors/CMF/475 mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - FSPropertiesObject.py cannot handle multiline input for lines, text attributes, [Deferred] http://www.zope.org/Collectors/CMF/271 - Can't invalidate skin items in a RAMCacheManager, [Pending] http://www.zope.org/Collectors/CMF/343 - workflow notify success should be after reindex, [Deferred] http://www.zope.org/Collectors/CMF/389 - Possible bug when using a BTreeFolder Member folder, [Pending] http://www.zope.org/Collectors/CMF/441 - purge_old in runAllImportSteps not working, [Pending] http://www.zope.org/Collectors/CMF/455 - Danger from Caching Policy Manager, [Pending] http://www.zope.org/Collectors/CMF/460 - properties setup handler: support for non-ascii strings, [Pending] http://www.zope.org/Collectors/CMF/468 - GenericSetup does not handle non-ascii data well, [Pending] http://www.zope.org/Collectors/CMF/471 - autocreation of catalog indexes, [Pending] http://www.zope.org/Collectors/CMF/472 - [GS] Error when choosing initial_configuration , [Pending] http://www.zope.org/Collectors/CMF/473 - Workflows are missing a description attribute, [Pending] http://www.zope.org/Collectors/CMF/480 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - Document.py: universal newlines, [Pending] http://www.zope.org/Collectors/CMF/174 - portal_type is undefined in initialization code, [Pending] http://www.zope.org/Collectors/CMF/248 - CMFTopic Does Not Cache, [Deferred] http://www.zope.org/Collectors/CMF/295 - Wishlist: a flag that tags the selected action., [Pending] http://www.zope.org/Collectors/CMF/301 - CMFDefault should make use of allowCreate(), [Pending] http://www.zope.org/Collectors/CMF/340 - Nested Skins, [Deferred] http://www.zope.org/Collectors/CMF/377 - CatalogVariableProvider code + tests, [Pending] http://www.zope.org/Collectors/CMF/378 - CMF needs View-based TypeInformation, [Pending] http://www.zope.org/Collectors/CMF/437 - New getNextEvent Method, [Pending] http://www.zope.org/Collectors/CMF/462 - Support 'remove' attribute for skin-path/ nodes in skins.xml, [Pending] http://www.zope.org/Collectors/CMF/479 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Making TypesTool faster
Am 03.05.2007 um 00:50 schrieb Alexander Limi: At present, Archetypes-based content types cannot be used with a factory (I tried hard, but there are some acquisition-related/factory related reasons); I'd like to refactor this, but we can't for Plone 3.0 at least. Right. Obviously, we'd like to do this the proper way, but we can't do that for a while yet. I'm sorry but it's -1 from me. The change is unnecessary and the problem seems to be with Archetypes and not the CMF. In my view it is incorrect to change the infrastucture to compensate for the deficiencies of a component. If you need it in Plone you can add it as a patch. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Tests: 8 OK, 1 Failed, 2 Unknown
Summary of messages to the cmf-tests list. Period Thu May 3 12:00:00 2007 UTC to Fri May 4 12:00:00 2007 UTC. There were 11 messages: 11 from CMF Unit Tests. Test failures - Subject: FAILED (failures=1) : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:34:48 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004853.html Unknown --- Subject: UNKNOWN : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:43:54 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004859.html Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:46:57 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004861.html Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Thu May 3 21:31:46 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004851.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Thu May 3 21:33:17 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004852.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Thu May 3 21:36:19 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004854.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:37:50 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004855.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:39:21 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004856.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:40:52 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004857.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:42:24 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004858.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:45:26 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004860.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Making TypesTool faster
Charlie Clark-3 wrote: Am 03.05.2007 um 00:50 schrieb Alexander Limi: At present, Archetypes-based content types cannot be used with a factory (I tried hard, but there are some acquisition-related/factory related reasons); I'd like to refactor this, but we can't for Plone 3.0 at least. Right. Obviously, we'd like to do this the proper way, but we can't do that for a while yet. I'm sorry but it's -1 from me. The change is unnecessary and the problem seems to be with Archetypes and not the CMF. In my view it is incorrect to change the infrastucture to compensate for the deficiencies of a component. If you need it in Plone you can add it as a patch. I'm not entirely convinced the problem is in AT, and I think we are conflating two different issues here. One is an observation of Tres' that AT has a function that could perform more cacheing. That's a good point, and may mitigate some of the performance issues by cacheing at a higher level, but it doesn't mean there aren't further opportunities for improvements to the underlying code. The other issue is some code in TypesTool which is making a lot of calls to a procedure in Zope which is unlikely (impossible?) to ever return a different result until Zope is restarted and new products are detected. If the two are orthogonal, and we already have a sane patch, then why not (at least if we can get some tests in place) fix the one at the CMF level and deal with the other Archetypes issue separately. Martin -- View this message in context: http://www.nabble.com/Making-TypesTool-faster-tf3678114.html#a10321411 Sent from the Zope - CMF list2 mailing list archive at Nabble.com. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Making TypesTool faster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Charlie Clark-3 wrote: Am 03.05.2007 um 00:50 schrieb Alexander Limi: At present, Archetypes-based content types cannot be used with a factory (I tried hard, but there are some acquisition-related/factory related reasons); I'd like to refactor this, but we can't for Plone 3.0 at least. Right. Obviously, we'd like to do this the proper way, but we can't do that for a while yet. I'm sorry but it's -1 from me. The change is unnecessary and the problem seems to be with Archetypes and not the CMF. In my view it is incorrect to change the infrastucture to compensate for the deficiencies of a component. If you need it in Plone you can add it as a patch. I'm not entirely convinced the problem is in AT, and I think we are conflating two different issues here. One is an observation of Tres' that AT has a function that could perform more cacheing. That's a good point, and may mitigate some of the performance issues by cacheing at a higher level, but it doesn't mean there aren't further opportunities for improvements to the underlying code. The other issue is some code in TypesTool which is making a lot of calls to a procedure in Zope which is unlikely (impossible?) to ever return a different result until Zope is restarted and new products are detected. I think I misunderstood: you guys have actually measured that the 'manage_addProducts[product]' dance is taking measurable time when building the add list? I thought we were trying to cache the result of the whole lookup, especially the meta_type-is-allowed + user-has-permission checks, which I would imagine are much more expensive than the factory dispatcher lookup. That said, I didn't really understand the patch as earlier proposed; I'm sorry for not reading more carefully. If the two are orthogonal, and we already have a sane patch, then why not (at least if we can get some tests in place) fix the one at the CMF level and deal with the other Archetypes issue separately. If factory dispatcher lookup is truly the hotspot, then we should be fixing it even lower in the stack (at the Zope level). Trse. - -- === 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 iD8DBQFGOyRg+gerLs4ltQ4RAi2cAKCq13gmBFz9MNfJNlmZTjiGgudnzgCgnWqC NTjFLPoZw0xL2OSbIBrpztQ= =1zFZ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Making TypesTool faster
Am 04.05.2007 um 14:00 schrieb Martin Aspeli: I'm not entirely convinced the problem is in AT, and I think we are conflating two different issues here. One is an observation of Tres' that AT has a function that could perform more cacheing. That's a good point, and may mitigate some of the performance issues by cacheing at a higher level, but it doesn't mean there aren't further opportunities for improvements to the underlying code. Indeed it doesn't but the argument is that there is a performance problem in Plone rather than CMF. Tres' most telling argument for me is: The cache is actually based only on the container (which could be a path) and the user ID. It would be a perfect use of a RAM Cache Manager (assuming that we cached mappings rather than persistent references). Using a volatile here (which is what I assume you mean) would dilute the locality of the cache by the number of database connections in use. The other issue is some code in TypesTool which is making a lot of calls to a procedure in Zope which is unlikely (impossible?) to ever return a different result until Zope is restarted and new products are detected. No, the issue is how often the TypesTool is being called (from within Plone). Surely the cache should be higher upstream in this case? Or maybe no, see below. If the two are orthogonal, and we already have a sane patch, then why not (at least if we can get some tests in place) fix the one at the CMF level and deal with the other Archetypes issue separately. The Archetypes issue should indeed be dealt with separately. I am, however, not convinced that this patch is sane. If the calls to Zope are indeed the issue as you suggest then I would suggest looking at their mechanism and whether Zope rather than the CMF can be improved in this respect - going on what Alec is quoted as saying it still makes sense to me to put the cache in the Zope making it available to all components. I've only had a brief look at the Product registration, etc. in Zope but from what I saw it looked like it could indeed be improved. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF Tests: 8 OK, 1 Failed, 2 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CMF Tests Summarizer wrote: Unknown --- Subject: UNKNOWN : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:43:54 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004859.html Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:46:57 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004861.html OK, I think I have this pegged: the version of the zope.testing on the Zope2 trunk was pinned to an older version than the on the 2.10 branch. It was: $ svn propget svn:externals lib/python/zope | grep testing testing svn://svn.zope.org/repos/main/zope.testing/tags/3.0/src/zope/testing [/home/tseaver/projects/Zope-CVS/Zope-2.10-branch] $ cd ../Zope-trunk/ [/home/tseaver/projects/Zope-CVS/Zope-trunk] $ svn propget svn:externals lib/python/zope | grep testing testing -r 67760 svn://svn.zope.org/repos/main/zope.testing/trunk/src/zope/testing I have updated the version to match the 2.10 version. The CMF functional tests now pass using a trunk Zope2 checkout. 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 iD8DBQFGOyrw+gerLs4ltQ4RAhYRAJ99LjxaVSCPL/nIueZs9u7oz2yHwQCeJp9/ uC1Cv7mx1o+I9hsrpAWRyh0= =Tzlh -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF Tests: 8 OK, 1 Failed, 2 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4 May 2007, at 07:45, Tres Seaver wrote: Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu May 3 21:46:57 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-May/004861.html OK, I think I have this pegged: the version of the zope.testing on the Zope2 trunk was pinned to an older version than the on the 2.10 branch. I pointed out that specific cause in mid-March and had hoped for help from Zen, who made the fixes to Zope 2.10: http://mail.zope.org/pipermail/zope-cmf/2007-March/025737.html jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGOy8xRAx5nvEhZLIRAodtAKC29tF0OEX0fDsbSvWRdwG9jtGU9ACeL8d8 pm9nhzfVpV0EUTmXkRJ754g= =T//H -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
