Re: [Zope] Zope hangs in FreeBSD with plenty of memory and CPU resources
My understanding is that get/setrecursionlimit is for the python internal limit and is not an indicator of the THREAD_STACK_SIZE value, but in any case, yes, we have compiled with that option and I don't think that these would be the symptoms I would see for a stack size issue anyway, but thanks for the suggestion! -- Jean On 2/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hmmm...unfortunately, that's not the cause of the problem (I'm responding since I'm on the East coast, Jean is on the West, and he's asleep right now): [EMAIL PROTECTED]: ~$ python Python 2.4.3 (#2, Jul 2 2006, 16:14:54) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type help, copyright, credits or license for more information. import sys sys.getrecursionlimit() 1000 Though I do appreciate you forwarding that URL along, because a *lot* of people have suggested the Python stack issue, and until now, we've been unable to definitively rule that out. It's almost as good to clear one problem as the potential cause as it is to fix things. :-) Alex Kirk http://plone.org/documentation/faq/plone-on-bsd-python-stack Stefan On 26. Feb 2007, at 06:06, Jean Lagarde wrote: All, As a coincidence, that hang of Zope I mentioned in a message I posted yesterday has happened again today (second time), after a planned reboot. So here is a completely different issue from the memory one we've been discussing today. -- Anything that, in happening, causes something else to happen, causes something else to happen. --Douglas Adams ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Large jumps of memory use increase, and seeking overall understanding of memory use
On 2/25/07, Jens Vagelpohl [EMAIL PROTECTED] wrote: On 25 Feb 2007, at 00:05, Jean Lagarde wrote: I fully understand that Zope has to be restarted regularly This may be needed in a situation where you have a memory-hungry application (like Plone), but otherwise there is no general need to restart Zope regularly. My websites run months without restart, and they don't balloon in memory footprint. Thanks Roché and Jens. Yes, of course I meant this in the context of a public Plone application. That setting is a little bit misleading. These values represent targets, not hard limits. If a request pulls in a much larger number of objects into memory then that chunk of memory is now held by Python and won't be released, small target value or not. I also realize that. Although here the part that is not clear to me: Python holds that memory and won't release it to the OS, but can't it reuse it internally for future object loads? If it just keeps piling up objects in memory then even talking of a target is meaningless. You would need to study all the inefficiencies inherent in the content types you use, or all the nasty stuff that gets pulled in for viewing the site furniture shown for every page etc. Very few product authors out there put memory efficiency onto their priority list. P.S.: Memory is cheap. Cheap enough even for a non-profit. Go get some, or at least compare the cost of buying meory with the cost of countless hours you already have and may continue to spend on this. I'm not saying it's not a worthwhile task to try and get to the bottom of code inefficiencies, but keep the practical side in mind. Yep, that's what I keep on telling my co-administrators. As I said we actually have a lot more physical memory available, but I need their buy-in to increase the process limits on FreeBSD (I'm not succeeding by the way -- got an email this morning suggesting that Zope/Plone was a bad idea instead). And yes, I do allow crawlers and they are poking at all kinds of things. However, I was still hoping that someone would address the specific examples I provided to tell me if they are in the ballpark of what is commonly observed. I understand all the generalities, but I want to find out if something is broken in my particular implementation (possibly because of a bad practice on my part, etc.). I realize that looking at requests only does not give the whole picture (although I think it should be the largest source of Zope activity by far, am I wrong?), and that the descriptions I have provided are far from sufficient to do a complete determination, but let's just take the first one: Memory size was at 417640 (Kb) from 03:01:40 to 03:04:41 (for three minutes). During these three minutes, there were requests for our front page and apparently everything that accompanies it in Plone, i.e. the Plone scripts.jss, the style sheets, bunch of icon gifs, image thumbs the logo.jpg, etc. No memory increase during that time. At 03:05:41 I logged a memory increase to 422704. Between 03:04:41 and 03:05:41, there was a single request at 03:05:02 for an image_view_fullscreen. For those unfamiliar with Plone, that is one of the barest page served: Just an image and a link to go back to Plone (none of the Plone portlets, etc.). The access log shows that the number of bytes returned was 1137. There was no GET for the actual image. There were no memory increase whatsoever for at least the next 30 minutes, and there were a number of other requests during that time. Now I'm looking for hypotheses to explain the 5Mb memory increase. Here are some: 1) It's impossible. I must have made a mistake when I created that merged log (i.e. I must be looking at bad data). 2) The 5 Mb necessarily had to be used by the object cache to load one or more objects. Note that the image was 2 Mb at most, and the object itself can't be much larger, so even if it was loaded in the cache then, my question is what else was loaded? Or, does Zope/Python grab more memory for the cache in chunks? (I know that when appending to a Python list for example, the list will grow in chunks, but that's only space for pointers and not the actual objects pointed to.) 3) Part of the 5 Mb was probably used loading into the object cache, but a significant part could have been used elsewhere (but the increase was still due to the request). So my question then is: Where else would previously unallocated megabytes of memory be needed to serve a page? I am using the default CacheFu behavior for images, so I know it wasn't also RAM cached. 4) Could have been a coincidence, unrelated to the request. My question then is: What else could Zope be doing in the background, other than serve requests, that consumes megabytes of new memory. (We don't use Webdav, or ftp; I'm quite positive in any case that no imports were being made. I do use external editor, but that would show up in the HTTP access log). Cheers, Jean
Re: [Zope] Large jumps of memory use increase, and seeking overall understanding of memory use
On 2/25/07, Jens Vagelpohl [EMAIL PROTECTED] wrote: Comparing the number of bytes served during a request and how much memory is consumed is a bit naive. You have *no* idea what all needs to be touched internally to serve that one object. The weightier the framework you run on to of Zope, the higher the chance that you're touching a whole lot of more or less related objects to serve the one you're interested in. 1) Some degree of naivete when looking at a problem is sometimes useful 2) I stated the amount served (which has some value as a lower bound) but also granted that the actual image object might have been loaded to serve the page, and offered hypotheses (2) and (3) which could fit your explanation, so you're making me more naive than I was. Which begs the question if you read an understood what I wrote. 3) As for all the baggage that might be tied to an object in the ZODB, I will admit a lot of naivete there, but Zope's behavior should not be black magic. In the end, behavior has to be deterministic. So to say that one can have *no* idea of all that needs to be touched internally is a bit cynical; if I had sufficient time on my hands I could find out *exactly* what is being touched and where that memory is going. To throw ones hands in the air and say it's unknowable means that there's no way to know if something is broken. I will agree though that it may be very difficult to find out. 4) If by You have *no* idea you mean I, specifically, have no idea, but you do, then I partly agree (I know I don't, but I can't tell if you do from your answers so far). That's why I asked the questions. By the way it's not my intent to be hard on you Jens, on the contrary, I thank you very much for having taken the time to look at my questions. Your point is also well taken about just throwing memory at it and restarting before it runs out; I acknowledged that myself in my initial post. I am still the obstinate curious type who like to know though. Cheers, Jean ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Large jumps of memory use increase, and seeking overall understanding of memory use
Thanks Maciej, Yes, I am using CacheFu (a comprehensive caching product for Plone). I have Squid installed and ready to go (had it in the loop for a little while, but we were having all kinds of server instabilities at some point and I turned that one off to simplify things; we are more stable now so will turn it back on soon). Now I will again admit to some overall experience, with even HTTP, so correct me if I'm wrong: Without squid, I can either cache objects in a Zope memory cache or in browser caches using headers (that's part of what CacheFu helps to configure). However, neither of those prevents Zope from entirely stopping to get requests for cached content. For memory cached content, it will just be served faster and without requiring to access the ZODB, but it will look the same in the access log, and for browser cached content, everything will still have to be loaded every time a browser is opened anew or when a force reload is requested. Once Squid is up, then I do expect to see a lot fewer requests to Zope. Am I missing something major here? Cheers, Jean P.S. Just so you guys don't think that I am a complete newby, I did realize for example that I needed to add some templates by hand to a CacheFu rule, to what was being cached by default, to account for the Composite Page Plone product I am using (the templates for the slots were not being cached and caused significant performance issues). On 2/25/07, Maciej Wisniowski [EMAIL PROTECTED] wrote: I've not seen whole thread so sorry if I missed something. there were requests for our front page and apparently everything that accompanies it in Plone, i.e. the Plone scripts.jss, the style sheets, bunch of icon gifs, image thumbs the logo.jpg, etc. Maybe this is your specific configuration for tests, or something that you are aware of (if so then sorry for telling you something obvious) but in general things like css, js, images should be cached and not served (always) directly by Zope/Plone instance. Properly set up caching is a incredible performance boost. If you have no caching then serving all this stuff from zope may also cause bigger RAM usage as all these objects are read into memory by Zope when they're 'touched'. -- Maciej Wisniowski ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Large jumps of memory use increase, and seeking overall understanding of memory use
Fair enough about me blaming Zope when Plone is the likely issue (I actually meant the system as a whole, but that's my bad for not thinking and writing clearly). As for the effort required to get to the bottom of these issues, then we are in agreement; I won't take the time to do so either (at least not right now -- too many other prorities). I was hoping that someone had made that effort already and had reached some general conclusions they would share (other than the ones already offered). Thanks again, Jean On 2/25/07, Jens Vagelpohl [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25 Feb 2007, at 20:07, Jean Lagarde wrote: 3) As for all the baggage that might be tied to an object in the ZODB, I will admit a lot of naivete there, but Zope's behavior should not be black magic. In the end, behavior has to be deterministic. This is a wrong conclusion. This is not Zope behavior. The inefficiencies are in the applications/frameworks on top of Zope. So to say that one can have *no* idea of all that needs to be touched internally is a bit cynical; if I had sufficient time on my hands I could find out *exactly* what is being touched and where that memory is going. To throw ones hands in the air and say it's unknowable means that there's no way to know if something is broken. I will agree though that it may be very difficult to find out. I don't think it's cynical, I think it's the only sane thing to do for me. I cannot afford to spend days digging into Plone to find all the problems, I just live with a fact that Plone-based applications tend to be memory hogs, that's all. If you on the other hand have days to spend, good for you. 4) If by You have *no* idea you mean I, specifically, have no idea, but you do, then I partly agree (I know I don't, but I can't tell if you do from your answers so far). That's why I asked the questions. I don't have any specific idea where the memory goes, either. I choose the slimmest framework possible to base my sites on, so I hardly ever have to worry about this type of problem. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF4eI6RAx5nvEhZLIRAh0WAKC41TGWGVEH2/vU0/o8E81uLohL+QCdG268 /7pDNta40mEQ8Ug+w7G1AaE= =Ns5I -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Large jumps of memory use increase, and seeking overall understanding of memory use
On 2/25/07, Jens Vagelpohl [EMAIL PROTECTED] wrote: Serving from cache still means they need to be touched at least once to get them into the cache, and (in case of normal caching behavior) they will be touched again once the cached record expires. Caching will not make any difference to memory behavior I'd say. Yes of course I forgot to mention that the caches also expire in my reply. My experience so far is indeed that the caches save on the CPU usage much more than on the memory. -- Jean ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Zope hangs in FreeBSD with plenty of memory and CPU resources
All, As a coincidence, that hang of Zope I mentioned in a message I posted yesterday has happened again today (second time), after a planned reboot. So here is a completely different issue from the memory one we've been discussing today. There was other weirdness (for whatever reason _mysql could not find libmysqlclient_r.so.15 on some restart attempts), but here is something that seemed to occur consistently while Zope was unresponsive: On FreeBSD 5.4, with zserver-threads set to the default 4, there were seven Zope threads with the following states (CPU use is 0% and memory use is well below the maximum, pretty much where it is at after a normal fresh Zope restart): select ksesig kserel kqread kqread kqread kqread When Zope is operating normally and idle, I generally only see the three top threads, and when serving pages, I rarely see more than three threads; one actually often disappears and I only see two, one in the RUN state. I know that the kqread state has to do with the kqueue or kevent system call, and assume that Zope being in that waiting state for a long time is abnormal. Asking here in case someone has seen this behavior before and knows what might be the cause. As for the last and only other time this happened, Zope regained normal behavior by itself after a little while (in the order of half an hour). I don't see anything abnormal in the event log (other than the _mysql issue I mentioned above), and while stuck, requests do not register in the Z2.log. Browsers do get a connection because they state waiting for... but they do not receive anything, not even headers. After a fresh restart, I could get Zope to respond to a relatively benign request (the top level ZMI page), while there were only three Zope threads, but if asking for more, Zope would quickly get to the unresponsive state described above. We're thinking that we may be having underlying OS issues and will probably ask on a FreeBSD list and/or upgrade FreebBSD and hope that helps, but I'm asking here first just in case that this pattern of behavior was observed and resolved before. Cheers, Jean ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Large jumps of memory use increase, and seeking overall understanding of memory use
All, (I am posting to both the general Zope and Plone lists, I hope that's all right. My questions are more directly Zope issues, but in case someone who only looks only at the Plone lists has a different insight to offer...) I'm the co-admin Alex Kirk was referring to in his recent post Random Crashes/Freezes on FreeBSD 5.4-RELEASE on the Zope list. The particular instance he was referring to was not a random crash but simply Zope running out of memory (with the standard 512M limit on FreeBSD, that we have not increased so far -- we have 2Gb of physical memory). I have had one truly unexplained unresponsive Zope on that system so far, but was not able to characterize it well enough to ask an intelligent question on the list about that one. I fully understand that Zope has to be restarted regularly and intend to use monit to do so, but I would like to better understand what is going on in any case, and hopefully be able to lower the required frequency of such restarts. I have searched the lists (posts like [Zope-dev] Very severe memory leak and [ plone.user] Memory leaks even with latest-everything minimalistic site?) and get the general idea, but what I have read so far does not directly explain what I am observing. I have a test machine, but for starters, I have done some analysis of memory consumption of our live site to see what normal traffic produces. I have used a script to capture the size of the Zope process every minute (from ps) and merged these results with the access log. What I see does not make sense to me in terms of object cache, or growth of refcounts. My only (entirely unverified) hypothesis is that modules like PIL grab large chunks of memory once in a while. I provide specific examples below. First, the system: Plone 2.5.1, CMF-1.6.2, Zope (Zope 2.9.5-final, python 2.4.3, freebsd5), Five 1.3.7, Python 2.4.3 (#2, Jul 2 2006, 16:14:54) [GCC 3.4.2 [FreeBSD] 20040728], PIL 1.1.5 FreeBSD 5.4 My object cache size was initially at the default of 5000 objects per threads (4 threads default). I reduced this to 2000 just to see, but as I expected, the overall memory use behavior was the same. I have made some minor customizations to Plone and added contributed as well as my own products. My use of CMFReportTool might explain some of what I see, but definitely not all. Overall, my custom memory-use/access-log shows long periods with no increase in memory at all, but there are some big jumps at times (during a one minute tick) by 5, 10, even 25 Mb! As pretty much expected, Zope never gives much memory back to the OS; that part I understand, however I would like to get it to a state where it mostly plateaus and then only slowly creeps up. Some specific examples: With memory use at 417640 Kb, no requests at all in the previous minute, and a single request for an image_view_fullscreen in that whole minute, memory use jumped by 5064 Kb to 422704. The image was definitely not that large! (access log shows size returned was 1137). While on that topic, I realize that the ATImage has to be loaded in the object cache at some point, and that if it's a large image (in the order of mega bytes), I might see the memory use jump by that much. Now assume that the cache was already full when the image was loaded, that a lot of other later requests fill the cache with much smaller objects (so the image is not cached anymore) and then later the image is requested again, my guess is that the cache should already have the space it needs to load it, i.e. should I expect to see another memory jump by the size of the image, and if so, why (where did the space it originally occupy go that it can't be reused)? Can I easily check if large objects are being split in smaller chunks as they should by the way? Other example: A few of the large jumps I noticed have as one of the request during that minute a PDF listing of some documents. I use CMFReportTool to generate the PDF. There seems to be a possible correlation there, however, the resulting PDF document is about 150K, and these memory jumps can be as large as 10 Mb! I'll have a look at my code, CMFReportTool's and ReportLab's, but that seems a bit excessive to produce that document, so I wonder if something else is going on there. Of course, there is a catalog query required to get the documents to list, but I generate the report with the metadata only ( i.e. so nothing should be loaded in the object cache). I expect some increase in memory the first time a module is loaded (like ReportLab, although doesn't that happen when Zope is launched as part of product initialization?), but that would not explain continued increases on further requests. There are also many cases where the same listing was requested with no increase in memory at all (although that may be due to caching -- I'll have to look into that; I use cacheFu but have turned Squid off for now). Other example: There are however cases where I just can't see any reason for the sudden jumps. In one
Re: [Zope-dev] Structured text issues (again?)
I wasn't aware of that effort, thanks for pointing it out. I was only tinkering so of course that project is a much more complete solution than what I was envisioning. Went through problems.txt and more rapidly throught the specs, and I liked what I saw. There is a formal statement on the handling of nested inline markup, but I wonder again if it is not overly restrictive: Inline markup delimiter characters are used for multiple constructs, so to avoid ambiguity there must be a specific recognition order for each character. The inline markup recognition order is as follows: - Asterisks: `Strong emphasis`_ (**) is recognized before emphasis_ (*). I don't see why these two markups couldn't be recognized independently and unambiguously (well, mostly). Anyway, is discussion of that particular project OT for the Zope list? Is there any consideration being given to ultimately migrating Zope's core structured text to that implementation once it is sufficiently advanced? One problem I guess is that there are enough differences between the implementations to break existing structured text previously produced by Zope users. Cheers, Jean Richard Jones wrote: On Thu, 21 Mar 2002 08:40, [EMAIL PROTECTED] wrote: How extensively is STX actually used? I've been looking at it myself recently, and the whole system seem rather simplistic to me in how it parses the text. I'm talking specifically of the STX version currently standard in Zope 2.5 (and 2.4 I think), which I believe is STXNG; [snip] I explain the problems I see next, followed by a proposed algorithm change and some rough code to make things better. Please also see the ReStructureText effort which addresses a lot of the problems that STXNG is perceived to have. It's really very nice, and one of these days I hope to get it wrapped in a Zope Product. http://structuredtext.sf.net/ Note specifically: http://structuredtext.sourceforge.net/spec/problems.txt If something you see as being a problem in STXNG isn't addressed there, I'm sure the author of ReST would love to hear about it! 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] Dataskin Zclass + Folder subclassing problem
Thanks Steve, No doubt that is probably what is happening. Sadly, I need ZClass1 to be a dataskin. I could always copy over the few properties and methods shared by ZClass1 and ZCLass2 to ZCLass2 and inherit only from DataSkin and Folder; not the nicest, but that would work for now. My approach to access the contained objects directly (and not attempt to list them) seems to work for now as well. If I find the time, I will investigate this further to see what is happening exactly. Cheers, Jean -Original Message- From: Steve Spicklemire [mailto:[EMAIL PROTECTED]] Sent: Friday, November 30, 2001 03:13 Hi Jean, You might get more feedback from the ZPatterns list on something like this. My gut reaction is that subclassing in python 2.1/1.5 traverses the classes to find methods in a way that makes the *order* of classes very important. IIUC Python 2.2 has a much more sophisticated attribute searching scheme, so that this will be easier to get right.. but so far Zope and 2.2 don't mix so well. You are no doubt getting the wrong class/attributes when you call objectIds etc. Can you try making ZClass1 a simple class and ZClass2 subclassing from DataSkin, Folder and *then* ZClass1? good luck! -steve On Tuesday, November 27, 2001, at 12:36 PM, Jean Lagarde wrote: Hi all, A ZClass inheriting from both DataSkin and Folder seems to work as expected (so much has been discussed in other messages, at least with ObjectManager). However, instead of inheriting directly from DataSkin, I want to inherit from another Zclass which is itself based on DataSkin, i.e. (not showing Zobjects): DataSkin ZClass1Folder | \ / | \ / v v v ZClass1ZClass2 After its creation, the new Zclass ZClass2 seems to have some management issues: - The views are initialized to those of ZClass1; no big deal, for now, I just added a new view tab named Contents for manage_main - When I create an instance of ZClass2 (in a Folder w/Customizer Support), the instance does show its Contents tab, but it does not quite know it's folderish: - It does not show in the left pane of the ZMI - If I add an object from the contents tab interface of the instance, say a dtml method, it adds OK, but does not show in the contents tab (the contents view is always empty no matter what I add) - The objects I added are there; I can traverse to them and their management interfaces, and I have also checked the ZODB directly using the wonderful pyTree.py. I'm afraid that I know just enough about Zope to be dangerous ;-) I basically just have the time to learn about the stuff that I need to get the job done, and I'm sure that the current version of what I'm working on will need some refactoring later on. So I have two questions: 1) Anybody can think of a quick fix to get the folderish behavior working as it should? 2) In its current state (if there is no quick fix), ZClass2 seems usable enough for my needs; I just need to add a couple of objects for each instance, and I can reach their management screens through explicit traversal. So I'm tempted to plug along and keep on experimenting with that setup for now. Any other more important consequences that I'm missing that should have me fix this more adequately before I proceed? Cheers, Jean ___ 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] Dataskin Zclass + Folder subclassing problem
It's Steves to the rescue today! Using the order (DataSkin, Folder, ZClass1) seems to have done the trick! Thanks! I would have thought about subclassing DataSkin again, eventually ;-) I had tried to inherit from (Folder, ZClass1) rather than (ZClass1, Folder), but that order was giving me a _v_dm_ key error; that should have clued me into the right direction. Jean From: Steve Alexander [mailto:[EMAIL PROTECTED]] Sent: Friday, November 30, 2001 09:10 Jean Lagarde wrote: Thanks Steve, No doubt that is probably what is happening. Sadly, I need ZClass1 to be a dataskin. Make both ZClass1 and ZClass2 derive from Dataskin before anything else. It will do no harm that DataSkin is derived from twice in one class. -- Steve Alexander ___ 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] dtml-in batching improved
Ivo, somehow I had missed the very start of the thread. I think that my change pretty much implements the third alternative you describe in your post, but for which you provided no patch (the one which defines the variables at the top and bottom only, because I leave the if index==first or index==last test). You are right that my change could break existing code, but I think not as badly as defining the variables for every iteration. In any case, I will keep the change in my version until I notice a side effect that I don't like. Cheers, Jean -Original Message- From: Ivo van der Wijk Sent: Monday, June 18, 2001 7:31 AM This is basically my patch #1. It makes previous-sequence-* and next-sequence-* available throughout the entire dtml-in loop. This sounds like a good fix, but people may rely on these variables being only set at resp. the start and end of the iteration. So this patch may break existing dtml code. That's why I suggested patch #2, which introduces new variables. Old code will continue to work, but people who want the problem fixed can use the newly introduced variables, which are available throughout the iteration. Ivo ___ 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 )
