Re: [Zope-dev] Bug days
Europe late afternoon = EST morning How would 1700 UTC (GMT) be for most people? People generally asleep between 12am and 6am. Therefore the best time is logically 2am or so central Pacific time (affecting very few) This is corresponds to 2pm GMT, 9am US EST, etc Adam ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6 planning - call for contributors!
FYI, everyone who's following this: I have hijacked http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration for this purpose. :-) Awesome. Exactly how I'd like the default zope install to be structured. :-) Adam ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: more on the segfault saga
Hi Martijn, We're basically just trying to construct traps to try to identify a smoking gun. The upside is, if it works, we'll be able to fix the bug very quickly. However, its based on assumptions about the exact nature of the bug -- so each trap I write essentially is making a hypothesis and then testing it. Because Leo can get the crash very quickly, if you have a difficult time reproducing it, you don't need to spend a lot of effort trying to keep up with my traps. On Friday, March 15, 2002, at 06:19 AM, Martijn Jacobs wrote: Hello Leo, Matt, Brian, I'm on it. Will send results when they're available. If anyone wants to talk to me during the period, I'll be on IRC. If you need any assistance for anything, I'm at your service Which channel/server are you on IRC? Did somebody succeed reproducing the crash? We try the best we can to make a reproducable testcase, but Zope doesn't want to crash here... The clients who use the production Zope which crashes are all using Active Desktop (I know :( ), could that be of any matter? Technically it's insane if it does matter, but you never know... I'm out of capabilities right now, don't know what to do anymore, so I hope the bug will be found soon. regards, martijn ___ 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] Bug days
I don't think we can do the geographic coverage without making it too painful. We should split bug days in half; a few hours in the morning and a few hours in the afternoon. --Paul Brian Lloyd wrote: Hi all - In an effort to better keep up with the collector, I'd like to throw out the idea of doing periodic bug days (a la the mozilla bug days), where Zope geeks and committers would get together on IRC and spend a few hours knocking out issues. I've drafted a preliminary bug day manifesto that describes how it would work in a little more detail: http://dev.zope.org/CVS/BugDays I'd like to hear what people think, as well as work out a few logistics: - Given the wide geographic area that committers (and patch submitters) cover, what is a good time of day for a bug day to start / end (where start and end are always going to be fuzzy, of course). - Would it be better for bugdays to be ad-hoc, or should we try to set up regularly-scheduled bugdays at some reasonable interval? If the latter, we need to come up with a day / time that is agreeable to as many of the committers as possible. Thoughts? -Brian ___ 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] RE: Object links/references
You told us that you will be refining Zope 2.6 plan. ProposedFeatures table contains an Implement links (object references) entry by Mario Valente. I've created SoftLink proposal in ProposalsWiki . These works appear related. We (Mario and me) discussed and decided that we can dedicate some efforts to make it working (Mario has working code already). The plan is to release Patch-like product for Zope 2.3, 2.4 and 2.5 to get feedback. And to incorporate functionality into Zope 2.6 without patching functionality. Please give us your recommendations / feedback / instructions for us, To be honest, I'm a little worried about the approach. Links can be very, very hard to get right (which is why they are not in the core now), especially with regard to security issues. Creating an object that impersonates another object is tough, because there a potentially unknown number of contracts that the impersonator must fulfill. This usually leads to problems :( For the SoftLink proposal in particular, the main problem you note in the proposal is that you want to avoid 404's when people go to a resource that has been moved. It seems to me that the best way to address that problem is to have a RedirectObject that you could add with the name of the object that was moved. It would _not_ try to impersonate the moved object, but when you went to view the object, you would be automatically redirected to the new location. That would avoid a lot of the problems of the link approach, with little overhead. Note that I'm not saying that object links are not a valid requirement, but it sounds like the problem you want to solve is definitely different than Mario's. In many ways, the correct required behavior of a link depends on what you expect to be able to do with it (the problem you are trying to solve). I can easily imagine that right behavior of a link if your main goal is to avoid 404s will _not_ be right if you are using the link in other ways. For example, if you went to a URL that had been moved, what is the right context that it should render itself in? I highly suspect that the right context is the place that it was moved to, rather than the context where the link lives (redirect semantics). That is basically the opposite of another possible usage of a link, where you would want to use the link to virtually include an object into a different context. I submit that trying to do both is too complex and probably too insecure as well (as managers of security would have to evaluate N possible security scenarios, most of which are not readily visible to them at the time they are setting up security). I think that the RedirectObject approach could sidestep all of these issues and provide an incremental step while still solving your problem. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 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] Modifying a menu
but gotta dive in and make some changes to this menu. It depends on what type of change you want to make. This menu does not exist in it's finished form anywhere in the code, but it it's contents are created each time you view it, and modified depending on several parameters. So modifying it is not just a question of finding out where it's created. ___ 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: more on the segfault saga
On Fri, 2002-03-15 at 08:19, Martijn Jacobs wrote: Hello Leo, Matt, Brian, I'm on it. Will send results when they're available. If anyone wants to talk to me during the period, I'll be on IRC. If you need any assistance for anything, I'm at your service Which channel/server are you on IRC? The official unofficial Zope place on irc is #zope at irc.openprojects.net. Lots of cool and very knowledgeable people hang out there. I'll be there today while I apply Matt's incref patches and run Zope I also have a very demanding client who goes bezerk every time the site is down, so I recomend you do the following, if you want to help with debugging (this assumes you run Zope behind a proxy server such as apache or squid): * Install ZEO on your current Zope and configure both the ZEO Client and Server on the same machine serving your site. Only the ZEO Client should get the segfaults and it restarts much faster (less than 10 secs, usually) than in standalone mode. * Open a source Zope package in another directory. Open a Python source package next to it. Configure Python to install it's files inside this Zope tree (./configure --prefix=/path/to/Zope-src). Apply Matt's patches, make and make install. Install ZEO in this instance but only configure the ZEO Client, making it listen in a different port from the other Zope. Copy over all the external methods and extra products, and make it access the other instance ZEO Server. Don't forget to REDIRECT STDERR TO A FILE (the best way is to redirect stderr to stdout and append stdout to a file). Start it and check that it's working as expected. * Keep two configuration files of your frontend proxy around: one pointing the site to the original Zope and another pointing the site to the instrumented Zope. When you want to test the crashes, switch the conf. files around and reload the proxy. * Report everything you find in Zope stderr. * If you want to increase the perceived stability of your site, put the two following lines somewhere in the original Zope z2.py: import gc gc.disable() It should stop crashing, but it'll start leaking instead. If the leak isn't so severe that it allows you to restart only once a day, in the period of least traffic, then leave it that way. Having ZEO Client will ensure you have the least amount of downtime possible in this restart. -- 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 )
[Zope-dev] Zope crashes: Tim Peters reports potential problem
Tim Peters reports on comp.lang.python: [Martin v. Loewis] The garbage collector runs while having the GIL, so it does not need to be thread-safe. There's still a vulnerability here: gc *assumes* the GIL is held when _PyObject_GC_Malloc gets called, and doesn't verify that the GIL is in fact held. A rogue extension module could violate this precondition without triggering a predictable error (and then random segfaults would be likely). Maybe, we should check for this, too. 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 )
[Zope-dev] Re: typo in HTTPResponse.py
Christian Theune wrote: Hmm. Is it possible to implement some option to turn this off? I just checked in the ability to use HTTP_TRACEBACK_STYLE to control the appearance of tracebacks in non-debug mode errors: '' (default): Place it in an HTML comment 'none': Omit it 'plain': Include it as plain text just as in debug mode. 'js': Show a sect; that expands into the traceback when clicked. Cheers, Evan @ 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 )
