Re: Debugging failed tests with pylons globals
On Jul 11, 8:23 am, Alberto Valverde [EMAIL PROTECTED] wrote: I honestly don't find them *that* hard to understand, and I'm not that bright either. Granted, I've fought them a lot and have implemented several libraries (one of them is open source, ToscaWidgets) that use them so I probably know more about them than the average Pylons user. What they do is not that difficult to understand, but how to affect their behavior is. The documentation describes how to register a new one, but not how to affect the values that are in there. In addition, it's very difficult to inspect the object that an SOP refers to since it obfuscates the object's __dict__. In the end, they're just a little too much magic for me. I believe some good docs explaining them, even better if they are written or reviewed by whoever designed/implemented them, would be enough to help understand them better. I agree Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Debugging failed tests with pylons globals
So SOPs are here to stay for now but nobody thinks they're ideal. The trouble is, we don't know what would be better. I understand that pylons 1.0 will be breaking backwards compatibility. That might be a good time to look at what might be a better option. If 98% of cases are served by threadlocals, that might be the way to go. It's rarely wise to introduce this kind of complexity for 2% of the use cases. Of course, there's also the possibility that SOPs aren't that complicated and the problem is really that nobody knows how to deal with them. The documentation for SOPs is somewhat lackluster; the API is described in the paste docs, but not the motivation or concepts. In the end, there is no technical reason why a program should not be able to access an SOP from anywhere. What I would like to see is a way of registering a thread to access the SOP that another thread is refering to. This obviously isn't safe, and shouldn't be the default, but for testing it's quite valuable to be able to access SOPs that were registered to a thread that is not your own. Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Expired Beaker Values and Memory
Hello, I'm using the pylons global cache object to cache a variety of data. I've noticed that beaker never clears expired values. It will refresh expired values with the passed create function when the are accessed, but expired values are never removed. This makes it hard to use beaker as a general cache as things that aren't touched for some time just build up in memory. I've run into this a number of times, but I'll give one solid example. My application uses facebook to get information on a user. We are allowed to cache this information for up to 24 hours, and for performance and stability reasons, its definitely in our interest to do so. However, using beaker just leads to unbounded memory usage. If a user hasn't logged in in a few days, there's no reason for us to still have his expired data lying around. Of course, this is fairly easy to fix. We can just run a cleanup thread every few minutes to clear out expired values. However, this seems like a bit of an oversight in a piece of software designed for long running processes. Is there anything in beaker that I've missed that addresses this? Should there be? Also, does this apply to sessions? Are old sessions kept around indefinitely? I haven't looked too much at them, but I have to imagine the situation is similar. Thanks, Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best way to send email w/o blocking?
On Jul 6, 12:35 am, kevin [EMAIL PROTECTED] wrote: What are your recommendations for sending email without blocking? Because I can imagine several ways, but maybe there's some niceness I'm not aware of. I actually spawn off a new thread that does some verification and then sends the email and exits. It's a bit heavyweight, I admit, but it allows you to take as much time as you want without interfering with the user experience. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
