Re: [Zope-dev] Copyright header change script ready
Hi, On 12/18/2009 11:27 PM, Tres Seaver wrote: > Christian Theune wrote: >> Hi, > >> after transferring the code ownership from ZC to the ZF we need to >> change copyright headers in the repository. > >> I wrote a script [1][2] to help doing that (changing the trunks and last >> two release branches) which is ready now. > >> This message is mainly intended as a heads-up: there'll be a lot of >> commits soon that will alter a lot of code automatically. > >> I'm currently planning to let the script run over all top-level projects >> I see in the repository on the coming week-end so if anybody >> likes to veto this, please step up today or tomorrow. > >> If you'd like to see how the change looks like, you can look at the >> changes produced by running it on gocept.zope3instance [3][4]. > > We want to be *replacing* Zope Corporation and contributors, not adding > on a new one: they have transferred all those copyrights to the > foundations. We also want to leave the dates alone (dates should only > change when separately-copyrightable changes are made to the module). That's what we initially thought. In the November board meeting we decided to go for the additional entry: http://foundation.zope.org/minutes/zfbod-minutes-20091102 Christian ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to automatically poke Zope2 on slow requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Helge Tesdal wrote: > I'm trying to debug slow requests/writes, and I'm wondering if there > are any suitable tools for this. It's not on every request or write, > we're not able to detect manually and start checking from the shell, > and we would prefer to not affect performance too much for all the > regular requests. > > What I've been thinking of is a proxy that can start poking with > signalstack and perhaps check system IO once a request has taken more > than a set number of seconds (or trigger by some other rule), or a > component that starts a monitor thread for each request that can do > something similar. I'm open to completely different approaches. You probably want to enable the trace log, along with maybe another something which logs additional data so that you can correlate with the traced requests. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkssAnIACgkQ+gerLs4ltQ5o+ACgtmu/9v1MwhMw2cUzuKrrVpah dgIAoIKJfVotqfRbeQLkDqaWOM/EXjAc =/LF8 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Copyright header change script ready
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > Hi, > > after transferring the code ownership from ZC to the ZF we need to > change copyright headers in the repository. > > I wrote a script [1][2] to help doing that (changing the trunks and last > two release branches) which is ready now. > > This message is mainly intended as a heads-up: there'll be a lot of > commits soon that will alter a lot of code automatically. > > I'm currently planning to let the script run over all top-level projects > I see in the repository on the coming week-end so if anybody > likes to veto this, please step up today or tomorrow. > > If you'd like to see how the change looks like, you can look at the > changes produced by running it on gocept.zope3instance [3][4]. We want to be *replacing* Zope Corporation and contributors, not adding on a new one: they have transferred all those copyrights to the foundations. We also want to leave the dates alone (dates should only change when separately-copyrightable changes are made to the module). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkssAcgACgkQ+gerLs4ltQ5tjwCg0wKLHF254uFsGM2wjKMJdIap 1JoAn2NPH4wmuO2xQiAMH+meVFt0Dqs6 =fy0T -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A summary of "Interfaces vs ZCA concepts"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ethan Jucovy wrote: > Hi, > > On Fri, Dec 18, 2009 at 9:47 AM, Lennart Regebro wrote: >> On Fri, Dec 18, 2009 at 08:51, Brian Sutherland >> wrote: >>> I like things to fail noisily and loudly unconfigured and give good >>> information about what's wrong. >> +1 > [snip] >> we make zope.interface aware that such a thing as utility-registries >> exist, but say we don't implement it. I don't think that's a problem. >> The error message also gives an example of an implementation. That's >> probably not a problem either. >> >>> I feel uncomfortable about that. >> I don't. :-) > > +1 from my perspective of "I don't know or understand the core ZCA > codebase very well (and don't understand all the implications in this > discussion) but often read or trace through the code." A > well-documented NotImplementedError seems much more human-useful than > a default implementation that fulfills the contract, because it > assertively announces the expectation for the most common case by far: > "you probably want to plug in a real implementation here." Then if > there is a need for the proposed default implementation, it can be > provided as a plugin by some other package, right? The same argument applies in your case: you could plug in your own wrapper implementation which raised errors if not replaced. - -1 to raising NotImplementedError. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkssANoACgkQ+gerLs4ltQ57XgCdGN8W4q4IevSbQX+XgaRaUXA4 rNkAn1ART1odK+s576b8GbjGX6JIJh6u =VJnE -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hey, > > Tres Seaver wrote: > [let's not suddenly change the behavior of __call__ for backwards > compatibility reasons] > >> If so, that code is already broken: it depends on an undocumented >> implementation detail (of a non-API method). The patch makes the >> __call__ method an API, and documents the (new) exception type. Anybody >> whose code breaks when this happens can hold off upgrading >> zope.interface until they fix that usage. > > Documentation status aside, are you really maintaining that a feature > that people have been using for many years is not actually part of the > API? So that we can change willy-nilly without any concern for backwards > compatibility? I didn't say "without concern" -- I suggested that we bump the minor version to indicate that this was something of an API change. If you would rather raise a compatibliity error (blending the two types together), I could live with that. I would still rather document LookupError, as it is the *correct* exception type: TypeError says "you violated the contract by passing me a bad argument", rather than "I couldn't find what you were looking for." Note that CLE already derives from LookupError, which reinforces the point. > If you do insist on taking that position, then please note that while > API may not be documented in zope.interface it is certainly documented > in other places. The __call__ behavior and the TypeError behavior for > instance is documented in at least one published book (see bottom of the > page): > > http://docs.zope.org/zope3/Book/ifaceschema/interface/show.html > > Documented for years. That example is a poor bit of documentation, as well as a bad test (depends on the repr of an exception). There is way too much "example cruft" and way too little prose there to help anybody figure out how to use interfaces by calling them. In particular, the role of the adapter hook is completely obscured. If __call__ is an API, why is it not documented where the rest of the API for Interface is specified? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksr/lUACgkQ+gerLs4ltQ620ACgifVngQZiIOhHNtHsDLtF8i0l dVYAoNhlXxcfJA4eMiyFIFo7nNHKiUQ+ =FCFu -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
Martijn Faassen wrote:
[snip]
> If you do insist on taking that position, then please note that while
> API may not be documented in zope.interface...
actually the API is documented in zope.interface's README.txt, including
TypeError:
If an object cannot be adapted, then a TypeError is raised::
>>> class I(zope.interface.Interface):
... pass
>>> I(0)
Traceback (most recent call last):
...
TypeError: ('Could not adapt', 0, )
That documentation went in there 3 years and 7 months ago.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
Hey, Tres Seaver wrote: [let's not suddenly change the behavior of __call__ for backwards compatibility reasons] > If so, that code is already broken: it depends on an undocumented > implementation detail (of a non-API method). The patch makes the > __call__ method an API, and documents the (new) exception type. Anybody > whose code breaks when this happens can hold off upgrading > zope.interface until they fix that usage. Documentation status aside, are you really maintaining that a feature that people have been using for many years is not actually part of the API? So that we can change willy-nilly without any concern for backwards compatibility? If you do insist on taking that position, then please note that while API may not be documented in zope.interface it is certainly documented in other places. The __call__ behavior and the TypeError behavior for instance is documented in at least one published book (see bottom of the page): http://docs.zope.org/zope3/Book/ifaceschema/interface/show.html Documented for years. [snip part where changing the name of a parameter is also fine as it's undocumented] -1 against merging this. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Lotze wrote: > Martijn Faassen wrote: > >> Hey, >> >> Tres Seaver wrote: >> [snip] >>> Any code today which wants a utility is calling 'getUtilty' (if it >>> *knows* the utility must be registered) or 'queryUtility' (if it thinks >>> it might not be). Less facetiously than my first challenge: please >>> point to actual code in the wild which looks like:: >>> >>> try: >>> foo = getUtilty(IFoo, name='bar') >>> except ComponentLookupError: >>> # do something >>> >>> instead of:: >>> >>>foo = queryUtility(IFoo, name='bar') >>>if foo is None: >>># do something >>> >>> I will argue that any code doing the first, outside of maybe tests of >>> the ZCA itself is plain broken. >> I have code like that in the wild - I have no real reason why I didn't >> queryUtility, but I didn't think it mattered. >> >> Why is it plain broken? Isn't getUtility supported to raise >> ComponentLookupError if it cannot find the required utility? > > The interface declaration for the zope.component API does assert that > getUtility raises a CLE if it cannot find the utility. Also, I wouldn't > say that queryUtility should be used instead of using getUtility and > catching the CLE, as that would deprive us of all the advantages of using > exceptions, such as propagation along the call stack. Those advantages don't obtain if the call site itself catches the CLE: at that point, all you have is a more expensive and less clear way to get what 'queryUtility' gives you. Tres - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksrvvwACgkQ+gerLs4ltQ64JgCfc9sKxivpsIZJT8A3ep+pW0cZ J7AAn0yRW2137WO7cHq92zAXCTj33cwf =anzG -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Martin Aspeli wrote: >>> Tres Seaver wrote: >>> In either case, I think TypeError (or maybe LookupError) is the *right* choice: we don't want to "hide" zope.component's API functions and then turn around and require folks to import zope.component just to catch its local exception types. >>> Yeah, that's a compelling reason. >> I have checked in a branch which makes failed adaptation (inside the >> __call__ of an interface) raise a LookupError instead of a TypeError: >> the branch also documents the semantics of __call__. I would like to >> merge this to the trunk a 3.6.0 version (bumped to indicate the >> quasi-API change). >> >> http://svn.zope.org/zope.interface/branches/tseaver-raise_lookup_error/?rev=106688&view=rev > > While I'm fine with the principle of this change, I do consider it > dangerous - people might be catching TypeError now instead of using the > "alternate" argument. Quite a bit of code depending on TypeError (even > if undocumented) might unexpectedly break. If so, that code is already broken: it depends on an undocumented implementation detail (of a non-API method). The patch makes the __call__ method an API, and documents the (new) exception type. Anybody whose code breaks when this happens can hold off upgrading zope.interface until they fix that usage. > We could support both errors by introducing an exception that subclasses > both TypeError and LookupError. The question is whether such a strategy > would help us deprecate TypeError altogether - I don't see how we can > detect that TypeError was caught instead of LookupError when our > exception is handled, so we can't output any messages.. > > Besides this you've documented the default argument as "default" while > it is in fact "alternate" (which we want to deprecate in favor of > default), so the documentation of __call__ isn't correct. __call__ is not an API, so again, anybody relying on its argument names can hold off on upgrading. > I think this needs some more thinking, unfortunately. I wish I could see > a gradual way forward on moving from TypeError to LookupError. I don't see any way, or any benefit, to holding off. Just publish the new version (with a bump), and let people find and fix the problematic places in their code as they upgrade. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksrvcMACgkQ+gerLs4ltQ5bewCg1jxWXSGE/cj+1OJ8X9yc0IIN KUcAnilGOd2LdOA4ZXtUKYSMVfbMLYGl =BkFw -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A summary of "Interfaces vs ZCA concepts"
Ethan Jucovy wrote:
> +1 from my perspective of "I don't know or understand the core ZCA
> codebase very well (and don't understand all the implications in this
> discussion) but often read or trace through the code." A
> well-documented NotImplementedError seems much more human-useful than
> a default implementation that fulfills the contract, because it
> assertively announces the expectation for the most common case by far:
> "you probably want to plug in a real implementation here." Then if
> there is a need for the proposed default implementation, it can be
> provided as a plugin by some other package, right?
I'm now convinced people want to see a clear NotImplementedError.
I think if we went with a plugin structure, we could do something like this:
class Interface:
...
def utility(...):
return lookup_plugin.utility(...)
class NotImplementedLookupPlugin(object):
def utility(...):
raise NotImplementedError("""
this is the not implemented lookup plugin. You need to install another
one. Blah blah zope.component blah blah""")
lookup_plugin = NotImplementedLookupPlugin()
def set_lookup_plugin(plugin):
global lookup_plugin
lookup_plugin = plugin
As long as external packages do not register a proper plugin, it'll
raise NotImplementedErrors. Both the actual error as well as the name of
the default lookup plugin signal something hasn't been installed.
We could also easily provide *another* plugin in zope.interface that
does the "as if the registry is empty" behavior, if that turns out to be
useful (perhaps for testing). But to use it someone would need to
explicitly enable it. Tests could also define fake lookup plugins with
other behavior so we can test these methods properly.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A summary of "Interfaces vs ZCA concepts"
Hi, On Fri, Dec 18, 2009 at 9:47 AM, Lennart Regebro wrote: > On Fri, Dec 18, 2009 at 08:51, Brian Sutherland > wrote: >> I like things to fail noisily and loudly unconfigured and give good >> information about what's wrong. > > +1 [snip] > we make zope.interface aware that such a thing as utility-registries > exist, but say we don't implement it. I don't think that's a problem. > The error message also gives an example of an implementation. That's > probably not a problem either. > >> I feel uncomfortable about that. > > I don't. :-) +1 from my perspective of "I don't know or understand the core ZCA codebase very well (and don't understand all the implications in this discussion) but often read or trace through the code." A well-documented NotImplementedError seems much more human-useful than a default implementation that fulfills the contract, because it assertively announces the expectation for the most common case by far: "you probably want to plug in a real implementation here." Then if there is a need for the proposed default implementation, it can be provided as a plugin by some other package, right? -Ethan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A summary of "Interfaces vs ZCA concepts"
On Fri, Dec 18, 2009 at 08:51, Brian Sutherland wrote:
> I like things to fail noisily and loudly unconfigured and give good
> information about what's wrong.
+1
> So my preferred implementation of a
> stub "utility" function on Interface is:
>
> def utility(default=None):
> """Lookup a utility for this interface.
>
> A utility is a ${long explanation of utility concept}.
>
> This method behaves like ${explanation of utility method contract}.
> """
> raise NotImplementedError("""No Utility lookup mechanism has been
> configured.
> If you wish to use utility lookups on interfaces, please configure
> a
> package that contains this mechanism. Packages known to
> implement this are:
> zope.component
> """)
>
> I agree that this encodes in the zope.interface package concepts from
> zope.component.
I think that is stretching the "encoding concepts" a bit too far. Yes,
we make zope.interface aware that such a thing as utility-registries
exist, but say we don't implement it. I don't think that's a problem.
The error message also gives an example of an implementation. That's
probably not a problem either.
> I feel uncomfortable about that.
I don't. :-)
--
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Testrunner option for running tests in random order?!?
Hi, On Fri, Dec 18, 2009 at 1:51 PM, Christian Theune wrote: > > Reviewed and merged. > > I made some minor textual changes, otherwise that code was fine. Thank you Christian! BTW, the Pypi page for zope.testing is a bit broken currently (the HTML has not been generated), can you fix this too? Regards, Jonathan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Testrunner option for running tests in random order?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/16/2009 06:59 PM, Sebastien Douche wrote: | On Fri, Oct 9, 2009 at 14:33, Christian Theune wrote: | | Hi Christian. | |> That's what working branches are for. | | Done : | http://svn.zope.org/zope.testing/branches/sdouche-shuffle/ Reviewed and merged. I made some minor textual changes, otherwise that code was fine. Christian - -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksrerUACgkQdUt9X/gknwIUXwCgqnT4K11BB0H8R/1uKNOM3toz uX4An3XKwn+SDAXfnGFm77IyFlAFxJf/ =9VoN -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to automatically poke Zope2 on slow requests
Helge Tesdal wrote: > On 18. des.. 2009, at 13:24, Andreas Jung wrote: > >> Publisher events are part of Zope 2.12 (not sure if they were >> backported to older versions). >> >> Perhaps of interest: >> >> http://pypi.python.org/pypi/haufe.requestmonitoring >> http://pypi.python.org/pypi/haufe.ztop > > > Thanks, I think this is exactly what we're looking for! :) > > If the events aren't backported I'm sure we can use the events that > are monkeypatched into Zope for cache control. Talk to Laurence about ZPublisherEventBackport. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to automatically poke Zope2 on slow requests
On 18. des.. 2009, at 13:24, Andreas Jung wrote: > Publisher events are part of Zope 2.12 (not sure if they were > backported to older versions). > > Perhaps of interest: > > http://pypi.python.org/pypi/haufe.requestmonitoring > http://pypi.python.org/pypi/haufe.ztop Thanks, I think this is exactly what we're looking for! :) If the events aren't backported I'm sure we can use the events that are monkeypatched into Zope for cache control. -- Helge Tesdal www.jarn.com/tesdal ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to automatically poke Zope2 on slow requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 schrieb Helge Tesdal: > On 18. des.. 2009, at 13:11, Andreas Jung wrote: > >> You're talking of Zope 2.x? Have you checked the publisher >> events? > > 2.10.6 and RelStorage 1.1.3 in this case. We expect RelStorage 1.4 > to help, but still want the debugging thingie. > > I haven't checked the publisher events, but I guess that's an > excellent way of starting and stopping the monitor thread? Or > would you use the events some other way? Publisher events are part of Zope 2.12 (not sure if they were backported to older versions). Perhaps of interest: http://pypi.python.org/pypi/haufe.requestmonitoring http://pypi.python.org/pypi/haufe.ztop Andreas - -- ZOPYX Ltd. & Co KG \ zopyx group Charlottenstr. 37/1 \ The full-service network for your D-72070 Tübingen \ Python, Zope and Plone projects www.zopyx.com, i...@zopyx.com \ www.zopyxgroup.com - E-Publishing, Python, Zope & Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksrdH4ACgkQCJIWIbr9KYyxuACgiOVBf6yyWyzxfAc5PjqeRgEO nDgAn2HQaagTZUTzfLBZ4G3Hij5Abqmv =qOeE -END PGP SIGNATURE- <>___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to automatically poke Zope2 on slow requests
On 18. des.. 2009, at 13:11, Andreas Jung wrote: > You're talking of Zope 2.x? Have you checked the publisher events? 2.10.6 and RelStorage 1.1.3 in this case. We expect RelStorage 1.4 to help, but still want the debugging thingie. I haven't checked the publisher events, but I guess that's an excellent way of starting and stopping the monitor thread? Or would you use the events some other way? -- Helge Tesdal www.jarn.com/tesdal ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to automatically poke Zope2 on slow requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 schrieb Helge Tesdal: > I'm trying to debug slow requests/writes, and I'm wondering if there > are any suitable tools for this. It's not on every request or write, > we're not able to detect manually and start checking from the shell, > and we would prefer to not affect performance too much for all the > regular requests. > > What I've been thinking of is a proxy that can start poking with > signalstack and perhaps check system IO once a request has taken more > than a set number of seconds (or trigger by some other rule), or a > component that starts a monitor thread for each request that can do > something similar. I'm open to completely different approaches. > You're talking of Zope 2.x? Have you checked the publisher events? Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksrcYQACgkQCJIWIbr9KYw2dQCcCbUjvEU3whVzZlzp0W7A7DaO t1QAn2pJdzPSySSQH9fRtMs/7BuFz0m7 =D25U -END PGP SIGNATURE- <>___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Thu Dec 17 12:00:00 2009 UTC to Fri Dec 18 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Dec 17 20:37:59 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013215.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Dec 17 20:39:59 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013216.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 17 20:41:59 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013217.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 17 20:43:59 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013218.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 17 20:45:59 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013219.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 17 20:47:59 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013220.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] How to automatically poke Zope2 on slow requests
I'm trying to debug slow requests/writes, and I'm wondering if there are any suitable tools for this. It's not on every request or write, we're not able to detect manually and start checking from the shell, and we would prefer to not affect performance too much for all the regular requests. What I've been thinking of is a proxy that can start poking with signalstack and perhaps check system IO once a request has taken more than a set number of seconds (or trigger by some other rule), or a component that starts a monitor thread for each request that can do something similar. I'm open to completely different approaches. -- Helge Tesdal www.jarn.com/tesdal ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A summary of "Interfaces vs ZCA concepts"
Wolfgang Schnerring wrote: > * Martijn Faassen [2009-12-17 17:48]: >> * Thomas Lotze : >>> zope.interface [should be] completely unaware of any particular uses >>> of interfaces >> Why is it a problem that the zope.interface package gains knowledge >> about adaptation (which it always had, anyway) and utility lookup? > > This is the key issue, I think. > (And I'd like to ask you not to argue "it has always been that way", > since what we're trying to do here precisely is to improve the status > quo.) I'm saying that because I don't recall people arguing against this before. Since the __call__ logic is only about adapter lookup, does this mean that your argument is expanded against this as well or does it fall under the notion of looking up anything by interface? I think from the rest of your mail that you mean the latter. At least it's a strict subset of an expanded notion of "lookup". [snip] > By putting method stubs into zope.interface which are exclusively about > concepts of zope.component we would be I would say that to be consistent in that position, you would need to argue not just against method stubs but against the presence of these methods at all, no matter where they come from. The rest is just an implementation detail. Reasoning from your position that zope.interface shouldn't have notions of adapter and utility lookup, it hardly matters what package implements these methods. To the user of Interface it will look the same, except that zope.component monkey-patching things in would be harder to understand and debug. To be consistent we have the following options: * only provide a general notion of "looking up something by interface" in zope.interface. This general notion unfortunately clearly doesn't have support from a large number of people so sadly I had to let that go. * not change anything at all. Looking up these things remains the task of zope.component and we better use zope.component APIs. Monkey-patching methods in from another package to me looks like it doesn't improve the conceptual story at all. Conceptually Interface ends up as messed up as before and it becomes more difficult to understand what's going on for the code reader or debugger. > which might or might not take additional parameters such as a > name to look them up ... > for me emphatically do *not* belong to what "interfaces" are about. I think you can see a name as another context in a multi-adaptation, where this context is special in that: * it needs to be human-readable text * it cannot extend another name, unlike interfaces, which can extend each other It's just a handy shortcut. :) > By putting method stubs into zope.interface which are exclusively > about concepts of zope.component we would be > a) On a conceptual level: blurring the distinction between the two > packages and concepts, which I think is a Bad Thing(tm) > b) On a more practical level: coupling zope.interface to > zope.component. > Given all the recent efforts of untangling the dependency structure > between our packages, I think doing that would be a step in the exact > opposite direction. I don't think the dependency refactoring argument holds. We were untangling physical dependencies. This wouldn't change physical dependencies one bit: zope.component would still depend on zope.interface. There are likely tons of places where package A depends on package B and also configures package B, changing its behavior. This would be no different: zope.component depends on zope.interface and plugs into it as well to configure some of its behavior. That's what it does today with the adapter hook. Putting notions of conceptual purity aside, I was arguing for a pragmatic solution that results in code that is as unsurprising as possible. I don't think .adapt and .utility are perfect, and I would have gone for another solution myself (a more generalized lookup method), but they seem to have consensus support. I don't think they do much in the way of active harm by being there in zope.interface. They help readability of the code that uses them. Moreover, this pragmatic solution would make code that looks up multi adapters and utilities more convenient to write. So, zope.interface needs to gain these methods, and open up a plugin point so that these methods can be fully implemented by another package. I think this can be constructed so that the only new notions to zope.interface are: * multi-adaptation, an extension of adaptation * look up by name, a conceptual extension of multi-adaptation :) * utility lookup Too many for my tastes when there's such an elegant general lookup method available, but I can't convince enough people of that. If we are going to make Interface support these methods for pragmatic considerations, we should just face it and implement them on Interface (delegating to a plugin). Anything else just helps to obfuscate what is going on. Regards, Martijn
Re: [Zope-dev] A summary of "Interfaces vs ZCA concepts"
* Martijn Faassen [2009-12-17 17:48]: > * Thomas Lotze : > > zope.interface [should be] completely unaware of any particular uses > > of interfaces > > Why is it a problem that the zope.interface package gains knowledge > about adaptation (which it always had, anyway) and utility lookup? This is the key issue, I think. (And I'd like to ask you not to argue "it has always been that way", since what we're trying to do here precisely is to improve the status quo.) The question is, which concepts belong into zope.interface and which don't? One might also phrase that as, what is the responsibility and purpose of zope.interface (drawing upon the software engineering terms of cohesion and coupling). My opinion is that > [__call__ introduces] the following notion into zope.interface: > "please look up an object that provides this interface, somehow. (with > zero or more context objects)" might well belong into zope.interface, but that anything of these: > adapters, utilities, null-adapters or contextual utilities absolutely do not. I think there is a clear distinction between what "interfaces" are about and what "component architecture" is about, and I think it is worthwile to maintain and clarify that distinction. For me, a notion of "looking up something that provides an interface" belongs to what "interfaces" are about. But notions of "utilities" which might or might not be singletons, of "adapters" which might or might not take additional parameters such as a name to look them up, or notions of a "context" or a "registry" (which for me comes up immediately when thinking about "global" vs. "local" utilities) that influences the lookup, for me emphatically do *not* belong to what "interfaces" are about. By putting method stubs into zope.interface which are exclusively about concepts of zope.component we would be a) On a conceptual level: blurring the distinction between the two packages and concepts, which I think is a Bad Thing(tm) b) On a more practical level: coupling zope.interface to zope.component. Given all the recent efforts of untangling the dependency structure between our packages, I think doing that would be a step in the exact opposite direction. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
