(OT) Re: [Zope-dev] Zope 2.6 planning - call for contributors!
On Mon, 2002-03-04 at 03:55, Anthony Baxter wrote: I think the performance hit is really quite minimal for two if statements at the entry and exit point(s) of a function to turn the behaviour on and off. I'm not convinced. Those small increments of performance really add up. Look at how Python's performance over time has degraded as one after another small bits of cruft accumulated. ?!?! :-) $ python1.5 pystone.py Pystone(1.1) time for 1 passes = 0.84 This machine benchmarks at 11904.8 pystones/second $ python2.1 pystone.py Pystone(1.1) time for 1 passes = 0.77 This machine benchmarks at 12987 pystones/second $ python2.2 pystone.py Pystone(1.1) time for 1 passes = 0.68 This machine benchmarks at 14705.9 pystones/second seb ___ 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 2.6 planning - call for contributors!
On Mon, 2002-03-04 at 03:47, Richard Jones wrote: On Mon, 4 Mar 2002 14:40, Casey Duncan wrote: I agree, monkey patches are perfect for this. That makes them totally transparent to the application and Zope for that matter. There's nothing wrong with them in the right application. My main concern is the use of monkeypatching in the core makes it difficult for someone else to release a product that also MPs without them worrying about whether something has already patched code. Especially when we're talking about MP'ing so many core Zope objects (yes, I count 1 as so many :) I agree - altering classes at runtime is less predictable or discoverable than defining them statically. I think the current solution is really nice, but I don't see that it has any particular benefits over a static implementation, which has the benefit of following a standard, well-known pattern. I think the performance hit is really quite minimal for two if statements at the entry and exit point(s) of a function to turn the behaviour on and off. Yes - I would bet the performace difference is in the order of hundredths of a second. seb ___ 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 2.6 planning - call for contributors!
seb bacon wrote: Yes - I would bet the performace difference is in the order of hundredths of a second. Which I would prefer not to have added to the several hundred other hundredths-of-a-second little differences-that-people-thought-wouldn't-make-a-difference that have been added to Zope over time... 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] Zope 2.6 planning - call for contributors!
On Mon, 2002-03-04 at 10:47, Chris Withers wrote: seb bacon wrote: Yes - I would bet the performace difference is in the order of hundredths of a second. Which I would prefer not to have added to the several hundred other hundredths-of-a-second little differences-that-people-thought-wouldn't-make-a-difference that have been added to Zope over time... What, like ZPT? ;-P http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/4084B02199CC6AFB (to save the bother of following the link, that's the thread from about a month ago regarding evidence suggesting ZPT may be *twice* as slow as DTML) seb ___ 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] ZPT needs speeding up
seb bacon wrote: http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/4084B02199CC6AFB (to save the bother of following the link, that's the thread from about a month ago regarding evidence suggesting ZPT may be *twice* as slow as DTML) Yup. And I'm a pretty strong advocate that ZPT should be speeded up a lot. Anyone got any idea who I ened to help to do this? 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] MonkeyPatching in the Core (was: Zope 2.6 planning)
On Mon, 2002-03-04 at 11:23, Chris Withers wrote: seb bacon wrote: http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/4084B02199CC6AFB (to save the bother of following the link, that's the thread from about a month ago regarding evidence suggesting ZPT may be *twice* as slow as DTML) Yup. And I'm a pretty strong advocate that ZPT should be speeded up a lot. Indeed. However, I was being a bit glib with my example, and didn't explain my point properly: that performance issues should be subordinate to good design. Therefore, I suspect MonkeyPatching is bad: Pros - a tiny performance gain Cons - unpredictable interaction with future products; not a well-known method of distributing products; not easily discoverable But perhaps my 'cons' are misplaced? Mostly, I'm uneasy that someone looking at ZPublisher code would have no way of knowing that CallProfiler hooks into it if it were monkeypatched. seb seb ___ 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: MonkeyPatching in the Core (was: Zope 2.6 planning)
seb bacon wrote: Pros - a tiny performance gain Cons - unpredictable interaction with future products; I'd rephrase that as a pro: Ability to work with products of the future, without the need to understand their inner workings... not a well-known method of distributing products; Urm... that I gotta disagree with... Tehre are now many such products for Zope... not easily discoverable What do you mean by discoverable? But perhaps my 'cons' are misplaced? Mostly, I'm uneasy that someone looking at ZPublisher code would have no way of knowing that CallProfiler hooks into it if it were monkeypatched. Yeah they would, 'cos CallProfiler will be well documented beforeit hits a release and will onyl come into play if explicity enabled. And if you explicitly enable it, you should read the documentation first... 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] Deleting versions from Control_Panel
For some reason, when I try to view the Version Management screen under Control Panel, I get a bunch of gibberish for one of the versions... And... it won't let me click on the check box and Discard it... Is there a way to do this manually? Or even see which versions are available manually? We are running ZEO, so I should be able to import Zope and go from there... --andy. ___ 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] Deleting versions from Control_Panel
On Mon, 4 Mar 2002 11:01:22 -0500 Andrew Sydelko [EMAIL PROTECTED] wrote: For some reason, when I try to view the Version Management screen under Control Panel, I get a bunch of gibberish for one of the versions... And... it won't let me click on the check box and Discard it... Is there a way to do this manually? Or even see which versions are available manually? We are running ZEO, so I should be able to import Zope and go from there... A low-level way to get a list of versions is to call the versions() method on the storage object. Example: from ZEO.ClientStorage import ClientStorage cs = ClientStorage(...) # your server address here cs.versions() Jeremy ___ 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] Deleting versions from Control_Panel
On Monday 04 March 2002 11:08, you wrote:
On Mon, 4 Mar 2002 11:01:22 -0500
A low-level way to get a list of versions is to call the
versions() method on the storage object. Example:
from ZEO.ClientStorage import ClientStorage
cs = ClientStorage(...) # your server address here
cs.versions()
from ZEO.ClientStorage import ClientStorage
cs = ClientStorage(('192.168.1.52',9900))
cs.versions()
Traceback (most recent call last):
File stdin, line 1, in ?
File /data/www/Zope.9/Zope/lib/python/ZEO/ClientStorage.py, line 619, in
versions
try: return self._call('versions', max)
File /data/www/Zope.9/Zope/lib/python/ZEO/zrpc.py, line 214, in __call__
self.message_output(args)
File /data/www/Zope.9/Zope/lib/python/ZEO/smac.py, line 213, in
message_output
raise Disconnected(This action is temporarily unavailable.p)
ZEO.smac.Disconnected: This action is temporarily unavailable.p
Sounds like a good start though... But once I find one, how do I
delete/discard it?
--andy.
___
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] Deleting versions from Control_Panel
On Mon, 4 Mar 2002 11:11:55 -0500 Andrew Sydelko [EMAIL PROTECTED] wrote: On Monday 04 March 2002 11:08, you wrote: On Mon, 4 Mar 2002 11:01:22 -0500 A low-level way to get a list of versions is to call the versions() method on the storage object. Example: from ZEO.ClientStorage import ClientStorage cs = ClientStorage(...) # your server address here cs.versions() If you wait a second or two, the client should connect. To actually, do something: import ZODB db = ZODB.DB(cs) cs.versions() # pick a version db.abortVersion(name) get_transaction().commit() Jeremy ___ 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: I'm locked out of managing my CMF folders,because it asks me to log in and the password doesn't work.
Based on your description below, it seems your RewriteRule is not writen correctly. To make proper use of the VirtualHostMonster it should read (all in one line): RewriteRule ^(.*)$ http://localhost:8080/VirtualHostBase/http/www.DonHopkins.com/80/Don/Hopkins/VirtualHostRoot$1 [P,L] The 'L' in '[P,L]' is optional but makes sure this is the last rewrite rule to be applied. The 'localhost:8080' part could be anything as long as it finds the correct Zope. The 'VirtualHostBase/http/www.DonHopkins.com/80/' part (including the '/80' part is really important to make sure Zope knows which server it is pretending to be from and display the proper 'host part' of generated URL's AND AUTHENTICATION MECHANISMS (this is the part that could be biting you). The '/Don/Hopkins/' part before the VirtualHostRoot tells zope which folder it is actually serving and the 'VirtualHostRoot$1' part makes sure Zope knows it is pretending that 'Don/Hopkins' is the root of the URL space. You can think of it as meaning the /Don/Hopkins folder of the localhost:8080 Zope is mounted in the root folder of www.DonHopkins.com:80. Making sure Zope correctly knows where it's pretending to be from is very important in authentication/authorization matters, since browsers promptly discard any authentication request (and cookie requests, for that matter) for a site they are not visiting as a means to prevent cross site exploits. Other than that, Proxying thru apache should pass authentication headers normally, without any other effort on your part. Cheers, Leo On Mon, 2002-03-04 at 03:46, Don Hopkins wrote: Hmm, after looking at the logs, it seems like it's not passing authorization info through the virtual host proxy rewrite rule. When I set Apache up to use a proxy rewrite rule, it asks me to log in instead of showing the folder manager, and the hits come from anonymous: [apache configuration for the name based virtual server DonHopkins.com] RewriteRule ^/(.*) http://www.DonHopkins.com:8080/Don/Hopkins/$1 [p] [zope log of clicking in logged in zope manager tree view on /Don/Hopkins cmf folder, which contains a virtual host monster] 216.175.91.16 - dhopkins [03/Mar/2002:23:33:01 -0700] GET /Don/Hopkins/manage_workspace HTTP/1.1 302 473 http://www.donhopkins.com:8080/manage_menu; Mozilla/4.0 (compatible; MSIE 5.5; W\ indows 98) 216.218.252.133 - Anonymous [03/Mar/2002:23:33:01 -0700] GET /Don/Hopkins/manage_main HTTP/1.0 302 617 http://www.donhopkins.com:8080/manage_menu; Mozilla/4.0 (compatible; MSIE 5.5; Win\ dows 98) 216.218.252.133 - Anonymous [03/Mar/2002:23:33:01 -0700] GET /Don/Hopkins/login_form?came_from=http://www.DonHopkins.com/Don/Hopkins/mana ge_mainretry= HTTP/1.0 200 4046 http://www.donho\ pkins.com:8080/manage_menu Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) 216.218.252.133 - Anonymous [03/Mar/2002:23:33:01 -0700] GET /Don/Hopkins/default_stylesheet HTTP/1.0 200 5513 http://www.donhopkins.com/Don/Hopkins/login_form?came_from=http%3A//www.Don \ Hopkins.com/Don/Hopkins/manage_mainretry= Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) Notice that the proxy requests come from 216.218.252.133 [the server's ip] as Anonymous. Is the auth info not getting passed? But when I change the apache rewrite rule to use external redirect instead of internal proxy, it works and shows me the folder manager, and the hits come from the right place, but the url in the browser is unnecessarily long and nasty. RewriteRule ^/(.*) http://www.DonHopkins.com:8080/Don/Hopkins/$1 [R] 216.175.91.16 - dhopkins [03/Mar/2002:23:35:03 -0700] GET /Don/Hopkins/manage_workspace HTTP/1.1 302 473 http://www.donhopkins.com:8080/manage_menu; Mozilla/4.0 (compatible; MSIE 5.5; W\ indows 98) 216.175.91.16 - dhopkins [03/Mar/2002:23:35:04 -0700] GET /Don/Hopkins/manage_main HTTP/1.1 200 32200 http://www.donhopkins.com:8080/manage_menu; Mozilla/4.0 (compatible; MSIE 5.5; Wind\ ows 98) I've been able to get it to work with external redirects instead of internal proxy, but the path displayed in the manager doubles it up: Don/Hopkins/Don/Hopkins ... So I put in the first rewrite rule with the ^/Don/Hopkins prefix, and that eliminated the weird double path prefix behavior I was getting. RewriteRule ^/Don/Hopkins/(.*) http://www.DonHopkins.com:8080/Don/Hopkins/$1 [R] Is there a better way for me to rewrite zope virtual host requests, so the authentication headers go through properly? I want to have apache handle https and logging, but let zope handle its own user authentication. And I want the url of the web browser to be short and sweet, not showing :8080 or the virtual host subdirectories. Should I be using fastcgi (or slow cgi) instead of internal proxy, and trying to trick it into passing the authorization in its own way? Thanks a lot for the help! There are so many options it's quite overwhelming... -Don - Original Message - From: Leonardo Rochael Almeida
[Zope-dev] STX Bug ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, i have a possibly problem using unordered lists with structured text. See the exemple: titulo paragrafo noono onoonono ono oo noonononon o onononono ononono onononono onononon onononon ononononono onono. * Item 1. * Item 2. * Item 3. The STX processor of zope render a HTML code like this: ul lipItem 1./p/li lipItem 2./p/li lipItem 3./p/li /ul My question is: the p tags are correctly generated by STX? IS IT A BUG? In my application, i have some problems with this output because i used CSS styles that makes the presentation of HTML very ugly. ul liItem 1./li liItem 2./li liItem 3./li /ul If It is not a bug, how can i get a output like the output above? Thanks. - -- _ www._ _|__ / _ | |/_//_ / __ \/ __ `/ Fabiano Weimar dos Santos (Xiru) _ ___/ / / / / /_/ /X3ng Web Technology /_/|_//_/ /_/\__, / //.com.br -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8g824TqbDpNXhEbERAgDJAKCk3tDoOodBYs7qbUhEPbTmpQNhQgCgx2IU ms696jAYx5QHhV6VqYQiCF4= =ZJOD -END PGP SIGNATURE- ___ 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] STX Bug ?
- Original Message - From: Fabiano Weimar dos Santos [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 04, 2002 14:40 Subject: [Zope-dev] STX Bug ? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, i have a possibly problem using unordered lists with structured text. See the exemple: titulo paragrafo noono onoonono ono oo noonononon o onononono ononono onononono onononon onononon ononononono onono. * Item 1. * Item 2. * Item 3. The STX processor of zope render a HTML code like this: ul lipItem 1./p/li lipItem 2./p/li lipItem 3./p/li /ul That's fine HTML although I admit that it looks ugly. My question is: the p tags are correctly generated by STX? IS IT A BUG? In my application, i have some problems with this output because i used CSS styles that makes the presentation of HTML very ugly. ul liItem 1./li liItem 2./li liItem 3./li /ul If It is not a bug, how can i get a output like the output above? Not a bug but feel free to hack HTMLClass.py. - aj ___ 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] MonkeyPatching in the Core (was: Zope 2.6 planning)
What if, instead of the static list of callable info that the CP currently uses, Zope objects could register themselves as profilable? We would then make sure that the object types that CP handles now register themselves, but other products that we don't know (or have to know) about could register themselves too if they wanted. Think of this as consentual monkey-patching (hmm... may have to change this metaphor soon!). The products have to take some explicit action to be profilable, so it is not invisible in the code of the product. The hooks will continue to installed as-needed, so there is no performance issue. Thoughts? Bingo! seb ___ 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] STX Bug ?
I don't know the discussion but feel free to fix it (don't forget to update the unittests and the regression tests). Andreas - Original Message - From: seb bacon [EMAIL PROTECTED] To: Andreas Jung [EMAIL PROTECTED] Cc: Fabiano Weimar dos Santos [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 04, 2002 16:37 Subject: Re: [Zope-dev] STX Bug ? The STX processor of zope render a HTML code like this: ul lipItem 1./p/li lipItem 2./p/li lipItem 3./p/li /ul If It is not a bug, how can i get a output like the output above? Not a bug but feel free to hack HTMLClass.py. I recall a conversation about this 'feature' last year, and I thought it had been agreed to fix it. It's a bad way to render list items, because it is not good structural markup and will behave in unexpected ways with style sheets. Plus, it's particularly baffling because it's not how the pre-NG STX did it. I'll volunteer to fix this if no-one objects. seb ___ 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 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] Zope 2.6 project updated
Hi all - I'm glad to see a thriving thread on 2.6 features :) To try to keep things manageable, I've created a project in the fishbowl at: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ ...to start getting the effort organized. In particular, I spent some time today going through the call for contributors thread and harvesting the various proposals: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures I tried to capture who volunteered for what, but please look this over and let me know if I have you volunteered for something that you didn't mean to volunteer for :) You can also fix it yourself if you like (its a wiki). The next step will be to whittle down the proposals, so if anyone wants to add to the list (or volunteer themselves for something on it), now is the time. At this point there are as many items without volunteers as with, so please don't add any more proposals to the list unless you are also volunteering :) Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.361.1716 Zope Corporation http://www.zope.com ___ 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] MonkeyPatching in the Core (was: Zope 2.6 planning)
With respect to the overhead of inserting things into modules in the source code, Fred Drake (I think!) pointed out to me that constructs in the form if __debug__: ... are automatically removed by the parser when Python is run with the -O flag. Note that I am *not* sure how Zope performs when run with Python -O. However, assuming it does run OK, then it makes sense to put all sorts of conditional things into code which are disabled for performance when -O is passed on the command line to Python. Also note that I guarantee Zope will not run with Python -OO, as this removes doc strings, which the Publisher relies upon. At the time, I was pushing more for a slightly more complex form of run time diagnostic control without the overhead of continuous symbol lookup, e.g. ifcondition(bitmask): such that either all the bits in the bitmask were enabled in the current debugging context, or at least some of them were. Then again, I effectively want exits in Python's ceval.c at various locations to be able to do magic without the burden of more interpretation. For instance, there are actually some clever things you can do with the new C level profiler, but 'stealing' the profiler to do other magic is not really the right approach. -- Matt Kromer Zope Corporation http://www.zope.com/ ___ 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 2.6 project updated
Brian Lloyd wrote: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures I tried to capture who volunteered for what, but please look this over and let me know if I have you volunteered for something that you didn't mean to volunteer for :) You can also fix it yourself if you like (its a wiki). To stir things up some more: for my part, I don't like seeing we need feature X without the corresponding I'll volunteer to write feature X. Items that dont get contributed probably are not going to survive. It's probably also worthwhile to consider how do I make the least intrusive contribution as well, such that we don't end up with highly-conflicting contributions. Products form fairly unintrusive contributions. Changes to ZServer cause headaches. :) I *really like* bugfixes or feature fixes though. -- Matt Kromer Zope Corporation http://www.zope.com/ ___ 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] improved logging
Florent Guillaume writes: Except that syslog (with all its faults) is designed for reliable logging, which means that if you send to your log 1000 lines, syslog will sync 1000 times thus trashing your disks. Decent syslog implementations (such as the one distributed with SuSE Linux) let you configure whether a log file will be synched after every message. Dieter ___ 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'm locked out of managing my CMF folders, because it asks me to log in and the password doesn't work.
Don Hopkins writes: ... I have seen this often when there was an exception in the action box. In this case, I was able to analyse the problem in one of the following ways: 1. disable cookie authentication You will then get a browser login request. Abort it. And it will show what object could not be accessed. 2. Print the exception in ZPublisher.Publish near line 106 after the tansactions_manager.abort(): import traceback; traceback.print_exc() But maybe, you password is indeed incorrect. Then become an emergency user and fix the problem (learn more about the emergency user on Zope.org). Dieter ___ 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] MonkeyPatching in the Core (was: Zope 2.6 planning)
On Tue, 5 Mar 2002 07:20, Brian Lloyd wrote: Seb wrote: Pros - a tiny performance gain Cons - unpredictable interaction with future products; not a well-known method of distributing products; not easily discoverable What if, instead of the static list of callable info that the CP currently uses, Zope objects could register themselves as profilable? We would then make sure that the object types that CP handles now register themselves, but other products that we don't know (or have to know) about could register themselves too if they wanted. This doesn't really address the concern I have with regard to the con given above. The main reason is that the call profiler's monkeypatching is done potentially many times, and it performs an unpatch as well as a patch. This muckery can potentially really stuff over other components that also monkeypatch the same methods. Especially if they _also_ perform unpatching. I'm not sure the consentual monkeypatch approach really solves this issue... and if the product has to be modified to make it register itself with the profiler, why not just have it include the (very simple) calls to the profiler instead? Richard ___ 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] MonkeyPatching in the Core (was: Zope 2.6 planning)
Brian Lloyd wrote What if, instead of the static list of callable info that the CP currently uses, Zope objects could register themselves as profilable? We would then make sure that the object types that CP handles now register themselves, but other products that we don't know (or have to know) about could register themselves too if they wanted. This would resolve the problems, yes. It's a nice approach to take, and it also allows the object to register a different method to be patched. Think of this as consentual monkey-patching (hmm... may have to change this metaphor soon!). Call it gorilla-patching - it's like monkey-patching.[1] The products have to take some explicit action to be profilable, so it is not invisible in the code of the product. The hooks will continue to installed as-needed, so there is no performance issue. This would suggest that the CallProfiler shouldn't be an add-on product, then, but installed in lib/python ? What's the best approach there? Rich didn't get any response on zope-coders about this... Anthony [1] Seagoon: Here! Have a gorilla. Eccles: Oh! Thanks. Grams: [Two gorillas fighting, or if you can't get that, lions.] Eccles: Oww! Oww! Ooh! Oww! Hey! These gorillas are strong. Here! Have one of my monkeys -- they're milder. -- http://www.residents.com/Goons/napoleon.piano.html -- Anthony Baxter [EMAIL PROTECTED] It's never to late to have a happy childhood. Seagoon: Here! Have a gorilla. Eccles: Oh! Thanks. Grams: [Two gorillas fighting, or if you can't get that, lions.] Eccles: Oww! Oww! Ooh! Oww! Hey! These gorillas are strong. Here! Have one of my monkeys -- they're milder. ___ 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: MonkeyPatching in the Core (was: Zope 2.6 planning)
I have to say I agree, up to a point. I think that monkeypatching goes right to the very heart of the language - Python was written not just to allow it, but it's opperation almost encorages it (Sort of). HOWEVER, I am somewhat against a monkeypatch being made part of the core distribution (No disrespect to the authors of such products - me included), these should be optional downloads, up to the point that the code is rolled into the core codebase. The call profiler seems to be a very popular feature, and it seems to provide very useful information. It's not rock solid yet (I am sure I even remember it's author saying this a day or so ago), but it will be, and that is the point that it should be considered for rolling in - Possibly to replace the existing debug/profiling stuff, that seems to be somewhat overshadowed by it... Just my 2c (Or 0.02 E, take you pick) Adrian... -- The difficulty of tactical maneuvering consists in turning the devious into the direct, and misfortune into gain. - Sun Tzu - Original Message - From: Chris Withers [EMAIL PROTECTED] To: seb bacon [EMAIL PROTECTED] Cc: Richard Jones [EMAIL PROTECTED]; Casey Duncan [EMAIL PROTECTED]; Anthony Baxter [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 04, 2002 12:54 PM Subject: [Zope-dev] Re: MonkeyPatching in the Core (was: Zope 2.6 planning) seb bacon wrote: Pros - a tiny performance gain Cons - unpredictable interaction with future products; I'd rephrase that as a pro: Ability to work with products of the future, without the need to understand their inner workings... not a well-known method of distributing products; Urm... that I gotta disagree with... Tehre are now many such products for Zope... not easily discoverable What do you mean by discoverable? But perhaps my 'cons' are misplaced? Mostly, I'm uneasy that someone looking at ZPublisher code would have no way of knowing that CallProfiler hooks into it if it were monkeypatched. Yeah they would, 'cos CallProfiler will be well documented beforeit hits a release and will onyl come into play if explicity enabled. And if you explicitly enable it, you should read the documentation first... 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 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] CallProfiler (was: MonkeyPatching in the Core (was: Zope 2.6 planning))
On Tue, 5 Mar 2002 10:54, Adrian Hungate wrote: The call profiler seems to be a very popular feature, and it seems to provide very useful information. It's not rock solid yet (I am sure I even remember it's author saying this a day or so ago) Any idea what I might have been referring to? I don't recall having said anything about the profiler in any forums except these about any topic other than integrating it into the core. And certainly nothing about stability. Mind you, I was quite ill late last week, and I might have unwittingly sent some email off in my delerious state... :) Richard ___ 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: MonkeyPatching in the Core (was: Zope 2.6planning)
What about something like apple's Extension Manager, where you could disable/enable 'sets' of products? Though frankly, it's not too tough to just move the subdirectory somewhere and restart... but it would be a way to have a TTW way of configuring your Zope, and having the option of 'loading up' the distribution with optional stuff (which might be disabled by default?) From: Adrian Hungate [EMAIL PROTECTED] I think that monkeypatching goes right to the very heart of the language - Python was written not just to allow it, but it's opperation almost encorages it (Sort of). HOWEVER, I am somewhat against a monkeypatch being made part of the core distribution (No disrespect to the authors of such products - me included), these should be optional downloads, up to the point that the code is rolled into the core codebase. ___ 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 on Windows?
I have run an old version of ZEO on Windows successfully, I dont know which version that was (or which version you are refering to). I had to fix a couple of lines, but then these were patched not long after. In fact a quick google search for ZEO Windows pops up the very email... http://lists.zope.org/pipermail/zodb-dev/2001-March/000591.html - Original Message - From: David Ascher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 01, 2002 9:30 PM Subject: [Zope-dev] ZEO on Windows? I'm having some issues trying to use ZEO on Win2k w/ Apache and Quixote. Specifically: - if I happen to call client code before the server is running, I get a python process which is completely hung -- I can't even kill it from the process monitor w/ administrator privs. Every client request will result in a hung Python process. - if the server is already set up (as should normally be the case), sometimes the client request goes through, sometimes it doesn't. I'm not getting any tracebacks or info in the Apache logs. I could write up some simple Python test cases, but the documentation makes me wonder if ZEO works on windows at all (e.g. the unqualified reference to unix domain sockets =). so... Does ZEO work on Windows? Any gotchas? --david ___ 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 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 )
