Re: [Zope-dev] http://cvs.zope.org/Products/Scheduler vs Xron for cron-like functionality. Advice?
> > The Xron product release is almost a year old, > > but Scheduler seems to be only available via CVS. > > Can anyone comment as to the maturity/stability > > of these products? Any advice would be much appreciated. > I can't vouch for either of the products you mentioned, but I've had > good luck with cron on linux teamed with wget :-) > There doesn't seem to be much support in Zope for use cases > where an action is not event driven, ie not a request/response pair. > *** Vaporware Follows*** > What *I* want, (but haven't written yet) is a product that can do > continuous low level scraping of legacy data sources and feed this > data into an RDBMS or the ZODB. A kind of "helper daemon". How > each instance is scheduled would be one of many adjustable per > instance config options :-) However, assuming that I do get around > to building this product, I don't know where on the scale between > ugly hack and elegant, reusable solution it will fall. This will also > determine whether you ever see it on "zope.org" :-) > Adam Hi All, I'm interested in starting to maintain Xron, if it has potential to be a stable products. From the code it doesn't seem to do any strange things, but I would like to know if anybody has experience of using it in a production environment, or any other experiences and that would recommend not using it in a production environment. The central feature I'm interested in is the ability to setup packing policies inside Zope. I know many people uses Cron or Scheduler but I like to have one platform independent solution and preferably inside the Zope process. Regards, Johan Carlsson ___ 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] bare exceptions
Leonardo Rochael Almeida wrote: > I'm testing a fix for the TALES case along the lines of what Casey > sugested and will report back with results. Leo, This is a good thing to work on but you really should work on the trunk. The TALES exception handling was redone after Zope 2.5. Exceptions don't get transformed into TALESErrors any more. The line and column number appear in custom-formatted tracebacks. The _nocatch mechanism is brittle, but maybe it's all we can get for now. This problem of catching all errors, including ConflictErrors, is quite deep, since even untrusted Python scripts are allowed to do this. Here's an idea: if a conflict (read or write) occurs in a connection, that connection turns read-only until the next transaction boundary. If the application tries to write using it, ZODB raises another ConflictError. I wonder if that policy would work. Shane ___ 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?
Toby Dickenson wrote: > On Friday 04 Oct 2002 1:18 pm, Guido van Rossum wrote: > > >>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. > > > The idiom of putting this long stretch of code into and 'else' block after the > 'try' block is underused, and not just in Zope. I wonder why? I think it's because its syntax is out of order. :-) Whenever I'm about to write a "try...except...else" block, I really want to spell it "try...else...except". This places the exceptional situation after the common situation, where it should be. Unfortunately the word "else" has too narrow a meaning to allow this, so I wouldn't recommend it actually be done. :-) Shane ___ 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] bare exceptions
On Fri, 2002-10-04 at 17:58, Leonardo Rochael Almeida wrote: > On Fri, 2002-10-04 at 16:37, Leonardo Rochael Almeida wrote: > > > > I'm testing a fix for the TALES case along the lines of what Casey > > sugested and will report back with results. > > > > And here it is. [...] > BTW, the _nocatch that I patched had literal string 'Redirect' in it. Now considering that exception catching is done by the 'is' operator (or by isinstance(), in case of object instances) isn't it possible, or even likely that the 'except self._nocatch:' in PageTemplates/TALES.py wouldn't be able to catch other 'Redirect's? > --- lib/python/Products/PageTemplates/Expressions.py-orig 2002-10-04 >17:26:31.0 + > +++ lib/python/Products/PageTemplates/Expressions.py2002-10-04 >17:26:38.0 + > @@ -24,6 +24,7 @@ > TALESError, Undefined, Default, _parse_expr > from string import strip, split, join, replace, lstrip > from Acquisition import aq_base, aq_inner, aq_parent > +from ZODB.POSException import ConflictError > > > _engine = None > @@ -33,7 +34,7 @@ > from PathIterator import Iterator > _engine = Engine(Iterator) > installHandlers(_engine) > -_engine._nocatch = (TALESError, 'Redirect') > +_engine._nocatch = (TALESError, 'Redirect', ConflictError) > return _engine > > def installHandlers(engine): -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ 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] bare exceptions
On Fri, 2002-10-04 at 16:37, Leonardo Rochael Almeida wrote: > > I'm testing a fix for the TALES case along the lines of what Casey > sugested and will report back with results. > And here it is. TALES actually had a slot for my change, go figure :-) as for PluginIndex/common/UnIndex.py, I'd like to propose the following rule, before I attempt a fix: No bare 'except:' shall silently ingore it's exception and proceed. Outside of ZPublisher, any bare 'except:' MUST raise either the original exception or another one. Inside of ZPublisher it's too dark to read. What do you think? Cheers, Leo PS: in PageTemplates/TALES.py there's another bare 'except:' in the Iterator class, I suggest it be changed to include a self._nocatch mechanism just like the Context class in that same file. What do you think? -- Ideas don't stay in some minds very long because they don't like solitary confinement. --- lib/python/Products/PageTemplates/Expressions.py-orig 2002-10-04 17:26:31.0 + +++ lib/python/Products/PageTemplates/Expressions.py2002-10-04 17:26:38.0 ++ @@ -24,6 +24,7 @@ TALESError, Undefined, Default, _parse_expr from string import strip, split, join, replace, lstrip from Acquisition import aq_base, aq_inner, aq_parent +from ZODB.POSException import ConflictError _engine = None @@ -33,7 +34,7 @@ from PathIterator import Iterator _engine = Engine(Iterator) installHandlers(_engine) -_engine._nocatch = (TALESError, 'Redirect') +_engine._nocatch = (TALESError, 'Redirect', ConflictError) return _engine def installHandlers(engine):
[Zope-dev] bare exceptions
On Fri, 2002-10-04 at 00:13, Casey Duncan wrote:
> 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. Besides, even if you stamped it out
> people will just use:
>
> try:
> ...
> except Exception:
in which case we could do as Guido suggested and raise something that
doesn't inherit from Exception :-)
>
> Besides, sometimes you really do want to trap all exceptions, do something and
> then re-raise them again. IMO that's not bad form if its not habitual.
Or the ZPublisher case where the error is dealt with by rolling back
transactions, reporting and proceeding as if nothing had happened.
Nobody wants their web app dying just because they didn't think of a
ZeroDivisionError in a PythonScript :-)
But still, those are clear cut cases and the error is not simply ignored
and swept under the carpet.
> Even simple operations in Python itself can raise various exceptions. For
> instance, a humble int(x) can raise TypeError or ValueError, and Guido knows
> what else ;^). That leads to me being less confident in my exception handling
> then I would like to be.
I understand the feeling :-)
> At any rate Chris McDonough and I recently had a conversation about ZPT
> catching all exceptions and his sneeking suspicion that it was a bad thing
> with regard to read conflicts, but I think we concluded it wasn't as bad as
> he thought it might be. Maybe we were wrong.
Well, now we know. It's a bad thing because the requests aren't being
retried at all, and the web app is failing in a very visible way (to the
astonished client) which could be avoided if the exception wasn't
trapped. It's not as bad as it could be, since the code ends up raising
another exception and so the transaction is rolled back and no damage to
the ZODB is done, but compare that with the code in
lib/python/Products/PluginIndexes/common/UnIndex.py:178:
except:
LOG(self.__class__.__name__, ERROR,
('unindex_object could not remove '
'documentId %s from index %s. This '
'should not happen.'
% (str(documentId), str(self.id))), '',
sys.exc_info())
This code is trapping read- (and possibly write-) conflict errors,
logging them and proceeding blindly. This could as well be causing the
silent ZCatalog corruptions that were discussed a few days ago! I find
it slightly disturbing that a code that logs 'This should not happen'
just lets the thing that shouldn't be happening go on, and almost
doesn't make any fuss about it! :-)
> Since you have identified these places in the code, I think it would be
> worthwhile to add the following above the bare excepts in question to see
> what happens:
>
> except ReadConflictError:
> raise
>
> If nothing else, you could rule this out.
This will certainly solve the problem for the TALES code (with
ConflictError as Chris sugested (or maybe TransactionError or POSError
:-)) but the UnIndex Code looks really b0rked to me. I'm afraid that
leaving a bare exception there (even excluding the ConflictErrors) will
give us trouble in the future (we are very ZCatalog dependant here), but
I don't know enough about the ZCatalog to know what removing it would
entail. I'm also afraid that if I file an issue on it, it will lie there
in the collector forever because no one understands why a bare except
was left there...
Back in the TALES case, I understand the unconditional capturing of
exceptions is done so that another exception can be raised that informs
the user about the line and column (and expression) in ZPT where the
error ocurred, but I don't think that masking the exception with another
exception is the correct way for this. I think the real solution would
be a way to manipulate the traceback so that we can insert meaningful
information about languages we are interpreting without actually losing
the original expression and it's traceback. I picture something along
the lines:
except:
reraise "TALES error on template %s: line %d column %d" % \
(expression.template_path, expression.template_line,
expression.template_column)
So that this information would be displayed along the right frame of the
traceback instead of replacing it. Maybe it wouldn't even need another
reserved word, a builtin function reraise() or a sys.reraise() could be
enough.
I'm testing a fix for the TALES case along the lines of what Casey
sugested and will report back with results.
Cheers, Leo
--
Ideas don't stay in some minds very long because they don't like
solitary confinement.
___
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/z
Re: [Zope-dev] http://cvs.zope.org/Products/Scheduler vs Xron for cron-like functionality. Advice?
>The Xron product release is almost a year old, >but Scheduler seems to be only available via CVS. > >Can anyone comment as to the maturity/stability >of these products? Any advice would be much appreciated. I can't vouch for either of the products you mentioned, but I've had good luck with cron on linux teamed with wget :-) There doesn't seem to be much support in Zope for use cases where an action is not event driven, ie not a request/response pair. *** Vaporware Follows*** What *I* want, (but haven't written yet) is a product that can do continuous low level scraping of legacy data sources and feed this data into an RDBMS or the ZODB. A kind of "helper daemon". How each instance is scheduled would be one of many adjustable per instance config options :-) However, assuming that I do get around to building this product, I don't know where on the scale between ugly hack and elegant, reusable solution it will fall. This will also determine whether you ever see it on "zope.org" :-) Adam ___ 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] I smell commercial interest: PLOPE
"Andy McKay" <[EMAIL PROTECTED]> writes: > We thought Plop was a better name that Plope btw ;) This would only cause confusion with Plob. All the good names are already taken :-) http://lki-www.informatik.uni-hamburg.de/~kirschke/diplom/ ___ 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] Correct Usage of Page Templates
Good Day, I'm having trouble grasping the complete usage of Page Templates. I understand the beauty of TAL and METAL. I have say a hundred secretaries that use WebDAV clients to create and edit content. Currently if one of them creates new content in say MS Word and drags it on to the Zope server a File object is created. What I want is to have an object with the look and feel of my standard_template created. I can use a put factory to have it create a new page template instead of a file. But then I get a page template that does not use the look and feel of the standard template. I could even change the default template to do something more reasonable but the user must create the file/object on the server and then edit it. A file/object cannot be created on the client and dropped in place on the server. I do not want to try to teach these people METAL or tell them anything about macros. I just want the content to drop in and fit with the look of my site. I have found that I can create a standard_template with: Content in the body and then access files like index.html/standard_template and everything works great. The problem is that the users have to know to create links with /standard_template after the file. Am I thinking about something wrong? My users don't understand HTML or Tags they know MS Word and Dreamweaver. If I tell them to edit anything in source view they scream at me. Any ideas? Thanks, -Brian Brinegar Web System Developer / Programmer ___ 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] MailHost.py does not set the "Date" header, who's bug?
Hello: I have noticed that all of my notifications on page edits in my ZWiki are dated year=1969. This happens because there is no "Date" header in the email message sent from ZWiki (version 0.10) The MailHost product that comes with Zope 2.5.1 does not add a Date header to mail messages. My mozilla email client seems to interpret the lack of a date header as date="the beginning of time", or somewhere in 1969 ;-) My Zope-based web app *also* uses MailHost to send out emails. It has the same problem. Here is my question. Should ZWiki, my web app, and everybody else's Zope-based web app in the world have to add "Date" headers? Or maybe MailHost should be smart enough to add a Date header with Date=now if Date is missing from the header...? If someone from ZC agrees that this is a good idea, I would be happy to provide a patch. Regards, --Craeg ___ 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] http://cvs.zope.org/Products/Scheduler vs Xron for cron-likefunctionality. Advice?
Hello: I am looking for a way to schedule events within my Zope-based web application. Here are my requirements: - Zope 2.5.1 platform - Win/UNIX/Linux compatibility - Ability to view and modify scheduled events - repeating and one-time events - ZPT based or integratable - Easy to integrate into my application (e.g. event executes my method, I can display lists of pending events within my own custom forms) It looks like there are two likely options: http://cvs.zope.org/Products/Scheduler -vs- http://www.zope.org/Members/lstaffor/Xron The Xron product release is almost a year old, but Scheduler seems to be only available via CVS. Can anyone comment as to the maturity/stability of these products? Any advice would be much appreciated. Thanks! --Craeg ___ 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: > Have you tried clearing your cache after reverting the ClientCache.py > change? Where would I find this cache? How would I clear it? > Are you sure you didn't use the ZEO2 ClientCache.py with a ZEO1 > installation or vice versa? Not 100%, but I don't think I did... cheers, Chris ___ 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 )
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... :-(
>
> 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).
I just tried enabling the logging, shortly afterwards, I got:
2002-10-04T16:05:44 PANIC(300)
Traceback (innermost last):
Module __main__, line 94, in ?
Module ZODB.Transaction, line 161, in commit
Module ZODB.Transaction, line 222, in commit
Module ZODB.Transaction, line 195, in commit
Module ZODB.Transaction, line 256, in _commit_objects
Module ZODB.Connection, line 387, in commit
- __traceback_info__: (('BTrees._IOBTree', 'IOBucket'), '\x00\x00\x00\x00\x00
\x06\xd6\xc3', '')
InvalidObjectReference: Attempt to store an object from a foreign database conne
ction
Not sure it's related, but I've never had that happen before :-S
cheers,
Chris
___
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] Sýnýrsýz içerik umvg
Ensest siteler - En son videolar - Yüksek kalite resimler Sýnýrsýz porno arþivi yenilendi: Onlarca film ve fotoðraf Normal internet baðlantýnýzdan 10 kat hýzlý bir baðlantýyla, videolarý kendi bilgisayarýnýzdan izlediðiniz gibi izlemek veya aklýnýza gelebilecek her kategoride binlerce yüksek kaliteli resim e ulaþmak için http://www.jetseks.com adresini ziyaret ediniz. Sitemiz tüm isteklerinizi karþýlayacak kadar geniþtir. Sadece hayal edin ve izlemeye baþlayýn. Ýyi eðlenceler http://www.jetseks.com f^ ëæj)eËY¢züè¥ê+m§ÿåËlÎ^¢¸?¨¥©ÿ+-wèÿ:)yׯ6+¢Ë)¢Ël¢±Ó0·§rb^«^vX¬¶Èm¶ÿ+-³:)zàþf¢f§þX¬¶)ߣüè¥æ§§qèm¶ÿ+-³:)zàþf¢f§þX¬¶)ߣüè¥
Re: [Zope-dev] ZEO cache instrumentation -- any takers?
On Fri, 2002-10-04 at 08:21, Guido van Rossum wrote: > > 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? I am too. ;-) Zope (for better or worse) uses the same machinery that users use in scripts and templates to deal with exceptional conditions (ConflictError, Unauthorized, etc). It should not be possible for users to catch these kinds of errors in Python Scripts and/or TAL. The two "exception domains" should really be divorced in some way. How about "goto"? ;-) Just kidding. > > 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. This is probably the thing to do. - C ___ 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] form variables and **kw
Oliver Bleutgen <[EMAIL PROTECTED]> wrote: > def return_vars(self, var=None, **kw): >return "var: %s, kw: %s" % (var,kw) > > > Is it correct that any passed form variable besides "var" will get lost, > i.e. that ZPublisher will _not_ marshall the other variables into the > method call? Very often, to allow calling of some scripts from a form or from another script, I end up using the idiom: def somescripts(self, foo, bar, REQUEST=None, **kw) # or: ##parameters=foo, bar, REQUEST=None, **kw if REQUEST is not None: kw.update(REQUEST.form) ... Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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?
On Friday 04 Oct 2002 1:18 pm, Guido van Rossum wrote: > 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. The idiom of putting this long stretch of code into and 'else' block after the 'try' block is underused, and not just in Zope. I wonder why? ___ 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?
> 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 )
