Re: [Zope-dev] Call Profiler
This is really cool. The implementation looks pretty reasonable too! Definitely useful for folks doing development and wondering why their scripts take > 2 secs to run! ;-) I think this will be in many folks' toolbags soon. - 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] Call Profiler
On Fri, 1 Feb 2002 14:10, Anthony Baxter wrote: > >>> Richard Jones wrote > > > > I've just announced our Call Profiler product on zope.org and the zope > > announce list (waiting for people in different timezones to authorise > > them :) ( http://www.zope.org/Members/richard/CallProfiler/ for the > > impatient) > > ... Richard had made my initial vile hack actually work in a way that > didn't cause bleeding from the brain) No comment ;) > Unfortunately, the existing python profiling stuff is at too low a > level to be useful - this stuff really fills a need. Although being able to tie this into the python profiler would _rock_ in terms of profiling websites that use a mix of DTML/ZPT and Python products. Even it it's just to get the timing marks where the higher level stuff like DTML/ZPT calls out to the python code (ie. getting timing for the python calls at the highest level) > Plus, if it's integrated into Zope, Richard doesn't have to spend work > time on maintaining it :) But I do have time for screenshots - there's some up on the product page now for those who have a short curiosity span :) 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] Call Profiler
>>> Richard Jones wrote > I've just announced our Call Profiler product on zope.org and the zope > announce list (waiting for people in different timezones to authorise them :) > ( http://www.zope.org/Members/richard/CallProfiler/ for the impatient) >From my point of view, this is a critical piece for Zope - right now, trying to work out what's going on in a Zope page render is somewhat painful. We found once we'd turned this onto our production code (and Richard had made my initial vile hack actually work in a way that didn't cause bleeding from the brain) we were able to very very quickly spot a whole lot of stuff that was Just Not Doing The Right Thing. Unfortunately, the existing python profiling stuff is at too low a level to be useful - this stuff really fills a need. Plus, if it's integrated into Zope, Richard doesn't have to spend work time on maintaining it :) Anthony ___ 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] Call Profiler
I've just announced our Call Profiler product on zope.org and the zope announce list (waiting for people in different timezones to authorise them :) ( http://www.zope.org/Members/richard/CallProfiler/ for the impatient) In a nutshell, it patches the rendering guts of DTMLMethod, ZSQL, etc. and the ZPublisher so that we can get timing marks for requests as the calls are made. The patching is quite simple (once I got the hang of it ;) and reversible, and means that there's no changes required to the Zope core to enable the testing (which our initial versions did). It does pose a question though: would it be better to have support for this stuff in the core, or is it OK for a product like this to dynamically patch the call methods when it needs to? On one hand, the performance hit when dynamically patching the methods is zero when the product is not "active", but it does mean diddling with methods that really probably should be left alone. On the other hand, having changes to the core code to test for profiling being enabled introduces a small performance hit even when profiling is not activated. Any comments? 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] Dynpersist.so and makefile.pre.in
On 1/31/02 5:02 PM, "Ed Colmar" <[EMAIL PROTECTED]> wrote: > Huh... > > I found a makefile.pre.in, but I'm seeing tons of errors on "make" > > There was some note in the Zpatterns docs that after zope2.2 the dynpersist > woudn't be neccesary anymore. Is this true? It seems like it should be true. To the best of my knowledge, DynPersist got around the issue that it wasn't all-too-safe to override __getattr__ and __setattr__ for persistent objects. I know that this issue was fixed in the ZODB, probably around the time of Zope 2.2. However, even in the most recent ZPatterns releases (as maintained in the 'TransactionAgents' package), some Python code still seems to depend on DynPersist. > Are there any other (simple) solutions to doing authentication through a SQL > DB? Jumping through hoops to get Zpatterns working seems silly when all I > need is basic authentication. Though it would probably make my life easier > once I figure it out. You might want to check out http://www.zope.org/Members/otto/userdb, although it looks rather old. If it's what I think it is, it's based on something done at Zope Corp back in the Principia (Zope before it was Zope) days. UserDb was a pretty simple system that might work for you if it still works. Much easier than anything ZPatterns based - especially given that ZPatterns has gone relatively unmaintained for so long. -- Jeffrey P Shell www.cuemedia.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] Dynpersist.so and makefile.pre.in
Huh... I found a makefile.pre.in, but I'm seeing tons of errors on "make" There was some note in the Zpatterns docs that after zope2.2 the dynpersist woudn't be neccesary anymore. Is this true? Are there any other (simple) solutions to doing authentication through a SQL DB? Jumping through hoops to get Zpatterns working seems silly when all I need is basic authentication. Though it would probably make my life easier once I figure it out. Anyways... Thanks for the assistance! -ed- - Original Message - From: "R. David Murray" <[EMAIL PROTECTED]> To: "Christian Theune" <[EMAIL PROTECTED]> Cc: "Ed Colmar" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, January 31, 2002 9:05 AM Subject: Re: [Zope-dev] Dynpersist.so and makefile.pre.in > On Thu, 31 Jan 2002, Christian Theune wrote: > > On my systems it is located at somewhere like > > > > /usr/lib/python(version)/config/Makefile.pre.in > > or > > /usr/local/lib/python(version)/config/Makefile.pre.in > > Just an FYI, Makefile.pre.in no longer exists (as far as I can > tell) under python 2.2. > > --RDM > > > ___ > 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 )
Re: [Zope-dev] segfaults persist in 2.4.4b1
Leonardo Rochael Almeida wrote: >On Thu, 2002-01-31 at 15:11, Matthew T. Kromer wrote: > >>Well, I think I mentioned this before, but you do NOT want >>--with-pymalloc on in your Python build. I'm just about 100% positive >>that ExtensionClass derived objects will not play well with pymalloc. >> > >Indeed you have, I just mentioned it because I was mentioning my next >steps and I suspect *the Python that comes with binary Zope 2.4.4b1* is >compiled with it. > > []'s Leo > The linux and solaris binaries should not; the Windows binary ... might. For the Windows binary, we use the regular PythonLabs distributed Python212.exe files. And I dont actually know if it uses pymalloc or not. -- 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] segfaults persist in 2.4.4b1
On Thu, 2002-01-31 at 15:11, Matthew T. Kromer wrote: > > Well, I think I mentioned this before, but you do NOT want > --with-pymalloc on in your Python build. I'm just about 100% positive > that ExtensionClass derived objects will not play well with pymalloc. Indeed you have, I just mentioned it because I was mentioning my next steps and I suspect *the Python that comes with binary Zope 2.4.4b1* is compiled with it. []'s 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/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Urgent help required
Andy McKay wrote: >>It uses the configuration set on the ODBC DSN I think. At least that is what >>appears to happen. >> > >AFAIK ZODBCA is only single threaded though, ZmxODBCA should be a better bet. > >There is a Zope-DB list BTW and Matt "Mr Zope RDBMS guru" Kromer hangs out there >a lot. >-- > Andy McKay > I *definately* recommend ZmxODBCA over what we have -- we have some SWIG generated code that's old and crufty -- it works, but it isn't being maintained. I do not have the time to vest in creating a new ODBC adapter for Zope. -- 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] Re: [Zope-CMF] How to get Type in manage_afterAdd?
Hmmm, probably I should have used the term "factory" instead of "constructor" in that last mail... Florent Florent Guillaume <[EMAIL PROTECTED]> wrote: > [sent to zope-dev] > > This problem is due to a deep bug in the current implementation of the > Types Tool: a created object has no way to know its portal_type during > construction (the constructor doesn't have this information, thus nor > __init__ nor the hooks like manage_afterAdd can have it). > > I thought that this bug was already in the Tracker but I don't find it. > Anyone knows ? > > Anyway I'd propose the following: we need, in constructInstance, to > somehow pass the portal_type to the object constructor. Unfortunately > this has to be backwards-compatible with all the constructors out there > that don't know about it. I see two possible ugly solutions to do it: > > - do "constructor.__portal_type = portal_type" before calling > constructor(...), and the constructor does something like: > def manage_addFoo(...): > try: > portal_type = manage_addFoo.__portal_type > manage_addFoo.__portal_type = None > except: > portal_type = None > ... > > - in constructInstance, use introspection (getargspec) to look > if the constructor accepts a portal_type=xxx named parameter, > and pass it if it does. > > Anyone sees something cleaner ? :-) -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 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[2]: [Zope-dev] Urgent help required
> It uses the configuration set on the ODBC DSN I think. At least that is what > appears to happen. AFAIK ZODBCA is only single threaded though, ZmxODBCA should be a better bet. There is a Zope-DB list BTW and Matt "Mr Zope RDBMS guru" Kromer hangs out there a lot. -- Andy McKay ___ 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: [Zope-CMF] How to get Type in manage_afterAdd?
[sent to zope-dev] This problem is due to a deep bug in the current implementation of the Types Tool: a created object has no way to know its portal_type during construction (the constructor doesn't have this information, thus nor __init__ nor the hooks like manage_afterAdd can have it). I thought that this bug was already in the Tracker but I don't find it. Anyone knows ? Anyway I'd propose the following: we need, in constructInstance, to somehow pass the portal_type to the object constructor. Unfortunately this has to be backwards-compatible with all the constructors out there that don't know about it. I see two possible ugly solutions to do it: - do "constructor.__portal_type = portal_type" before calling constructor(...), and the constructor does something like: def manage_addFoo(...): try: portal_type = manage_addFoo.__portal_type manage_addFoo.__portal_type = None except: portal_type = None ... - in constructInstance, use introspection (getargspec) to look if the constructor accepts a portal_type=xxx named parameter, and pass it if it does. Anyone sees something cleaner ? :-) Florent Jon Edwards <[EMAIL PROTECTED]> wrote: > I've created a new product - "organisation", which has a property > "org_type", which I set in manage_afterAdd by doing - > > self.org_type = self.portal_type > > - which then gets catalogued. Works fine for the basic product, but if I use > the Portal Types tool to make a new type "Hospital", using "organisation" as > the underlying default type, it should use "Hospital" as the "org_type". > > I've tried everything I can think of in place of self.portal_type > (meta_type, Type(), _getPortalTypeName(), etc.) but I still get > "organisation" instead of "Hospital" in the catalog. > > There must be a way to get it, cos when I view the catalog entry for the new > item, Type is "Hospital", but org_type stubbornly refuses to find that > value! Can someone please save me from pulling out any more hair? :-) > > Also, when creating a product, what's the best-practice for setting > "meta_type =" and "portal_type =" in the class? Some products use both, some > neither, some use one but not the other! > > TIA > > Cheers, Jon > > Jon Edwards > Pricom Ltd > www.pricom.co.uk > > > ___ > Zope-CMF maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-cmf > > See http://www.zope.org/Products/PTK/Tracker for bug reports and feature > requests > -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 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] segfaults persist in 2.4.4b1
Leonardo Rochael Almeida wrote: >Hi, > >I previously had a segfaulting Zope 2.4.3 installation, whose segfaults >I traded for a leak when I disabled the cycle-gc. > >I just installed Zope 2.4.4b1 (binary) hoping it'd fix the segfaults so >that Zope could go back to not leaking, but they persist. Disabling gc >in this new version stops the segfaults, but restarts the leak, just >like before. Basically, it feels like the problems are the same for me. > >I'm now in the process of recompiling python 2.1.2 --without-pymalloc to >see if it solves the problem but I suspect it'll only make Zope crash >less instead of stop crashing (like it did last time). > >If anyone has any tip (or an automatic stack dump generator for running >zope processes) > Well, I think I mentioned this before, but you do NOT want --with-pymalloc on in your Python build. I'm just about 100% positive that ExtensionClass derived objects will not play well with pymalloc. -- 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] Dynpersist.so and makefile.pre.in
On Thu, 31 Jan 2002, Christian Theune wrote: > On my systems it is located at somewhere like > > /usr/lib/python(version)/config/Makefile.pre.in > or > /usr/local/lib/python(version)/config/Makefile.pre.in Just an FYI, Makefile.pre.in no longer exists (as far as I can tell) under python 2.2. --RDM ___ 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] Dynpersist.so and makefile.pre.in
On my systems it is located at somewhere like /usr/lib/python(version)/config/Makefile.pre.in or /usr/local/lib/python(version)/config/Makefile.pre.in On Wed, Jan 30, 2002 at 10:25:59AM -0800, Ed Colmar wrote: > Hey! > > I know I've done this before, but for some reason it's eluding me. > > I'm on a brand new box with a fresh 2.4.3 zope. > > I am trying to get sql authentication working with loginmanager/Zpatterns > > I can't seem to find a "makefile.pre.in" on my system. I have python and > python-devel both from RPM, and a regular install of zope. should be enough. > > I tried using a makfile.pre.in from some other package (found on the web) > but got tons of errors. > > Where would I find a copy of this file for my platform? Which > incedentally is Mandrake 8.1. Anyone have one that might work. Do I need > to build python from the source? no, just find the Makefile.pre.in for you build ;) > > Thanks! > > -ed- > -- Christian Theune - [EMAIL PROTECTED] gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b']) msg09268/pgp0.pgp Description: PGP signature
[Zope-dev] segfaults persist in 2.4.4b1
Hi, I previously had a segfaulting Zope 2.4.3 installation, whose segfaults I traded for a leak when I disabled the cycle-gc. I just installed Zope 2.4.4b1 (binary) hoping it'd fix the segfaults so that Zope could go back to not leaking, but they persist. Disabling gc in this new version stops the segfaults, but restarts the leak, just like before. Basically, it feels like the problems are the same for me. I'm now in the process of recompiling python 2.1.2 --without-pymalloc to see if it solves the problem but I suspect it'll only make Zope crash less instead of stop crashing (like it did last time). If anyone has any tip (or an automatic stack dump generator for running zope processes) -- 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] Running out of options
Erik Stephens wrote: >Hello, > >This is regarding the Zope restarting problem that's been talked about >recently. We've tried TONS of different configurations: > > Python 2.1.x (with threads and with & without pymalloc) > Zope 2.4.x (built wo_pcgi & binary installs) > ZMySQLDA (with & without the Kromer patch) > MySQLdb (built against the different flavors of Python) > >Here's our latest attempt at a stable Zope: > > - Python 2.1.2 (with threads and with pymalloc) > - Zope 2.4.4b1 (wo_pcgi build) > - ZMySQLDA (latest CVS checkout with and without the Kromer patch >applied to db.py) > - MySQLdb (latest CVS checkout build against Python 2.1.2) > - TinyTable product (one of our patches applied) > - A customizations product for removing specific restrictions on >through-the-web components. > >Does anyone know for sure if this is a problem with ZMySQLDA or with >Zope? > >We've been hearing talk that once 2.4.4 is released, all will be good >in the hood. Are we missing the boat somewhere? Can anyone confirm >that a similar setup fixed their Zope restart problems? > >Are there any magic option values (num threads, disable watchdog) we >can be passing to z2.py that might help stop the bleeding? > >If it is confirmed that 2.4.4 is still hosed, then what is the >recommended course of action? Down-grade to Zope 2.3.3? Cross our >fingers and wait? Which is more stable right now, Zope 2.5.0 or Zope >2.4.4? > >Thank you, >Erik > Try starting with -t 1 (single-threaded mode) and see if that helps. It won't actually hurt your performance very badly unless you are compute or I/O intensive. Andy Dustman has a better fix than mine in the works; he posted something about it on the main Zope list today. BTW, you said in your message above you use --with-pymalloc. That's almost for sure going to cause problems with extension classes. Use --without-pymalloc so that the custom allocator gets left out. -- 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] CMF 1.2 - Can I convert Files to PortalFiles
You can use FTP to upload the files - check out which port your Zope FTP server is running on and have a look there. Investigate the content_type_registry to see how to link certain file types to particular CMF types. Sorry for the brevity of the mail, but hopefully that points you in the right direction. seb On Wed, 2002-01-30 at 17:58, [EMAIL PROTECTED] wrote: > I have a number (100plus - not too many but enough) of objects of type File > in my zope that aren't visible under CMF 1.2. Is there any easy way to > convert these into objects of type PortalFile without having to upload all > of the content again. > > I have tried importing them, but the CMF site catalog is not updated > automatically. > > I understand that I might have to add in the new metadata. I just want a > way to avoid the uploads. > > I'm not a python programmer, so please don't tell me that I could write a > script in a minute, but you could send me the script. > > John Knutson > Candle Corp > England > > > ___ > 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 )
