Modified items

All recently modified items, latest first.

zope-wildcard.fixpersistentutilities-1.1b7-1.lbn13.noarch: Introduction This product was created to help you remove nasty local persistent utilities that won't go away and can destroy your instance when you try to remove a product that registered one. Features * remove adapters * remove subscribers * remove provided interfaces * remove provided interfaces across the entire site - useful for removing collective.flowplayer Just append '/@@fix-persistent-utilities' onto your plone site root or the root of zope(for gsm) and browse through all your registered utilities on your site and remove things at will. By default, the tools prevents you from removing certain registrations; however, you can enter "expert mode" and remove whatever you want. WARNING!!! You can really screw up things if you do this wrong so use with extreme care and backup your instance before you use it. I will not take responsibility if you misuse this tool... Advice Do not include this product as part of your normal set of products. Only install this product on debug zope clients. This product should allow you to remove things from products that are no longer installed on the system; although, if you experience problems removing things, make sure to add those eggs to the system again.

zope-pgsql-2.13.18-2.lbn13.x86_64: This package contains the PostgreSQL backend for Zope and necessary startups

zope-oracle-2.13.18-2.lbn13.x86_64: This package contains the Oracle backend for Zope and necessary startups

zope-mysql-2.13.18-2.lbn13.x86_64: This package contains the MySQL backend for Zope and necessary startups

zope-jarn.checkinterval-1.0-3.lbn13.noarch: $ checkinterval 1305 The number you see is the recommended check interval for this machine; put it into your zope.conf file: python-check-interval 1305 Now restart Zope and bask in the glow. Why care? The Python Library Reference on the topic of check interval: "This integer value determines how often the interpreter checks for periodic things such as thread switches and signal handlers. The default is 100, meaning the check is performed every 100 Python virtual instructions. Setting it to a larger value may increase performance for programs using threads." Now, the Zope application server is such a program, and it benefits greatly from setting the right check interval. If the value is too low, Zope threads are interrupted unnecessarily, causing a noticable performance hit on today's multi-cpu hardware. Where's the 50 coming from? The constant 50 in the formula was determined by benchmarks performed at Zope Corporation and has become part of the "Zope lore" (See e.g. this post by Matt Kromer). Going beyond pystone/50 produced no further benefits. The value may well be meaningless for applications other than Zope and platforms other than Intel. Background More on check intervals and the GIL from David Beazly. For those back from the Beazly talk: Zope uses long running threads and asyncore, making it (more) independent from OS scheduling issues. Still, the interruption argument holds.

zope-instance-2.13.15-3.lbn13.x86_64: Setup of zope unix account and empty Zope database primed for this user

zope-cmf.pt-1.0-1.lbn13.noarch: The cmf.pt package allows using the Chameleon template engine with the Zope 2 CMF.

zope-ZPublisherEventsBackport-1.1-3.lbn13.noarch: Backport publication events from Zope 2.12 ZPublisher to Zope 2.10

zope-RelStorage-pgsql-1.5.1-11.lbn13.noarch: PostgreSQL backend for RelStorage

zope-RelStorage-1.5.1-11.lbn13.noarch: RelStorage is a storage implementation for ZODB that stores pickles in a relational database. PostgreSQL 8.1 and above (via psycopg2), MySQL 5.0.32+ / 5.1.34+ (via MySQLdb 1.2.2 and above), and Oracle 10g and 11g (via cx_Oracle) are currently supported. RelStorage replaced the PGStorage project. * It is a drop-in replacement for FileStorage and ZEO. * There is a simple way to convert FileStorage to RelStorage and back again. You can also convert a RelStorage instance to a different relational database. * Designed for high volume sites: multiple ZODB instances can share the same database. This is similar to ZEO, but RelStorage does not require ZEO. * According to some tests, RelStorage handles high concurrency better than the standard combination of ZEO and FileStorage. * Whereas FileStorage takes longer to start as the database grows due to an in-memory index of all objects, RelStorage starts quickly regardless of database size. * Supports undo, packing, and filesystem-based ZODB blobs. * Both history-preserving and history-free storage are available. * Capable of failover to replicated SQL databases.


	Copyright © 2000-2025 Corporation of Balclutha Inc. All rights reserved.