Re: [Zope-CMF] Re: [dev] failing tests and other unit test issues
Dieter Maurer wrote: yuppie wrote at 2005-4-4 20:59 +0200: ... 2.) I prefer to see the correct import in each file and to use utils just for the fallback. But, then you get a nasty "try: ... except:" in hundred of files rather than just a single one. Eight files in CMF, not hundreds of files for 'import transaction'. It's a different story for 'import Zope2'. All unit test files would need a nasty try/except and 'import Zope' makes much less noise than 'get_transaction()'. So I'll leave them as they are, at least for now. Cheers, Yuppie ___ 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 Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open chrisw - "Limit the roles that can create specified types of content.", [Accepted] http://www.zope.org/Collectors/CMF/114 gregweb - "CMFUid.UniqueIdGeneratorTool's counter may return double unique ids", [Accepted] http://www.zope.org/Collectors/CMF/306 jens - "manage_addFactoryTIForm mangles entries", [Accepted] http://www.zope.org/Collectors/CMF/49 - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Accepted] http://www.zope.org/Collectors/CMF/271 - "Allow FSZSQLMethods to specify pluggable brain & connection hook", [Accepted] http://www.zope.org/Collectors/CMF/335 - "DirectoryView - more flexibility on ignoring things", [Accepted] http://www.zope.org/Collectors/CMF/319 mj - "CMFSetup doesn't correctly detect DCWorkflow on export", [Accepted] http://www.zope.org/Collectors/CMF/298 shh - "CMF 1.4 doesn't work under Zope 2.8", [Accepted] http://www.zope.org/Collectors/CMF/321 Pending / Deferred Issues - "DCWorkflow: cannot define variable 'meta_type'", [Pending] http://www.zope.org/Collectors/CMF/45 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "acl_users/roster", [Pending] http://www.zope.org/Collectors/CMF/63 - "Where did index_html_utils.html come from?", [Pending] http://www.zope.org/Collectors/CMF/93 - "iso-8859-2 in CMF ?", [Pending] http://www.zope.org/Collectors/CMF/160 - "Debuggable scripts", [Pending] http://www.zope.org/Collectors/CMF/194 - "formatRFC822Headers weakness?", [Pending] http://www.zope.org/Collectors/CMF/230 - "CMFCalendar weekday locale issue", [Pending] http://www.zope.org/Collectors/CMF/237 - "CMFCalendar: Events ending on midnight", [Pending] http://www.zope.org/Collectors/CMF/246 - "Wrong cache association for FSObject", [Pending] http://www.zope.org/Collectors/CMF/255 - "CMFSetup: Windows exports contain CR/LF, LF and even CR newlines", [Pending] http://www.zope.org/Collectors/CMF/266 - "Unable to copy/import site due to talkbalk attribute assumptions", [Pending] http://www.zope.org/Collectors/CMF/282 - "DateIndex in portal_catalog", [Deferred] http://www.zope.org/Collectors/CMF/286 - "PortalCatalog.ZopeFindAndApply should probably also search in opaqueItems", [Pending] http://www.zope.org/Collectors/CMF/296 - "WorkflowTool should recurse into opaqueItems", [Pending] http://www.zope.org/Collectors/CMF/297 - "ToolInit icon error", [Pending] http://www.zope.org/Collectors/CMF/305 - "PortalFolder._checkId does wrong acquisition", [Pending] http://www.zope.org/Collectors/CMF/311 - "Dates shown are incorrect if object originates in another timezone", [Pending] http://www.zope.org/Collectors/CMF/325 - "add External Methods to workflow script handling", [Pending] http://www.zope.org/Collectors/CMF/329 - "FSFile and FSImage don't update caching headers for 304 responsens", [Pending] http://www.zope.org/Collectors/CMF/333 - "SkinContainer raises exception for .svn folder", [Pending] http://www.zope.org/Collectors/CMF/336 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "TTW configuration of registration tool", [Pending] http://www.zope.org/Collectors/CMF/32 - "Provide delete reply function to standard skins that come with CMF", [Pending] http://www.zope.org/Collectors/CMF/38 - "Allow flexible date editing in Event.py (CMFCalendar)", [Pending] http://www.zope.org/Collectors/CMF/40 - "Topic should be catalogued", [Pending] http://www.zope.org/Collectors/CMF/53 - "Renaming states and transitions", [Pending] http://www.zope.org/Collectors/CMF/89 - "Make changeFromProperties accept sequences too", [Pending] http://www.zope.org/Collectors/CMF/99 - "path criteria on Topic should honor VHM", [Pending] http://www.zope.org/Collectors/CMF/111 - "having a locale.pot file should ease the process of translating CMF", [Pending] http://www.zope.org/Collectors/CMF/155 - "french translation for CMF 1.4", [Pending] http://www.zope.org/Collectors/CMF/157 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "Permissions in PortalFolder: invokeFactory()", [Pending] http://www.zope.org/Collectors/CMF/175 - "Add condition for transition's action like other action", [Pending] http://www.zope.org/Collectors/CMF/207 - "Major action enhancement", [Pending] http://www.zope.org/Collectors/CMF/2
Re: [Zope-CMF] [Performance] "listFilteredActionsFor" unnecessarily expensive
Dieter Maurer <[EMAIL PROTECTED]> wrote: > In our regular profiles, "listFilteredActionsFor" belongs to > the top consumers of CPU time. > > Recently, I found the main culprit (in CMF 1.4): > >It is the completely unnecessary: > > if not action in catlist: > > In our case, "listFilteredActionsFor" spends about 70 percent > of its complete time in the checking of "action in catlist". > > How in hell should the same action be defined more than once > such that we need to prevent such a case by an explicit check -- > especially by such an expensive one? > > A comment before the line indicates that the author intended > to check by identity. But, of course, "action in catlist" > does *NOT* check by identity but by equality. > > > I propose to remove the check altogether... +1. The three lines above could be reduced to one using .setdefault() too. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: [Performance] "listFilteredActionsFor" unnecessarily expensive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: > Dieter Maurer <[EMAIL PROTECTED]> wrote: > >>In our regular profiles, "listFilteredActionsFor" belongs to >>the top consumers of CPU time. >> >>Recently, I found the main culprit (in CMF 1.4): >> >> It is the completely unnecessary: >> >> if not action in catlist: >> >>In our case, "listFilteredActionsFor" spends about 70 percent >>of its complete time in the checking of "action in catlist". >> >>How in hell should the same action be defined more than once >>such that we need to prevent such a case by an explicit check -- >>especially by such an expensive one? >> >>A comment before the line indicates that the author intended >>to check by identity. But, of course, "action in catlist" >>does *NOT* check by identity but by equality. >> >> >>I propose to remove the check altogether... > > > +1. > > The three lines above could be reduced to one using .setdefault() too. We could also use a 'seen' dictionary: key = (category, action.id) if key not in seen: seen[key] = 1 Tres. - -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation "Zope Dealers" http://www.zope.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCU/zcGqWXf00rNCgRAucmAJ99O136uSaCVPP5oywsSPpuXiw77wCfcCuw HXKo7WZbt5d/h4u6m1uthfM= =8Elp -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: [Performance] "listFilteredActionsFor" unnecessarily expensive
On Wednesday 06 April 2005 08:14 am, Tres Seaver wrote: > Florent Guillaume wrote: > > Dieter Maurer <[EMAIL PROTECTED]> wrote: > >>In our regular profiles, "listFilteredActionsFor" belongs to > >>the top consumers of CPU time. > >> > >>Recently, I found the main culprit (in CMF 1.4): > >> > >> It is the completely unnecessary: > >> > >> if not action in catlist: > >> > >>In our case, "listFilteredActionsFor" spends about 70 percent > >>of its complete time in the checking of "action in catlist". > >> > >>How in hell should the same action be defined more than once > >>such that we need to prevent such a case by an explicit check -- > >>especially by such an expensive one? > >> > >>A comment before the line indicates that the author intended > >>to check by identity. But, of course, "action in catlist" > >>does *NOT* check by identity but by equality. > >> > >> > >>I propose to remove the check altogether... > > > > +1. > > > > The three lines above could be reduced to one using .setdefault() too. > > We could also use a 'seen' dictionary: > > key = (category, action.id) > if key not in seen: > seen[key] = 1 > That would be changing behavior, and the result may be undesirable to some (as yuppie indicates above). I think it's probably a good idea (I've always been surprised that this wasn't the way things worked), but maybe not for a minor release on the 1.4 branch. Alec ___ 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] CMFSetup profile extensions dependencies
I'd like to discuss possible improvements to have profile extensions
check some dependencies. This will require a way to express
dependencies, which in the general case can be extremely complex -- but
we probably don't need that.
Use cases
-
1. When installing CMFDefault:default, I'm offered the extensions
SQLDiscussions and BlogDiscussions, which both change the
portal_discussions tool but are incompatible between each other.
=> There may be conflicts between extensions.
2. At a customer I'm installing CPS:default, with the standard extension
CPS:simple_mode (which doesn't make sense with CMF), and finally the
customer-specific extension SomeCustomer:default. Just selecting
"Somecustomer:default" should get all the required profiles.
=> An extension may have required profiles, and this can be cascaded.
3. CPSCalendar:default was coded with requiring CMFDefault:default but
actually CPS:default can also work with it, even if CPSCalendar doesn't
know about it.
=> A profile may say that it accepts an extension even if the
extension has explicit requirements and the profile isn't listed
in them.
Proposal
Today a profile can be either BASE or EXTENSION.
I'd like to extend this value to be one of:
- None
Which means a toplevel profile, equivalent to BASE
- {}
Which means a simple extension profile, equivalent to EXTENSION
- {'requires': ('CMFDefault:default', 'CPS:default')}
Which means that this profile can only be installed with
one of the listed profiles.
(Should maybe be 'requires_any' to be clear.)
- {'conflicts': ('Bar:bar',)}
Which means that this profile cannot be installed with any
of the listed profiles.
- {'provides': {'Foo': ('Bar', 'Baz')}}
Which says that this profile can pose as Foo in package Bar and
Baz's requirements. Maybe () could mean for all packages. Maybe
this should also be taken into account by conflicts?
Comments? I'm pretty sure this can be improved in term of expressing the
dependencies, but the basic use cases are real for me.
One of the challenges would be the user interface, of course.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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
