Modified items

All recently modified items, latest first.

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.

zope-MultiMapping-2.13.0-3.lbn13.x86_64: Special MultiMapping objects used in Zope2.

zope-Jinja2-2.5.5-3.lbn13.noarch: A small but fast and easy to use stand-alone template engine written in pure python.


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