Re: [Zope-dev] [Interested?] New use for Zope+CMF+Archetypes -- startup time improvements
Andreas Jung wrote at 2005-5-14 11:00 +0200: > ... >Although I already worked with pypackage my questions: is it an optional >feature or will pypackage take control over all and everything? Provided that any access to a package relative resource is converted from "dirname(__file__)" to "package_home" logic to use or not use "pypackage" could be localized in "package_home" and (maybe) "OFS.Application.get_products". >Products >using __path__ or changing the current directory need to be fixed, right? "__path__" is a string in a frozen application. It is likely that any software part that uses "__path__" currently asumes it to be a list. Any product that tries the change the current directory to lie in a ZIP archive or execatable will observe that this is impossible. -- 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] inituser problem
On May 13, 2005, at 20:25, Chris Withers wrote: It creates a user under what I feel are fairly bizarre circumstances. I feel it should simply use inituser if it's there and the user in it doesn't already exist in the root acl_users. Either that, or it should overwrite any user if the inituser file exists. The weird special case of one user being in the root acl_users seems extremely counterintuitive. You describe what you feel it should do, but not what it does right now and why it's weird and should be changed... 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] inituser problem
Hi, I have a problem with the code in AccessControl.User.UserFolder._createInitialUser. It creates a user under what I feel are fairly bizarre circumstances. I feel it should simply use inituser if it's there and the user in it doesn't already exist in the root acl_users. Either that, or it should overwrite any user if the inituser file exists. The weird special case of one user being in the root acl_users seems extremely counterintuitive. What do other people feel? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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] [Interested?] New use for Zope+CMF+Archetypes -- startup time improvements
Dieter, this sounds very interesting. The idea of creating such application that are "shared" between desktop and web has always appealed me and I was wondering how to implement it. So I would be very interested - that your patches make their way to the Zope core (I am not a Zope core contributor tough) - to learn more about what you have done. Robert Dieter Maurer wrote: Dear Zope developers, we have used Zope+CMF+Archetypes in a new way -- not as a Web Application framework but as a framework for desktop applications that share a large part of their functionality with online applications (implemented with Zope+CMF+Archetypes). A major stumbling block has been Zope's incredibly high startup time. We observerd times in the order of a minute on computers with either slow CPU or slow IO. This may be acceptable for a Web server but is prohibitive for a desktop application -- especially as the predecessor application started within a few seconds. To overcome this obstacle, we tweaked Zope and fixed Python's import mechanism such that Zope now starts either out of a ZIP archive or as a frozen application. These measures had the following results. Startup times on a mid range computer (AMD Athon 1.4 GHz; 512 MB memory) with a standard IDE disk. Cold start Warm start (after computer startup)(most files in OS cache) File system 13s5s ZIP archive 8s4s Frozen 5s3s In more details, we did: * implement a package for a new kind of "url"s "pypackage:" for package relative access to resources. The package monkey patches Python's "open", "os.listdir", "os.stat" to provide transparent access to "pypackage:" identified resources. It currently support package relative access for packages loaded from the file system, from a ZIP archive and from the executable itself (i.e. frozen packages). In the last case, the resources are in a separate ZIP archive. This package might be interesting for Python as a whole as it is not Zope specific. * implement a shared object importer to be used as a Python "meta_path" hook. This importer allows to load shared objects into the context of a parent package (such as e.g. "ZODB.TimeStamp") although the shared object is not located inside the package's source (ZIP archive or executable). * fix about 70 occurrences in Zope code where package relative access was implemented by "dirname(__file__)" to consistenty use "package_home". * modify about a dozen places in Zope+CMF to use "pypackage:" and cope with "__path__" not being a list for frozen packages * fix a few products (Archetypes and friends, TextIndexNG2, PlacelessTranslationService, ...) to use "package_home" (rather than "dirname(__file__)") and not to change the current working directory (which obviously would fail for destinationsbe in a ZIP archive or the executable). * implement lazy loading of "ImageFile"s to reduce the risk of recursive imports (and reduce startup time). * support lazy product initialization * support configuration from a pickle file (to avoid expensive parsing of the schema and configuration files). The pickle is used as a configuration cache. * fixed Python's import mechanism not to treat ZIP archives as a directory when the archive could not find a module. If you were *really* interested in these startup time improvements, I could provide patches which might be integrated in the Zope core for e.g. Zope 2.9. ___ 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] [Interested?] New use for Zope+CMF+Archetypes -- startup time improvements
--On Freitag, 13. Mai 2005 19:26 Uhr +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote: If you were *really* interested in these startup time improvements, I could provide patches which might be integrated in the Zope core for e.g. Zope 2.9. Although I already worked with pypackage my questions: is it an optional feature or will pypackage take control over all and everything? Products using __path__ or changing the current directory need to be fixed, right? I think 2.9 would be a good target. If there is common agreement that it should go into the core (+1 from my side) then please wait with submitting patches until we have cut a release branch for Zope 2.8...then the trunk can be used for new features for Zope 2.9. Andreas pgpZj4jMgFUOw.pgp Description: 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: [Interested?] New use for Zope+CMF+Archetypes -- startup time improvements
This is really interesting! A year ago I put Python + Zope on a USB key, just for fun. It would barely fit so I looked at zip techniques, and never could figure out how to get ZPTs etc. to load from a ZIP. How did you do that part? --Paul Dieter Maurer wrote: Dear Zope developers, we have used Zope+CMF+Archetypes in a new way -- not as a Web Application framework but as a framework for desktop applications that share a large part of their functionality with online applications (implemented with Zope+CMF+Archetypes). A major stumbling block has been Zope's incredibly high startup time. We observerd times in the order of a minute on computers with either slow CPU or slow IO. This may be acceptable for a Web server but is prohibitive for a desktop application -- especially as the predecessor application started within a few seconds. To overcome this obstacle, we tweaked Zope and fixed Python's import mechanism such that Zope now starts either out of a ZIP archive or as a frozen application. These measures had the following results. Startup times on a mid range computer (AMD Athon 1.4 GHz; 512 MB memory) with a standard IDE disk. Cold start Warm start (after computer startup)(most files in OS cache) File system13s5s ZIP archive 8s4s Frozen 5s3s In more details, we did: * implement a package for a new kind of "url"s "pypackage:" for package relative access to resources. The package monkey patches Python's "open", "os.listdir", "os.stat" to provide transparent access to "pypackage:" identified resources. It currently support package relative access for packages loaded from the file system, from a ZIP archive and from the executable itself (i.e. frozen packages). In the last case, the resources are in a separate ZIP archive. This package might be interesting for Python as a whole as it is not Zope specific. * implement a shared object importer to be used as a Python "meta_path" hook. This importer allows to load shared objects into the context of a parent package (such as e.g. "ZODB.TimeStamp") although the shared object is not located inside the package's source (ZIP archive or executable). * fix about 70 occurrences in Zope code where package relative access was implemented by "dirname(__file__)" to consistenty use "package_home". * modify about a dozen places in Zope+CMF to use "pypackage:" and cope with "__path__" not being a list for frozen packages * fix a few products (Archetypes and friends, TextIndexNG2, PlacelessTranslationService, ...) to use "package_home" (rather than "dirname(__file__)") and not to change the current working directory (which obviously would fail for destinationsbe in a ZIP archive or the executable). * implement lazy loading of "ImageFile"s to reduce the risk of recursive imports (and reduce startup time). * support lazy product initialization * support configuration from a pickle file (to avoid expensive parsing of the schema and configuration files). The pickle is used as a configuration cache. * fixed Python's import mechanism not to treat ZIP archives as a directory when the archive could not find a module. If you were *really* interested in these startup time improvements, I could provide patches which might be integrated in the Zope core for e.g. Zope 2.9. ___ 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 )
