Re: Intermittent error on Pylons apps
Actually, the a different traceback that was emailed to me suggests the error might be in docutils, not Pylons. I'll investigate this before bugging the list more. Regards, Cliff On Sun, 2008-04-13 at 22:16 -0700, Cliff Wells wrote: I have intermittent errors on a couple Pylons sites when performing POST operations: Traceback (most recent call last): File /var/www/virtual/twisty-industries.com/lib/python2.5/PasteScript-1.3.6-py2.5.egg/paste/script/wsgiserver/__init__.py, line 624, in communicate req.respond() File /var/www/virtual/twisty-industries.com/lib/python2.5/PasteScript-1.3.6-py2.5.egg/paste/script/wsgiserver/__init__.py, line 357, in respond response = self.wsgi_app(self.environ, self.start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/PasteDeploy-1.3.1-py2.5.egg/paste/deploy/config.py, line 276, in __call__ return self.app(environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/cascade.py, line 92, in __call__ return self.apps[-1](environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/registry.py, line 340, in __call__ app_iter = self.application(environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/recursive.py, line 80, in __call__ return self.application(environ, start_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/errordocument.py, line 185, in __call__ app_iter = self.application(environ, change_response) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/exceptions/errormiddleware.py, line 149, in __call__ response = self.exception_handler(exc_info, environ) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/exceptions/errormiddleware.py, line 178, in exception_handler simple_html_error=simple_html_error) File /var/www/virtual/twisty-industries.com/lib/python2.5/Paste-1.4.2-py2.5.egg/paste/exceptions/errormiddleware.py, line 353, in handle_exception exc_data.exception_type, exc_data.exception_value)) IOError: [Errno 5] Input/output error Restarting the application solves the issue for a time, but it inevitably happens again. It doesn't appear to be a hardware or resource issue as it only happens with Pylons apps. The apps affected appear to be limited to ones that have been upgraded from earlier versions of Pylons, but I haven't been able to locate any omissions in my upgrade (and they work for days or weeks without issue). I'll provide source if someone has a suggestion as to which source I should provide =) Regards, Cliff --~--~-~--~~~---~--~~ 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: Internal Errors due to WebError failures on source encoding
Are there any chances to have this patched, in any - even temporary and dirty - way, so easy_install-ed weberror does not crash? At the moment I must manually patch it on every environment, that's really troublesome. --~--~-~--~~~---~--~~ 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: paster on vista x64: cannot find python executable
Jose Galvez escreveu: Ben Lee wrote: http://groups.google.com/group/pylons-discuss/browse_thread/thread/5b31478b1d4b8710/b80979242b1895f2?lnk=gstq=cannot+find+python#b80979242b1895f2 Cannot find Python executable C:\Python25\python.exe is python in your system path? I don't think the python path is added by default when you install python. if not add it and give that a try Are there any mismatches between setuptools' arch and your installed Python? Like a 32bit easy_install (which creates the paster.exe file) on a 64bit Python? I solved this by realizing I don't need the big address space and sticking with a 32bit Python. --~--~-~--~~~---~--~~ 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: Unpacking PylonsApp?
PylonsApp seems to do two separate things: - construct and register objects like request, response, session, g, h, ... - dispatch the request to correct controller (and wrap it with testing support and error handling) Couldn't those two be separated? (...) I've been thinking about something similar, that WebOb has made WSGI obsolete. WSGI will have to change anyway in Python 3 due to the changing relationship of string to Unicode. (...) Well, Python3, WSGI2, etc. Years. In the meantime, WebOb has a design pattern to make writing middleware much easier. See Writing your own middleware with WebOb in What's New in Pylons 0.9.7. http://wiki.pylonshq.com/pages/viewpage.action?pageId=11174779 I do not quite trust this code (what is my_wsgi_application, why (class) insteado of (object)...), but let's leave it. The main question is that here one is still re-creating Request object. What I suggest is that some middleware should create request once and for good, so lower layers are able to reuse it. As for getting the session, it's in a WSGI environment variable. environ['beaker.session'] and environ['beaker.get_session'](), it looks like. Accessing the Pylons globals (pylons.request, pylons.response, pylons.session) means you're going through StackedObjectProxies, which just adds complication. Well, one thing StackedObjectProxies do is that I do not need to pass environ to every function anymore, referring pseudo-globals is easier and smoother. PS I roughly did the aforementioned split, can post it if somebody is interested. Not much testing so far though. -- -- | Marcin Kasperski | Users typically do not know exactly what | http://mekk.waw.pl | they want and are unable to articulate all || that they know. (Parnas) -- --~--~-~--~~~---~--~~ 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: Unpacking PylonsApp?
On Mon, Apr 14, 2008 at 7:33 AM, Marcin Kasperski [EMAIL PROTECTED] wrote: PylonsApp seems to do two separate things: - construct and register objects like request, response, session, g, h, ... - dispatch the request to correct controller (and wrap it with testing support and error handling) Couldn't those two be separated? (...) I've been thinking about something similar, that WebOb has made WSGI obsolete. WSGI will have to change anyway in Python 3 due to the changing relationship of string to Unicode. (...) Well, Python3, WSGI2, etc. Years. In the meantime, WebOb has a design pattern to make writing middleware much easier. See Writing your own middleware with WebOb in What's New in Pylons 0.9.7. http://wiki.pylonshq.com/pages/viewpage.action?pageId=11174779 I do not quite trust this code (what is my_wsgi_application, why (class) insteado of (object)...), but let's leave it. The main question is that here one is still re-creating Request object. my_wsgi_app is whatever application comes next in the middleware stack. 'class' is a typo. The pattern works; it's being used in middleware now. What I suggest is that some middleware should create request once and for good, so lower layers are able to reuse it. That's what I'm saying too. Although I think the server should create the request. As for getting the session, it's in a WSGI environment variable. environ['beaker.session'] and environ['beaker.get_session'](), it looks like. Accessing the Pylons globals (pylons.request, pylons.response, pylons.session) means you're going through StackedObjectProxies, which just adds complication. Well, one thing StackedObjectProxies do is that I do not need to pass environ to every function anymore, referring pseudo-globals is easier and smoother. It's easier but it makes everything depend on this non-straightforward structure. For instance, the webhelpers are supposed to be independent of any framework, yet you need 'url_for' and 'session' for certain kinds of helpers. They can't access the WSGI environ because they're not a direct descendant of the middleware chain. For WebHelpers 0.7 I'm going to try some kind of generic abstraction layer for framework services, but for now I just punted and let the functions import url_for and session directly, with a note in the docstring saying the helper depends on this or that. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Unpacking PylonsApp?
On Mon, Apr 14, 2008 at 9:55 AM, Mike Orr [EMAIL PROTECTED] wrote: On Mon, Apr 14, 2008 at 7:33 AM, Marcin Kasperski Well, one thing StackedObjectProxies do is that I do not need to pass environ to every function anymore, referring pseudo-globals is easier and smoother. It's easier but it makes everything depend on this non-straightforward structure. Quixote has top-level functions instead: quixote.get_request(), quixote.get_session(). At first I really liked pylons.request etc, but after seeing how much magic the StackedObjectProxies do, I wish Pylons had gone with functions because they make explicit that something is happening. But the pylons.request style has been established in Pylons for so long that it can't be changed. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
addressing app 'name'
i'm working on a building a framework of common social networking features for several pylons apps to subclass/inherit from an issue that I'm running into, is that I need to access/import some things not from pylons, but from the app itself instead of doing from ..lib import helpers as h is there a better way to do something like from PylonsApp import helpers as h --~--~-~--~~~---~--~~ 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: appengine-monkey, Pylons, library support
Thanks Ian, this works great! Just two little issues: 1) appengine-boot.py fails to copy development.ini.template, I had to rename it to development.ini. 2) The Pylons appengine-monkey tutorial should metion somewhere that in order to use Mako (with Pylons 0.9.7 at least), TemplateLookup's module_directory parameter should not be set. Because appengine doesn't support filesystem write operations. Augusto On Apr 13, 7:33 pm, Ian Bicking [EMAIL PROTECTED] wrote: Hi all. I've been working on a project to provide some of the functionality that is missing from the App Engine environment: http://code.google.com/p/appengine-monkey/ Currently this fairly modest set of functions and a couple modules. Some of the modules provided (like subprocess) aren't actually *working*, but this makes the module importable for cases where a library imports a module, but only uses that module in a couple functions, and there's other parts of the library that are still useful. This also makes Setuptools functional, and by association Pylons. The current state of Pylons is that the Mako trunk is working and the session handling (provided in the Beaker trunk) supports the Datastore as a backend. So Pylons basically works, though with the caveat that it hasn't been tested much. Full instructions for starting a Pylons application are located here: http://code.google.com/p/appengine-monkey/wiki/Pylons I also welcome contributors to appengine-monkey. If you are interested in implementing layers on urlfetch to be compatible with httplib, urllib, or urllib2, that would be well within the scope of this project. (BTW, my blog post describing mostly the same things as this email is here:http://blog.ianbicking.org/2008/04/13/app-engine-and-pylons/) -- Ian Bicking : [EMAIL PROTECTED] :http://blog.ianbicking.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
