[Zope-dev] Re: [Geeks] Re: Interface Meta Data proposal
> I notice you mention post/pre conditions (something that UML obviously talks > about). I wonder if we want to do a bit of research on Eiffle and it's > contractual description. The only thing I wonder is if some of this is > actually useful programatically, if that makes sense? It's great info, but > is it useful at runtime? In Eiffel (I've never heard of Eiffle :-), pre- and post-conditions are turned into run-time checks, just like assertions. There are separate flags to turn code generation for pre- and post-conditions off. This is useful, as follows: while debugging your code, turn both on. When you've fully debugged an application, you turn both off. When you've fully debugged a library module, you create two versions: one with both turned off, for use in fully debugged applications, and one with pre-conditions on and post-conditions off, for use by other code that is still in need of debugging. I've heard that this works very well, and in Python 3000 (when we have optional static typing) I would love to add this to Python. If it's not feature bloat. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Shared lexicons for ZCTextIndex (was: Re: [Zope-Checkins] CVS: Zope/lib/python/Products/ZCTextIndex - ZCTextIndex.py:1.32)
> I think that there is at least potential value in sharing lexicons. > Of course, a down side is that it complicates set up. This is where I say "YAGNI" and announce that I'll be happy to refactor the code if and when a real need is discovered. > On the subject of referencing lexicons by path rather than using > direct references, I'm inclined to agree that direct references are > better for simplicity and speed. It's easy enough to add a new index > when you want to change a lexicon. (Well, there are some > complications having to do with making sure that you get all the > needed data into the new index...) What was the use case for switching lexicons in the first place? I bet it was just someone idly playing around and noticing that it didn't work right... --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Shared lexicons for ZCTextIndex (was: Re: [Zope-Checkins] CVS: Zope/lib/python/Products/ZCTextIndex - ZCTextIndex.py:1.32)
> I guess the main complaint was that given a set of indexes sharing a > lexicon, deleting the lexicon and replacing it with another one had > no effect on the indexes and in fact removes your ability to manage > their lexicon at all. So you must replace all of the indexes to use > the new lexicon by hand. What ability to "manage" the lexicon are you talking about? The lexicon has nothing manageable once it's created, except its name. :-) IMO we should remove the external Lexicon from ZCTextIndex and let ZCTextIndex create the Lexicon for you. That means that the pipeline options need to be selected when you create a ZCTextIndex -- this is actually simpler because it's now one-stop shopping (except for the need to still create a ZCatalog). --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Integrating ZEO with Zope 2.7
We're close to finishing a new version of ZEO, which will be released as part of the next ZODB3 release (formerly StandaloneZODB). I think this would be a good opportunity to make ZEO a standard part of Zope, starting with Zope 2.7. Advantage for users: if you download Zope, you have everything you need; you don't have to find and download a separate ZEO or ZODB release. Advantage for Zope developers: no need to test and maintain a separate ZEO release. There will still be a separate ZODB3 release, which will include ZEO. We have to do this anyway, for people who want to use ZODB outside Zope. Is there anybody who thinks this is a bad idea? (Full disclosure: Brian & Jim think it's a good idea, as long as we make sure that the ZEO that goes into the Zope 2.7 release is properly documented from the sysadmin POV, i.e. how to start/stop/configure. Of course we'll do this.) --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZEO cache instrumentation -- any takers?
A while ago I announced a new ZEO cache instrumentation feature, and asked if anyone was interested in enabling this instrumentation in their site. I got exactly zero responses... :-( I'd like to repeat the offer. From the instrumentation data, it is easy to determine the most effective cache size for your site (a tool to do this is part of the release). All you need to do is replace one file, ClientCache.py. Both ZEO 1 and ZEO 2 are supported. The instrumentation code does *not* use zLOG and causes very little overhead. It can create a large log file though (100 MB per day at one Zope Corp customer). Here's a copy of my original announement: >Subject: ZEO cache analysis tools prerelease >From: Guido van Rossum <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Date: Tue, 10 Sep 2002 17:02:41 -0400 * Do you want to know if your ZEO client cache is configured properly? * Are you using ZEO but you didn't know it had a client cache? * Do you want to contribute towards a better ZEO client cache design? If you answered yes at least once, read on! Jeremy is working on a new ZEO 2 release; the first beta was released two weeks ago. For that release I have written cache instrumentation code that lets you review the effectiveness of the ZEO client cache. There's also a version of the instrumented cache for ZEO 1. I don't plan to work on it more before the ZEO 2 release (unless I receive bug reports). All code is available *now* from the ZODB3 CVS tree: http://cvs.zope.org/ZODB3/. In addition to adding instrumentation, some bugs affecting performance but not correctness of the cache have been fixed in the instrumented cache code. The instrumentation is controlled by an environment variable so you can leave the new cache code in place after turning off the instrumentation. I'm inviting everyone who is running ZEO seriously to install the cache instrumentation code, run it for a while, and send me the resulting trace file. (The trace files contain no privacy-sensitive data, so you don't have to worry about revealing anything about your site.) The trace files will be used as input to a simulation of a new cache design. The only way to validate a cache design is to run experiments, and trace files are the most reliable way to run such experiments. The more trace files I receive the better. The larger they are the better (traces of several days of uninterrupted service are ideal). I've got the disk space to burn. I should mention that I'm confident that the instrumentated cache works correctly: we've been collecting traces without problems at a Zope Corp customer site since last Wednesday. To enable the cache instrumentation, you need to replace a single file in the ZEO package used by the Zope application, set an environment variable, and restart the Zope application. The file you need to replace is named ClientCache.py. Here are the URLs: For ZEO 1: http://cvs.zope.org/ZODB3/ZEO1/ClientCache.py?rev=HEAD For ZEO 2: http://cvs.zope.org/ZODB3/ZEO/ClientCache.py?rev=HEAD Make sure to get the file for the ZEO version you are using! Details about enabling the tracing can be found here: http://cvs.zope.org/ZODB3/ZEO/README.txt?rev=HEAD If you want to play with the statistics or simulation programs yourself, get stats.py and simul.py from the ZEO directory: http://cvs.zope.org/ZODB3/ZEO/ These work with trace files produced by either version of the instrumented cache code. Once you have one or more trace files for me, the best way to get it to me is probably to place a gzipped copy on an FTP or HTTP server from which I can download it and mail me the URL. As I said, these trace files contain no sensitive data. If you still prefer a different approach, email me and we'll figure something out. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Integrating ZEO with Zope 2.7
> > IMHO, Zope releases should, in this scenario, be configured by default to > > use a custom_zodb.py file with ClientStorage over a socket at startup, > > That is a tempting idea. > > Use of a TCP socket has security implications that make it a bad > choice for a default, unless we implement mutual authentication. > > Use of a unix socket has the obvious problem that it wont work on windows. What about using localhost? I'm not sure, but it seems to me that localhost cannot be connected to from outside the machine. On Unix, a Unix socket is the best idea; on Windows, localhost would prevent access from outside the machine, and Windows boxes typically have only one user, so I'm not concerned about internal attackers. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZEO cache instrumentation -- any takers?
> Guido van Rossum wrote: > > A while ago I announced a new ZEO cache instrumentation feature, and > > asked if anyone was interested in enabling this instrumentation in > > their site. I got exactly zero responses... :-( > > Hmmm... people might have done it and not let you know. Are you > looking to get the log files back so you can analyse them? Yes, that was what I was explicitly asking if you read back the announcement. > And can you just put the new ClientCache.py on one ZEO client in the > configuration? Yes. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Integrating ZEO with Zope 2.7
> Great idea, but this could also be a chance to fix the windows z2.py > thang and the installer ;) Maybe, but I have no expertise in this area. > As long as standalone Zope without ZEO would still be a startup > option, Im sure there are more things out there like the Plone > Controller that might take a while to catch up. I'm not planning to change the default startup configuration -- we're just adding the ZEO code so that you don't have to download and install it separately. ZEO has been added to the trunk now -- enjoy! --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Integrating ZEO with Zope 2.7
> IMHO, Zope releases should, in this scenario, be configured by default to > use a custom_zodb.py file with ClientStorage over a socket at startup, > making the default config of Zope one that uses ZEO. Also, start scripts > should be distributed with options to support both the following: > - Zope's start script Start ZEO via ZEO's start.py, > wait for confirmation of loaded storages, > then start Zope's z2.py > - Separate shell scripts to start each > > The advantage to this is the ability get access to the ZODB in automation > and sysadmin scripts without taking Zope down. This should be transparent > to those who don't care, unless there is a huge performance difference > between directly using FileStorage, and using ClientStorage on a local > socket to the same end (is the protocol overhead really that much?)... I'm not sure that such a drastic change can be done without breaking expectations set by previous Zope releases. But I'll let the Powers That Be decide on this -- I'm not touching the default configuration. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZEO cache instrumentation -- any takers?
> PS: Hey, Guido, any chance of deprecating exceptionless 'exception:' > clauses anytime soon? We got a bunch of those making our life harder > on Zope :-) No chance for backwards compatibility, but I try to stamp them out whenever I see them. Submit a tracker issue about the ones that particularly bug you -- with patch if you've got a suggestion. We'll get there still. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZEO cache instrumentation -- any takers?
> As much as I try to avoid them (especially in Zope code), they are > sometimes necessary because you simply don't know what exceptions > might be raised from inside Python or the standard libs. Sure. But the point is that *historically* Zope code (and lots of other Python code!) has contained a lot of places where "except:" was used when the author knew exactly which exceptions he was expecting. To make it worse when this is sometimes done for a large stretch of code, even though there are only a few specific spots where the exception is expected. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZEO cache instrumentation -- any takers?
> What would be nice is a way to define in Python a kind of exception > that is not caught by bare "except:" statements but only by "except > SpecificClass:" statements. Not quite an uncatchable exception, but > one that is caught only by except statements that name it. I'm skeptical about this one. Can you explain the use case? You can probably fake this to a large extent by using "except Exception:" instead of "except:" everywhere; then you can raise an exception that does not inherit from Exception. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZEO cache instrumentation -- any takers?
Have you tried clearing your cache after reverting the ClientCache.py change? Are you sure you didn't use the ZEO2 ClientCache.py with a ZEO1 installation or vice versa? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] zdaemon fix
We recently had an event at a customer site where a ZEO process was started with bogus arguments that kept spewing messages in the log file forever: the zdaemon module kept restarting the program, and the program kept failing (without logging a message!). I think we've all gone through this. Killing the rogue program is a bit of a pain because it dies before the pid file is written. I am thinking of a fairly simple change to zdaemon: if it finds that it is continuously respawning the program more than 10 times in 2 minutes, it assumes there is a fatal error, log a PANIC level message, and exit. (I took the criterion, but not the response from init(8).) Are there any concerns about checking this in? This would go into Zope 2.7 and ZODB 3.1, and could possibly be backported to 2.6 and 2.5. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zdaemon fix
BTW, here's the patch I propose:
*** Daemon.py 14 Aug 2002 22:12:52 - 1.11
--- Daemon.py 5 Oct 2002 08:14:51 -
***
*** 17,22
--- 17,28
import zLOG
from SignalPasser import SignalPasser
+ # If zdaemon finds that it is continuously respawning more than 10
+ # times in 2 minutes, it will assume that there is an error, log a
+ # PANIC level message, and exit.
+ RESPAWN_TIME = 120 # 2 minutes
+ RESPAWN_LIMIT = 10 # 10 times
+
pyth = sys.executable
class DieNow(Exception):
***
*** 32,38
--- 38,54
if not os.environ.has_key('Z_DEBUG_MODE'):
detach() # detach from the controlling terminal
+ starttimes = [] # for RESPAWN_LIMIT
while 1:
+ # Give up if respawning too often
+ starttimes.append(time.time())
+ if len(starttimes) > RESPAWN_LIMIT:
+ del starttimes[0]
+ if starttimes[-1] - starttimes[0] < RESPAWN_TIME:
+ pstamp('Respawning more than %d times in %d seconds. Quit.' %
+(RESPAWN_LIMIT, RESPAWN_TIME), zLOG.PANIC)
+ sys.exit(1)
+ del starttimes[0]
try:
pid = os.fork()
if pid:
While we're improving zdaemon, I have two other suggestions:
- Use grown-up language in log messages rather than "Aiieee!" and
"Houston, we have forked"
- Why does zdaemon add "zdaemon: : " to its log messages?
That info is already added by zLOG.
A typical set of zdaemon log messages now looks like this:
--
2002-10-05T04:23:31 INFO(0) zdaemon zdaemon: Sat Oct 5 04:23:31 2002: Houston,
we have forked: pid 2915
--
2002-10-05T04:24:12 ERROR(200) zdaemon zdaemon: Sat Oct 5 04:24:12 2002:
Aiieee! Process 2915 terminated normally, exit status: 1
--
while it could look like this:
--
2002-10-05T04:23:31 INFO(0) zdaemon Started subprocess: pid 2915
--
2002-10-05T04:24:12 ERROR(200) zdaemon Process 2915 terminated normally, exit
status: 1
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zdaemon fix
> > I am thinking of a fairly simple change to zdaemon: if it finds that > > it is continuously respawning the program more than 10 times in 2 > > minutes, it assumes there is a fatal error, log a PANIC level message, > > and exit. ( > > > (I took the criterion, but not the response from init(8).) > > In this scenario init pauses for a few minutes, rather than > aborting. I would like an option to prevent zdaemon aborting, and I > am surpised you dont want it as the default. > > I think init uses a simple fixed pause... an exponential backoff would > probably be smarter (like how a disconnected ZEO ClientStorage tries to > reconnect to its server) I thought about this, and figured it wasn't necessary. Unlike init, zdaemon only manages one process. When that process doesn't get past its initialization, manual intervention is normally required to make it run again; that manual intervention can include restarting it. But I have to admit that the use case I've been thinking of is that of starting zeo and finding that it crashes immediately, over and over. There the auto-stop is just what you need (there's no point in filling up the log file while you're thinking about what could have caused this). There's a different use case where something changes in the environment after the program has run successfully for a while, which causes it to crash and causes subsequent restarts to crash immediately. It is *possible* that the environment fixes itself after a while -- it could be something like a network, DNS or NFS outage -- and then an auto-restart option might be nice. I'm not sure what should be the default -- as a developer, I prefer that it stops (and I hate that zdaemon is the default at all), but for a production site something different might be in order. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZODB-Dev] ZEO signal feature
[Guido] > > > It's probably unavoidable that the log file is opened as root -- > > > it's used to report "can't setuid()". :-) [Toby] > Thats what syslog is for. > > It is good security practice that a daemon should *never* have a > writeable file descriptor for its log file. If it does, and the > daemon is compromised, an attacker can trivially cover his tracks by > removing the incriminating evidence from the log file. Well, there goes zLOG's MinimalLogger implementation. (This only holds for log files owned by a root, right?) [Chris] > > Pidfiles too. > > Currently it is common practice for Zope's 'stop' scripts to be run > as root. We cant allow the pid files to be written by non-root > users, otherwise those users could trick root into killing an > arbitrary process. The current design, for whatever reason, writes the pidfile as *late* as possible. That's often bugged me, because there's a failure mode where the process dies before the pidfile is written; zdaemon restarts it over and over (that's what prompted my zdaemon hack proposal), and the stop script won't stop it. (And of course, being an very infrequent Zope user, I always forget how to set up the environment so that Zope will run correctly. Fortunately I never run it as root. :-) > > The only real purpose to running as root is to be able to bind to > > low-numbered TCP ports. > > IMO there are better solutions to the problems to which low-numbered > ports are a common solution. Zope/ZSS never *needs* a low numbered > port, and zope should never be started as root. Correct. > (I have cc'ed zope-dev. I suggest we continue there, rather than zodb-dev) I wish there were fewer lists. I can never decide which list is right. :-( --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZODB-Dev] ZEO signal feature
> > Well, there goes zLOG's MinimalLogger implementation. > > The module name might be 'MinimalLogger', but everywhere else it is > known as 'the stupid log'. And stupid it is. But it's the only one we've got in the Zope core. :-( > > (This only holds for log files owned by a root, right?) > > No, I dont think ownership is relevant. Any log file which the zope > process can overwrite it of little use in proving that your zope > process has not been compromised. Fair enough. But then why did you specifically refer to file descriptors? > > > > Pidfiles too. > > > > > > Currently it is common practice for Zope's 'stop' scripts to be run > > > as root. We cant allow the pid files to be written by non-root > > > users, otherwise those users could trick root into killing an > > > arbitrary process. > > > > The current design, for whatever reason, writes the pidfile as *late* > > as possible. That's often bugged me, because there's a failure mode > > where the process dies before the pidfile is written; zdaemon restarts > > it over and over (that's what prompted my zdaemon hack proposal), and > > the stop script won't stop it. > > There is a trick here - it writes two pid files. One is written by > the server process (as you point out, this one is written very > late), the other is written by the supervisor process immediately > after forking. By default this is in var/zProcessManager.pid This is done by zdaemon, right? I think that ZEO at least disables this. > You should be able to send SIGTERM to the supervisor process, and it > should pass it on to the server process. Ive only just discovered > that: > > a. The signal forwarding doesnt seem to work for me > > b. The default stop script doesnt use this pid. How typical. One problem here, as always, is that the conventions are undocumented, or at least not documented where I would look for the documentation. :-( --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZODB-Dev] ZODB 3.2 release plan posted
> > There are a small set of proposed features centering around better > > configuration and management of ZEO and ZODB. > > > > Feedback is welcome. > > Not explicitly mentioned on that list, but improved logging is tied up with > better daemon support. I think Chris M has been looking at zope logging > recently - Im not sure if that work could be applied to ZEO too. I'm not sure how daemon support and better logging are tied together? I was thinking of letting the daemon manager use zLOG just like everybody else. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Simplifying the zdaemon package
The zdaemon package contains a bunch of dead wood, or "decoys", as Jim would call it, that I'd like to remove. AFAICT, Heartbeat.py is not used anywhere. At least not in the Zope sources -- maybe there are outside users??? And ZDaemonLogging.py is a very thin layer on top of zLOG -- can I get rid of it too? The SignalHandler.py class is not used by zdaemon itself; perhaps it can be moved into the Signals package? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: What catalog/index to use ...
> The problem seems to be that ZCTextIndex indeed does not do the > splitting "right" if German Umlauts are used. There is no option for > "Unicode-aware splitter". Instead of a Vocabulary it uses a > Lexicon, which just offers two options: "HTML aware splitter" and > "Whitespace splitter". I haven't tested the whitespace splitter yet, > but the HTML aware splitter did not do the Umlaut thing right > without the patch, i.e. it used umlauts as splitting characters ... That's just what the default ZMI interface for ZCTextIndex offers. It's easy to add your own splitter by writing a few lines of Python code. RTSL. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: What catalog/index to use ...
> >>The problem seems to be that ZCTextIndex indeed does not do the > >>splitting "right" if German Umlauts are used. There is no option for > >>"Unicode-aware splitter". Instead of a Vocabulary it uses a > >>Lexicon, which just offers two options: "HTML aware splitter" and > >>"Whitespace splitter". I haven't tested the whitespace splitter yet, > >>but the HTML aware splitter did not do the Umlaut thing right > >>without the patch, i.e. it used umlauts as splitting characters ... > > > > That's just what the default ZMI interface for ZCTextIndex offers. > > It's easy to add your own splitter by writing a few lines of Python > > code. RTSL. > > of course everyone can write his own Splitter... one for german, one > for french, etc.pp. but what is the problem with the patch? is > pythons-regexp (?L) not just intended for this simple way of > "localizing" software? > > and think of the european market: > > no one will "buy" Zope, if it is not working with your native language > out of the box. and that's what the patch for... I must've missed the start of this thread (I only just signed up for this list). I didn't see any patch -- I thought it was just a gripe about ZCTextIndex. Of course patches are welcome -- where can I find this particular patch? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Simplifying the zdaemon package
> I think all these things are reasonable things to do... > > Guido van Rossum wrote: > > The zdaemon package contains a bunch of dead wood, or "decoys", as Jim > > would call it, that I'd like to remove. AFAICT, Heartbeat.py is not > > used anywhere. At least not in the Zope sources -- maybe there are > > outside users??? And ZDaemonLogging.py is a very thin layer on top of > > zLOG -- can I get rid of it too? Done. Also lost a silly "main" program hiding in zdaemon/__init__.py. > > The SignalHandler.py class is not used by zdaemon itself; perhaps it > > can be moved into the Signals package? Will do. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: What catalog/index to use ...
> I don't know where you would expect a patch to be found, but in this > particular case the Zope Collector is a good place to look: > > http://collector.zope.org/Zope/597 > > Use the collector, Luke! ;-) Um, that's not a patch. Can you attach a context or unified diff to the collector item? > Joachim > > P.S.: I guess most of the people on the zope-dev list have some clue > on how to write their own splitters, but the message of my "gripe" > was that something worked o.k. (for the dumb end user) with the old > TextIndex and doesn't with the thing that is advertised on the Add > form as the replacement, and that just isn't cool. Indeed. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Simplifying the zdaemon package
> > > The SignalHandler.py class is not used by zdaemon itself; perhaps it > > > can be moved into the Signals package? > > Will do. Done. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZODB-Dev] ZODB 3.2 release plan posted
> On Tuesday 05 November 2002 7:04 pm, Jeremy Hylton wrote: > > I have posted a tenative release plan for ZODB 3.2 in the ZODB Wiki at > > http://www.zope.org/Wikis/ZODB/ZODB%203.2%20Release > > > > There are a small set of proposed features centering around better > > configuration and management of ZEO and ZODB. > > Is 3.2 work happing on the trunk or a branch? I presume it's going on the trunk. Is there a problem with that? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Problem with Zope 2.6.0 and ZShell
> Module sre, line 168, in ? > AttributeError: 'module' object has no attribute 'hexversion' > * > > This seems to be deep in Python standard library. Not that deep actually. sre.py line 168 is this: if sys.hexversion >= 0x0202: > Since I don't actually use Zope 2.6, does anyone have an idea on > where the problem may come from ? You're using restricted mode (the rexec module) and this apparently doesn't provide sys.hexversion. This is a shallow bug; it's already fixed in Python 2.3 (CVS). > Does any of you use ZShell with Zope 2.6 ? > > It works fine in 2.5.1 with Python 2.1.3, so something has > changed somewhere which breaks it. Probably those versions of Python didn't have the test for sys.hexversion; it's testing whether this is Python 2.2 or higher. A workaround would be to set sys.hexversion to 0x0202 (or to 0 if you're not sure which Python version you're using) before importing sre for the first time. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Problem with Zope 2.6.0 and ZShell
> On Tue, Nov 19, 2002 at 01:54:56PM -0500, Guido van Rossum wrote: > > > > > Since I don't actually use Zope 2.6, does anyone have an idea on > > > where the problem may come from ? > > > > You're using restricted mode (the rexec module) and this apparently > > doesn't provide sys.hexversion. This is a shallow bug; it's already > > fixed in Python 2.3 (CVS). > > ... > > Probably those versions of Python didn't have the test for > > sys.hexversion; it's testing whether this is Python 2.2 or higher. > > > > A workaround would be to set sys.hexversion to 0x0202 (or to 0 if > > you're not sure which Python version you're using) before importing > > sre for the first time. > > Thanks for your answer. > > Unfortunately I never import sre. > > I import re, then rexec in the main program, > then in the restricted code I add the > os and os.path modules, and the resticted code > then import the glob modules and calls its glob > method. > > So should I set sys.hexversion *before* my re and rexec > imports in the main program, or add the sys module and > a fake hexversion value in the restricted code ? In the restricted code, right at the start. Restricted code loads its own copy of each module it uses. The glob module uses re, which uses sre. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Caches
> We have diskless ZEO clients (Netboot). There is really no reason for our > ZEO clients to write their caches to the disk (RAM Disk). Can we turn this > off? To free up RAM for the other caches? That's a new use scenario for me. You can't turn the ZEO cache off. But I think you misunderstand the purpose of the ZEO cache. If you don't have a reasonably-sized ZEO cache, you lose big because you have to go to the server for *every* request. The ZEO cache caches a different kind of data than the other caches, and it caches this data *only* to disk, so it's not the case that it's wasting RAM disk space by writing cached data to disk that's also in memory. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Caches
> Thank you for your response. How does one determine if they have a > "reasonably-sized" ZEO cache? In our case we have about 260,000 objects in > the database with an ideal cache size of 10,000 objects. I have no idea > what our hit/miss ratio is or how to find that out. Any assistance would > be great! Try this: http://cvs.zope.org/ZODB3/ZEO/README.txt?rev=1.4&content-type=text/vnd.viewcvs-markup --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Caches
> > Thank you for your response. How does one determine if they have a > > "reasonably-sized" ZEO cache? In our case we have about 260,000 objects in > > the database with an ideal cache size of 10,000 objects. I have no idea > > what our hit/miss ratio is or how to find that out. Any assistance would > > be great! > > Try this: > > http://cvs.zope.org/ZODB3/ZEO/README.txt?rev=1.4&content-type=text/vnd.viewcvs-markup Simpler would be to check your log file for "cache flip" messages. If you get these more than a few times per day, you should consider doubling the cache size. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
> In the meantime, I think this list summarizes the adjusted goals well:
>
> * configure; make; make install installation
> * control script for starting/stopping/debugging zope
I'd like to compare notes on this. Where's the control script that
you are using? I'm hoping that we can use (some future evolution of)
zdaemon/{zdaemon,zdctl}.py in the Zope 2.7 trunk. This separates the
concerns of
- the actual server process (Zope/ZEO/ZRS; for ZEO, this is
runsvr.py)
- a daemon subprocess manager, which restarts the subprocess when it
dies, etc. (zdaemon.py)
- a tool to control the subprocess manager, telling it to
start/restart/stop the server subprocess, etc. (zdctl.py)
> * config file for all options including logging,
> servers, and databases.
> * real "effective user" support (logfiles, database files, etc.
> dont get written as root if you start as root).
> * better support for instance home/software home split
> * better support for Windows services
I'd like to hear more about this; my zdaemon.py currently doesn't do
Windows at all. Where can I peek at your code?
> * RPM-building support.
> * where possible, the banishment of environment variables
> as configuration.
>
> All of these things save for the last are more or less complete on
> the "chrism-install-branch" of the Zope trunk. The major missing
> piece is the fleshing out of the interaction between the
> configuration system (ZConfig) and Zope itself. It works currently
> but it needs to be improved and canonized to everyone's liking.
Can you point to where Zope's use of ZConfig is?
> Since ZConfig will also used by other ZC software (ZEO, ZRS),
> there's a bit of back and forth that needs to be done to get
> everybody to agree on a way to do it. Once that is worked out, and
> the proposal is cleaned up, I think we can just merge.
Apologies in advance: my refrain seems to be "where's your code for
X?" -- there's so much good stuff in your branch that I don't know
where to begin, especially not with the Zope part (in ZODB, I know my
way around better).
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Weird BTrees/ZODB interaction under Solaris
> I made the following reproducable observation running Zope 2.5 under > Solaris: > > I was indexing a CMF site using TextIndexNG with about 1600 objects. > During the commit phase (after all objects were indexed), the Zope > process grow from about 100MB to more than 1.2GB. > > I could track this down to TextIndexNG. There is a function written > in C that inserts the list of splittet words into the BTrees > for the forward and reverse index (by generating the WordIDs > internally). Replacing this method with a pure Python implementation > made Zope behave fine. > > Torturing the corresponding C implementation in an isolated environment > did not show any memory leaks (neither under Solaris nor under Linux > i386). To make it short: my C implementation has three args: the forward > index, the reverse index and a list of words to be inserted. The indexes > are an OIBTree and an IOBTree. Internally I call PyObject_SetItem() > to store the word-wid mapping. This seems to work fine isolated but > seems to blow up the ZODB for unknown reasons. > > Note that his behaviour is only reproducable under Solaris. I made some > tests by indexing about 100.000 docs under Linux with TextIndexNG and > the Zope memory usage was very fine (up to 150MB). Could you try again with the C version, substituting a different malloc implementation, or Python 2.3 (which has effectively a different malloc for small blocks)? It could be a semi-bug in the platform malloc where the allocation and deallocation pattern of your test happens to cause worst-case fragmentation. Using Python code probably changes the allocation pattern enough to avoid the fragmentation. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
> I gather from reading other posts that this is a different format than > Zope 3's ZCML. Would it be worth it to at least make some sort of > 'ZCML Lite' to do this sort of configuration? The main thing I'm > concerned about is that there's a whole new Zope coming down the road > that depends heavily on configuration files, and it might make sense to > start weaning people onto its general syntax if Zope 2's finally going > to have a config file. There was a conscious decision to have two different "configuration" language: ZCML for *software* configuration, and ZConfig for *process* configuration. A sysop is not expected to have to edit ZCML, but she will definitely have to edit the ZConfig file. Since XML is not designed for routine editing/reading by humans (its "human-readability" is a debugging feature), ZConfig uses a more readable format. It's documented in the ZConfig CVS tree. > ZRS? This isn't the long-discussed replicated storage is it? Yes, http://www.zope.com/Products/ZopeProducts/ZRS --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bugfix release?
> > Someone posted already a fix for this problem. It should not be > > hard to fix this single problem by exchanging the DateTime.py file > > on your sites > > I'll echo my earlier comment: Whatever happened to "release early, > release often"? > > Why is this not happening with Zope? Because it doesn't apply. "Release early, release often" is for bleeding edge developers. For a system like the Linux kernel, where it's nearly impossible to check out a consistent version from CVS, daily or weekly snapshot releases are a good idea. With Zope, bleeding edge developers have access to CVS, so there's no need for such "releases". A bugfix release for Zope 2.6.0, named Zope 2.6.1, was planned for this week. But yesterday, three new bugs in 2.6.0 were reported, and we'd like to fix those too. With the holidays, it'll be next week. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bugfix release?
> Says who? I thought the idea behind it was to get the releases out > early, so you can find the bugs faster and get the releases more > stable more quickly... > > I guess what I'm saying is that for a version 2.x.y, x should behave > as you describe while y should go up as often as a bug is discovered > and fixed... That means we either waste a lot more time doing releases, or the releases become a lot more shoddy, hardly more than a snapshot from CVS. Neither sounds attractive, sorry. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the template edit window
> Can we get the same patch without the generic "except:", please? > > the last thing I want is a database corruption caused by resizing the > Edit box... Why would this particular except clause cause database corruption? int() happens to raise a bunch of different exceptions, and I think an unqualified except: clause is okay here (though it needs a comment). Also note that the unpatched code has an unqualified except: already, so you can't really blame Dmitry. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the template edit window
> I saw "try: int() except:" pattern in many places through all the Zope
> code. I think catching ValueError only does the job, but then we should
> replace it in all the places. :-)
Yes, catching ValueError is sufficient for string conversions to int.
I thought you could get an OverflowError, but that can only happen
when the input is a Python long or float -- int("999")
raises ValueError, as does int("xxx").
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the template edit window
> I think this would be a useful note for the Zope3 style guide. > > > What exceptions can int() raise? > > On converting a preexisting value to an int: > >ValueError, OverflowError, TypeError, AttributeError > >(Any others?) > > On converting an instance that implements __int__: > >Anything at all. >It can even return a non-int value. > > On evaluating the expression inside the int() brackets: > >Anything at all. Anything can raise MemoryError. On converting an 8bit string to an int: ValueError *only* On converting a Unicode string to an int: ValueError UnicodeError (or UnicodeEncodeError, which is a subclass of it) --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Guido van Rossum: Re: [ZODB-Dev] Fwd: [Zope3-dev] directory hierarchy proposal (MartijnFaassen)
Sorry, cc'ed the wrong list. :-( --- Forwarded Message Date:Wed, 11 Dec 2002 10:29:12 -0500 From:Guido van Rossum <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (Jeremy Hylton) cc: [EMAIL PROTECTED] Subject: Re: [ZODB-Dev] Fwd: [Zope3-dev] directory hierarchy proposal (Martijn Faassen) > SA> Can they be methods on objects, rather than functions in a > SA> module? > > Just what I asked Tim :-). There are as many as six functions -- > difference, union, intersection, weightedUnion, weightedIntersection, > and multiunion. The functions operate on sets; they accept any of XY > family of objects. So it's not obvious what they would be methods > of. Each object -- Set, TreeSet, Bucket, BTree -- could get a copy of > the code, but that seems a little silly. Perhaps it could be defined on a common base class? - --Guido van Rossum (home page: http://www.python.org/~guido/) --- End of Forwarded Message ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the template edit window
> > Anything can raise MemoryError. > > Ok. But I don't think regular application code should catch these. Correct. > > On converting an 8bit string to an int: > > > > ValueError *only* > > Ok. > > > On converting a Unicode string to an int: > > > > ValueError > > UnicodeError (or UnicodeEncodeError, which is a subclass of it) > > Can you provide an example of raising a unicode error like this: > >u = makeUnicodeString() # your choice of function >int(u) In Python 2.3, I get this: >>> int(u"\u1234") Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'decimal' codec can't encode character '\u1234' in position 0: invalid decimal Unicode string >>> In Python 2.2, this raises ValueError. I think I may have to report this as a bug in Python 2.3 though. > My point is that once you have a valid unicode object, I don't see how > calling int(valid_unicode_object) will raise a UnicodeError. > > If this is so, then the style should be: > >value = expression_to_compute_value >try: >i = int(value) >except ValueError: ># take corrective action > > rather than: > >try: >i = int(expression_to_compute_value) >except: # Note: calling 'int()' can raise just about anything ># take corrective action Even if we decide that we have to use a bare except after all, the expression_to_compute_value should still be moved outside the try/except. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the template edit window
> > Can you provide an example of raising a unicode error like this: > > > >u = makeUnicodeString() # your choice of function > >int(u) > > In Python 2.3, I get this: > > >>> int(u"\u1234") > Traceback (most recent call last): > File "", line 1, in ? > UnicodeEncodeError: 'decimal' codec can't encode character '\u1234' in position 0: >invalid decimal Unicode string > >>> > > In Python 2.2, this raises ValueError. I spoke too soon. UnicodeEncodeError is a subclass of ValueError. So catching ValueError from int(str_or_unicode) is the way to go. Who's writing that Zope 3 style guide again? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ClientCache and Large Files
> We're running ZEO with Zope 2.5.1. We currently have a ZEO Cache > (ClientCache) of 200 meg. Occasionally someone will download a 300 > meg file that completely blows away the client cache. Is there a way > to prevent this? I'm afraid not; this isn't a very typical use case. You could implement a file size limit, or increase the cache size to be more than twice the largest expected dowload (the cache is implemented as two files, each of which is limited to half the nominal cache size). --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] debugging Zope -> ImportError: ./ExtensionClass.so: undefined symbol: PyObject_Init
> I tried to follow "Chapter 7: Testing and Debugging" of "The Zope Developer's > Guide (Zope 2.4 edition)" > http://www.zope.org/Documentation/Books/ZDG/current/TestingAndDebugging.stx > > However, on my Linux server I get the following error: > (Zope is v2.5.1) > > [root@prefect Zope-2.5.1-linux2-x86-dev]# cd lib/python > [root@prefect python]# python > Python 1.5.2 (#1, Apr 3 2002, 18:16:26) [GCC 2.96 2731 (Red Hat Linux Um, Zope 2.5.1 requires Python 2.1.3 or later. You're using Python 1.5.2 here. That's probably the cause of the problems. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Infuriating ZClass registry Heisenbug
> The nice thing about fixing this bug is that the code continues to be > improved. The last round of beautification made the code > substantially more readable. This was a direct result of trying to > track down a reference count problem. The problem proved to be > elsewhere, but it was nearly impossible for me to inspect the old > coptimizations.c code to figure out if the problem was there. > > If we make the code easier to read, we reduce the burden we all share > more keeping the software working. Inscrutable code hides subtle bugs > and encourages work arounds that make the whole system harder to > understand. +1. Remember the XP dogma: refactor mercilessly. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CRITICAL!!!! CVS: Zope/lib/python/OFS - Image.py:1.141.4.3
> BIG PROBLEM WITH THIS CHECK-IN FROM YESTERDAY: I've updated my ZOPE and > now all Images are broken!!! ZOPE lives behind a SQUID. > > I think that > > RESPONSE.setBase(None) > > is NOT a good idea at all!!! Commenting this out and all works as > expected... Indeed -- the nightly unit tests also pointed this out. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3 sprint at pycon?
> Is anybody planning a zope 3 sprint at pycon? > > would be a good excuse for me to dive into > z3 :) Jim wants a Z3 sprint at the Zope Corp headquarters in Fredericksburg (a mere hour south of DC). I think it's also very likely that some people will spontaneously sprint at PyCon in DC. If there's enough demand (and/or if people will pay for the space) we can get space at the PyCon venue the two or three days before the conference proper for an extended sprint. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope and python compatibility
>Zope 2.5 + Python 2.1 --> Good >Zope 2.6 + Python 2.1 --> Good >Zope 2.7 + Python 2.1 --> Bad >Zope 2.5 + Python 2.2 --> Bad >Zope 2.6 + Python 2.2 --> Bad >Zope 2.7 + Python 2.2 --> Good I'm beginning to wonder whether Zope 2.7 shouldn't require Python 2.1.3 rather than 2.2.2. The original motivation for requiring 2.2.x was to allow easy backporting of Zope 3 components, and that is no longer a goal. I've asked Brian to review the version decision in this light. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope and python compatibility
> Without python 2.2 zope will continue to harbor remotely exploitable > zlib-based memory exhaustion attacks. FWIW Can you explain? Where does Zope even use zlib? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope and python compatibility
> On Saturday 11 January 2003 4:06 pm, Jamie Heilman wrote: > > Guido van Rossum wrote: > > > > Without python 2.2 zope will continue to harbor remotely exploitable > > > > zlib-based memory exhaustion attacks. FWIW > > There are workarounds that work in 2.1.x, and I dont think any uses in Zope > are performance-critical. I will be happy to push through any patches for any > other Zopes uses. I expect I'll be releasing Python 2.1.4 in the next month or so. Can you submit a patch and assign it to me? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope and Python compatibility
> What would the arguments be for sticking with Zope 2.1.3 for Zope 2.7? I > feel most people want to use the latest and greatest versions, usually... Actually, most people don't care about the latest and greatest, and would prefer tried and trusted. Especially if the latest and greatest means they have to install more stuff. > Or? > > Of course, if the requirement could be 2.1.3 *or* 2.2.2, that would > be nice, but is that realistic? In practice, Zope 2.6(.x) already fulfills this requirement, it's only that ZC doesn't have the resources to guarantee it. I think 2.7 would be in the same boat. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope and Python compatibility
> FYI, the current CVS head (to be 2.7) now requires 2.2.2 as per an > earlier papal edict. So there will be at least some work involved in > making it run under 2.1.3. I know. It's not much work, and I have already volunteered to do it. Jim has explicitly undone that decision and told me it's Brian's call now. > I kindof feel like we already made a rather firm commitment to > *requiring* 2.2.x. I did not fully agree with that decision at the > time, but to renig on it now seems fairly counterproductive unless > someone can provide a really good reason. I also did not agree at the time. I don't see how it can be counterproductive to change a broken decision. > I personally feel like Zope should run on 2.2.x whether required or > not. Requiring 2.2.x does have the advantage of limiting the > possible blessed configurations on which Zope will run, thereby > making development, support and bug fixing that much easier. I *also* volunteer to make sure that *to the limits of my knowledge* Zope 2.7 indeed continues to run under Python 2.2.2. > Otherwise I can see having to develop on Python 2.1.x and test on > 2.1.x and 2.2.x. It would be nice not to have to do this when > developing 2.7 only code. I realize that this would be necessary > when backporting things to 2.6. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope and Python compatibility
> On Monday 13 January 2003 7:46 pm, Casey Duncan wrote: > > > I personally feel like Zope should run on 2.2.x whether required or not. > > Requiring 2.2.x does have the advantage of limiting the possible blessed > > configurations on which Zope will run, thereby making development, support > > and bug fixing that much easier. [Toby] > Im not sure thats true. Having less strict version requirements > means that there will be *more* *people* doing the development, > support, and bug fixing. Hm. My experience with Zope 3 is that if developers can choose different Python versions, it's quite easy for version-dependent bugs to creep in, and it can take a while to track these down. For example, Zope 3 currently has some unit test suite failures that only occur on Python 2.3, and the only developer who knows the broken code well enough to fix them has no time to maintain both the 2.2.2 and the 2.3 code. So I'm (now) convinced that we should pick one Python version and stick with it, and not worry (too much) about failures with later Python versions. But it's Brian's call, and unless he agrees to switch back to 2.1.3, this is moot. In the mean time I ask not to use Python 2.2 features like bool gratuitously. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [PATCH] Forking daemon in debug mode, and new start scripts
> I understand zdaemon is going away soon, but here's a small patch to > Daemon.py to fork if it finds an EVENT_LOG_FILE. Why do you want that? Logging to a file in the background is a useful feature. [snip -- thanks for the scripts] > The non-detaching daemon, however, is just plain annoying. On Unix > you can always tail the logfile for the same effect. I do not understand this remark. Your patch *prevents* the daemon from detaching. So you find your own patch annoying? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] testMaxListUsers failure
Who knows more about this test failure in the Zope 2.7 test suite? == FAIL: testMaxListUsers (testUserFolder.UserFolderTests) -- Traceback (most recent call last): File "testUserFolder.py", line 57, in testMaxListUsers AssertionError: Did not raise overflow error -- Ran 2089 tests in 1201.517s FAILED (failures=1) == OVERALL FAILED (total failures=1) --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [PATCH] Forking daemon in debug mode, and new start scripts
> But this means I can't really write a start script that works (or > makes sense) with debug mode both on and off. I don't think that's a valid use case anyway. Remember, "debug" mode really means "don't daemonize" and nothing more. This for use by a developer who wants to see possible exceptions, print statements and other stuff that goes to stdout/stderr. > Yes. I would much prefer an explicit flag for each, because I run a > number of dev Zopes on a number of boxes to which I only have ssh > access, and I don't want to have to remember to play games with my > stdio, or restart Zope if I restart screen, etc. > > Speaking of the (side-)effects of debug mode, what exactly are they? > Is it just the automatic re-loading of DTMLFiles and PageTemplates > from disk? I've tried to explain already -- debug mode for ZEO *only* determines whether the ZEO server goes into daemon mode or not. There may be a Zope debug mode, but it's not related (even if it uses the same envariable). --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [PATCH] Forking daemon in debug mode, and new start scripts
> On January 21, Guido van Rossum wrote: > > There may be a Zope debug mode, but it's not related (even if it > > uses the same envariable). > > I'm sorry, I'm talking about Zope's debug mode. Eh? This started with your suggesting a change to ZEO/start.py, to which I objected. Oh well. What a waste of time. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [PATCH] Forking daemon in debug mode, and new start scripts
> > Eh? This started with your suggesting a change to ZEO/start.py, to > > which I objected. > > > > Oh well. What a waste of time. > > Now I'm lost. > He posted a patch to lib/python/zdaemon/Daemon.py. > Nobody said anything about ZEO/start.py. You're right. :-( I know that file from the context of ZODB. But it is also used by Zope. I'm sorry for the confusion. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [PATCH] Forking daemon in debug mode, and new start scripts
> a summary, AFAICT: everybody agrees that splitting up the many things > in Zope toggled by debug mode would be a good thing, but > nobody has time to do it. :( Actually, on the chrism-installer-branch, we're doing something about it, and we're getting closer. Most likely, Zope 2.7 will use zdrun.py from the ZODB 3.2 CVS for process management. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 2.6.1b2?
> > I'd just like to know when can we expect a 2.6.1b2. It would be nice to > > have a new release where we don't have to patch just to get ZClasses to > > work. > > Yes, it IS indeed a problem if there is no single Zope version out there > that can be used without patches. 2.6.0 has the DateTime bug, the > 2.6.1b1 has new issues. I have complained a lot about the lousy release > management in the past, but nobody seems to listen. > > Joachim > > P.S.: After all, it's so easy: Take a Zope version that has some bugs, > fix the bugs and release it as a bugfix release. DON'T add features that > might trigger new bugs. THEN start working on the next feature release. > > AND: THERE SHOULD NEVER, I REPEAT: NEVER BE NEW FUNCTIONALITY OR CODE > CHANGES BETWEEN A FINAL BETA AND A RELEASE! IF IT IS NOT FINAL; RELEASE > ANOTHER BETA!! If only it were that easy. Everybody wants "no new features" except for the one feature they desperately want to have without upgrading to the next feature release. :-( --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 2.6.1b2?
> Guido van Rossum wrote: > > > > If only it were that easy. Everybody wants "no new features" except > > for the one feature they desperately want to have without upgrading to > > the next feature release. :-( > > Still, we're back to the situation where it's been weeks since the > last release, and there's nothing we (the public) can do about that > :-( If you want to make a rogue release, that will be available until Brian deems the time ready for the next release, be my guest. > PS: How's the new zope.org coming? Very well. I just posted a progress update: http://lists.zope.org/pipermail/zope-web/2003-January/002310.html --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope] PCGI?
[me] > AFAIK most people use Apache's mod_redirect to a Zope HTTP server > running at (e.g.) port 8000. No additional software needed. I meant mod_proxy of course. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: [Zope] PCGI?
> Having only ever used Zope-behind-PCGI myself, if we drop it, what would > be the prevailing approach for running Zope behind Apache? Has everyone > switched to FastCGI (or Quixote's SCGI) but me? AFAIK most people use Apache's mod_redirect to a Zope HTTP server running at (e.g.) port 8000. No additional software needed. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: [Zope] PCGI?
> of course, you should also close port 8080 (or whatever your zope server > runs on) from any access from hosts other than 127.0.0.1 Actually, I think you can do this already by *binding* that port only on 127.0.0.1. I believe there's a "host" parameter that lets you specify the host to bind to. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] ZEO 2 and Zope 2.5.1
> We've been using ZEO 1 with Zope 2.5.1 but some issues exist with ZEO 1, > so we decided to move to ZEO 2. Which version of ZEO 2 exactly? (It suffices to tell which exact ZODB 3.1.x release you used to get it.) > Everything is installed installs and starts normally. The server logs show > a connection. However any HTTP requests sent to the ZEO client hang. I did > a bit of poking around and it appears that the load method of > ClientStorage is not called when a request is recieved. > > Can anyone point me in the right direction? Would it be an option to upgrade to Zope 2.6.1 as well? If not, what exactly is in the logs? Note that you need to have the new ZEO in the Python path both on the client side and on the server side. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Creating a fully stand-alone Zope Page Templates
> Hurm. I can't answer this directly, but I have done the same as you and > divorced ZPT completely from Zope for Roundup. See http://roundup.sf.net/ in > the roundup.cgi.[PageTemplates|TAL|ZTUtils] packages. I wonder if it would be worth our while to make sure that ZPT is separately usable, just like we do for ZODB? Just how much did you have to change to divorce ZPT from Zope? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Offtopic: it's vs. its
___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Offtopic: it's vs. its
> I, for one, think that proper grammar in checkins, source code > and wikis is wonderful, and beneficial in the same way as syntax > highlighting in editors. Agreed. > While reading Zope source in the past, I have, a couple of times, > made diffs fixing niggly grammatical issues (I can be compulsive > that way .. ) but have always refrained from submitting them as > issues, because I was afraid they'd be considered noise. Is this > a justified fear? Indeed. If you have checkin perms, feel free to fix coding style and English grammar issues quietly. But trackers should be used for real coding issues. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] [Vote] PEP308 voting began
> Attention: cross post > > PEP308 is concerned with the introduction of a ternary conditional > operator (something like an "if cond: val_true else: val_false") > into Zope. > > In my view, such an operator would make TALES expressions > easier because we could get rid of the "and/or" hack to > represent conditionals and we could forget about the "test" > function, which evaluates too eagerly. > > Please have a look at PEP308 and consider voting. > Details in "comp.lang.python.announce". > > Dieter IMO TALES should solve this for itself by introducing an if/then/else expression form rather than depending on Python. If you can have a "not:.." expression, surely you can have an "if:..:then:..:else:.." expression. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Proposed installation changes for review
> Adrian van den Dries writes: > > Debug mode needs to be broken out into directives for its real > > effects. I always want Zope to run as a daemon, but I also want > > automatic PT/DTML reloading, and immediate tracebacks. I think there > > should be a separate "no-detach" for those people who want that > > feature. > > I'm happy with this (more so than the single option). I think it's > fair for us to get this implemented before we're done; not sure if it > has to happen before the merge (I'm mostly tied up this week). The no-detach choice is already separate -- this is now an option to the separate zopectl program. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: [Zope-dev] Proposed installation changes for review
> The point I'm trying to make is that Zope has learned nothing from the > UNIX philosophy. Yes, you can extend the config schema. You can grow > new, better config files, of extraordinary magnitude. The > all-powerful server will grow from being all-powerful to being > all-powerful + n. It will be able to read mail. Its heralds shall > sit upon mountain high throwns hewn of the finest O'Reilly and New > Riders scripture. But lo, still you won't be able to do something as > mundane as limit the memory the FTP server is able to consume without > affecting the HTTP server. > > Fracture the server infrastructure into small, seperate processes. > The configuration of the individual pieces becomes trivial. The > understanding of the overall data flow improves. When there's nothing > left to remove from code, you've won. Some of the breaks have already > been made, like the separation of the storage from its front-end. > Thats good, we need more action along those lines. You're barking up the wrong tree. Zope 2 won't change. Zope 3 is still in a state of flux, and that's where you should aim your speech. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: [Zope-dev] Proposed installation changes for review
> On Tue, 2003-03-11 at 15:22, Guido van Rossum wrote: > > > > That's why we're including the correct versions of ZODB and ZEO in > > Zope itself. That's already the case in Zope 2.6. > > Zope 2.6 doesn't yet include ZEO, at least I don't think it does. ;-) Oops, I stand corrected. But Zope 2.7 does include ZEO! --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: [Zope-dev] Proposed installation changes for review
> > Oops, I stand corrected. But Zope 2.7 does include ZEO! > > Very good! But in that case, shouldn't the new Zope 2.7 install and > startup stuff support it? Well, in a typical installation, you won't be running ZEO on the same machine as Zope, right? ZEO has its own install and config stuff, which is very similar to that for Zope, but ZEO is not installed as part of the main Zope install. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: [Zope-dev] Proposed installation changes for review
> > Very good! But in that case, shouldn't the new Zope 2.7 install and > > startup stuff support it? > > It does. It's just that the default setup is still to use a non-ZEOd > FileStorage for your main database. But you can change options in the > config file to make it use a ZEO ClientStorage. This is in lieu of of > requiring you to edit custom_zodb.py as you needed to do in 2.6 and > prior. > > It's clear that the Zope source distro should support the use of > ClientStorage "out of the box". It's not however so clear that the Zope > source distro should make it to set up a ZEO server (although it does > happen to include the necessary files to run a ZEO server too, it > doesn't include a 'zeoctl' or a zeo.conf, etc). Chris, have you looked at ZEO/mkzeoinst.py? It uses a somewhat simpler approach than the new Zope setup, but it creates a zeoctl script and a zeo.conf configuration file. > That's not to say that it shouldn't be easy to set up a ZEO server, but > that making it easy should probably the job of a package other than Zope > proper. The right thing to do would be to package up a ZEO server > installer separate from Zope 2.7 with a similar kind of buildout, > support files, and configuration file. At least that's been my idea so > far. Not needed; it's all there (though far simpler in approach than the Zope installer). --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: [Zope-dev] Proposed installation changes for review
> > Chris, have you looked at ZEO/mkzeoinst.py? It uses a somewhat > > simpler approach than the new Zope setup, but it creates a zeoctl > > script and a zeo.conf configuration file. > Cool! I didn't know. > > Do you think we should tell people that if they want to run a ZEO server > to just run mkzeoinst from the software home resulting from Zope's "make > install" and to edit zope.conf to use a ClientStorage? That should work, yes, as long as mkzeoinst.py, zdctl.py, zdrun.py and runzeo.py are all on $PATH at that point. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Zope] Re: Proposed installation changes for review
> I routinely run ZEO on all of my sites, on the same machine. I don't > gain any "scalability" benefits this way, but it is fantastic for > debugging and tweaking a live site. > > My creaky old zctl.py auto-starts ZEO when necessary, using the same > configuration data as it uses for the associated Zope instance, so they > both know to use 'var/zeo.soc' to connect. zdrun takes care of auto-restart. Sharing config data may be a little trickier; Fred and/or Chris should know more about that. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Proposed installation changes for review
> I thought you had to install ZEO on top/inside of an existing Zope > installation. Will this be different in Zope 2.7? Yes, ZEO will be an integral part of Zope then. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Proposed installation changes for review
> > ZEO client configuration is included in the new configuration schema. > > > > ZEO server configuration has its own schema and tools, also based on > > ZConfig and the new zdaemon; you can check these out in the ZODB 3.2 > > alpha release. > > Does this mean that Zope 2.7 will require ZODB 3.2 for ZEO users? Zope 2.7 will *come with* ZODB 3.2 (or later, depending on the timing of the Zope 2.7 release), so I suppose so. > As an aside, am I the only one who's confused by this new bundling > of ZEO as part of the stand alone ZODB product? I don't know. What's confusing for you? The new approach is that: Zope includes ZODB includes ZODB What's confusing about that? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Proposed installation changes for review
> Zope doesn't (currently) include ZEO so to get an up to date ZEO we > now have to obtain the correct version of the stand-alone ZODB and > extract the contained ZEO. The version numbers of the ZEO and > stand-alone ZODB are unrelated so figuring out which ZODB we need to > get ZEO is a bit of a pain. Also, ZEO is packaged differently in > the stand alone ZODB than it used to be in on it's own. That's why we're including the correct versions of ZODB and ZEO in Zope itself. That's already the case in Zope 2.6. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Proposed installation changes for review
> The things that seemed to be missing from your writeup were: > > Almost no mention of ZEO (only one mention of a "zeo client name" > parameter). How does ZEO fit into this? ZEO client configuration is included in the new configuration schema. ZEO server configuration has its own schema and tools, also based on ZConfig and the new zdaemon; you can check these out in the ZODB 3.2 alpha release. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Any thoughts on when Zope 2.7 beta1 might be available?
> I am using multiple third party Python libraries with Zope, and they > are no longer supporting Python 2.1.X at all. I am forced to > upgrade to Python 2.2.X > > As I see it, my options are: > > 1- try to recompile Zope 2.6.1 from source using Python 2.2.2 (and cross > my fingers) In my experience this works fine. The reason this isn't officially supported by Zope Corporation is that we haven't had time to thoroughly evaluate this combination, so you should indeed cross your fingers, but I don't expect there's anything that would be a showstopper for you. If you find problems, please report them here so they can be fixed in Zope 2.7! --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Create top-level folder
> You'll see this at the bottom of each message on the [EMAIL PROTECTED] list: > >___ >Zope-Dev maillist - [EMAIL PROTECTED] >http://mail.zope.org/mailman/listinfo/zope-dev >** No cross posts or HTML encoding! ** > > The question you are asking should be asked on [EMAIL PROTECTED], not > [EMAIL PROTECTED] Andreas was kind enough to answer, but please do try > the [EMAIL PROTECTED] list first. > > The [EMAIL PROTECTED] list is for discussing the development of Zope and > its internals, not for discussing how to use Zope and its API. Maybe the bottom message should be clearer on the purpose? "No cross posts" doesn't really help one decide which list to use. "zope-dev" == "development using zope" sounds plausible enough... --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
> To anyone not following the "Problem committing zope 'version' objects" > thread on [EMAIL PROTECTED]: It's been proposed that Versions should be > at least stamped in the ZMI with big warnings, or possibly disabled > altogether. Numerous users have been bit by the fact that versions > basically do not work as advertised, leading in various cases to zodb > corruption or work that can't be saved. There are other security issues > that Oliver Bleutgen raised privately which I won't state here. > > Comments? Could we get at least some warnings in the ZMI before > 2.6.2 final? IMO versions do nothing except complexify the code. I believe it's an official Zope Corp position to discourage them for new projects. Yet Jeremy Hylton seems to think that they are somehow useful and has carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, they would have been gone, with a big helping of YAGNI! --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Versions: should they die?
> Perhaps Jeremy could run through his reasons for wanting them to > stay around again? That's not necessary. They could stay in ZODB (certainly cutting them out of ZODB3 now would be more work than leaving them in) but be disabled in ZMI. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] 2.7 installation
> 2. I see no reason for Zope to eschew the .py extension for callable >scripts, eg. configure.py, zopectl.py, etc. Distributions may >choose to wrap these in shell scripts, or strip the extension, but >that is a distribution's decision. $(insert impertinent aside >about Zope's support for Python Labs and branding.) I'm not sure what you mean by that final remark, but I also like to install scripts with their .py extension. Some at PL disagree though. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] PyCon DC 2003: Extension of Submission Deadline
The deadline for submissions to PyCon DC 2003 appears to have been too tight for many authors. While some promised submissions have arrived, several have not even though the original deadline of 15 December has passed. Rather than exclude promising papers the organizing committee has decided to extend the deadline for submissions. Accordingly, the new schedule for proposals is as follows: Submission Deadline: January 15, 2003 Notification of Acceptance: January 31, 2003 Final Versions Due: March 10, 2003 Conference Dates: March 26-28, 2003 [unchanged] Authors who have already submitted abstracts are invited to resubmit if they feel that the original deadline had an adverse effect on the quality of their submissions. Please make any appropriate media, mailing lists and newsgroups aware of this announcement. Enquiries should be sent in the first instance to [EMAIL PROTECTED] Information about PyCon DC 2003 is available at the following URLs: www.python.org/pycon www.python.org/cgi-bin/moinmoin/PyCon The latter URL, a Wiki page, can also be used to communicate with the conference organizers. This is *your* conference: tell us what *you* want to see in it. regards --- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/pwp/ Bring your musical instrument to PyCon!http://www.python.org/pycon/ --- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
