Re: [Zope-dev] makerequest issues
On Tue, Apr 04, 2006 at 08:09:05PM +0200, Stefan H. Holek wrote: > This looks fine to me because the world ends at parent. Your earlier > example wrapped an object that was in the middle of an acquisition > chain (IIRC), no, I think you invented that :) > which I am not sure I like. You are safe to wrap the > top-most object, be it a true "app" or not. OK. In that case, 2057 really *is* a bug. http://www.zope.org/Collectors/Zope/2057 -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TCP CLOSE_WAIT leaks
Alan Milligan wrote at 2006-4-4 21:19 +1000: >Dieter Maurer wrote: > >> Looks as if your Python were compiled without debugging symbols. >> You will get much better tracebacks (easier to understand), >> when you rebuild your Python with debugging symbols. > >But of course, it's a production system :( - temporarily installing >python-debuginfo ... Debug symbols do not increase the runtime. They only make the binaries (considerably) larger. You must also recompile the Zope extensions (as they compile the same way, Python has been compiled). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] makerequest issues
The one in ZopeTestCase.utils is also meant to play with startZServer (same module). I agree that the one in Testing.makerequest could probably gain ACTUAL_URL, and maybe even the request._steps hack to make URL1 and friends available... However, I have not seen these URL vars used anywhere but templates and DTML. ZTC adds them because it's used quite heavily for integration and functional testing(*). Also note that the values are faked, i.e. they are present but contain dummy values. In real-life they would be maintained by traversal, and no traversal takes place in unit tests. If you use ZTC you will automatically get an app object wrapped by utils.makerequest. If you don't use ZTC, I guess it depends on whether you think you will need ACTUAL_URL often enough to warrant adding it to Testing.makerequest. I don't think that's the case but YMMV. Stefan (*) To be honest they where likely added for Plone, now shoot me. On 4. Apr 2006, at 17:37, Paul Winkler wrote: Stefan, do you have any insight into my first question? I wrote: 1) there is a "makerequest" function in both Testing/makerequest.py and Testing/ZopeTestCase/utils.py. They are subtly different. Is there a deliberate reason for this? I notice that ... (snip) the one in makerequest.py lacks an ACTUAL_URL. If there's no reason for the implementations to differ, I can delete one definition and just import the other in its place. -- Anything that happens, happens. --Douglas Adams ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] makerequest issues
On 4. Apr 2006, at 16:53, Paul Winkler wrote: Hmmm, but unit tests very often don't reflect "reality" - deliberately! Because "reality" is Too Much Stuff. True enough. Any other opinions on this? Do we really need to require an App at the root any time we want to acquire REQUEST? That seems kind of arbitrary to me when any acquisition-enabled object would do. I've inherited a test suite that has a lot of stuff like: parent = makerequest(Folder()) ... and I don't see anything wrong with that in principle, but if the concensus is that Stefan's right, I'll bow to that. This looks fine to me because the world ends at parent. Your earlier example wrapped an object that was in the middle of an acquisition chain (IIRC), which I am not sure I like. You are safe to wrap the top-most object, be it a true "app" or not. Stefan -- Anything that happens, happens. --Douglas Adams ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Hunting down objects without classes...
Hi All, I'm currently plagued by the following annoying: ZODB Could not import class 'BTree' from module 'BTree' What's the recommended way of tracking these down? Is there anything we can do to make the logged message give more info about where the object is? I eventually stab-in-the-dark'ed it on this one and found the offending object in the root dictionary of a storage I was mounting some stuff from... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] makerequest issues
Stefan, do you have any insight into my first question? I wrote: > 1) there is a "makerequest" function in both Testing/makerequest.py > and Testing/ZopeTestCase/utils.py. They are subtly different. > Is there a deliberate reason for this? I notice that ... (snip) > the one in makerequest.py lacks an ACTUAL_URL. If there's no reason for the implementations to differ, I can delete one definition and just import the other in its place. -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] makerequest issues
On Sat, Apr 01, 2006 at 01:07:35PM +0200, Stefan H. Holek wrote: > I don't think makerequest is intended for wrapping anything but the > root application object. Putting the RequestContainer on arbitrary > objects doesn't feel right and certainly isn't how Zope does it, i.e. > you get a test fixture that doesn't reflect "reality". > > NotABug/WontFix ;-) Hmmm, but unit tests very often don't reflect "reality" - deliberately! Because "reality" is Too Much Stuff. Any other opinions on this? Do we really need to require an App at the root any time we want to acquire REQUEST? That seems kind of arbitrary to me when any acquisition-enabled object would do. I've inherited a test suite that has a lot of stuff like: parent = makerequest(Folder()) ... and I don't see anything wrong with that in principle, but if the concensus is that Stefan's right, I'll bow to that. -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TCP CLOSE_WAIT leaks
Dieter Maurer wrote:
> Looks as if your Python were compiled without debugging symbols.
> You will get much better tracebacks (easier to understand),
> when you rebuild your Python with debugging symbols.
But of course, it's a production system :( - temporarily installing
python-debuginfo ...
>
> The following GDB macros can be used to help in the analysis.
> "pfr" can be called in frames "eval_frame" to learn
> about the Python frame.
>
> def ps
> x/s ({PyStringObject}$arg0)->ob_sval
> end
>
Dieter, I don't know where you manage to find this stuff!!
Have stuck it in my .gdbinit and am knocking myself out with it...
Cheers, Alan
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug in Zope 2.9?
Stefan H. Holek wrote: This is an old ZODB, right? Yup, from Zope 2.7.6 ZGlobals is used by ZClasses. There used to be a time when ZGlobals was still a BTree when it should have been a BTrees.BTree. Then some migration code was added. It obviously never kicked in ;-) I suppose the error comes from the fact that BTree.so is now finally no longer part of Zope and your ZODB is old. Or something along these lines ;-) Well, I guess the thing gets rebuilt, otherwise it'd keep whining... Anyway, as long as you don't use ZClasses (and I seem to remember you, err, are pretty explicit about your dislike) forget about it. ...but given that I don't care, and it doesn't hurt anymore, I shall indeed forget about it. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
