Re: Beaker error (Beaker 1.4.2 released)
Hi Ben, I've recently upgraded one of my busiest sites to use beaker 1.4.2 and I am getting an intermittent error: Module beaker.cache:115 in get def get(self, key, **kw): Retrieve a cached value from the container return self._get_value(key, **kw).get_value() get_value = get return self._get_value(key, **kw).get_value() Module beaker.container:269 in get_value if not creation_lock.acquire(wait=False): debug(get_value returning old value while new one is created) return value else: debug(lock_creatfunc (didnt wait)) return value UnboundLocalError: local variable 'value' referenced before assignment I am using Memcached with the pure-python driver as the caching backend. What we do is manually invalidate (delete) the cache under certain circumstances. What is happening here as far as I can tell is: - the cache gets delted (using memcached's delete key functionality) - the first request comes in where it gets regenerated - while the cache is being regenerated, a second request comes in and beaker tries to return the old value which no longer exists, even though for some reason beaker thinks its there. I understand this is to avoid the dog-pile effect, and would be the correct thing to do if we still had the old cache. Is delting the key not the way to go? Can I 'invlidate' the cache some other way that preserves the anti-dogpile effect? Also, should beaker not behave differently if there is no old value to return? Thanks, Damian This bug has been fixed with a work-around in Beaker, and Beaker 1.4.2 has been released with it. - Ben --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: render is UNDEFINED in Pylons 0.9.7, was ok in 0.9.6
That doesn't seem to work.
I had to resort to this:
%namespace name=templating module=pylons.templating/
${templating.render('mako', '/source/header.mako')}
I also tested this issue on a newly paster created 0.9.7 helloworld
instance.
On Oct 1, 5:39 pm, Mike Orr sluggos...@gmail.com wrote:
On Thu, Oct 1, 2009 at 1:33 AM, Moshe C. mos...@gmail.com wrote:
Calling render() from within a template used in a Pylon application
fails in 0.9.7, while it worked in 0.9.6 .
In each Python file generated per template there is a line
render = context.get('render', UNDEFINED)
and render is assigned UNDEFINED.
Comparing 0.9.6 pylons.templating._update_names() with 0.9.7
pylons.templating.pylons_globals, shows that in the former 'render'
was set, but not in the latter.
This seems to be a bug, but what is the best way to workaround it?
Seehttp://wiki.pylonshq.com/pages/viewpage.action?pageId=11174779
The templating system was simplified in Pylons 0.9.7. Now the
controllers should:
from pylons.templating import render_mako as render
--
Mike Orr sluggos...@gmail.com
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Pg West in two weeks (Seattle)
PostgreSQL Conference West is set to hit in two weeks! Running from October 16th-18th a Central Seattle Community College, this West is set to be the largest West Coast PostgreSQL conference to date. There is a fair amount of Python being discussed as well as a half day tutorial using Pylons and The Stack (the developers wanted to call it pixie dust... sigh). Our list of talks is up: http://www.postgresqlconference.org/2009/west/talks Our tentative schedule is up: http://www.postgresqlconference.org/2009/west/schedule And our registration is up: http://www.postgresql.us/purchase Remember folks, all proceeds are a donation to United States (PgUS) PostgreSQL. A United States 501c3. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Using Django Forms with Pylons (and a successor to @validate?)
I've switched to using django.forms with Pylons, and I really like the change so far. I've posted a writeup, and a drop-in module, on using django.forms with Pylons here: http://marcuscavanaugh.com/posts/pylons-django-forms/ Also, if django.forms isn't your thing but you still want to use FormEncode, I included some code that lets you use FormEncode validation with django-style controller code (to replace @validate). I've thought about @validate for a long time now, and I don't think a decorator will ever give the flexibility we need; Django's idioms work equally well for FormEncode, so maybe that will spark your interest. YMMV, of course, but I'm using Django's Forms with my project now and I'm very happy with it. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Beaker error (Beaker 1.4.2 released)
On Oct 2, 2009, at 6:05 AM, Damian wrote: Module beaker.cache:115 in get def get(self, key, **kw): Retrieve a cached value from the container return self._get_value(key, **kw).get_value() get_value = get return self._get_value(key, **kw).get_value() Module beaker.container:269 in get_value if not creation_lock.acquire(wait=False): debug(get_value returning old value while new one is created) return value else: debug(lock_creatfunc (didnt wait)) return value UnboundLocalError: local variable 'value' referenced before assignment It would appear that it sees the value with has_value right before its deleted. I've added a line so that if it fails to then get the value, it sets has_value to false. This should remedy your situation, if you could try the latest Beaker tip from source that has this fix in it, that'd be great. Cheers, Ben --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Using Django Forms with Pylons (and a successor to @validate?)
On Fri, Oct 2, 2009 at 11:32 AM, Marcus Cavanaugh marcuscavana...@gmail.com wrote: I've switched to using django.forms with Pylons, and I really like the change so far. I've posted a writeup, and a drop-in module, on using django.forms with Pylons here: This looks great, Marcus. Every now and then a little flare-up of anxiety has hit me about the attempt you and I did at PyCon... and each time I didn't know what to do to fix @validate or to make recommendations based on what you and I worked through. Thanks for sharing your solution. I expect that ditching @validate is the right way to fix @validate. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Using Django Forms with Pylons (and a successor to @validate?)
On Fri, Oct 2, 2009 at 1:28 PM, Matt Feifarek matt.feifa...@gmail.com wrote: On Fri, Oct 2, 2009 at 11:32 AM, Marcus Cavanaugh marcuscavana...@gmail.com wrote: I've switched to using django.forms with Pylons, and I really like the change so far. I've posted a writeup, and a drop-in module, on using django.forms with Pylons here: This looks great, Marcus. Every now and then a little flare-up of anxiety has hit me about the attempt you and I did at PyCon... and each time I didn't know what to do to fix @validate or to make recommendations based on what you and I worked through. Thanks for sharing your solution. I expect that ditching @validate is the right way to fix @validate. That's an idea. We could just split the validator code into parts and then not bother reassembling the decorator. I'm of mixed minds on Marcus' approach. People have been using django.forms with Pylons for quite a while. And I always used to do form presentation-validation-action all in one method before I came to Pylons. I never did quite accept the argument for splitting them into separate methods, except that it avoids a complex if-block, for whatever that's worth. But I don't know if Pylons is ready for such a major change when we're trying to nail it down for 1.0. A FormEncode wrapper might be worthwhile, though I'm not sure it's buying you much if DjangoForms compatibility is not a constraint. FormEncode schemas are already complicated enough, so I'm a bit uneasy about combining them with a form and wrapper code in the same class. I'd be more comfortable with a wrapper that contains a schema rather than being a schema. The one-method system would also break for resource routes, where unrelated actions are doubled up on the same URL. I suppose with POST/PUT/DELETE conditions, Routes could route to the same action for edit/update and new/create. But it would probably have to be a separate method (.resource2) given the significant difference in behavior. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
View Template Error
I started pylons today and I'm following along with the pylons book.
I'm trying to render a simple template but continue to get: OSError:
[Errno 13] Permission denied: '/var/pylons_projects/bin/HelloWorld/
data'
Anyone know what's wrong?
The url is: http:xxx.xxx.xxx.xxx:5000/hello/index
The index action (method):
def index:
name = 'Dan'
return render('/hello.html', extra_vars={'name':name})
Within the templates directory I've saved hello.html, which follows:
html
headtitleHello/title/head
body
h1Template Test/h1
pHello ${name}/p
/body
/html
Thanks,
Dan
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: View Template Error
On Oct 2, 2009, at 1:17 PM, Dan06 wrote: I started pylons today and I'm following along with the pylons book. I'm trying to render a simple template but continue to get: OSError: [Errno 13] Permission denied: '/var/pylons_projects/bin/HelloWorld/ data' Pylons sets mako and Beaker to write out its data to the data/ directory in the root directory of your Pylons project. Obviously you don't have permissions to write to it for whatever reason. Fix the permissions problem or change the directory used in the ini file. -- Philip Jenvey --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Using Django Forms with Pylons (and a successor to @validate?)
WTForms does this already: http://wtforms.simplecodes.com/ It uses the same pattern as Django forms, and might be a bit further developed. On Oct 2, 10:17 pm, Mike Orr sluggos...@gmail.com wrote: On Fri, Oct 2, 2009 at 1:28 PM, Matt Feifarek matt.feifa...@gmail.com wrote: On Fri, Oct 2, 2009 at 11:32 AM, Marcus Cavanaugh marcuscavana...@gmail.com wrote: I've switched to using django.forms with Pylons, and I really like the change so far. I've posted a writeup, and a drop-in module, on using django.forms with Pylons here: This looks great, Marcus. Every now and then a little flare-up of anxiety has hit me about the attempt you and I did at PyCon... and each time I didn't know what to do to fix @validate or to make recommendations based on what you and I worked through. Thanks for sharing your solution. I expect that ditching @validate is the right way to fix @validate. That's an idea. We could just split the validator code into parts and then not bother reassembling the decorator. I'm of mixed minds on Marcus' approach. People have been using django.forms with Pylons for quite a while. And I always used to do form presentation-validation-action all in one method before I came to Pylons. I never did quite accept the argument for splitting them into separate methods, except that it avoids a complex if-block, for whatever that's worth. But I don't know if Pylons is ready for such a major change when we're trying to nail it down for 1.0. A FormEncode wrapper might be worthwhile, though I'm not sure it's buying you much if DjangoForms compatibility is not a constraint. FormEncode schemas are already complicated enough, so I'm a bit uneasy about combining them with a form and wrapper code in the same class. I'd be more comfortable with a wrapper that contains a schema rather than being a schema. The one-method system would also break for resource routes, where unrelated actions are doubled up on the same URL. I suppose with POST/PUT/DELETE conditions, Routes could route to the same action for edit/update and new/create. But it would probably have to be a separate method (.resource2) given the significant difference in behavior. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Using Django Forms with Pylons (and a successor to @validate?)
On Oct 2, 6:05 pm, Dan danjac...@gmail.com wrote: WTForms does this already:http://wtforms.simplecodes.com/ It uses the same pattern as Django forms, and might be a bit further developed. Cool, I had not heard of WTForms before. If it's well-maintained, then that's a win-win. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: View Template Error
On Oct 2, 5:40 pm, Philip Jenvey pjen...@underboss.org wrote: Pylons sets mako and Beaker to write out its data to the data/ directory in the root directory of your Pylons project. Obviously you don't have permissions to write to it for whatever reason. Fix the permissions problem or change the directory used in the ini file. -- Philip Jenvey I went through the error stack and noticed that the program was trying to create the 'data' directory; I didn't understand why while rendering the template it was trying to create the 'data' directory. Thanks for the explanation. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: View Template Error
On Oct 2, 7:32 pm, Dan06 dan.king...@yahoo.com wrote: rendering the template it was trying to create the 'data' directory. mako keeps a compiled version of the template in data/templates. If you use filebased sessions, they are written in data/sessions. --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: paster/beamer hangs forever
is lockd/statd running or an alternative dlm?
NFS v4?
On Oct 2, 7:21 am, Alvaro alvaro.fernan...@ific.uv.es wrote:
when doing the setup for an aplication with paster (i.e: paster setup-
app test.ini) on a directory mounted over NFS the process is stuck
forever, hanging.
I believe there is a syscall for locking files that is not working due
to the networked file system implementation.
doing a strace on the process I get the following:
fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET,
start=1073741824, len=1}, 0xbff74810) = -1 ENOLCK (No locks available)
nanosleep({0, 100}, NULL) = 0
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Using Django Forms with Pylons (and a successor to @validate?)
On Fri, Oct 2, 2009 at 4:05 PM, Dan danjac...@gmail.com wrote: WTForms does this already: http://wtforms.simplecodes.com/ It uses the same pattern as Django forms, and might be a bit further developed. That looks pretty elegant. It would obviate FormEncode, htmlfill, and the form helpers, it looks like. Are the validators complete? Not that FormEncode's validators are easy to use in their semi-documented state. Can you use the validators alone without the form? I use a FormEncode schema to validate the INI file in environment.py, so that I can make all exceptions happen at the beginning rather than in unexpected requests. If you can make a Pylons tutorial for it, we can consider documenting it in the next version of Pylons. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
