Re: [web2py] Re: PAPERBACK web2py book
On Aug 17, 2010, at 4:49 AM, mdipierro wrote: > As I explained in a previous thread there seem to be some legal > problems. Lulu is the publisher and they offer amazon or ibookstore. > They do not seem to allow both and I cannot redistribute the book > without them using the same isbn. yet ibookstore requires an isbn. Let > me keep looking if you have any advice let me know. While I prefer iBooks for reading, if I were publishing and had to make that choice, I'd go with Amazon, given that Kindle readers are fairly widespread. Presumably that will change, but for now > > Massimo > > On Aug 17, 6:22 am, David Mitchell wrote: >> Hi Massimo, >> >> Any chance of an EPUB format? >> >> I've promised myself I won't buy any more technical books in dead-tree >> format, and PDFs are just too hard to read on my ebook reader. >> >> Regards >> >> David Mitchell >> >> >> > On Aug 13, 5:36 pm, mdipierro wrote: >> >> The 3rd edition of the book is finally available in paperback. >> >>> http://www.lulu.com/product/paperback/web2py-(3rd-edition)/12199578 >> >> The 3rd edition has 40% more text and it is 30% cheaper than the 2nd >> edition. >> >> Massimo
Re: [web2py] Re: Logging in web2py
On Aug 17, 2010, at 9:16 PM, Yarin wrote: > @Jonathan- Like your use of config files for default configurations, > but beyond that I'm not clear on what your patch is meant to solve- > What's your reason for introducing named loggers and sub-loggers at > the site level? Couldn't the root logger just handle all this? The main purpose of the configuration file is to allow a site to configure the logging destination. The current logging all goes to stdout (which in the case of Fedora or RHEL, at least, is /dev/null for system-started daemons). The configuration file lets us log to files, rotating files, or syslog, local or remote. The reason for named loggers is twofold. One is trivial: to identify the source of log messages. The other is not so trivial, but mainly for development: to let us have different log levels for different loggers. If I'm debugging URL rewrite, I can lower the level of the web2py.rewrite logger to (say) debug, without enabling all the other debug/info loggers in the system. Note that having named loggers is a pretty trivial addition, once we have a config file; it's not central, but it's a distinct convenience. Note also that we already have named loggers (eg Rocket and its kin), but no way to configure them. > > My intention was to use named loggers to allow for logging control at > the application level, but for site level logging I see no reason to > stray from root. > > @Iceberg- Yeah, I played around with abstracting > get_configured_logger() into a contrib module, but it got messy > because > a) The request object we use to get application name and log file path > isn't available outside the mvc classes, and would have to be passed > in. > b) More importantly, it killed the flexibility of being able to do > custom configuration, use custom or multiple handlers, etc. > > The GAEHandler and others I include in the link are useful, but > they're not web2py specific so Massimo might not want to clutter the > framework with them. > > On Aug 17, 2:32 pm, Iceberg wrote: >> Nice work, Yarin! You use a more decent way, >> logging.getLogger(request.application), to achive app-wide logger. It is >> better than my cache.ram() trick. Oh, I was so blind, man. :-) >> >> And I wish GAEHandler and get_configured_logger() could go to web2py trunk, >> and the scaffold's models/model.py contains just one extra line: >> >> logger = get_configured_logger(folder = 'static', maxBytes=1024, >> backupCount=5) >> >> so it will be even easier to use. >> >> Best regards, >> Iceberg, 2010-Aug-18, 02:20(AM), Wed >> >> >> >> --- Original Message --- >> From:Yarin >> To: web2py-users >> >> Cc: iceb...@21cn.com >> Date:Mon, 16 Aug 2010 13:31:16 -0700 (PDT) >> Subject: Logging in web2py >> --- >> >>> I've posted an updated slice with an in-depth treatment of logging in >>> web2py. >>> http://web2pyslices.com/main/slices/take_slice/91 >> >>> Based on our earlier discussion >>> http://groups.google.com/group/web2py/browse_thread/thread/d3b534113a... >> >>> The slice addresses the issues of application-level logging, once-only >>> configuration, and simpler syntax. It offers an approach that fully >>> leverages Python's native logging capabilities, allows for full >>> flexibility in configuration, and doesn't interfere with existing >>> logging implementations. >> >>> Some notes: >>> -I decided against creating a separate contrib module for the code as >>> it would impede flexibility and obscure the simplicity of solution. >>> If included in the framework, I think it should be as model code. >>> -I abandoned the cache approach to creating singleton loggers, and >>> just inspect handlers instead. (Logger caching was causing problems >>> on GAE) >> >>> Let me know what you think. Thanks Massimo, Iceberg...
Re: [web2py] Re: Logging in web2py
On Aug 18, 2010, at 6:36 AM, Yarin wrote: >> The reason for named loggers is twofold. One is trivial: to identify the >> source of log messages. > Logging already tracks module, function, lineno... we can even insert > a stack trace >> The other ... to let us have different log levels for different loggers. > But it looks like you're introducing several named loggers only to log > several messages at startup. For example, your "web2py.sql" logger's > only function is to log a single driver exception. As far as I can > tell, only the "web2py.rewrite" logger does any continuous work. And > I assume the Rocket logger does a lot of work. But beyond that I > can't see the justification in forcing the framework to create and > configure a number of different loggers that will only be used once, > if at all? Mostly for purposes of example. The web2py.foo loggers needn't appear in the config file; they can all use the web2py logger (I keep writing 'blogger'). The Rocket module is (I think) independent of web2py; if not, I'd have changed its logger (or asked Tim to do so) to something like 'web2py.rocket.*' (maybe we could pass a logger base name in to it). Identifying the source of the log messages through the logger name is useful for more than human consumption. log levels is one use; another is choice of handler. I'd have no objection to consolidating the startup-only loggers into 'web2py.startup', though I think that a noisy logger (even if noisy only at startup) ought to have its own name.
Re: [web2py] Re: Bug in URL(..,..,vars={})
On Aug 20, 2010, at 8:29 AM, mdipierro wrote:
> I changed and changed back. I am waiting for comments form other
> developers. I am not sure what the best course of action is.
What's an example of the framework breakage using the helper form of URL?
>
> Massimo
>
> On Aug 20, 8:23 am, Phyo Arkar wrote:
>> So the way it worked before was a bug and now (rev 853) it is a feature?
>>
>> On 8/20/10, mdipierro wrote:
>>
>>> On a second thought we should leave it alone. Else we break the
>>> scaffolding app, i.e. 90% os apps out there.. Anyway,... I'd still
>>> like to hear your opinions.
>>
>>> On Aug 19, 8:38 pm, mdipierro wrote:
There is a problem (in 1.83.2 and earlier version)
>>
URL()
>>
returns a string, not a helper. If you want to include the string
without escaping twice you have to do
>>
{{=XML(URL(...))}}
>>
In trunk, I modified the definition of URL so that it returns the
XML(..) helper wrapping the string. This will prevent
>>
{{=URL(...)}}
>>
from double escaping but will prevent you from doing
>>
'http://127.0.0.:8000'+URL(..)
>>
you would have to do
>>
'http://127.0.0.:8000%s'%URL(..)
>>
we cannot have it both ways.
>>
URL is either a helper or a string... The more I think about it the
more I am convinced URL should be a helper not a string otherwise all
the examples in which we use {{=URL(...)}} are buggy. Therefore this
change should be considered a bug fix and not a breaking of backward
compatibility.
>>
What do other people think? Should we change this as in trunk or leave
it alone?
>>
Massimo
>>
On Aug 19, 1:39 pm, Phyo Arkar wrote:
>>
> Trunk version Rev 853
>>
> in view:
> $("#list").jqGrid({
>>
> url:"{{=URL(r=request,f='listMIME.json',vars={'extracted_path':extracted_path,'source_path':source_path})}}",
>>
> HTML Result:
> $("#list").jqGrid({
> url:"/sExtract/extraction/listMIME.json?source_path=home*&*
> ;extracted_path=target",
>>
> it insert &instead of &
>>
> that screwed up all my sites :D ..
>>
> have not tested with released version ..
Re: [web2py] Re: Bug in URL(..,..,vars={})
On Aug 19, 2010, at 6:38 PM, mdipierro wrote:
> In trunk, I modified the definition of URL so that it returns the
> XML(..) helper wrapping the string. This will prevent
>
> {{=URL(...)}}
>
> from double escaping but will prevent you from doing
>
> 'http://127.0.0.:8000'+URL(..)
Couldn't this be fixed by implementing URL.__radd__() ?
def __add__(self,other):
return '%s%s' % (self,other)
def __radd__(self,other):
return '%s%s' % (other,self)
>
> you would have to do
>
> 'http://127.0.0.:8000%s' % URL(..)
>
> we cannot have it both ways.
Re: [web2py] Re: Bug in URL(..,..,vars={})
On Aug 20, 2010, at 9:22 AM, Jonathan Lundell wrote:
> On Aug 19, 2010, at 6:38 PM, mdipierro wrote:
>
>> In trunk, I modified the definition of URL so that it returns the
>> XML(..) helper wrapping the string. This will prevent
>>
>> {{=URL(...)}}
>>
>> from double escaping but will prevent you from doing
>>
>> 'http://127.0.0.:8000'+URL(..)
>
> Couldn't this be fixed by implementing URL.__radd__() ?
I meant XML.__radd__()
>
>def __add__(self,other):
>return '%s%s' % (self,other)
>
>def __radd__(self,other):
>return '%s%s' % (other,self)
>
>
>
>>
>> you would have to do
>>
>> 'http://127.0.0.:8000%s' % URL(..)
>>
>> we cannot have it both ways.
>
>
Re: [web2py] Re: Bug in URL(..,..,vars={})
On Aug 20, 2010, at 10:17 AM, mdipierro wrote:
> I did as you suggest. I also had to add lower(), upper() and __len__
> methods to the XML class.
> I think this is a good solution. Thanks Jonathan.
oops:
+def upper(self):
+return str(self).lower()
>
> Massimo
>
> On Aug 20, 11:31 am, Jonathan Lundell wrote:
>> On Aug 20, 2010, at 9:22 AM, Jonathan Lundell wrote:
>>
>>> On Aug 19, 2010, at 6:38 PM, mdipierro wrote:
>>
>>>> In trunk, I modified the definition of URL so that it returns the
>>>> XML(..) helper wrapping the string. This will prevent
>>
>>>> {{=URL(...)}}
>>
>>>> from double escaping but will prevent you from doing
>>
>>>> 'http://127.0.0.:8000'+URL(..)
>>
>>> Couldn't this be fixed by implementing URL.__radd__() ?
>>
>> I meant XML.__radd__()
>>
>>
>>
>>>def __add__(self,other):
>>>return '%s%s' % (self,other)
>>
>>>def __radd__(self,other):
>>>return '%s%s' % (other,self)
>>
>>>> you would have to do
>>
>>>> 'http://127.0.0.:8000%s'% URL(..)
>>
>>>> we cannot have it both ways.
Re: [web2py] Re: Should we have a feature freeze and stability maintenance period in future?
On Aug 20, 2010, at 2:40 PM, mdipierro wrote: > I see a lot of value in > > - bug-squishing-contest , > - Stress test, Test everything , try to crash web2py etc. > - fix bugs, fix performance issues , improve performance > - code cleanup , documentation. > > we can set deadlines for that. This means we would stress test and > improve features existing at a certain date and we would only add new > features tagged as "experimental" that do not interfere with parts > that are being stress tested. Makes sense? I think so, as long as the terms are clear. In particular, it should be clear how the experimental features would move to stable (perhaps just a time limit on the stress test, or some more specific condition). Perhaps in going through an exercise like this, we could also think about something like it could be incorporated into the normal development cycle, on an ongoing basis rather than as a one-shot project.
Re: [web2py] Re: TypeError: 'XML' object is unsubscriptable
On Aug 21, 2010, at 10:02 PM, mdipierro wrote: > Did you try 819? I think XML needs this: def __getitem__(self, key): return str(self).__getitem__(key) > > Massimo > > On Aug 21, 11:01 pm, "mr.freeze" wrote: >> I get the same thing on a newly created app when running from trunk: >> >> Traceback (most recent call last): >> File "C:\web2py\gluon\restricted.py", line 188, in restricted >> exec ccode in environment >> File "C:\web2py\applications\crashtest/views\default/index.html", >> line 27, in >> TypeError: 'XML' object is unsubscriptable >> >> On Aug 21, 9:58 pm, mdipierro wrote: >> >>> Which version. If not web2py stable, please check latest trunk. >> >>> On Aug 21, 8:33 pm, Jose wrote: >> Hi, >> (I can not find the thread where it was this error) >> From admin create a new application: apptest >> go to:http://127.0.0.1:8000/apptest >> produces the following error: >> TypeError: 'XML' object is unsubscriptable >> if type(code) == types.CodeType: ccode = code else: ccode = compile2(code,layer) >> exec ccode in environment >> except HTTP: raise except Exception: # XXX Show exception in Wing IDE if running in debugger
Re: [web2py] Re: TypeError: 'XML' object is unsubscriptable
On Aug 21, 2010, at 10:41 PM, mdipierro wrote: > I had it, together with __getslice__, I thought I pushed in 819 but > perhaps I did not. Pushing again. That's better. > > On Aug 22, 12:17 am, Jonathan Lundell wrote: >> On Aug 21, 2010, at 10:02 PM, mdipierro wrote: >> >>> Did you try 819? >> >> I think XML needs this: >> >> def __getitem__(self, key): >> return str(self).__getitem__(key) >> >> >> >>> Massimo >> >>> On Aug 21, 11:01 pm, "mr.freeze" wrote: >>>> I get the same thing on a newly created app when running from trunk: >> >>>> Traceback (most recent call last): >>>> File "C:\web2py\gluon\restricted.py", line 188, in restricted >>>> exec ccode in environment >>>> File "C:\web2py\applications\crashtest/views\default/index.html", >>>> line 27, in >>>> TypeError: 'XML' object is unsubscriptable >> >>>> On Aug 21, 9:58 pm, mdipierro wrote: >> >>>>> Which version. If not web2py stable, please check latest trunk. >> >>>>> On Aug 21, 8:33 pm, Jose wrote: >> >>>>>> Hi, >> >>>>>> (I can not find the thread where it was this error) >> >>>>>> From admin create a new application: apptest >> >>>>>> go to:http://127.0.0.1:8000/apptest >> >>>>>> produces the following error: >> >>>>>> TypeError: 'XML' object is unsubscriptable >> >>>>>> if type(code) == types.CodeType: >>>>>> ccode = code >>>>>> else: >>>>>> ccode = compile2(code,layer) >> >>>>>> exec ccode in environment >> >>>>>> except HTTP: >>>>>> raise >>>>>> except Exception: >>>>>> # XXX Show exception in Wing IDE if running in debugger
Re: [web2py] Re: Should we have a feature freeze and stability maintenance period in future?
On Aug 24, 2010, at 11:29 AM, mart wrote: > Well, this is all interesting :) After reading Michele's email, I just > had to spend hours looking at Mercurial (& the like) as deeply as the > day would let me (I'm on PTO, so I can do this). I thought I had a > good idea about "distributed" version control system but, as it turns > out, a few surprises were there waiting for me. I have always been a > believer in "development against the known reference version" (now, > that's me being old fashioned). So, yes... Mercurial must be a painful > thing. Based on what I have read, mercurial seems a little too > chaotic for my taste. I do believe there is one way to manage a source > repository (did I really just say that?) wrt to input/output. Well, > honestly, I am way too big of a "exactly what is going to any of the > products I build" junky, to even accept some of the basic premises of > Mercurial. Like any workingDirectory is a potential branch? The O'Reilly Hg book "Mercurial: The Definitive Guide" is a really good reference here, not just for day-to-day help, but for real insight into the advantages and strategies of distributed version control. Highly recommended.
Re: [web2py] dashes in controller names?
On Aug 24, 2010, at 6:47 PM, Cory Coager wrote: > How do you use dashes in controller names? I get errors, "Invalid > request". You can't. The URL parser allows only \w+ (alphanumeric or underscore).
Re: [web2py] Re: dashes in controller names?
On Aug 24, 2010, at 8:03 PM, Kevin wrote:
> As far as I can find, you have to set up web2py routes to do this --
> it's pretty easy to do redirection using routes (using routes_in), but
> I'm not aware of any way off-hand to do the equivalent of rewriting/
> translation the URL for inbound requests (routes_out does to
> translation).
I think it would be difficult, unless you explicitly translated known
controller names. Which you could do...
We could translate incoming hyphens to underscores, I suppose, without too much
effort, but we wouldn't know whether to reverse the translation on the outbound
side.
Come the revolution (new rewrite logic), all things will be possible. But no
promises on a schedule.
We *could* simply allow hyphens in controller names, without translation. We
can't do that with functions, since they need to function as Python
identifiers.
>
> This is something I (and doubtless) many others need as well, and it
> really should be a (default enabled) option for web2py to
> automatically treat URL-embedded hyphens as though they were
> underscores for matching app, controller and function names, and an
> optionally enablable setting to make all generated routes use hyphens
> instead of underscores for apps, controllers, and functions.
>
> The open-and-shut arguments for using hyphens boil down to (in order
> of severity):
>
> * Underscores are obscured when URLs are underlined
> * Hyphens are easier to type than underscores – no need for the shift
> key
> * Hyphens are easier to read
> * Underscores are a typographical construction invented primarily for
> underlining characters ( on a
> typewriter), and today is used primarily in programming and other
> technical contexts. In short, there is little justification for
> exposing back-end considerations to the world.
>
> Many references can be found on this subject:
>
> *
> http://pylonsbook.com/en/1.1/urls-routing-and-dispatch.html#choosing-good-urls
> * http://semicolons.org/post/256699383/friendly-urls
> *
> http://www.wordsellinc.com/blog/content-optimization/use-hyphens-not-underscores-in-urls/
>
> This is one of the sore points I have with anything I put on the web
> -- to provide what I feel is a correct URL scheme to the user, I'll
> bypass or override half of the backend code if necessary, which is
> suboptimal.
>
> Web2py is very close to making it easy to provide URLs that'll
> withstand the scrutiny of bloggers -- besides the hyphen bit, all I
> really see as being needed is:
>
> * The aforementioned settings for hyphenization.
>
> * in routes_in and routes_out add the ability to supply a function/
> lambda in the second index of any inner two-tuple, which would receive
> a match object and return a string. For example, the following could
> be a stop-gap way to perform this kind of underscore-to-hyphen
> conversion:
>
> routes_out = ( (r'/([^/]*)/([^/]*)/([^/]*)(/?P.*)?',
> lambda match: '/'.join(part.replace('_', '-') for part in
> match.groups()) + match.group('any')), )
>
> On Aug 24, 7:47 pm, Cory Coager wrote:
>> How do you use dashes in controller names? I get errors, "Invalid
>> request".
Re: [web2py] Re: dashes in controller names?
On Aug 25, 2010, at 1:42 AM, Kevin wrote:
> It would be safe for the routing code to treat hyphens as underscores
> when matching for app, controller, or function, though -- since web2py
> (and python) semantics require that the code itself uses underscores.
> Of course underscores in the rest of the URL would have to pass
> through untouched.
Are Python restrictions relevant for applications and controllers? Or just
filename restrictions? I'm not sure.
>
> Reverse translation is not an issue, since I could just do something
> like:
>
> {{= DASH(URL(...)) }}
>
> Where DASH replaces all underscores with hyphens (which is acceptable
> for me, since I don't use any underscores in URLs), though it would be
> handy to make the routes.py configurable to do that automatically in
> the URL call itself if I wanted.
It could be an option to URL, I suppose. I'm thinking that you wouldn't want to
translate underscores in the query string.
>
> On Aug 24, 9:46 pm, Jonathan Lundell wrote:
>> On Aug 24, 2010, at 8:03 PM, Kevin wrote:
>>
>>> As far as I can find, you have to set up web2py routes to do this --
>>> it's pretty easy to do redirection using routes (using routes_in), but
>>> I'm not aware of any way off-hand to do the equivalent of rewriting/
>>> translation the URL for inbound requests (routes_out does to
>>> translation).
>>
>> I think it would be difficult, unless you explicitly translated known
>> controller names. Which you could do...
>>
>> We could translate incoming hyphens to underscores, I suppose, without too
>> much effort, but we wouldn't know whether to reverse the translation on the
>> outbound side.
>>
>> Come the revolution (new rewrite logic), all things will be possible. But no
>> promises on a schedule.
>>
>> We *could* simply allow hyphens in controller names, without translation. We
>> can't do that with functions, since they need to function as Python
>> identifiers.
>>
>>
>>
>>> This is something I (and doubtless) many others need as well, and it
>>> really should be a (default enabled) option for web2py to
>>> automatically treat URL-embedded hyphens as though they were
>>> underscores for matching app, controller and function names, and an
>>> optionally enablable setting to make all generated routes use hyphens
>>> instead of underscores for apps, controllers, and functions.
>>
>>> The open-and-shut arguments for using hyphens boil down to (in order
>>> of severity):
>>
>>> * Underscores are obscured when URLs are underlined
>>> * Hyphens are easier to type than underscores – no need for the shift
>>> key
>>> * Hyphens are easier to read
>>> * Underscores are a typographical construction invented primarily for
>>> underlining characters ( on a
>>> typewriter), and today is used primarily in programming and other
>>> technical contexts. In short, there is little justification for
>>> exposing back-end considerations to the world.
>>
>>> Many references can be found on this subject:
>>
>>> *http://pylonsbook.com/en/1.1/urls-routing-and-dispatch.html#choosing-...
>>> *http://semicolons.org/post/256699383/friendly-urls
>>> *http://www.wordsellinc.com/blog/content-optimization/use-hyphens-not-...
>>
>>> This is one of the sore points I have with anything I put on the web
>>> -- to provide what I feel is a correct URL scheme to the user, I'll
>>> bypass or override half of the backend code if necessary, which is
>>> suboptimal.
>>
>>> Web2py is very close to making it easy to provide URLs that'll
>>> withstand the scrutiny of bloggers -- besides the hyphen bit, all I
>>> really see as being needed is:
>>
>>> * The aforementioned settings for hyphenization.
>>
>>> * in routes_in and routes_out add the ability to supply a function/
>>> lambda in the second index of any inner two-tuple, which would receive
>>> a match object and return a string. For example, the following could
>>> be a stop-gap way to perform this kind of underscore-to-hyphen
>>> conversion:
>>
>>> routes_out = ( (r'/([^/]*)/([^/]*)/([^/]*)(/?P.*)?',
>>> lambda match: '/'.join(part.replace('_', '-') for part in
>>> match.groups()) + match.group('any')), )
>>
>>> On Aug 24, 7:47 pm, Cory Coager wrote:
>>>> How do you use dashes in controller names? I get errors, "Invalid
>>>> request".
>>
>>
Re: [web2py] Re: IS_IMAGE() broke?
On Aug 25, 2010, at 8:11 AM, Joe Wakefield wrote:
> The assertion errors are blank, so I added some extra output:
>
> -IS_IMAGE STARTED-
> filename: 1.png
> extension: png
> self.extensions: jpeg
> ERROR IN IS_IMAGE:
>
> -IS_IMAGE STARTED-
> filename: llamas.jpg
> extension: jpg
> self.extensions: jpeg
> __jpeg called
> width, height: 400, 300
> new: users.photo.81f708977b7f7851.6c6c616d61732e6a7067.jpgold:
>
> -IS_IMAGE STARTED-
> filename: 1.png
> extension: png
> self.extensions: jpeg
> ERROR IN IS_IMAGE:
> new: users.photo.8ef32f83074cd5bf.312e706e67.pngold: users.photo.
> 81f708977b7f7851.6c6c616d61732e6a7067.jpg
>
> -IS_IMAGE STARTED-
> filename: test.zip
> extension: zip
> self.extensions: jpeg
> ERROR IN IS_IMAGE:
> new: users.photo.a4b74cd11efaf711.746573742e7a6970.zipold:
> users.photo.8ef32f83074cd5bf.312e706e67.png
>
> This would suggest that the IS_IMAGE validator is working fine, and
> I'm guessing the problem would be in sqlform.accepts()?
My desk-check of IS_IMAGE suggested that it was OK, too. It could use a couple
of documenting doctests, I think.
You're deliberately restricting it to jpeg above, right? Hence the rejection of
png?
>
>
> On Aug 25, 10:17 am, mdipierro wrote:
>> can you help me debug?
>>
>> in gluon/validators.py
>>
>> classIS_IMAGE:
>> def __call__(self,value):
>>
>> except:
>> return (value, self.error_message)
>>
>> replace last two lines with
>>
>> except Exception, e:
>> return (value, str(r))
>>
>> what does the error say?
>>
>> On Aug 23, 4:06 pm, mdipierro wrote:
>>
>>> Something is wrong here
>>
>>> IS_IMAGE(extensions=('jpeg'))
>>
>>> should be
>>
>>> IS_IMAGE(extensions=('jpeg',))
>>
>>> A tuple of one element must contain a comma. Not sure if that may be
>>> the cause of your problem.
>>
>>> On Aug 23, 3:16 pm, Joe Wakefield wrote:
>>
I was also experiencing this issue, but found that rebuilding the
database only worked until the first valid upload, after which it is
broken again.
>>
In my case, I am using:
Field('photo', 'upload', uploadfield='photo_data',
requires=IS_IMAGE(extensions=('jpeg'))),
Field('photo_data', 'blob', requires=IS_IMAGE(extensions=('jpeg'))),
>>
And was using SQLFORM to display the update form.
>>
When I first added this, it was accepting absolutely everything (pdf,
odt, zip) as an upload. I deleted my database entirely, and had it
rebuilt. I first noticed that it started rejecting non-image uploads.
However, once I had uploaded an image, all subsequent uploads of non-
image types were allowed again. A second database build showed the
exact same behaviour; proper rejection until the first valid upload.
>>
I then made a backup of my web2py folder, and extracted today's
nightly build over my folder. Rebuilding my database one last time, it
shows the exact same behaviour.
>>
On Jul 11, 2:56 pm, Rob wrote:
>>
> I just recently added:
>>
> db.Item.image.requires =IS_IMAGE()
>>
> The records that existed prior to adding this line does not obey
> theIS_IMAGE() (ie: they still allow me to upload a PDF). All new records
> created DO work - they force me to select an image or else they show
> an error.
>>
> steps to reproduce (untested)
> 1) create DB
> db.define_table('Item',
> Field('description'),
> Field('need', 'boolean'),
> Field('image', 'upload'))
>>
> 2) add rows to the table
> 3) add rules:
> db.Item.category.requires = IS_IN_DB(db, db.Category.id,'%(name)s')
> db.Item.description.requires = IS_NOT_EMPTY()
> db.Item.image.requires =IS_IMAGE()
>>
> 4) go back to the rows you added to the Item table and add non-image
> files - notice it works
>>
> Does that help?
>>
> On Jul 11, 11:42 am, mdipierro wrote:
>>
>> Please tell us more. When do you get an error? What is the error?
>>
>> On 11 Lug, 11:57, Rob wrote:
>>
>>> This issue only happens for records that were created before I added
>>> the .requires fields. Error handling on new records works as
>>> expected... so... is it still a bug?
>>
>>> On Jul 11, 9:15 am, Rob wrote:
>>
db.define_table('Category',
Field('name'))
>>
db.define_table('Item',
Field('category', db.Category),
Field('description'),
Field('need', 'boolean'),
Field('image', 'upload'))
>>
db.Item.category.requires = IS_IN_DB(db, db.Category.id)
db.Item.description.requires = IS_NOT_EMPTY()
db.Item.image.requires =IS_IMAGE()
>>
def details():
item = request.args(0)
form = crud.update(db.Item, item, next=URL(r=request, args=ite
Re: [web2py] Re: IS_IMAGE() broke?
On Aug 25, 2010, at 8:33 AM, Joe Wakefield wrote:
> I'll do you one better. The problem is in "sqlhtml.py" at lines
> 909-917. It changes ret=False to ret=True if the field already has a
> value.
Good catch. This is a case where a comment documenting the intent of this hunk
of code would come in handy for those of us reading it. The error is cancelled
under certain conditions, but what's the intent?
>
> ===
> ret, errors: False,
> new ret:False
> ===
> ret, errors: True,
> new ret:True
> new: users.photo.8a5327ab32003765.6c6c616d61732e6a7067.jpgold:
> ===
> ret, errors: False,
> new ret:True
> new: users.photo.b6369c7a23ae4813.312e706e67.pngold: users.photo.
> 8a5327ab32003765.6c6c616d61732e6a7067.jpg
>
> On Aug 25, 10:17 am, mdipierro wrote:
>> can you help me debug?
>>
>> in gluon/validators.py
>>
>> classIS_IMAGE:
>> def __call__(self,value):
>>
>> except:
>> return (value, self.error_message)
>>
>> replace last two lines with
>>
>> except Exception, e:
>> return (value, str(r))
>>
>> what does the error say?
>>
>> On Aug 23, 4:06 pm, mdipierro wrote:
>>
>>> Something is wrong here
>>
>>> IS_IMAGE(extensions=('jpeg'))
>>
>>> should be
>>
>>> IS_IMAGE(extensions=('jpeg',))
>>
>>> A tuple of one element must contain a comma. Not sure if that may be
>>> the cause of your problem.
>>
>>> On Aug 23, 3:16 pm, Joe Wakefield wrote:
>>
I was also experiencing this issue, but found that rebuilding the
database only worked until the first valid upload, after which it is
broken again.
>>
In my case, I am using:
Field('photo', 'upload', uploadfield='photo_data',
requires=IS_IMAGE(extensions=('jpeg'))),
Field('photo_data', 'blob', requires=IS_IMAGE(extensions=('jpeg'))),
>>
And was using SQLFORM to display the update form.
>>
When I first added this, it was accepting absolutely everything (pdf,
odt, zip) as an upload. I deleted my database entirely, and had it
rebuilt. I first noticed that it started rejecting non-image uploads.
However, once I had uploaded an image, all subsequent uploads of non-
image types were allowed again. A second database build showed the
exact same behaviour; proper rejection until the first valid upload.
>>
I then made a backup of my web2py folder, and extracted today's
nightly build over my folder. Rebuilding my database one last time, it
shows the exact same behaviour.
>>
On Jul 11, 2:56 pm, Rob wrote:
>>
> I just recently added:
>>
> db.Item.image.requires =IS_IMAGE()
>>
> The records that existed prior to adding this line does not obey
> theIS_IMAGE() (ie: they still allow me to upload a PDF). All new records
> created DO work - they force me to select an image or else they show
> an error.
>>
> steps to reproduce (untested)
> 1) create DB
> db.define_table('Item',
> Field('description'),
> Field('need', 'boolean'),
> Field('image', 'upload'))
>>
> 2) add rows to the table
> 3) add rules:
> db.Item.category.requires = IS_IN_DB(db, db.Category.id,'%(name)s')
> db.Item.description.requires = IS_NOT_EMPTY()
> db.Item.image.requires =IS_IMAGE()
>>
> 4) go back to the rows you added to the Item table and add non-image
> files - notice it works
>>
> Does that help?
>>
> On Jul 11, 11:42 am, mdipierro wrote:
>>
>> Please tell us more. When do you get an error? What is the error?
>>
>> On 11 Lug, 11:57, Rob wrote:
>>
>>> This issue only happens for records that were created before I added
>>> the .requires fields. Error handling on new records works as
>>> expected... so... is it still a bug?
>>
>>> On Jul 11, 9:15 am, Rob wrote:
>>
db.define_table('Category',
Field('name'))
>>
db.define_table('Item',
Field('category', db.Category),
Field('description'),
Field('need', 'boolean'),
Field('image', 'upload'))
>>
db.Item.category.requires = IS_IN_DB(db, db.Category.id)
db.Item.description.requires = IS_NOT_EMPTY()
db.Item.image.requires =IS_IMAGE()
>>
def details():
item = request.args(0)
form = crud.update(db.Item, item, next=URL(r=request, args=item))
return dict(form=form)
>>
It allows me to upload PDFs and flashes 'record updated'
>>
>>
Re: [web2py] Re: Web2py and threads
On Aug 25, 2010, at 9:00 AM, Phyo Arkar wrote: > Did I Read that reading files inside controller will block web2py , Does it? > > Thats a bad news.. i am doing a file crawler and while crawling , > web2py is blocked even tho the process talke only 25% of 1 out of 4 > CPUs .. This stuff gets a little coverage in the book's deployment chapter, but it could use a systematic discussion. What are the implication for web2py apps of http server policies, database locks (sqlite especially), session locking, the GIL, etc? With a section on best practices. > > > > On 8/25/10, pierreth wrote: >> I would appreciate a good reference to understand the concepts you are >> talking about. It is something new to me and I don't understand. >> >> On 25 août, 11:22, John Heenan wrote: >>> No, nothing that abstract. Using WSGI forces a new thread for each >>> request. This is is a simple and inefficient brute force approach that >>> really only suits the simplest Python applications and where only a >>> small number of concurrent connection might be expected. >>> >>> Any application that provides web services is going to OS block on >>> file reading (and writing) and on database access. Using threads is a >>> classic and easy way out that carries a lot of baggage. Windows has >>> had a way out of this for years with its asynch (or event) >>> notification set up through an OVERLAPPED structure. >>> >>> Lightttpd makes use of efficient event notification schemes like >>> kqueue and epoll. Apache only uses such schemes for listening and Keep- >>> Alives. >>> >>> No matter how careful one is with threads and processes there always >>> appears to be unexpected gotchas. Python has a notorious example, the >>> now fixed 'Beazly Effect' that affected the GIL. Also I don't think >>> there is a single experienced Python user that trusts the GIL. >>> >>> John Heenan >>> >>
Re: [web2py] Re: Web2py and threads
On Aug 25, 2010, at 1:41 PM, mdipierro wrote: > > call > > session._unlock() > > if you do not need session locking If you do that (without calling session.forget), what will happen in _try_store_on_disk when cPickle.dump(dict(self), response.session_file) is called with a None file argument? Or is cPickle.dump cool with that? Or am I misreading the logic? > > On Aug 25, 11:38 am, Phyo Arkar wrote: >> Yes may be session was locked , thats why >> session.current=processing_path not working >> >> But then again , while processing files i try opening separate page , >> to other controller , it was waited till the first (file Crawler) page >> finished parsing. >> >> ok i will make a separate thread about this. >> >> On 8/25/10, mdipierro wrote: >> >> >> >>> On Aug 25, 11:00 am, Phyo Arkar wrote: Did I Read that reading files inside controller will block web2py , Does it? >> >>> No web2py does not block. web2py only locks sessions that means one >>> user cannot request two concurrent pages because there would be a race >>> condition in saving sessions. Two user can request different pages >>> which open the same file unless the file is explicitly locked by your >>> code. >> Thats a bad news.. i am doing a file crawler and while crawling , web2py is blocked even tho the process talke only 25% of 1 out of 4 CPUs .. >> >>> Tell us more or I cannot help. >> On 8/25/10, pierreth wrote: >> > I would appreciate a good reference to understand the concepts you are > talking about. It is something new to me and I don't understand. >> > On 25 août, 11:22, John Heenan wrote: >> No, nothing that abstract. Using WSGI forces a new thread for each >> request. This is is a simple and inefficient brute force approach that >> really only suits the simplest Python applications and where only a >> small number of concurrent connection might be expected. >> >> Any application that provides web services is going to OS block on >> file reading (and writing) and on database access. Using threads is a >> classic and easy way out that carries a lot of baggage. Windows has >> had a way out of this for years with its asynch (or event) >> notification set up through an OVERLAPPED structure. >> >> Lightttpd makes use of efficient event notification schemes like >> kqueue and epoll. Apache only uses such schemes for listening and Keep- >> Alives. >> >> No matter how careful one is with threads and processes there always >> appears to be unexpected gotchas. Python has a notorious example, the >> now fixed 'Beazly Effect' that affected the GIL. Also I don't think >> there is a single experienced Python user that trusts the GIL. >> >> John Heenan
Re: [web2py] Re: Web2py and threads
On Aug 25, 2010, at 6:37 PM, mdipierro wrote: > > The problem is only if have two http request from the same client in > the same session Thanks for that; I was wondering under which conditions unlocking might be permissible (and I'm still not entirely clear, but never mind for now). My concern is this. Here's unlock: def _unlock(self, response): if response and response.session_file: try: portalocker.unlock(response.session_file) response.session_file.close() del response.session_file <<<<<- except: ### this should never happen but happens in Windows pass Now we save the session file: def _try_store_on_disk(self, request, response): if response._dbtable_and_field \ or not response.session_id \ or self._forget: self._unlock(response) return if response.session_new: # Tests if the session folder exists, if not, create it session_folder = os.path.dirname(response.session_filename) response.session_file = open(response.session_filename, 'wb') portalocker.lock(response.session_file, portalocker.LOCK_EX) cPickle.dump(dict(self), response.session_file) <<<<<<<<< self._unlock(response) But response.session_file is None at this point. > > A arrives loads session and unlocks > B arrives loads session and unlocks > A change session and saves it > B changes session and saves it > > Nothing breaks but B never sees changes made by A and they are > overwritten by B. > With locks > > A arrives loads session > B arrives and waits > A change session and saves it > B loads session (with changes made by A) > B changes session and saves it > > > On Aug 25, 3:52 pm, Jonathan Lundell wrote: >> On Aug 25, 2010, at 1:41 PM, mdipierro wrote: >> >> >> >>> call >> >>> session._unlock() >> >>> if you do not need session locking >> >> If you do that (without calling session.forget), what will happen in >> _try_store_on_disk when cPickle.dump(dict(self), response.session_file) is >> called with a None file argument? Or is cPickle.dump cool with that? Or am I >> misreading the logic? >> >> >> >>> On Aug 25, 11:38 am, Phyo Arkar wrote: >>>> Yes may be session was locked , thats why >>>> session.current=processing_path not working >> >>>> But then again , while processing files i try opening separate page , >>>> to other controller , it was waited till the first (file Crawler) page >>>> finished parsing. >> >>>> ok i will make a separate thread about this. >> >>>> On 8/25/10, mdipierro wrote: >> >>>>> On Aug 25, 11:00 am, Phyo Arkar wrote: >>>>>> Did I Read that reading files inside controller will block web2py , Does >>>>>> it? >> >>>>> No web2py does not block. web2py only locks sessions that means one >>>>> user cannot request two concurrent pages because there would be a race >>>>> condition in saving sessions. Two user can request different pages >>>>> which open the same file unless the file is explicitly locked by your >>>>> code. >> >>>>>> Thats a bad news.. i am doing a file crawler and while crawling , >>>>>> web2py is blocked even tho the process talke only 25% of 1 out of 4 >>>>>> CPUs .. >> >>>>> Tell us more or I cannot help. >> >>>>>> On 8/25/10, pierreth wrote: >> >>>>>>> I would appreciate a good reference to understand the concepts you are >>>>>>> talking about. It is something new to me and I don't understand. >> >>>>>>> On 25 août, 11:22, John Heenan wrote: >>>>>>>> No, nothing that abstract. Using WSGI forces a new thread for each >>>>>>>> request. This is is a simple and inefficient brute force approach that >>>>>>>> really only suits the simplest Python applications and where only a >>>>>>>> small number of concurrent connection might be expected. >> >>>>>>>> Any application that provides web services is going to OS block on >>>>>>>> file reading (and writing) and on database access. Using threads is a >>>>>>>> classic and easy way out that carries a lot of baggage. Windows has >>>>>>>> had a way out of this for years with its asynch (or event) >>>>>>>> notification set up through an OVERLAPPED structure. >> >>>>>>>> Lightttpd makes use of efficient event notification schemes like >>>>>>>> kqueue and epoll. Apache only uses such schemes for listening and Keep- >>>>>>>> Alives. >> >>>>>>>> No matter how careful one is with threads and processes there always >>>>>>>> appears to be unexpected gotchas. Python has a notorious example, the >>>>>>>> now fixed 'Beazly Effect' that affected the GIL. Also I don't think >>>>>>>> there is a single experienced Python user that trusts the GIL. >> >>>>>>>> John Heenan
Re: [web2py] Re: Web2py and threads
On Aug 25, 2010, at 7:56 PM, mdipierro wrote: > > This is a bug. I fixed it in trunk. Thanks Jonathan. It's fixed in the sense that it won't raise an exception. But now how is calling _unlock different from calling forget? > > On Aug 25, 9:30 pm, Jonathan Lundell wrote: >> On Aug 25, 2010, at 6:37 PM, mdipierro wrote: >> >> >> >>> The problem is only if have two http request from the same client in >>> the same session >> >> Thanks for that; I was wondering under which conditions unlocking might be >> permissible (and I'm still not entirely clear, but never mind for now). >> >> My concern is this. Here's unlock: >> >> def _unlock(self, response): >> if response and response.session_file: >> try: >> portalocker.unlock(response.session_file) >> response.session_file.close() >> del response.session_file <<<<<- >> except: ### this should never happen but happens in Windows >> pass >> >> Now we save the session file: >> >> def _try_store_on_disk(self, request, response): >> if response._dbtable_and_field \ >> or not response.session_id \ >> or self._forget: >> self._unlock(response) >> return >> if response.session_new: >> # Tests if the session folder exists, if not, create it >> session_folder = os.path.dirname(response.session_filename) >> response.session_file = open(response.session_filename, 'wb') >> portalocker.lock(response.session_file, portalocker.LOCK_EX) >> cPickle.dump(dict(self), response.session_file) >> <<<<<<<<< >> self._unlock(response) >> >> But response.session_file is None at this point. >> >> >> >>> A arrives loads session and unlocks >>> B arrives loads session and unlocks >>> A change session and saves it >>> B changes session and saves it >> >>> Nothing breaks but B never sees changes made by A and they are >>> overwritten by B. >>> With locks >> >>> A arrives loads session >>> B arrives and waits >>> A change session and saves it >>> B loads session (with changes made by A) >>> B changes session and saves it >> >>> On Aug 25, 3:52 pm, Jonathan Lundell wrote: >>>> On Aug 25, 2010, at 1:41 PM, mdipierro wrote: >> >>>>> call >> >>>>> session._unlock() >> >>>>> if you do not need session locking >> >>>> If you do that (without calling session.forget), what will happen in >>>> _try_store_on_disk when cPickle.dump(dict(self), response.session_file) is >>>> called with a None file argument? Or is cPickle.dump cool with that? Or am >>>> I misreading the logic? >> >>>>> On Aug 25, 11:38 am, Phyo Arkar wrote: >>>>>> Yes may be session was locked , thats why >>>>>> session.current=processing_path not working >> >>>>>> But then again , while processing files i try opening separate page , >>>>>> to other controller , it was waited till the first (file Crawler) page >>>>>> finished parsing. >> >>>>>> ok i will make a separate thread about this. >> >>>>>> On 8/25/10, mdipierro wrote: >> >>>>>>> On Aug 25, 11:00 am, Phyo Arkar wrote: >>>>>>>> Did I Read that reading files inside controller will block web2py , >>>>>>>> Does >>>>>>>> it? >> >>>>>>> No web2py does not block. web2py only locks sessions that means one >>>>>>> user cannot request two concurrent pages because there would be a race >>>>>>> condition in saving sessions. Two user can request different pages >>>>>>> which open the same file unless the file is explicitly locked by your >>>>>>> code. >> >>>>>>>> Thats a bad news.. i am doing a file crawler and while crawling , >>>>>>>> web2py is blocked even tho the process talke only 25% of 1 out of 4 >>>>>>>> CPUs .. >> >>>>>>> Tell us more or I cannot help. >> >>>>>>>
Re: [web2py] Re: IS_IMAGE() broke?
On Aug 26, 2010, at 6:56 AM, Joe Wakefield wrote:
>
> Massimo,
>
> The new code works great! Thanks for the quick fix.
And yes, the comment is helpful.
>
> Regards,
> Joe
>
> On Aug 25, 10:51 pm, mdipierro wrote:
>> Please check if this is fixed in trunk and if the comment I added
>> makes any sense.
>>
>> Massimo
>>
>> On Aug 25, 10:59 am, Jonathan Lundell wrote:
>>
>>> On Aug 25, 2010, at 8:33 AM, Joe Wakefield wrote:
>>
>>>> I'll do you one better. The problem is in "sqlhtml.py" at lines
>>>> 909-917. It changes ret=False to ret=True if the field already has a
>>>> value.
>>
>>> Good catch. This is a case where a comment documenting the intent of this
>>> hunk of code would come in handy for those of us reading it. The error is
>>> cancelled under certain conditions, but what's the intent?
>>
>>>> ===
>>>> ret, errors: False,
>>>> new ret:False
>>>> ===
>>>> ret, errors: True,
>>>> new ret:True
>>>> new: users.photo.8a5327ab32003765.6c6c616d61732e6a7067.jpgold:
>>>> ===
>>>> ret, errors: False,
>>>> new ret:True
>>>> new: users.photo.b6369c7a23ae4813.312e706e67.pngold: users.photo.
>>>> 8a5327ab32003765.6c6c616d61732e6a7067.jpg
>>
>>>> On Aug 25, 10:17 am, mdipierro wrote:
>>>>> can you help me debug?
>>
>>>>> in gluon/validators.py
>>
>>>>> classIS_IMAGE:
>>>>> def __call__(self,value):
>>>>>
>>>>> except:
>>>>> return (value, self.error_message)
>>
>>>>> replace last two lines with
>>
>>>>> except Exception, e:
>>>>> return (value, str(r))
>>
>>>>> what does the error say?
>>
>>>>> On Aug 23, 4:06 pm, mdipierro wrote:
>>
>>>>>> Something is wrong here
>>
>>>>>> IS_IMAGE(extensions=('jpeg'))
>>
>>>>>> should be
>>
>>>>>> IS_IMAGE(extensions=('jpeg',))
>>
>>>>>> A tuple of one element must contain a comma. Not sure if that may be
>>>>>> the cause of your problem.
>>
>>>>>> On Aug 23, 3:16 pm, Joe Wakefield wrote:
>>
>>>>>>> I was also experiencing this issue, but found that rebuilding the
>>>>>>> database only worked until the first valid upload, after which it is
>>>>>>> broken again.
>>
>>>>>>> In my case, I am using:
>>>>>>> Field('photo', 'upload', uploadfield='photo_data',
>>>>>>> requires=IS_IMAGE(extensions=('jpeg'))),
>>>>>>> Field('photo_data', 'blob', requires=IS_IMAGE(extensions=('jpeg'))),
>>
>>>>>>> And was using SQLFORM to display the update form.
>>
>>>>>>> When I first added this, it was accepting absolutely everything (pdf,
>>>>>>> odt, zip) as an upload. I deleted my database entirely, and had it
>>>>>>> rebuilt. I first noticed that it started rejecting non-image uploads.
>>>>>>> However, once I had uploaded an image, all subsequent uploads of non-
>>>>>>> image types were allowed again. A second database build showed the
>>>>>>> exact same behaviour; proper rejection until the first valid upload.
>>
>>>>>>> I then made a backup of my web2py folder, and extracted today's
>>>>>>> nightly build over my folder. Rebuilding my database one last time, it
>>>>>>> shows the exact same behaviour.
>>
>>>>>>> On Jul 11, 2:56 pm, Rob wrote:
>>
>>>>>>>> I just recently added:
>>
>>>>>>>> db.Item.image.requires =IS_IMAGE()
>>
>>>>>>>> The records that existed prior to adding this line does not obey
>>>>>>>> theIS_IMAGE() (ie: they still allow me to upload a PDF). All new
>>>>>>>> records
>>>>>>>> created DO work - they force me to select an image or else they show
>>>>>>>> an error.
>>
>>>>>>>> steps to reproduce (untested)
>>>>>>>&
Re: [web2py] Re: Web2py and threads
On Aug 25, 2010, at 8:12 PM, Jonathan Lundell wrote: > > On Aug 25, 2010, at 7:56 PM, mdipierro wrote: >> >> This is a bug. I fixed it in trunk. Thanks Jonathan. > > It's fixed in the sense that it won't raise an exception. But now how is > calling _unlock different from calling forget? Nag. > >> >> On Aug 25, 9:30 pm, Jonathan Lundell wrote: >>> On Aug 25, 2010, at 6:37 PM, mdipierro wrote: >>> >>> >>> >>>> The problem is only if have two http request from the same client in >>>> the same session >>> >>> Thanks for that; I was wondering under which conditions unlocking might be >>> permissible (and I'm still not entirely clear, but never mind for now). >>> >>> My concern is this. Here's unlock: >>> >>>def _unlock(self, response): >>>if response and response.session_file: >>>try: >>>portalocker.unlock(response.session_file) >>>response.session_file.close() >>>del response.session_file <<<<<- >>>except: ### this should never happen but happens in Windows >>>pass >>> >>> Now we save the session file: >>> >>>def _try_store_on_disk(self, request, response): >>>if response._dbtable_and_field \ >>>or not response.session_id \ >>>or self._forget: >>>self._unlock(response) >>>return >>>if response.session_new: >>># Tests if the session folder exists, if not, create it >>>session_folder = os.path.dirname(response.session_filename) >>>response.session_file = open(response.session_filename, 'wb') >>>portalocker.lock(response.session_file, portalocker.LOCK_EX) >>>cPickle.dump(dict(self), response.session_file) >>> <<<<<<<<< >>>self._unlock(response) >>> >>> But response.session_file is None at this point. >>> >>> >>> >>>> A arrives loads session and unlocks >>>> B arrives loads session and unlocks >>>> A change session and saves it >>>> B changes session and saves it >>> >>>> Nothing breaks but B never sees changes made by A and they are >>>> overwritten by B. >>>> With locks >>> >>>> A arrives loads session >>>> B arrives and waits >>>> A change session and saves it >>>> B loads session (with changes made by A) >>>> B changes session and saves it >>> >>>> On Aug 25, 3:52 pm, Jonathan Lundell wrote: >>>>> On Aug 25, 2010, at 1:41 PM, mdipierro wrote: >>> >>>>>> call >>> >>>>>> session._unlock() >>> >>>>>> if you do not need session locking >>> >>>>> If you do that (without calling session.forget), what will happen in >>>>> _try_store_on_disk when cPickle.dump(dict(self), response.session_file) >>>>> is called with a None file argument? Or is cPickle.dump cool with that? >>>>> Or am I misreading the logic? >>> >>>>>> On Aug 25, 11:38 am, Phyo Arkar wrote: >>>>>>> Yes may be session was locked , thats why >>>>>>> session.current=processing_path not working >>> >>>>>>> But then again , while processing files i try opening separate page , >>>>>>> to other controller , it was waited till the first (file Crawler) page >>>>>>> finished parsing. >>> >>>>>>> ok i will make a separate thread about this. >>> >>>>>>> On 8/25/10, mdipierro wrote: >>> >>>>>>>> On Aug 25, 11:00 am, Phyo Arkar wrote: >>>>>>>>> Did I Read that reading files inside controller will block web2py , >>>>>>>>> Does >>>>>>>>> it? >>> >>>>>>>> No web2py does not block. web2py only locks sessions that means one >>>>>>>> user cannot request two concurrent pages because there would be a race >>>>>>>> condition in saving sessions. Two user can request different pages >>>>>>>> which open the same fi
Re: [web2py] Re: best grid system
On Aug 28, 2010, at 10:07 AM, mdipierro wrote: > >> datatable --> i can do all i want, nice documentation/example > > good for searching but only for small datasets Supports server-side filtering, though: http://www.datatables.net/usage/server-side > >> jqgrid --> i cant find a good documentation, i can do only the basic >> configuration > > wery well documented and good implementation: > http://www.trirand.com/jqgridwiki/doku.php?id=wiki:jqgriddocs > powerfuls confifurations, seach and ajax features. Scales well with > large datasets (because ajax search). intergrated with plugin_wiki > (look at source code). > You can use it without much JS programming. > >> flexigrid --> wonderfull from screenshot, but i can't find nothing on it > > Requires lots of JS on your side to use it. I gave up.
Re: [web2py] Re: please check 1.84.0 (beta)
On Aug 29, 2010, at 12:02 AM, mart wrote: > > 2. changed .bash_profile to point to python 2.7 (even if nor > recommended, 1.83 worked just fine on 2.7 for me). This time got the > 'No handlers could be found for logger "web2py"' error and returned > the terminal to the cursor (web2py stopped immediately - which I > believe should be expected because of the unsupported python version > (although 1.83 worked fine) Try making a copy of logging.example.conf and naming it logging.conf, and see what happens. I haven't done any testing with 2.7. Quite possibly if there isn't a logging.conf we ought to install an explicit default logger.
Re: [web2py] Re: please check 1.84.0 (beta)
On Aug 29, 2010, at 9:46 AM, mart wrote:
>
> So, I just downloaded the src from
> http://web2py.com/examples/static/nightly/web2py_src.zip,
> just in case there are changes since last night. I am on mac os 10.6.4
> and this is what I get (copied from terminal):
>
> macmart:web2py_184 mart$ python web2py.py
> Warning: web2py requires Python 2.4, 2.5 (recommended), or 2.6 but you
> are running:
> 2.7 (r27:82508, Jul 3 2010, 21:12:11)
> [GCC 4.0.1 (Apple Inc. build 5493)]web2py Enterprise Web Framework
> Created by Massimo Di Pierro, Copyright 2007-2010
> Version 1.84.0 (2010-08-29 06:19:04)
> Database drivers available: SQLite3
> Starting hardcron...
> No handlers could be found for logger "web2py"
> choose a password:*
> please visit:
> http://127.0.0.1:8000
> use "kill -SIGTERM 1746" to shutdown the web2py server
> macmart:web2py_184 mart$
>
>
> So, we still notice the same error "No handlers could be found for
> logger "web2py"" and the I am brought back to the terminal cursor.
>
> So, now on to Jonathan's suggestion.
>
> SO, now I/ looking for logging.example.conf but can't find it, does it
> usually come with the src? Or what should the contents be? I did see
> some references to that file in a few place though...
It should be in the root directory, as part of the distribution (it's a new
file); if it's not, it must have something to do with how the distribution is
created. Massimo?
In the meantime, try the following (plain text file):
[loggers]
keys=root,rocket,markdown,web2py,rewrite,app,welcome
# the default configuration is console-based (stdout) for backward compatibility
#
# note that file-based handlers are thread-safe but not mp-safe;
# for mp-safe logging, configure the appropriate syslog handler
[handlers]
keys=consoleHandler
#keys=consoleHandler,rotatingFileHandler
#keys=osxSysLogHandler
[formatters]
keys=simpleFormatter
[logger_root]
level=WARNING
handlers=consoleHandler
[logger_web2py]
level=WARNING
handlers=consoleHandler
qualname=web2py
propagate=0
[logger_rewrite]
level=WARNING
qualname=web2py.rewrite
handlers=consoleHandler
propagate=0
# generic app handler
[logger_app]
level=WARNING
qualname=web2py.app
handlers=consoleHandler
propagate=0
# welcome app handler
[logger_welcome]
level=WARNING
qualname=web2py.app.welcome
handlers=consoleHandler
propagate=0
# loggers for legacy getLogger calls: Rocket and markdown
[logger_rocket]
level=WARNING
handlers=consoleHandler
qualname=Rocket
propagate=0
[logger_markdown]
level=WARNING
handlers=consoleHandler
qualname=markdown
propagate=0
[handler_consoleHandler]
class=StreamHandler
level=WARNING
formatter=simpleFormatter
args=(sys.stdout,)
# Rotating file handler
# mkdir logs in the web2py base directory if not already present
# args: (filename[, mode[, maxBytes[, backupCount[, encoding[, delay])
#
[handler_rotatingFileHandler]
class=handlers.RotatingFileHandler
level=INFO
formatter=simpleFormatter
args=("logs/web2py.log", "a", 100, 5)
[handler_osxSysLogHandler]
class=handlers.SysLogHandler
level=WARNING
formatter=simpleFormatter
args=("/var/run/syslog", handlers.SysLogHandler.LOG_DAEMON)
[handler_linuxSysLogHandler]
class=handlers.SysLogHandler
level=WARNING
formatter=simpleFormatter
args=("/dev/log", handlers.SysLogHandler.LOG_DAEMON)
[handler_remoteSysLogHandler]
class=handlers.SysLogHandler
level=WARNING
formatter=simpleFormatter
args=(('sysloghost.domain.com', handlers.SYSLOG_UDP_PORT),
handlers.SysLogHandler.LOG_DAEMON)
[formatter_simpleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
datefmt=
Re: [web2py] Re: please check 1.84.0 (beta)
On Aug 29, 2010, at 9:46 AM, mart wrote:
>
> So, we still notice the same error "No handlers could be found for
> logger "web2py"" and the I am brought back to the terminal cursor.
There may be two problems here.
One is that the "no handlers" message may be normal, but shouldn't result in
termination. So there may be a separate 2.7 issue that's causing you to
terminate that has nothing to do with the message.
Try running this from the python command line:
>>> import logging
>>> l = logging.getLogger('foobar')
>>> l.warning('bar')
No handlers could be found for logger "foobar"
>>>
This is 2.6.4 on OS X. We get the message, but no termination. How about 2.7?
Re: [web2py] Re: please check 1.84.0 (beta)
On Aug 29, 2010, at 10:26 AM, mart wrote:
>
> Working great now! Thanks for that :)
A favor, please, Mart. In main.py, you'll find this logging init code:
logpath = os.path.join(web2py_path, "logging.conf")
if os.path.exists(logpath):
logging.config.fileConfig(os.path.join(web2py_path, "logging.conf"))
logger = logging.getLogger("web2py")
In the configuration that terminates for you (2.7 and no logging.conf, I
believe), try adding an else clause to the above, thus:
logpath = os.path.join(web2py_path, "logging.conf")
if os.path.exists(logpath):
logging.config.fileConfig(os.path.join(web2py_path, "logging.conf"))
else:
logging.basicConfig()
logger = logging.getLogger("web2py")
Hopefully that will solve the termination problem, in which case we'll want
that patch for 2.7 (and it should do no harm before that). I have to think it's
a 2.7 bug, but who knows?
Also, Mart, can you try that python command-line test under 2.7?
>
> On Aug 29, 1:06 pm, Jonathan Lundell wrote:
>> On Aug 29, 2010, at 9:46 AM, mart wrote:
>>
>>
>>
>>
>>
>>> So, I just downloaded the src
>>> fromhttp://web2py.com/examples/static/nightly/web2py_src.zip,
>>> just in case there are changes since last night. I am on mac os 10.6.4
>>> and this is what I get (copied from terminal):
>>
>>> macmart:web2py_184 mart$ python web2py.py
>>> Warning: web2py requires Python 2.4, 2.5 (recommended), or 2.6 but you
>>> are running:
>>> 2.7 (r27:82508, Jul 3 2010, 21:12:11)
>>> [GCC 4.0.1 (Apple Inc. build 5493)]web2py Enterprise Web Framework
>>> Created by Massimo Di Pierro, Copyright 2007-2010
>>> Version 1.84.0 (2010-08-29 06:19:04)
>>> Database drivers available: SQLite3
>>> Starting hardcron...
>>> No handlers could be found for logger "web2py"
>>> choose a password:*
>>> please visit:
>>>http://127.0.0.1:8000
>>> use "kill -SIGTERM 1746" to shutdown the web2py server
>>> macmart:web2py_184 mart$
>>
>>> So, we still notice the same error "No handlers could be found for
>>> logger "web2py"" and the I am brought back to the terminal cursor.
>>
>>> So, now on to Jonathan's suggestion.
>>
>>> SO, now I/ looking for logging.example.conf but can't find it, does it
>>> usually come with the src? Or what should the contents be? I did see
>>> some references to that file in a few place though...
>>
>> It should be in the root directory, as part of the distribution (it's a new
>> file); if it's not, it must have something to do with how the distribution
>> is created. Massimo?
>>
>> In the meantime, try the following (plain text file):
>>
>> [loggers]
>> keys=root,rocket,markdown,web2py,rewrite,app,welcome
>>
>> # the default configuration is console-based (stdout) for backward
>> compatibility
>> #
>> # note that file-based handlers are thread-safe but not mp-safe;
>> # for mp-safe logging, configure the appropriate syslog handler
>>
>> [handlers]
>> keys=consoleHandler
>> #keys=consoleHandler,rotatingFileHandler
>> #keys=osxSysLogHandler
>>
>> [formatters]
>> keys=simpleFormatter
>>
>> [logger_root]
>> level=WARNING
>> handlers=consoleHandler
>>
>> [logger_web2py]
>> level=WARNING
>> handlers=consoleHandler
>> qualname=web2py
>> propagate=0
>>
>> [logger_rewrite]
>> level=WARNING
>> qualname=web2py.rewrite
>> handlers=consoleHandler
>> propagate=0
>>
>> # generic app handler
>> [logger_app]
>> level=WARNING
>> qualname=web2py.app
>> handlers=consoleHandler
>> propagate=0
>>
>> # welcome app handler
>> [logger_welcome]
>> level=WARNING
>> qualname=web2py.app.welcome
>> handlers=consoleHandler
>> propagate=0
>>
>> # loggers for legacy getLogger calls: Rocket and markdown
>> [logger_rocket]
>> level=WARNING
>> handlers=consoleHandler
>> qualname=Rocket
>> propagate=0
>>
>> [logger_markdown]
>> level=WARNING
>> handlers=consoleHandler
>> qualname=markdown
>> propagate=0
>>
>> [handler_consoleHandler]
>> class=StreamHandler
>> level=WARNING
>> formatter=simpleFormatter
>> args=(sys.stdout,)
>>
>> # Rotating file handler
>> # mkdir logs in the web2py base directory if not already present
>> # args: (filename[, mode[, maxBytes[, backupCount[, encoding[, delay])
>> #
>> [handler_rotatingFileHandler]
>> class=handlers.RotatingFileHandler
>> level=INFO
>> formatter=simpleFormatter
>> args=("logs/web2py.log", "a", 100, 5)
>>
>> [handler_osxSysLogHandler]
>> class=handlers.SysLogHandler
>> level=WARNING
>> formatter=simpleFormatter
>> args=("/var/run/syslog", handlers.SysLogHandler.LOG_DAEMON)
>>
>> [handler_linuxSysLogHandler]
>> class=handlers.SysLogHandler
>> level=WARNING
>> formatter=simpleFormatter
>> args=("/dev/log", handlers.SysLogHandler.LOG_DAEMON)
>>
>> [handler_remoteSysLogHandler]
>> class=handlers.SysLogHandler
>> level=WARNING
>> formatter=simpleFormatter
>> args=(('sysloghost.domain.com', handlers.SYSLOG_UDP_PORT),
>> handlers.SysLogHandler.LOG_DAEMON)
>>
>> [formatter_simpleFormatter]
>> format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
>> datefmt=
Re: [web2py] Re: please check 1.84.0 (beta)
On Aug 29, 2010, at 11:12 AM, mart wrote:
>
> hey Jonathan,
>
> renamed logging.conf to logging_x.conf, modified main.py, and re-ran
> web2py. Worked great for me! :)
Thanks, I appreciate it.
>
> Thanks,
> Mart :)
>
> On Aug 29, 1:42 pm, Jonathan Lundell wrote:
>> On Aug 29, 2010, at 10:26 AM, mart wrote:
>>
>>
>>
>>> Working great now! Thanks for that :)
>>
>> A favor, please, Mart. In main.py, you'll find this logging init code:
>>
>> logpath = os.path.join(web2py_path, "logging.conf")
>> if os.path.exists(logpath):
>> logging.config.fileConfig(os.path.join(web2py_path, "logging.conf"))
>> logger = logging.getLogger("web2py")
>>
>> In the configuration that terminates for you (2.7 and no logging.conf, I
>> believe), try adding an else clause to the above, thus:
>>
>> logpath = os.path.join(web2py_path, "logging.conf")
>> if os.path.exists(logpath):
>> logging.config.fileConfig(os.path.join(web2py_path, "logging.conf"))
>> else:
>> logging.basicConfig()
>> logger = logging.getLogger("web2py")
>>
>> Hopefully that will solve the termination problem, in which case we'll want
>> that patch for 2.7 (and it should do no harm before that). I have to think
>> it's a 2.7 bug, but who knows?
>>
>> Also, Mart, can you try that python command-line test under 2.7?
>>
>>
>>
>>> On Aug 29, 1:06 pm, Jonathan Lundell wrote:
>>>> On Aug 29, 2010, at 9:46 AM, mart wrote:
>>
>>>>> So, I just downloaded the src
>>>>> fromhttp://web2py.com/examples/static/nightly/web2py_src.zip,
>>>>> just in case there are changes since last night. I am on mac os 10.6.4
>>>>> and this is what I get (copied from terminal):
>>
>>>>> macmart:web2py_184 mart$ python web2py.py
>>>>> Warning: web2py requires Python 2.4, 2.5 (recommended), or 2.6 but you
>>>>> are running:
>>>>> 2.7 (r27:82508, Jul 3 2010, 21:12:11)
>>>>> [GCC 4.0.1 (Apple Inc. build 5493)]web2py Enterprise Web Framework
>>>>> Created by Massimo Di Pierro, Copyright 2007-2010
>>>>> Version 1.84.0 (2010-08-29 06:19:04)
>>>>> Database drivers available: SQLite3
>>>>> Starting hardcron...
>>>>> No handlers could be found for logger "web2py"
>>>>> choose a password:*
>>>>> please visit:
>>>>>http://127.0.0.1:8000
>>>>> use "kill -SIGTERM 1746" to shutdown the web2py server
>>>>> macmart:web2py_184 mart$
>>
>>>>> So, we still notice the same error "No handlers could be found for
>>>>> logger "web2py"" and the I am brought back to the terminal cursor.
>>
>>>>> So, now on to Jonathan's suggestion.
>>
>>>>> SO, now I/ looking for logging.example.conf but can't find it, does it
>>>>> usually come with the src? Or what should the contents be? I did see
>>>>> some references to that file in a few place though...
>>
>>>> It should be in the root directory, as part of the distribution (it's a
>>>> new file); if it's not, it must have something to do with how the
>>>> distribution is created. Massimo?
>>
>>>> In the meantime, try the following (plain text file):
>>
>>>> [loggers]
>>>> keys=root,rocket,markdown,web2py,rewrite,app,welcome
>>
>>>> # the default configuration is console-based (stdout) for backward
>>>> compatibility
>>>> #
>>>> # note that file-based handlers are thread-safe but not mp-safe;
>>>> # for mp-safe logging, configure the appropriate syslog handler
>>
>>>> [handlers]
>>>> keys=consoleHandler
>>>> #keys=consoleHandler,rotatingFileHandler
>>>> #keys=osxSysLogHandler
>>
>>>> [formatters]
>>>> keys=simpleFormatter
>>
>>>> [logger_root]
>>>> level=WARNING
>>>> handlers=consoleHandler
>>
>>>> [logger_web2py]
>>>> level=WARNING
>>>> handlers=consoleHandler
>>>> qualname=web2py
>>>> propagate=0
>>
>>>> [logger_rewrite]
>>>> level=WARNING
>>>> qualname=web2py.rewrite
>>>> handlers=consoleHandler
>>>> propagate=0
>>
>>>>
Re: [web2py] Re: please check 1.84.0 (beta)
On Aug 29, 2010, at 3:40 PM, mart wrote:
>
> Just downloaded src from same location. All is working great :)
> however... i am still weeing the warning 'No handlers could be found
> for logger "web2py"'
Do have a logging.conf, and/or do you see the change in main.py?
>
>
> thanks,
> Mart :)
>
> On Aug 29, 6:34 pm, mart wrote:
>> Any time :)
>>
>> On Aug 29, 4:40 pm, Jonathan Lundell wrote:
>>
>>> On Aug 29, 2010, at 11:12 AM, mart wrote:
>>
>>>> hey Jonathan,
>>
>>>> renamed logging.conf to logging_x.conf, modified main.py, and re-ran
>>>> web2py. Worked great for me! :)
>>
>>> Thanks, I appreciate it.
>>
>>>> Thanks,
>>>> Mart :)
>>
>>>> On Aug 29, 1:42 pm, Jonathan Lundell wrote:
>>>>> On Aug 29, 2010, at 10:26 AM, mart wrote:
>>
>>>>>> Working great now! Thanks for that :)
>>
>>>>> A favor, please, Mart. In main.py, you'll find this logging init code:
>>
>>>>> logpath = os.path.join(web2py_path, "logging.conf")
>>>>> if os.path.exists(logpath):
>>>>> logging.config.fileConfig(os.path.join(web2py_path, "logging.conf"))
>>>>> logger = logging.getLogger("web2py")
>>
>>>>> In the configuration that terminates for you (2.7 and no logging.conf, I
>>>>> believe), try adding an else clause to the above, thus:
>>
>>>>> logpath = os.path.join(web2py_path, "logging.conf")
>>>>> if os.path.exists(logpath):
>>>>> logging.config.fileConfig(os.path.join(web2py_path, "logging.conf"))
>>>>> else:
>>>>> logging.basicConfig()
>>>>> logger = logging.getLogger("web2py")
>>
>>>>> Hopefully that will solve the termination problem, in which case we'll
>>>>> want that patch for 2.7 (and it should do no harm before that). I have to
>>>>> think it's a 2.7 bug, but who knows?
>>
>>>>> Also, Mart, can you try that python command-line test under 2.7?
>>
>>>>>> On Aug 29, 1:06 pm, Jonathan Lundell wrote:
>>>>>>> On Aug 29, 2010, at 9:46 AM, mart wrote:
>>
>>>>>>>> So, I just downloaded the src
>>>>>>>> fromhttp://web2py.com/examples/static/nightly/web2py_src.zip,
>>>>>>>> just in case there are changes since last night. I am on mac os 10.6.4
>>>>>>>> and this is what I get (copied from terminal):
>>
>>>>>>>> macmart:web2py_184 mart$ python web2py.py
>>>>>>>> Warning: web2py requires Python 2.4, 2.5 (recommended), or 2.6 but you
>>>>>>>> are running:
>>>>>>>> 2.7 (r27:82508, Jul 3 2010, 21:12:11)
>>>>>>>> [GCC 4.0.1 (Apple Inc. build 5493)]web2py Enterprise Web Framework
>>>>>>>> Created by Massimo Di Pierro, Copyright 2007-2010
>>>>>>>> Version 1.84.0 (2010-08-29 06:19:04)
>>>>>>>> Database drivers available: SQLite3
>>>>>>>> Starting hardcron...
>>>>>>>> No handlers could be found for logger "web2py"
>>>>>>>> choose a password:*
>>>>>>>> please visit:
>>>>>>>>http://127.0.0.1:8000
>>>>>>>> use "kill -SIGTERM 1746" to shutdown the web2py server
>>>>>>>> macmart:web2py_184 mart$
>>
>>>>>>>> So, we still notice the same error "No handlers could be found for
>>>>>>>> logger "web2py"" and the I am brought back to the terminal cursor.
>>
>>>>>>>> So, now on to Jonathan's suggestion.
>>
>>>>>>>> SO, now I/ looking for logging.example.conf but can't find it, does it
>>>>>>>> usually come with the src? Or what should the contents be? I did see
>>>>>>>> some references to that file in a few place though...
>>
>>>>>>> It should be in the root directory, as part of the distribution (it's a
>>>>>>> new file); if it's not, it must have something to do with how the
>>>>>>> distribution is created. Massimo?
>>
>>>>>>> In the meantime, try the following (plain text file):
>&
Re: [web2py] Re: please check 1.84.0 (beta)
On Aug 29, 2010, at 6:24 PM, mart wrote:
>
> hey again...
>
> So, I should have looked a little deeper earlier when I saw it working
> but still getting the error/warning...
>
> so, not too sure what's happening right now (will deeper later this
> evening).
>
> but for now. I synced the src from same location specified at the
> beginning of the thread. extracted in a different location as
> yesterday's instance. the web2py_path/gluon/main.py does not contain
> your new else statement, but the older version:
>
> logpath = os.path.join(web2py_path, "logging.conf")
> if os.path.exists(logpath):
>logging.config.fileConfig(os.path.join(web2py_path,
> "logging.conf"))
> logger = logging.getLogger("web2py")
>
> and no logging.conf exists.
Just for the record: the release will have logging.example.conf, which you'll
need to copy to logging.conf to have it take effect.
But the change to main.py should give a (possibly) reasonable default in the
absence of a logging.conf, as long as it's possible to write to stdout.
>
> I noticed that os.environ is being used to set cwd, so I checked the
> output, which gives me this:
I'm suspicious of the cwd logic, too. But that's (maybe) a question for another
day.
>
> macmart:web2py_2_184 mart$ python
> Python 2.7 (r27:82508, Jul 3 2010, 21:12:11)
> [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import os
>>>> for item in os.environ:
> ... print("{0} = {1}".format(item,os.environ[item]))
> ...
> LANG = en_CA.UTF-8
> TERM = xterm-color
> Apple_PubSub_Socket_Render = /tmp/launch-nyryAG/Render
> SHLVL = 1
> OLDPWD = /Users/mart/Downloads
> SSH_AUTH_SOCK = /tmp/launch-xtTLKc/Listeners
> TERM_PROGRAM_VERSION = 273
> __CF_USER_TEXT_ENCODING = 0x1F6:0:0
> PWD = /Users/mart/Downloads/web2py_2_184
> SHELL = /bin/bash
> LOGNAME = mart
> USER = mart
> HOME = /Users/mart
> PATH = /Library/Frameworks/Python.framework/Versions/2.7/bin:/Library/
> Frameworks/Python.framework/Versions/2.6/bin:/usr/bin:/bin:/usr/sbin:/
> sbin:/usr/local/bin:/usr/local/git/bin:/usr/X11/bin
> COMMAND_MODE = unix2003
> _ = /Library/Frameworks/Python.framework/Versions/2.7/bin/python
> DISPLAY = /tmp/launch-fj9Ipo/org.x:0
> TMPDIR = /var/folders/gL/gLsicOEFGNC3VqZE1yVgmU+++TM/-Tmp-/
> TERM_PROGRAM = Apple_Terminal
>>>>
>
>
>
> So, no mention of previous web2py install path (unless I;m not looking
> correctly), but it still works. To be sure, I renamed the previous
> web2py's folder name (just in case, something had picked it up)... but
> still working (and getting the warning)...
>
> So, not too sure why this isn't failing as it did, this morning...
>
> Thanks,
> Mart :)
>
>
>
>
> On Aug 29, 6:59 pm, Jonathan Lundell wrote:
>> On Aug 29, 2010, at 3:40 PM, mart wrote:
>>
>>
>>
>>> Just downloaded src from same location. All is working great :)
>>> however... i am still weeing the warning 'No handlers could be found
>>> for logger "web2py"'
>>
>> Do have a logging.conf, and/or do you see the change in main.py?
>>
>>
>>
>>> thanks,
>
>>> Mart :)
>>
>>> On Aug 29, 6:34 pm, mart wrote:
>>>> Any time :)
>>
>>>> On Aug 29, 4:40 pm, Jonathan Lundell wrote:
>>
>>>>> On Aug 29, 2010, at 11:12 AM, mart wrote:
>>
>>>>>> hey Jonathan,
>>
>>>>>> renamed logging.conf to logging_x.conf, modified main.py, and re-ran
>>>>>> web2py. Worked great for me! :)
>>
>>>>> Thanks, I appreciate it.
>>
>>>>>> Thanks,
>>>>>> Mart :)
>>
>>>>>> On Aug 29, 1:42 pm, Jonathan Lundell wrote:
>>>>>>> On Aug 29, 2010, at 10:26 AM, mart wrote:
>>
>>>>>>>> Working great now! Thanks for that :)
>>
>>>>>>> A favor, please, Mart. In main.py, you'll find this logging init code:
>>
>>>>>>> logpath = os.path.join(web2py_path, "logging.conf")
>>>>>>> if os.path.exists(logpath):
>>>>>>> logging.config.fileConfig(os.path.join(web2py_path, "logging.conf"))
>>>>>>> logger = logging.getLogger("web2py")
>>
>>>>>>> In the configuration that terminates for you (2.7 and no logging.conf,
>>>>
Re: [web2py] Re: per app routes
On Aug 31, 2010, at 9:31 AM, mwolfe02 wrote: > > I'm still debugging now, but there seems to be an issue using the > special $anything token inside app-specific routes_in. It appears > that the incoming URL is being applied to each app-specific routes_in > one at a time before it is applied against routes_app. > > I'll try to include more details later, but I wanted to bring it to > your attention now. Thanks. I'll wait to hear from you. It should look at the global routes_app first (because it doesn't know which app-specific routes to use), and if that resolves to an app that has its own routes file, then use that for routes_in. > > -Mike > > On Aug 7, 12:36 pm, Jonathan Lundell wrote: >> On Aug 7, 2010, at 9:32 AM, David Marko wrote: >> >>> Hello, >>> have you tested performance impact on application. Do you assume some >>> noticeable slowdown when usingroutes? >> >> I have not measured it, but I'd expect the effect to be trivial, perhaps >> unmeasurable in that it'd be in the noise. >> >> In particular, the routing files are read and the regexes compiled only >> once, when web2py starts up, so the per-request overhead is quite low. >> >> >> >> >> >>> david >> >>> On 7 srp, 18:26, Jonathan Lundell wrote: >>>> On Aug 7, 2010, at 9:03 AM, mdipierro wrote: >> >>>>> Thanks to Jonathan Lundell we have an experimental version in trunk of >>>>> applevelroutes. >>>>> To understand how it works readroutes.example.py and comments in the >>>>> file gluon/rewrite.py >> >>>>> If you test it please report your findings here. >> >>>> *Very* experimental, mostly not tested. >> >>>> I'll describe some of the changes here. >> >>>> 1. If you don't explicitly invoke any of the new features, routing should >>>> behave identically to before. If you see any different, please let us know >>>> asap. >> >>>> 2. You can now have aroutes.py in the top level folder of an application, >>>> and it will be used *instead* of the baseroutes.py. However, it's not >>>> enough to simply have the file there; you must inform the routing logic >>>> about it. >> >>>> 3. The way you inform the routing logic is with a new element in the >>>> baseroutes.py: routes_app. routes_app is processed identically to >>>> routes_in, but the output must be anappname (or nothing). routes_app is >>>> processed at the beginning of a request. If it produces anappname, and >>>> thatapphas anapp-specificroutes.py (that is, >>>> applications/appname/routes.py), then thatroutes.py is used instead of the >>>> baseroutes.py. >> >>>> 4. In an unrelated change, there are three other new elements inroutes.py: >> >>>> default_application = "init" >>>> default_controller = "default" >>>> default_function = "index" >> >>>> Note that default_application doesn't interact withapp-specfic routing, >>>> since it's used after rewrite has taken place. default_controller and >>>> default_function should normally be used only in anapp-specificroutes.py, >>>> because, in the baseroutes.py, they will apply to all apps *without* >>>> anapp-specificroutes.py. That would probably lead to confusion when >>>> running admin or examples; at the very least their defaults would break. >> >>>> 5. As usual, I suggest that when you editroutes.example.py to generate a >>>> newroutes.py, you also edit the doctest at the end, and use it to verify >>>> that you're getting what you expect. To run the doctest, just do >>>> "pythonroutes.py". >> >>>> Note also that I have a more far-reaching change in mind, but don't have >>>> it worked out yet. The new version will move away from regexes (though the >>>> old logic will remain in place for compatibility). It's supposed to be >>>> more flexible and much easier to use, and also handle URL encoding & >>>> decoding better. But this change should help in the meantime.
Re: [web2py] Re: per app routes
On Aug 31, 2010, at 10:01 AM, mwolfe02 wrote: > > More clues... When web2py loads, rewrite.params.routes_in gets set as > follows: > > - items from base routes_in are appended first > - then items from app-specific routes_in are appended in alphabetical > order by application > > This seems to be causing my problems. More info to follow... I think I may see the problem. If I'm right, when we initialize a new set of params from the default set, we need to do a deeper copy than we're doing now. Can I send you a replacement rewrite.py to try out? It'd be from the trunk, which ought to be equivalent, for our purposes, to the current nightly and close enough to the last stable release. > > -Mike > > On Aug 31, 12:31 pm, mwolfe02 wrote: >> I'm still debugging now, but there seems to be an issue using the >> special $anything token insideapp-specificroutes_in. It appears >> that the incoming URL is being applied to eachapp-specificroutes_in >> one at a time before it is applied against routes_app. >> >> I'll try to include more details later, but I wanted to bring it to >> your attention now. >> >> -Mike >> >> On Aug 7, 12:36 pm, Jonathan Lundell wrote: >> >> >> >>> On Aug 7, 2010, at 9:32 AM, David Marko wrote: >> >>>> Hello, >>>> have you tested performance impact on application. Do you assume some >>>> noticeable slowdown when usingroutes? >> >>> I have not measured it, but I'd expect the effect to be trivial, perhaps >>> unmeasurable in that it'd be in the noise. >> >>> In particular, the routing files are read and the regexes compiled only >>> once, when web2py starts up, so the per-request overhead is quite low. >> >>>> david >> >>>> On 7 srp, 18:26, Jonathan Lundell wrote: >>>>> On Aug 7, 2010, at 9:03 AM, mdipierro wrote: >> >>>>>> Thanks to Jonathan Lundell we have an experimental version in trunk of >>>>>> applevelroutes. >>>>>> To understand how it works readroutes.example.py and comments in the >>>>>> file gluon/rewrite.py >> >>>>>> If you test it please report your findings here. >> >>>>> *Very* experimental, mostly not tested. >> >>>>> I'll describe some of the changes here. >> >>>>> 1. If you don't explicitly invoke any of the new features, routing should >>>>> behave identically to before. If you see any different, please let us >>>>> know asap. >> >>>>> 2. You can now have aroutes.py in the top level folder of an application, >>>>> and it will be used *instead* of the baseroutes.py. However, it's not >>>>> enough to simply have the file there; you must inform the routing logic >>>>> about it. >> >>>>> 3. The way you inform the routing logic is with a new element in the >>>>> baseroutes.py: routes_app. routes_app is processed identically to >>>>> routes_in, but the output must be anappname (or nothing). routes_app is >>>>> processed at the beginning of a request. If it produces anappname, and >>>>> thatapphas anapp-specificroutes.py (that is, >>>>> applications/appname/routes.py), then thatroutes.py is used instead of >>>>> the baseroutes.py. >> >>>>> 4. In an unrelated change, there are three other new elements inroutes.py: >> >>>>> default_application = "init" >>>>> default_controller = "default" >>>>> default_function = "index" >> >>>>> Note that default_application doesn't interact withapp-specfic routing, >>>>> since it's used after rewrite has taken place. default_controller and >>>>> default_function should normally be used only in anapp-specificroutes.py, >>>>> because, in the baseroutes.py, they will apply to all apps *without* >>>>> anapp-specificroutes.py. That would probably lead to confusion when >>>>> running admin or examples; at the very least their defaults would break. >> >>>>> 5. As usual, I suggest that when you editroutes.example.py to generate a >>>>> newroutes.py, you also edit the doctest at the end, and use it to verify >>>>> that you're getting what you expect. To run the doctest, just do >>>>> "pythonroutes.py". >> >>>>> Note also that I have a more far-reaching change in mind, but don't have >>>>> it worked out yet. The new version will move away from regexes (though >>>>> the old logic will remain in place for compatibility). It's supposed to >>>>> be more flexible and much easier to use, and also handle URL encoding & >>>>> decoding better. But this change should help in the meantime.
Re: [web2py] Re: per app routes
On Aug 31, 2010, at 10:16 AM, Jonathan Lundell wrote: > > On Aug 31, 2010, at 10:01 AM, mwolfe02 wrote: >> >> More clues... When web2py loads, rewrite.params.routes_in gets set as >> follows: >> >> - items from base routes_in are appended first >> - then items from app-specific routes_in are appended in alphabetical >> order by application >> >> This seems to be causing my problems. More info to follow... > > I think I may see the problem. If I'm right, when we initialize a new set of > params from the default set, we need to do a deeper copy than we're doing now. > > Can I send you a replacement rewrite.py to try out? It'd be from the trunk, > which ought to be equivalent, for our purposes, to the current nightly and > close enough to the last stable release. Here's an updated rewrite.py. Easier to follow, too, I think. http://web.me.com/jlundell/filechute/rewrite.zip Massimo, you should probably hold up 1.84 until this gets resolved. > >> >> -Mike >> >> On Aug 31, 12:31 pm, mwolfe02 wrote: >>> I'm still debugging now, but there seems to be an issue using the >>> special $anything token insideapp-specificroutes_in. It appears >>> that the incoming URL is being applied to eachapp-specificroutes_in >>> one at a time before it is applied against routes_app. >>> >>> I'll try to include more details later, but I wanted to bring it to >>> your attention now. >>> >>> -Mike >>> >>> On Aug 7, 12:36 pm, Jonathan Lundell wrote: >>> >>> >>> >>>> On Aug 7, 2010, at 9:32 AM, David Marko wrote: >>> >>>>> Hello, >>>>> have you tested performance impact on application. Do you assume some >>>>> noticeable slowdown when usingroutes? >>> >>>> I have not measured it, but I'd expect the effect to be trivial, perhaps >>>> unmeasurable in that it'd be in the noise. >>> >>>> In particular, the routing files are read and the regexes compiled only >>>> once, when web2py starts up, so the per-request overhead is quite low. >>> >>>>> david >>> >>>>> On 7 srp, 18:26, Jonathan Lundell wrote: >>>>>> On Aug 7, 2010, at 9:03 AM, mdipierro wrote: >>> >>>>>>> Thanks to Jonathan Lundell we have an experimental version in trunk of >>>>>>> applevelroutes. >>>>>>> To understand how it works readroutes.example.py and comments in the >>>>>>> file gluon/rewrite.py >>> >>>>>>> If you test it please report your findings here. >>> >>>>>> *Very* experimental, mostly not tested. >>> >>>>>> I'll describe some of the changes here. >>> >>>>>> 1. If you don't explicitly invoke any of the new features, routing >>>>>> should behave identically to before. If you see any different, please >>>>>> let us know asap. >>> >>>>>> 2. You can now have aroutes.py in the top level folder of an >>>>>> application, and it will be used *instead* of the baseroutes.py. >>>>>> However, it's not enough to simply have the file there; you must inform >>>>>> the routing logic about it. >>> >>>>>> 3. The way you inform the routing logic is with a new element in the >>>>>> baseroutes.py: routes_app. routes_app is processed identically to >>>>>> routes_in, but the output must be anappname (or nothing). routes_app is >>>>>> processed at the beginning of a request. If it produces anappname, and >>>>>> thatapphas anapp-specificroutes.py (that is, >>>>>> applications/appname/routes.py), then thatroutes.py is used instead of >>>>>> the baseroutes.py. >>> >>>>>> 4. In an unrelated change, there are three other new elements >>>>>> inroutes.py: >>> >>>>>> default_application = "init" >>>>>> default_controller = "default" >>>>>> default_function = "index" >>> >>>>>> Note that default_application doesn't interact withapp-specfic routing, >>>>>> since it's used after rewrite has taken place. default_controller and >>>>>> default_function should normally be used only in >>>>>> anapp-specificroutes.py, because, in the baseroutes.py, they will apply >>>>>> to all apps *without* anapp-specificroutes.py. That would probably lead >>>>>> to confusion when running admin or examples; at the very least their >>>>>> defaults would break. >>> >>>>>> 5. As usual, I suggest that when you editroutes.example.py to generate a >>>>>> newroutes.py, you also edit the doctest at the end, and use it to verify >>>>>> that you're getting what you expect. To run the doctest, just do >>>>>> "pythonroutes.py". >>> >>>>>> Note also that I have a more far-reaching change in mind, but don't have >>>>>> it worked out yet. The new version will move away from regexes (though >>>>>> the old logic will remain in place for compatibility). It's supposed to >>>>>> be more flexible and much easier to use, and also handle URL encoding & >>>>>> decoding better. But this change should help in the meantime. > >
Re: [web2py] Re: per app routes
On Aug 31, 2010, at 12:53 PM, mwolfe02 wrote: > > default_function does not seem to be recognized properly in app- > specific routes.py. I'm thinking default_controller may have a > similar problem, but I'm not really redefining it. > > My base routes.py has default_application set to 'my_app' (and nothing > set for default_controller or default_function). In the routes.py > file for my 'my_app' I have the following set: > > default_controller = 'default' # ordinarily set in app-specific > routes.py > default_function = 'search' # ordinarily set in app-specific > routes.py > > When I visit http://domain.com/ I receive the 'invalid function' page > instead of rewriting to http://domain.com/my_app/default/search/. I'm > debugging now and will post back when I learn more. You'll need to define default_application in the app-specific routes file. I know that doesn't make a lot of sense; I'll look at changing that so that it shows up as the current app by default. Let me know if that works.
Re: [web2py] Re: per app routes
On Aug 31, 2010, at 12:53 PM, mwolfe02 wrote: > > default_function does not seem to be recognized properly in app- > specific routes.py. I'm thinking default_controller may have a > similar problem, but I'm not really redefining it. > > My base routes.py has default_application set to 'my_app' (and nothing > set for default_controller or default_function). In the routes.py > file for my 'my_app' I have the following set: > > default_controller = 'default' # ordinarily set in app-specific > routes.py > default_function = 'search' # ordinarily set in app-specific > routes.py > > When I visit http://domain.com/ I receive the 'invalid function' page > instead of rewriting to http://domain.com/my_app/default/search/. I'm > debugging now and will post back when I learn more. OK, making the current app the default turned out to be pretty straightforward, and even if that's not the problem you're having, I think it makes sense to do. Here's the new rewrite.py: http://web.me.com/jlundell/filechute/rewrite.zip
Re: [web2py] Re: per app routes
On Aug 31, 2010, at 2:20 PM, Michael Wolfe wrote:
>
> That didn't seem to quite do it. Visiting http://domain.com/ rewrites
> to http://domain.com/my_app/default/index/ instead of
> http://domain.com/my_app/default/search/. The URL is being
> substantively rewritten in the parse_url function (lines 802-807) of
> gluon/main.py:
>
>request.application = \
>regex_space.sub('_', match.group('a') or
> rewrite.params.default_application)
>request.controller = \
>regex_space.sub('_', match.group('c') or
> rewrite.params.default_controller)
>request.function = \
>regex_space.sub('_', match.group('f') or
> rewrite.params.default_function)
>
> The problem being that rewrite.params.default_function is not using
> the default_function specified in my app-specific routes.py.
>
>
> The parse_url function is being called from line 326 of gluon/main.py:
>
># ##
># invoke the legacy URL parser and serve static file
># ##
>
>static_file = parse_url(request, environ)
>
> To be clear, /my_app/default/search/ is not a static file; parse_url
> appears to do double-duty identifying static files and performing
> simple URL re-writes.
>
>
> On a side note, I'll be heading home for the day soon and won't be
> working on this project again until Thursday. So if you don't get a
> response from me for awhilethat's why.
OK. I'll take a closer look. It's helpful to know that it's getting 'index' in
this case.
One final thing: what's your routes_app? Is http://domain.com/ resulting in
my_app? Maybe you could send me, privately if you like, your global and my_app
routes.py.
>
> -Mike
>
>
> On Tue, Aug 31, 2010 at 4:09 PM, Jonathan Lundell wrote:
>> On Aug 31, 2010, at 12:53 PM, mwolfe02 wrote:
>>>
>>> default_function does not seem to be recognized properly in app-
>>> specific routes.py. I'm thinking default_controller may have a
>>> similar problem, but I'm not really redefining it.
>>>
>>> My base routes.py has default_application set to 'my_app' (and nothing
>>> set for default_controller or default_function). In the routes.py
>>> file for my 'my_app' I have the following set:
>>>
>>> default_controller = 'default' # ordinarily set in app-specific
>>> routes.py
>>> default_function = 'search' # ordinarily set in app-specific
>>> routes.py
>>>
>>> When I visit http://domain.com/ I receive the 'invalid function' page
>>> instead of rewriting to http://domain.com/my_app/default/search/. I'm
>>> debugging now and will post back when I learn more.
>>
>> OK, making the current app the default turned out to be pretty
>> straightforward, and even if that's not the problem you're having, I think
>> it makes sense to do. Here's the new rewrite.py:
>>
>> http://web.me.com/jlundell/filechute/rewrite.zip
[web2py] rewrite.py patch
One more change to rewrite.py. http://web.me.com/jlundell/filechute/rewrite.zip I took out the custom logging logic, which was confusing, because now that we have generalized logging it's redundant. However, there's a remaining problem to be resolved. Maybe.
[web2py] bug in app-specific routing
Massimo, it dawned on me (literally--I was lying in bed with the sun coming up) that we can't use the global rewrite.params to store the app-specific routing parameters because it's not thread-safe. Right? But I can't think of where we *could* keep that info, given the places that need to use it. So: help!
Re: [web2py] Re: bug in app-specific routing
On Sep 1, 2010, at 7:01 AM, mdipierro wrote: > > No we cannot. > > rewrite.params[appname]? That structure exists, but where would appname come from (in general)? I think that's the same problem. We could maybe stick it in request or response, but params is used a couple of places where that's not available. Maybe the environment that carries request and the other globals? > > On Sep 1, 8:46 am, Jonathan Lundell wrote: >> Massimo, it dawned on me (literally--I was lying in bed with the sun coming >> up) that we can't use the global rewrite.params to store the app-specific >> routing parameters because it's not thread-safe. Right? >> >> But I can't think of where we *could* keep that info, given the places that >> need to use it. >> >> So: help!
Re: [web2py] Re: bug in app-specific routing
On Sep 1, 2010, at 7:32 AM, mdipierro wrote:
>
> request.application is already there. Where is it used and the
> appmname is not available?
If request were always available, we could store the appropriate params link
there as request.params.
Here's an example (not, I think, the only one):
streamer.stream_file_or_304_or_206() looks like this:
def stream_file_or_304_or_206(
static_file,
chunk_size = DEFAULT_CHUNK_SIZE,
request = None,
headers = {},
error_message = rewrite.params.error_message,
):
We could default error_message to None, and fill in the default
programmatically, but it looks to me like we can't count on having request here.
Similarly, in rewrite.filter_out, the first thing we look for is
params.routes_out, but can we count on any global context at all?
>
>
>
> On Sep 1, 9:17 am, Jonathan Lundell wrote:
>> On Sep 1, 2010, at 7:01 AM, mdipierro wrote:
>>
>>
>>
>>> No we cannot.
>>
>>> rewrite.params[appname]?
>>
>> That structure exists, but where would appname come from (in general)? I
>> think that's the same problem.
>>
>> We could maybe stick it in request or response, but params is used a couple
>> of places where that's not available. Maybe the environment that carries
>> request and the other globals?
>>
>>
>>
>>> On Sep 1, 8:46 am, Jonathan Lundell wrote:
>>>> Massimo, it dawned on me (literally--I was lying in bed with the sun
>>>> coming up) that we can't use the global rewrite.params to store the
>>>> app-specific routing parameters because it's not thread-safe. Right?
>>
>>>> But I can't think of where we *could* keep that info, given the places
>>>> that need to use it.
>>
>>>> So: help!
Re: [web2py] Re: rewrite.py patch
On Sep 1, 2010, at 5:14 PM, mart wrote: > > just a quick question: is this related to the 1.84 build issue on Mac > os with python 2.7? Not exactly, I don't think. That was fixed, afaik, by the default logger patch. This is a bug in app-specific routing that we don't have a solution to yet. No problem if you're not using it, or if you have only one application running. > > thanks, > Mart :) > > On Aug 31, 9:08 pm, Jonathan Lundell wrote: >> One more change to rewrite.py. >> >> http://web.me.com/jlundell/filechute/rewrite.zip >> >> I took out the custom logging logic, which was confusing, because now that >> we have generalized logging it's redundant. >> >> However, there's a remaining problem to be resolved. Maybe.
Re: [web2py] Re: per app routes
On Sep 2, 2010, at 6:40 AM, mwolfe02 wrote:
>
> Actually, I had commented out routes_app altogether. When I restored
> it to this, things seemed to work again:
>
> routes_app = ((r'/(?Pwelcome|admin|examples|app)\b.*',
> r'\g'),
> (r'(.*)', r'my_app'),
> (r'/?(.*)', r'my_app'))
>
> I was thinking that the logic would work as follows:
>
> 1. if base routes_in exists check URL against base routes_in (if match
> found then rewrite else continue)
> 2. if routes_app exists check URL against routes_app (if match found
> then load app-specific routes_in or app-specific default controller/
> function else continue)
> 3. if default_app specified then load app-specific routes_in or app-
> specific default controller/function for the default_app
> 4. if no default_app specified and URL does not match base routes_in
> or routes_app return error
First of all, default_* doesn't really have anything to do with rewriting. I
added them to routes.py as a convenience, to be able to override the default
init/default/index logic that happens after all the routes_in is complete. I
would recommend using routes_* or default_*, but not both.
routes_app is the first thing we look at. It completely determines which
routes.py (base or app-specific) we'll use for the entire request and response.
If there's no routes_app, then we'll always use the base routes.py.
So the rule is actually pretty simple:
1. If routes_app produces an application name, and that application has its own
routes.py, then use that app-specific routes.py. In all other cases, use the
base routes.py. (This decision is final for the entire request.)
2. Using the routes.py determined in (1), apply routes_in to the URL. The best
practice, in my view, is for routes_in to always product a complete URL
(a/c/f/...).
3. If the URL does not have all three routing elements /a/c/f, complete it with
default_* from the selected routes.py (defaulting in the code to
/init/default/index if not overridden).
4. All subsequent rewriting (routes_out, error rewriting, etc) uses the
routes.py selected in (1).
Note that an app-specfic routes.py is all or nothing. If (1) selects an
app-specific routes.py and that routes.py does not contain (say) a routes_out,
we do *not* fall back on the base routes_out. Similarly for default_*.
>
>
> Once URL rewriting has been redirected to a specific app (as in step 2
> or 3 above) do the following:
>
> 1. if app-specific routes_in exists check URL against app-specific
> routes_in (if match found then rewrite else continue)
> 2. if URL maps to an existing controller/function, then call that
> controller/function else continue
> 3. if default_controller specified, prepend default_controller to URL
> and try step 2 else continue
> 4. if default_controller and default_function specified, prepend
> default_controller/default_function to URL and try step 2 else
> continue
> 5. if default_function specified, assume first part of URL is
> controller, insert default_function after assumed controller and
> before any potential function arguments
> 6. if nothing matches, return error
>
> Obviously my assumptions were not entirely correct. I'm wondering if
> you could pass along a brief overview of how the routes_app,
> default_app, default_controller, and default_function parameters all
> actually do interact in terms of URL rewriting.
>
> Thanks again,
> -Mike
>
> On Aug 31, 5:34 pm, Jonathan Lundell wrote:
>> On Aug 31, 2010, at 2:20 PM, Michael Wolfe wrote:
>>
>>
>>
>>
>>
>>
>>
>>> That didn't seem to quite do it. Visitinghttp://domain.com/rewrites
>>> tohttp://domain.com/my_app/default/index/instead of
>>> http://domain.com/my_app/default/search/. The URL is being
>>> substantively rewritten in the parse_url function (lines 802-807) of
>>> gluon/main.py:
>>
>>>request.application = \
>>>regex_space.sub('_', match.group('a') or
>>> rewrite.params.default_application)
>>>request.controller = \
>>>regex_space.sub('_', match.group('c') or
>>> rewrite.params.default_controller)
>>>request.function = \
>>>regex_space.sub('_', match.group('f') or
>>> rewrite.params.default_function)
>>
>>> The problem being that rewrite.params.default_function is not using
>>> the default_function specified in my app-specific routes.py.
>>
>>> The parse_url function is being called from line 326 of gluon/main.py:
>>
>>>#
Re: [web2py] Re: per app routes
On Sep 2, 2010, at 7:40 AM, Michael Wolfe wrote: > > Great info. Thanks for taking the time to explain. You're welcome. A caveat: I don't believe that the current logic is thread-safe. Consequently, if you have simultaneous requests on different threads that use different routes.py files, one of them could end up using the wrong logic for some or all of its translations. I intend to fix it, but I haven't figured out how yet. So if you're using multiple apps in production, I recommend sticking to the base routes.py for now. > > -Mike > > On Thu, Sep 2, 2010 at 10:16 AM, Jonathan Lundell wrote: >> On Sep 2, 2010, at 6:40 AM, mwolfe02 wrote: >>> >>> Actually, I had commented out routes_app altogether. When I restored >>> it to this, things seemed to work again: >>> >>> routes_app = ((r'/(?Pwelcome|admin|examples|app)\b.*', >>> r'\g'), >>> (r'(.*)', r'my_app'), >>> (r'/?(.*)', r'my_app')) >>> >>> I was thinking that the logic would work as follows: >>> >>> 1. if base routes_in exists check URL against base routes_in (if match >>> found then rewrite else continue) >>> 2. if routes_app exists check URL against routes_app (if match found >>> then load app-specific routes_in or app-specific default controller/ >>> function else continue) >>> 3. if default_app specified then load app-specific routes_in or app- >>> specific default controller/function for the default_app >>> 4. if no default_app specified and URL does not match base routes_in >>> or routes_app return error >> >> >> First of all, default_* doesn't really have anything to do with rewriting. I >> added them to routes.py as a convenience, to be able to override the default >> init/default/index logic that happens after all the routes_in is complete. I >> would recommend using routes_* or default_*, but not both. >> >> routes_app is the first thing we look at. It completely determines which >> routes.py (base or app-specific) we'll use for the entire request and >> response. If there's no routes_app, then we'll always use the base routes.py. >> >> So the rule is actually pretty simple: >> >> 1. If routes_app produces an application name, and that application has its >> own routes.py, then use that app-specific routes.py. In all other cases, use >> the base routes.py. (This decision is final for the entire request.) >> >> 2. Using the routes.py determined in (1), apply routes_in to the URL. The >> best practice, in my view, is for routes_in to always product a complete URL >> (a/c/f/...). >> >> 3. If the URL does not have all three routing elements /a/c/f, complete it >> with default_* from the selected routes.py (defaulting in the code to >> /init/default/index if not overridden). >> >> 4. All subsequent rewriting (routes_out, error rewriting, etc) uses the >> routes.py selected in (1). >> >> Note that an app-specfic routes.py is all or nothing. If (1) selects an >> app-specific routes.py and that routes.py does not contain (say) a >> routes_out, we do *not* fall back on the base routes_out. Similarly for >> default_*. >> >> >>> >>> >>> Once URL rewriting has been redirected to a specific app (as in step 2 >>> or 3 above) do the following: >>> >>> 1. if app-specific routes_in exists check URL against app-specific >>> routes_in (if match found then rewrite else continue) >>> 2. if URL maps to an existing controller/function, then call that >>> controller/function else continue >>> 3. if default_controller specified, prepend default_controller to URL >>> and try step 2 else continue >>> 4. if default_controller and default_function specified, prepend >>> default_controller/default_function to URL and try step 2 else >>> continue >>> 5. if default_function specified, assume first part of URL is >>> controller, insert default_function after assumed controller and >>> before any potential function arguments >>> 6. if nothing matches, return error >>> >>> Obviously my assumptions were not entirely correct. I'm wondering if >>> you could pass along a brief overview of how the routes_app, >>> default_app, default_controller, and default_function parameters all >>> actually do interact in terms of URL rewriting. >>> >>> Thanks again, >&
Re: [web2py] Using SOLR as the web2py backend
On Sep 2, 2010, at 2:05 PM, harryf wrote: > > This is kind of a re-post of a question I asked on stackoverflow - > http://stackoverflow.com/questions/3630641/whats-the-most-productive-frontend-framework-to-use-with-solr-as-the-backend/ > which Massimo invited me to ask here. > > To repeat, I want to build a web app using SOLR as the backend ( no > RDBMS or other backend ). Most of the data will be stored in SOLR via > offline jobs but there is some need for CRUD from the web app. The > schema will probably move fairly slowly ( in fact it already exists ) > so creating / changing models manually is acceptable from a > maintenance point of view. > > Have only got so far as a web2py "Hello World" so don't have deep > insight but would appreciate any hints on how this might be > accomplished in web2py. Also if anyone has any general experience of > using web2py with a RESTful backend as the primary data source, would > be great to hear about it. My main web2py application is a manager for a collection of servers running my company's network services. The server API is xml-rpc, but I imagine that a RESTful API would work just as well. I have a local database for users, and another one that basically provides access info for the managed servers. The servers themselves I treat as a kind of distributed "database". Not that I try to do SQL or anything, but in that they store their own data, and I don't try to keep local copies of it (except for backup & restore, which is another matter). It works quite well. I encapsulate each managed server in its own object, and use threads so that I can talk to a bunch of them in parallel when I need to. I'm pleased with the way it turned out.
Re: [web2py] RESTful URLs
On Sep 3, 2010, at 9:28 PM, bally boy wrote: > Hi is there a way to generate RESTful URLS. Let me explain:- > 1. I have an app called 'app' > 2. a controller called 'cont' > 3. a function called 'func' > > Instead of being called by the url > http://.../app/cont/func > Can it be called like > http://../func > directly.. > I am sure that it can be done ... just that I would have to spend some time > on the docs.. can someone please just link me to the correct section http://web2py.com/book/default/chapter/04?search=routes.py URL Rewrite
Re: [web2py] What is polymodel?
On Sep 6, 2010, at 9:10 AM, Jose wrote: > > What is polymodel? http://code.google.com/appengine/articles/polymodel.html > Do you use? > How is it used?
Re: [web2py] Re: Routes.py on GAE
On Sep 9, 2010, at 6:27 AM, mdipierro wrote:
>
> I do not understand where "unable to import Rocket" comes from.
That's a strange error. Also, the syntax error on routes.py is on line 3, which
is empty; there's no code until line 4.
My advice is to resolve the first error (Rocket) before worrying about the
routes error.
>
> On Sep 9, 8:03 am, Richard wrote:
>> I am using the following simple routes.py and find it works fine on
>> GAE with latest trunk:
>>
>> routes_in = (
>> ('/', '/init/default/index'),
>> ('/topics', '/init/topics/index'),
>> )
>> routes_out = [(second, first) for (first, second) in routes_in]
>>
>> On Sep 9, 9:49 pm, mdipierro wrote:
>>
>>> i cannot reproduce this problem. Can you send me your routes?
>>
>>> On Sep 7, 1:28 am, Miguel Goncalves wrote:
>>
Hi
>>
I guess this bug has not been fixed yet?
>>
I am getting the following error:
>>
unable to import Rocket
Your routes.py has a syntax error Please fix it before you restart web2py
Traceback (most recent call last):
File
"/base/data/home/apps/reviewround/1.344628390884008259/gluon/rewrite.py",
line 106, in load
exec routesfp.read() in symbols
File "", line 3
>>
^
SyntaxError: invalid syntax
>>
: invalid syntax (, line 3)
Traceback (most recent call last):
File
"/base/data/home/apps/reviewround/1.344628390884008259/gaehandler.py",
line 52, in
import gluon.main
File
"/base/data/home/apps/reviewround/1.344628390884008259/gluon/main.py",
line 66, in
rewrite.load()
File
"/base/data/home/apps/reviewround/1.344628390884008259/gluon/rewrite.py",
line 114, in load
raise e
: invalid syntax (, line 3)
>>
The routes.py looks like :
#!/usr/bin/python
# -*- coding: utf-8 -*-
>>
default_application = 'reviewround' # ordinarily set in base routes.py
default_controller = 'default' # ordinarily set in app-specific
routes.py
default_function = 'index'
>>
routes_in = ( ('/', '/reviewround/default/index'),)
routes_out = ( ('/reviewround/default/index', '/'),)
>>
thanks
Miguel
>>
>>
Re: [web2py] Re: Routes.py on GAE
On Sep 9, 2010, at 7:49 AM, mdipierro wrote:
>
> gaehanlder.py does not import Rocket.
main imports Rocket
> Is it possible gaehandler.py or
> app.yaml were modified?
>
> On Sep 9, 9:40 am, Jonathan Lundell wrote:
>> On Sep 9, 2010, at 6:27 AM, mdipierro wrote:
>>
>>
>>
>>> I do not understand where "unable to import Rocket" comes from.
>>
>> That's a strange error. Also, the syntax error on routes.py is on line 3,
>> which is empty; there's no code until line 4.
>>
>> My advice is to resolve the first error (Rocket) before worrying about the
>> routes error.
>>
>>
>>
>>> On Sep 9, 8:03 am, Richard wrote:
>>>> I am using the following simple routes.py and find it works fine on
>>>> GAE with latest trunk:
>>
>>>> routes_in = (
>>>> ('/', '/init/default/index'),
>>>> ('/topics', '/init/topics/index'),
>>>> )
>>>> routes_out = [(second, first) for (first, second) in routes_in]
>>
>>>> On Sep 9, 9:49 pm, mdipierro wrote:
>>
>>>>> i cannot reproduce this problem. Can you send me your routes?
>>
>>>>> On Sep 7, 1:28 am, Miguel Goncalves wrote:
>>
>>>>>> Hi
>>
>>>>>> I guess this bug has not been fixed yet?
>>
>>>>>> I am getting the following error:
>>
>>>>>> unable to import Rocket
>>>>>> Your routes.py has a syntax error Please fix it before you restart web2py
>>>>>> Traceback (most recent call last):
>>>>>> File
>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gluon/rewrite.py",
>>>>>> line 106, in load
>>>>>> exec routesfp.read() in symbols
>>>>>> File "", line 3
>>
>>>>>>^
>>>>>> SyntaxError: invalid syntax
>>
>>>>>> : invalid syntax (, line 3)
>>>>>> Traceback (most recent call last):
>>>>>> File
>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gaehandler.py",
>>>>>> line 52, in
>>>>>> import gluon.main
>>>>>> File
>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gluon/main.py",
>>>>>> line 66, in
>>>>>> rewrite.load()
>>>>>> File
>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gluon/rewrite.py",
>>>>>> line 114, in load
>>>>>> raise e
>>>>>> : invalid syntax (, line 3)
>>
>>>>>> The routes.py looks like :
>>>>>> #!/usr/bin/python
>>>>>> # -*- coding: utf-8 -*-
>>
>>>>>> default_application = 'reviewround' # ordinarily set in base
>>>>>> routes.py
>>>>>> default_controller = 'default' # ordinarily set in app-specific
>>>>>> routes.py
>>>>>> default_function = 'index'
>>
>>>>>> routes_in = ( ('/', '/reviewround/default/index'),)
>>>>>> routes_out = ( ('/reviewround/default/index', '/'),)
>>
>>>>>> thanks
>>>>>> Miguel
>>
>>
Re: [web2py] Re: Routes.py on GAE
On Sep 9, 2010, at 9:17 AM, mdipierro wrote:
>
> try:
>import rocket
> except:
>logging.warn('unable to import Rocket')
>
> True. This is supposed to fail on GAE. I will change it. No need to
> try the import and issue a warning on GAE.
...which leaves the mystery of the routes syntax error.
I'd try it with the first three lines (two comments and blank line) removed,
and see what happens.
I'd also carefully check routes.py for invisible garbage characters, perhaps
from some word processor. Word's idea of a non-breaking space, for example.
If possible, zip the routes.py that you're uploading to GAE, and send me a copy.
>
>
>
> On Sep 9, 9:57 am, Jonathan Lundell wrote:
>> On Sep 9, 2010, at 7:49 AM, mdipierro wrote:
>>
>>
>>
>>> gaehanlder.py does not import Rocket.
>>
>> main imports Rocket
>>
>>> Is it possible gaehandler.py or
>>> app.yaml were modified?
>>
>>> On Sep 9, 9:40 am, Jonathan Lundell wrote:
>>>> On Sep 9, 2010, at 6:27 AM, mdipierro wrote:
>>
>>>>> I do not understand where "unable to import Rocket" comes from.
>>
>>>> That's a strange error. Also, the syntax error on routes.py is on line 3,
>>>> which is empty; there's no code until line 4.
>>
>>>> My advice is to resolve the first error (Rocket) before worrying about the
>>>> routes error.
>>
>>>>> On Sep 9, 8:03 am, Richard wrote:
>>>>>> I am using the following simple routes.py and find it works fine on
>>>>>> GAE with latest trunk:
>>
>>>>>> routes_in = (
>>>>>> ('/', '/init/default/index'),
>>>>>> ('/topics', '/init/topics/index'),
>>>>>> )
>>>>>> routes_out = [(second, first) for (first, second) in routes_in]
>>
>>>>>> On Sep 9, 9:49 pm, mdipierro wrote:
>>
>>>>>>> i cannot reproduce this problem. Can you send me your routes?
>>
>>>>>>> On Sep 7, 1:28 am, Miguel Goncalves wrote:
>>
>>>>>>>> Hi
>>
>>>>>>>> I guess this bug has not been fixed yet?
>>
>>>>>>>> I am getting the following error:
>>
>>>>>>>> unable to import Rocket
>>>>>>>> Your routes.py has a syntax error Please fix it before you restart
>>>>>>>> web2py
>>>>>>>> Traceback (most recent call last):
>>>>>>>> File
>>>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gluon/rewrite.py",
>>>>>>>> line 106, in load
>>>>>>>> exec routesfp.read() in symbols
>>>>>>>> File "", line 3
>>
>>>>>>>>^
>>>>>>>> SyntaxError: invalid syntax
>>
>>>>>>>> : invalid syntax (, line 3)
>>>>>>>> Traceback (most recent call last):
>>>>>>>> File
>>>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gaehandler.py",
>>>>>>>> line 52, in
>>>>>>>> import gluon.main
>>>>>>>> File
>>>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gluon/main.py",
>>>>>>>> line 66, in
>>>>>>>> rewrite.load()
>>>>>>>> File
>>>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gluon/rewrite.py",
>>>>>>>> line 114, in load
>>>>>>>> raise e
>>>>>>>> : invalid syntax (, line 3)
>>
>>>>>>>> The routes.py looks like :
>>>>>>>> #!/usr/bin/python
>>>>>>>> # -*- coding: utf-8 -*-
>>
>>>>>>>> default_application = 'reviewround' # ordinarily set in base
>>>>>>>> routes.py
>>>>>>>> default_controller = 'default' # ordinarily set in
>>>>>>>> app-specific
>>>>>>>> routes.py
>>>>>>>> default_function = 'index'
>>
>>>>>>>> routes_in = ( ('/', '/reviewround/default/index'),)
>>>>>>>> routes_out = ( ('/reviewround/default/index', '/'),)
>>
>>>>>>>> thanks
>>>>>>>> Miguel
>>
>>
Re: [web2py] Re: Routes.py on GAE
On Sep 9, 2010, at 9:07 PM, Miguel Goncalves wrote:
> in my case I was using the following routes.py
What I'm looking for is the file itself (preferably zipped). I'm wondering if
there might be something in it that isn't surviving a paste into email, because
I don' t seen anything in line 3 that would cause a syntax error. (Notice that
this is a Python syntax error, not a complaint from the rewrite code.)
>
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
>
> default_application = 'reviewround' # ordinarily set in base routes.py
> default_controller = 'default' # ordinarily set in app-specific
> routes.py
> default_function = 'index'
>
>
> routes_in = ( ('/', '/reviewround/default/index'),)
> routes_out = ( ('/reviewround/default/index', '/'),)
>
> -Miguel
>
>
> On Thu, Sep 9, 2010 at 9:28 AM, Jonathan Lundell wrote:
> On Sep 9, 2010, at 9:17 AM, mdipierro wrote:
> >
> > try:
> >import rocket
> > except:
> >logging.warn('unable to import Rocket')
> >
> > True. This is supposed to fail on GAE. I will change it. No need to
> > try the import and issue a warning on GAE.
>
> ...which leaves the mystery of the routes syntax error.
>
> I'd try it with the first three lines (two comments and blank line) removed,
> and see what happens.
>
> I'd also carefully check routes.py for invisible garbage characters, perhaps
> from some word processor. Word's idea of a non-breaking space, for example.
>
> If possible, zip the routes.py that you're uploading to GAE, and send me a
> copy.
>
> >
> >
> >
> > On Sep 9, 9:57 am, Jonathan Lundell wrote:
> >> On Sep 9, 2010, at 7:49 AM, mdipierro wrote:
> >>
> >>
> >>
> >>> gaehanlder.py does not import Rocket.
> >>
> >> main imports Rocket
> >>
> >>> Is it possible gaehandler.py or
> >>> app.yaml were modified?
> >>
> >>> On Sep 9, 9:40 am, Jonathan Lundell wrote:
> >>>> On Sep 9, 2010, at 6:27 AM, mdipierro wrote:
> >>
> >>>>> I do not understand where "unable to import Rocket" comes from.
> >>
> >>>> That's a strange error. Also, the syntax error on routes.py is on line
> >>>> 3, which is empty; there's no code until line 4.
> >>
> >>>> My advice is to resolve the first error (Rocket) before worrying about
> >>>> the routes error.
> >>
> >>>>> On Sep 9, 8:03 am, Richard wrote:
> >>>>>> I am using the following simple routes.py and find it works fine on
> >>>>>> GAE with latest trunk:
> >>
> >>>>>> routes_in = (
> >>>>>> ('/', '/init/default/index'),
> >>>>>> ('/topics', '/init/topics/index'),
> >>>>>> )
> >>>>>> routes_out = [(second, first) for (first, second) in routes_in]
> >>
> >>>>>> On Sep 9, 9:49 pm, mdipierro wrote:
> >>
> >>>>>>> i cannot reproduce this problem. Can you send me your routes?
> >>
> >>>>>>> On Sep 7, 1:28 am, Miguel Goncalves wrote:
> >>
> >>>>>>>> Hi
> >>
> >>>>>>>> I guess this bug has not been fixed yet?
> >>
> >>>>>>>> I am getting the following error:
> >>
> >>>>>>>> unable to import Rocket
> >>>>>>>> Your routes.py has a syntax error Please fix it before you restart
> >>>>>>>> web2py
> >>>>>>>> Traceback (most recent call last):
> >>>>>>>> File
> >>>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gluon/rewrite.py",
> >>>>>>>> line 106, in load
> >>>>>>>> exec routesfp.read() in symbols
> >>>>>>>> File "", line 3
> >>
> >>>>>>>>^
> >>>>>>>> SyntaxError: invalid syntax
> >>
> >>>>>>>> : invalid syntax (, line 3)
> >>>>>>>> Traceback (most recent call last):
> >>>>>>>> File
> >>>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gaehandler.py",
> >>>>>>>> line 52, in
> >>>>>>>> import gluon.main
> >>>>>>>> File
> >>>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gluon/main.py",
> >>>>>>>> line 66, in
> >>>>>>>> rewrite.load()
> >>>>>>>> File
> >>>>>>>> "/base/data/home/apps/reviewround/1.344628390884008259/gluon/rewrite.py",
> >>>>>>>> line 114, in load
> >>>>>>>> raise e
> >>>>>>>> : invalid syntax (, line 3)
> >>
> >>>>>>>> The routes.py looks like :
> >>>>>>>> #!/usr/bin/python
> >>>>>>>> # -*- coding: utf-8 -*-
> >>
> >>>>>>>> default_application = 'reviewround' # ordinarily set in base
> >>>>>>>> routes.py
> >>>>>>>> default_controller = 'default' # ordinarily set in
> >>>>>>>> app-specific
> >>>>>>>> routes.py
> >>>>>>>> default_function = 'index'
> >>
> >>>>>>>> routes_in = ( ('/', '/reviewround/default/index'),)
> >>>>>>>> routes_out = ( ('/reviewround/default/index', '/'),)
> >>
> >>>>>>>> thanks
> >>>>>>>> Miguel
> >>
> >>
>
>
>
[web2py] app-specific routing
Massimo has applied (after a false start on my part) the final portion of the app-specific routing patch. There are no API changes (unless you're directly looking at rewrite.params, in which case ask about the new interface), but the new code is thread-safe and should be good to go. Have a look at the web2py book or at the comments in routes.example.py for general information on how to use the feature. (This is not the next-gen URL-rewrite code, which is still a good intention merely. It's just the app-specific version of the existing URL-rewrite logic.)
Re: [web2py] Re: app-specific routing
On Sep 10, 2010, at 1:20 PM, _po wrote: > > Hi, > > I am having trouble with this patch. (rev d38a7099445b) > The recently modified /gluon/streamer.py seems to prevent web2py from > starting : Thanks; I'll have a look. > > $ hg up d38a7099445b > 4 files updated, 0 files merged, 0 files removed, 0 files unresolved > > $ python web2py.py > Traceback (most recent call last): > File "web2py.py", line 17, in >import gluon.widget > File "/media/DONNEES/Mes documents/Documents/Prog/web2py/gluon/ > widget.py", line 28, in >import main > File "/media/DONNEES/Mes documents/Documents/Prog/web2py/gluon/ > main.py", line 48, in >from globals import Request, Response, Session > File "/media/DONNEES/Mes documents/Documents/Prog/web2py/gluon/ > globals.py", line 19, in >from streamer import streamer, stream_file_or_304_or_206, > DEFAULT_CHUNK_SIZE > File "/media/DONNEES/Mes documents/Documents/Prog/web2py/gluon/ > streamer.py", line 46, in >error_message = main.thread.routes.error_message % 'invalid > request', > AttributeError: 'thread._local' object has no attribute 'routes' > > > > > On 10 sep, 19:10, Jonathan Lundell wrote: >> Massimo has applied (after a false start on my part) the final portion of >> the app-specific routing patch. There are no API changes (unless you're >> directly looking at rewrite.params, in which case ask about the new >> interface), but the new code is thread-safe and should be good to go. >> >> Have a look at the web2py book or at the comments in routes.example.py for >> general information on how to use the feature. >> >> (This is not the next-gen URL-rewrite code, which is still a good intention >> merely. It's just the app-specific version of the existing URL-rewrite >> logic.)
Re: [web2py] Re: app-specific routing
On Sep 10, 2010, at 1:20 PM, _po wrote: > > Hi, > > I am having trouble with this patch. (rev d38a7099445b) > The recently modified /gluon/streamer.py seems to prevent web2py from > starting : I found this problem (and another one), and will send Massimo a patch shortly. > > $ hg up d38a7099445b > 4 files updated, 0 files merged, 0 files removed, 0 files unresolved > > $ python web2py.py > Traceback (most recent call last): > File "web2py.py", line 17, in >import gluon.widget > File "/media/DONNEES/Mes documents/Documents/Prog/web2py/gluon/ > widget.py", line 28, in >import main > File "/media/DONNEES/Mes documents/Documents/Prog/web2py/gluon/ > main.py", line 48, in >from globals import Request, Response, Session > File "/media/DONNEES/Mes documents/Documents/Prog/web2py/gluon/ > globals.py", line 19, in >from streamer import streamer, stream_file_or_304_or_206, > DEFAULT_CHUNK_SIZE > File "/media/DONNEES/Mes documents/Documents/Prog/web2py/gluon/ > streamer.py", line 46, in >error_message = main.thread.routes.error_message % 'invalid > request', > AttributeError: 'thread._local' object has no attribute 'routes' > > > > > On 10 sep, 19:10, Jonathan Lundell wrote: >> Massimo has applied (after a false start on my part) the final portion of >> the app-specific routing patch. There are no API changes (unless you're >> directly looking at rewrite.params, in which case ask about the new >> interface), but the new code is thread-safe and should be good to go. >> >> Have a look at the web2py book or at the comments in routes.example.py for >> general information on how to use the feature. >> >> (This is not the next-gen URL-rewrite code, which is still a good intention >> merely. It's just the app-specific version of the existing URL-rewrite >> logic.)
Re: [web2py] Re: Scaffolding app with Twitter OAuth1.0a auth
Folks playing with Twitter OAuth might care to read this: http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars/
Re: [web2py] TAG() throws a ticket when string too short
On Sep 12, 2010, at 8:57 AM, weheh wrote: > > I'm flattening some text, assuming it's html, and get this error > message when the text input is less than 4 characters: > > input='abc' > stream=cStringIO.StringIO(TAG(input).flatten()) What are you expecting this to generate? At first glance, it seems like an abuse of TAG(). > > > File "C:/web2py/applications/myapp/controllers/myfunc.py", line 311, > in process_text_in >stream=cStringIO.StringIO(TAG(input).flatten()) > File "C:\web2py\gluon\html.py", line 821, in __call__ >return web2pyHTMLParser(decoder.decoder(html)).tree > File "C:\web2py\gluon\decoder.py", line 72, in decoder >encoding = autoDetectXMLEncoding(buffer) > File "C:\web2py\gluon\decoder.py", line 38, in autoDetectXMLEncoding >bytes = (byte1, byte2, byte3, byte4) = tuple(map(ord, > buffer[0:4])) > ValueError: need more than 3 values to unpack > > 4 or more characters works OK.
Re: [web2py] Re: Routes.py on GAE
On Sep 12, 2010, at 11:46 AM, Miguel Goncalves wrote:
> I attached the zipped routed file to this email.
Thank you. It looks OK.
Miguel, if I send you a small patch for rewrite.py, to add a little debugging,
could you run it for me?
What I have in mind (and feel free to do this for yourself if you like) is
printing a hex dump of the relevant string, in the exception handler.
You could also try deleting the first three lines of routes.py (two comments
and a blank line) to see if that makes any difference.
The patch would be something like this. Here's the stock code:
try:
routesfp = open(path, 'r')
exec routesfp.read() in symbols
routesfp.close()
logger.info('URL rewrite is on. configuration in %s' % path)
except SyntaxError, e:
routesfp.close()
logger.error('Your %s has a syntax error ' % path + \
'Please fix it before you restart web2py\n' + \
traceback.format_exc())
raise e
The debug code:
try:
routesfp = open(path, 'r')
routestring = routesfp.read()
exec routestring in symbols
routesfp.close()
logger.info('URL rewrite is on. configuration in %s' % path)
except SyntaxError, e:
routesfp.close()
hex = ""
for c in routestring:
hex += "0123456789abcdef"[ord(c)//16] +
"0123456789abcdef"[ord(c)%16] + " "
logger.error('Your %s has a syntax error ' % path + \
'Please fix it before you restart web2py\n' + \
'File: %s\n' % hex + \
traceback.format_exc())
raise e
>
> thanks
> Miguel
>
>
> On Thu, Sep 9, 2010 at 9:24 PM, Jonathan Lundell wrote:
> On Sep 9, 2010, at 9:07 PM, Miguel Goncalves wrote:
>> in my case I was using the following routes.py
>
> What I'm looking for is the file itself (preferably zipped). I'm wondering if
> there might be something in it that isn't surviving a paste into email,
> because I don' t seen anything in line 3 that would cause a syntax error.
> (Notice that this is a Python syntax error, not a complaint from the rewrite
> code.)
>
>>
>> #!/usr/bin/python
>> # -*- coding: utf-8 -*-
>>
>> default_application = 'reviewround' # ordinarily set in base routes.py
>> default_controller = 'default' # ordinarily set in app-specific
>> routes.py
>> default_function = 'index'
>>
>>
>> routes_in = ( ('/', '/reviewround/default/index'),)
>> routes_out = ( ('/reviewround/default/index', '/'),)
>>
>> -Miguel
>>
>>
>> On Thu, Sep 9, 2010 at 9:28 AM, Jonathan Lundell wrote:
>> On Sep 9, 2010, at 9:17 AM, mdipierro wrote:
>> >
>> > try:
>> >import rocket
>> > except:
>> >logging.warn('unable to import Rocket')
>> >
>> > True. This is supposed to fail on GAE. I will change it. No need to
>> > try the import and issue a warning on GAE.
>>
>> ...which leaves the mystery of the routes syntax error.
>>
>> I'd try it with the first three lines (two comments and blank line) removed,
>> and see what happens.
>>
>> I'd also carefully check routes.py for invisible garbage characters, perhaps
>> from some word processor. Word's idea of a non-breaking space, for example.
>>
>> If possible, zip the routes.py that you're uploading to GAE, and send me a
>> copy.
>>
>> >
>> >
>> >
>> > On Sep 9, 9:57 am, Jonathan Lundell wrote:
>> >> On Sep 9, 2010, at 7:49 AM, mdipierro wrote:
>> >>
>> >>
>> >>
>> >>> gaehanlder.py does not import Rocket.
>> >>
>> >> main imports Rocket
>> >>
>> >>> Is it possible gaehandler.py or
>> >>> app.yaml were modified?
>> >>
>> >>> On Sep 9, 9:40 am, Jonathan Lundell wrote:
>> >>>> On Sep 9, 2010, at 6:27 AM, mdipierro wrote:
>> >>
>> >>>>> I do not understand where "unable to import Rocket" comes from.
>> >>
>> >>>> That's a strange error. Also, the syntax error on routes.py is on line
>> >>>> 3, which is empty; there's no code until line 4.
>> >>
>> >>>> My advice is to resolve the first error (Rocket) before worrying about
>> >>&g
Re: [web2py] TAG() throws a ticket when string too short
On Sep 12, 2010, at 9:56 AM, Jonathan Lundell wrote: > > On Sep 12, 2010, at 8:57 AM, weheh wrote: >> >> I'm flattening some text, assuming it's html, and get this error >> message when the text input is less than 4 characters: >> >> input='abc' >> stream=cStringIO.StringIO(TAG(input).flatten()) > > What are you expecting this to generate? At first glance, it seems like an > abuse of TAG(). Never mind; my misreading.
Re: [web2py] Re: Decimal type validator
On Sep 13, 2010, at 4:55 AM, mdipierro wrote:
>
> Can you help debug? In gluon/validators.py
>
>def __call__(self, value):
>try:
>v = decimal.Decimal(str(value)) # << line 725
>...
>except (ValueError, TypeError, decimal.InvalidOperation):
>pass
>return (value, self.error_message)
>
> why is the exception not caught?
Catching InvalidOperation was a fix we added a while back. So it's probably a
version problem.
BTW, I notice that decimal.py is not locale-sensitive. The regex it's using to
parse the number has a literal period in it, so no hope of a comma being
accepted, at least not in 2.6 and earlier (I have no idea about later).
Massimo, I notice that there's no way to call IS_DECIMAL_IN_RANGE(None,None):
that is, to ask for a decimal number without caring about min/max. That seems
wrong to me.
>
> On Sep 13, 2:22 am, Kenneth wrote:
>> Hello,
>>
>> I have a tablefield defined as decimal(10,2).
>>
>> Fields for SQLFORM is defined as:
>> fields=['price_consumer']
>> field_labels=['price_cunsumer': T('price consumer')]
>>
>> and then the form is generated as:
>> form = SQLFORM(db.product, fields=fields, labels=field_labels)
>>
>> When I try to fill the form with values I get a Internal error because
>> i tried to put the price with a comma, so 12,50 is not allowed but
>> 12.50 is.
>>
>> How to indicate the problem and not to get the Internal error?
>>
>> Error traceback:
>> Traceback (most recent call last):
>> File "gluon/restricted.py", line 186, in restricted
>> exec ccode in environment
>> File "/data/domains/exp-kal.nudata.fi/applications/init/controllers/
>> product.py", line 99, in
>> File "gluon/globals.py", line 96, in
>> self._caller = lambda f: f()
>> File "gluon/tools.py", line 2219, in f
>> return action(*a, **b)
>> File "/data/domains/exp-kal.nudata.fi/applications/init/controllers/
>> product.py", line 81, in edit
>> if form.accepts(request.vars, session):
>> File "gluon/sqlhtml.py", line 906, in accepts
>> hideerror=hideerror,
>> File "gluon/html.py", line 1512, in accepts
>> status = self._traverse(status,hideerror)
>> File "gluon/html.py", line 522, in _traverse
>> newstatus = c._traverse(status,hideerror) and newstatus
>> File "gluon/html.py", line 522, in _traverse
>> newstatus = c._traverse(status,hideerror) and newstatus
>> File "gluon/html.py", line 522, in _traverse
>> newstatus = c._traverse(status,hideerror) and newstatus
>> File "gluon/html.py", line 522, in _traverse
>> newstatus = c._traverse(status,hideerror) and newstatus
>> File "gluon/html.py", line 529, in _traverse
>> newstatus = self._validate()
>> File "gluon/html.py", line 1300, in _validate
>> (value, errors) = validator(value)
>> File "gluon/validators.py", line 2313, in __call__
>> return self.other(value)
>> File "gluon/validators.py", line 725, in __call__
>> v = decimal.Decimal(str(value))
>> File "/usr/lib64/python2.5/decimal.py", line 614, in __new__
>> self._sign, self._int, self._exp =
>> context._raise_error(ConversionSyntax)
>> File "/usr/lib64/python2.5/decimal.py", line 2325, in _raise_error
>> raise error, explanation
>> InvalidOperation
Re: [web2py] Re: Decimal type validator
On Sep 13, 2010, at 8:34 AM, Jonathan Lundell wrote: > > Massimo, I notice that there's no way to call IS_DECIMAL_IN_RANGE(None,None): > that is, to ask for a decimal number without caring about min/max. That seems > wrong to me. The comment says: > The minimum and maximum limits can be None, meaning no lower or upper > limit, > respectively. ...but this seems not to be true. Same for IS_FLOAT_IN_RANGE. Would you like a patch? I think we should also default min & max to None, so one can call eg IS_DECIMAL_IN_RANGE()(something), meaning IS_DECIMAL()(something).
Re: [web2py] Re: Decimal type validator
On Sep 13, 2010, at 9:42 AM, mdipierro wrote: > > yes please. thanks. http://web.me.com/jlundell/filechute/validators.zip also IS_INT_IN_RANGE. > > On Sep 13, 11:22 am, Jonathan Lundell wrote: >> On Sep 13, 2010, at 8:34 AM, Jonathan Lundell wrote: >> >> >> >>> Massimo, I notice that there's no way to call >>> IS_DECIMAL_IN_RANGE(None,None): that is, to ask for a decimal number >>> without caring about min/max. That seems wrong to me. >> >> The comment says: >> >>> The minimum and maximum limits can be None, meaning no lower or upper >>> limit, >>> respectively. >> >> ...but this seems not to be true. >> >> Same for IS_FLOAT_IN_RANGE. >> >> Would you like a patch? I think we should also default min & max to None, so >> one can call eg IS_DECIMAL_IN_RANGE()(something), meaning >> IS_DECIMAL()(something).
Re: [web2py] Re: web2py 1.84.1 is out
On Sep 13, 2010, at 12:33 PM, bally boy wrote: > Could someone be kind enough to point me to the posts relating to these > changes in the new release:- > > > improved OpenID (thanks Michele) > > moved DAL and routes to thread.local (thanks Jonathan, again) (***) > The threading.local changes don't affect the API. My initial implementation of app-specific routes was not thread-safe; this one is. The DAL was already thread-safe, but Massimo changed the relevant code to use threading.local.
Re: [web2py] Re: Routes.py on GAE
On Sep 13, 2010, at 11:44 PM, Miguel Goncalves wrote:
> Hi
>
> So I installed the debugging code and following the errors it was giving me I
> got rid of empty lines.
OK, this took longer than it should have, largely thanks to Python's terse
error messages.
The problem is that you're using DOS-style end-of-lines (\r\n) and the Python
exec() statement, which is being used to compile routes.py, will not accept
them. Hence the syntax error.
The quick fix: save the file with Unix-style newlines only (\n).
The longer-term fix: we need to read the file and remove carriage returns
before calling exec.
There's a slight mystery: how does routes.py ever work on Windows? I have four
theories:
1. Nobody ever uses routes.py on Windows
2. Everyone is saving routes.py with Unix newlines on Windows
3. read() on Windows Python strips \r by default
4. exec() on Windows Python tolerates \r
Not that it matters, particularly. The fix is to get rid of them.
> My current routes.py is (I also attached it compressed to this mail):
>
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
> default_application = 'reviewround' # ordinarily set in base routes.py
> default_controller = 'default' # ordinarily set in app-specific
> routes.py
> default_function='index'
> routes_in = ( ('/', '/reviewround/default/index'),)
> routes_out = ( ('/reviewround/default/index', '/'),)
>
> AND I still get the following error:
>
> unable to import Rocket
> Your routes.py has a syntax error Please fix it before you restart web2py
> File: 23 21 2f 75 73 72 2f 62 69 6e 2f 70 79 74 68 6f 6e 0d 0a 23 20 2d 2a 2d
> 20 63 6f 64 69 6e 67 3a 20 75 74 66 2d 38 20 2d 2a 2d 0d 0a 64 65 66 61 75 6c
> 74 5f 61 70 70 6c 69 63 61 74 69 6f 6e 20 3d 20 27 72 65 76 69 65 77 72 6f 75
> 6e 64 27 20 20 20 20 20 23 20 6f 72 64 69 6e 61 72 69 6c 79 20 73 65 74 20 69
> 6e 20 62 61 73 65 20 72 6f 75 74 65 73 2e 70 79 0d 0a 64 65 66 61 75 6c 74 5f
> 63 6f 6e 74 72 6f 6c 6c 65 72 20 3d 20 27 64 65 66 61 75 6c 74 27 20 20 20 20
> 20 20 20 20 20 20 23 20 6f 72 64 69 6e 61 72 69 6c 79 20 73 65 74 20 69 6e 20
> 61 70 70 2d 73 70 65 63 69 66 69 63 20 72 6f 75 74 65 73 2e 70 79 0d 0a 64 65
> 66 61 75 6c 74 5f 66 75 6e 63 74 69 6f 6e 3d 27 69 6e 64 65 78 27 0d 0a 72 6f
> 75 74 65 73 5f 69 6e 20 3d 20 28 20 28 27 2f 27 2c 20 27 2f 72 65 76 69 65 77
> 72 6f 75 6e 64 2f 64 65 66 61 75 6c 74 2f 69 6e 64 65 78 27 29 2c 29 0d 0a 72
> 6f 75 74 65 73 5f 6f 75 74 20 3d 20 28 20 28 27 2f 72 65 76 69 65 77 72 6f 75
> 6e 64 2f 64 65 66 61 75 6c 74 2f 69 6e 64 65 78 27 2c 20 27 2f 27 29 2c 29
> Traceback (most recent call last):
> File
> "/base/data/home/apps/reviewround/1.344790923581374734/gluon/rewrite.py",
> line 121, in load
> exec routestring in symbols
> File "", line 5
> default_function='index'
>
> ^
> SyntaxError: invalid syntax
>
> : invalid syntax (, line 5)
> Traceback (most recent call last):
> File "/base/data/home/apps/reviewround/1.344790923581374734/gaehandler.py",
> line 52, in
> import gluon.main
> File "/base/data/home/apps/reviewround/1.344790923581374734/gluon/main.py",
> line 66, in
> rewrite.load()
> File
> "/base/data/home/apps/reviewround/1.344790923581374734/gluon/rewrite.py",
> line 133, in load
> raise e
> : invalid syntax (, line 5)
>
> Not sure what is wrong with the line 5.
>
> thanks
> Miguel
>
>
>
>
> On Sun, Sep 12, 2010 at 12:29 PM, Jonathan Lundell wrote:
> On Sep 12, 2010, at 11:46 AM, Miguel Goncalves wrote:
> > I attached the zipped routed file to this email.
>
> Thank you. It looks OK.
>
> Miguel, if I send you a small patch for rewrite.py, to add a little
> debugging, could you run it for me?
>
> What I have in mind (and feel free to do this for yourself if you like) is
> printing a hex dump of the relevant string, in the exception handler.
>
> You could also try deleting the first three lines of routes.py (two comments
> and a blank line) to see if that makes any difference.
>
> The patch would be something like this. Here's the stock code:
>
>try:
>routesfp = open(path, 'r')
>exec routesfp.read() in symbols
>routesfp.close()
>logger.info('URL rewrite is on. configuration in %s' % path)
>except SyntaxError, e:
>routesfp.close()
>logger.error('Your %s has a syntax error ' % path + \
> 'Please fix it before you restart web2py\n' + \
> traceback.format_exc())
>rai
Re: [web2py] Re: Routes.py on GAE
Massimo, here's a patch. In rewrite.py, change this:
exec routesfp.read() in symbols
to this:
exec routesfp.read().translate(None, '\r') in symbols
(and test)
I notice that there's something like this elsewhere:
def compile2(code,layer):
"""
The +'\n' is necessary else compile fails when code ends in a comment.
"""
return compile(code.rstrip().replace('\r\n','\n')+'\n', layer, 'exec')
...though in the case of the rewrite exec call, there doesn't seem to be a need
for a terminal newline, even if I put a comment on the last line.
Re: [web2py] bug in gluon/rocket.py
On Sep 15, 2010, at 1:05 PM, Bruno Rocha wrote: > May be it is a Typo? and should be "exec" No. The call is: handled = self._handleError(*exc) The bad line is: tb = traceback.format_exception(*exc) it should probably be this: tb = traceback.format_exception((typ, val, tb)) If you're in a position to test it, you could try that until Tim has a chance to verify it. > > 2010/9/15 Kevin > starting browser...in 5 seconds > Exception in thread Thread-18: > Traceback (most recent call last): > File "threading.pyc", line 486, in __bootstrap_inner > File "gluon/rocket.py", line 880, in run > File "gluon/rocket.py", line 822, in _handleError > NameError: global name 'exc' is not defined > > I downloaded the code and took a quick look. It is true that exc is > not defined. It isn't as clear as to what to do about it. Need a > web2py developer to take a look. > > > > -- > > http://rochacbruno.com.br
[web2py] web2py & Python 2.7
Is that combination working out OK for anyone? I have a motivation to move to 2.7, because of another project I contribute to (OpenSTV), but I have no desire to maintain two Pythons.
Re: [web2py] Re: bug in gluon/rocket.py
On Sep 15, 2010, at 2:06 PM, mdipierro wrote: > > when does the bug show up? When a web2py request throws an exception back to Rocket, it looks like. > > On Sep 15, 3:20 pm, Jonathan Lundell wrote: >> On Sep 15, 2010, at 1:05 PM, Bruno Rocha wrote: >> >>> May be it is a Typo? and should be "exec" >> >> No. The call is: >> >> handled = self._handleError(*exc) >> >> The bad line is: >> >> tb = traceback.format_exception(*exc) >> >> it should probably be this: >> >> tb = traceback.format_exception((typ, val, tb)) >> >> If you're in a position to test it, you could try that until Tim has a >> chance to verify it. >> >> >> >>> 2010/9/15 Kevin >>> starting browser...in 5 seconds >>> Exception in thread Thread-18: >>> Traceback (most recent call last): >>> File "threading.pyc", line 486, in __bootstrap_inner >>> File "gluon/rocket.py", line 880, in run >>> File "gluon/rocket.py", line 822, in _handleError >>> NameError: global name 'exc' is not defined >> >>> I downloaded the code and took a quick look. It is true that exc is >>> not defined. It isn't as clear as to what to do about it. Need a >>> web2py developer to take a look. >> >>> -- >> >>> http://rochacbruno.com.br >> >>
Re: [web2py] Re: Routes.py on GAE
On Sep 15, 2010, at 2:53 PM, Michael Ellis wrote:
>
> Not sure if this is related; apologies if not.
> I have web2py/routes.py containing
>
> """
> routes_in = (
> ('/favicon.ico', '/init/static/favicon.ico'),
> ('/robots.txt', '/init/static/robots.txt'),
> )
> routes_out = ()
> """
>
> and app.yaml containing
>
> """
> - url: /(?P.+?)/static/(?P.+)
> static_files: applications/\1/static/\2
> upload: applications/(.+?)/static/(.+)
> secure: optional
> expiration: "90d"
> """
>
> GAE Launcher at startup is saying:
>
> WARNING 2010-09-15 21:43:18,429 dev_appserver.py:1175] Blocking
> access to static file "/Users/mellis/web2py/applications/init/static/
> favicon.ico"
>
> and thereafter issuing 403's for attempts to get favicon.ico.
>
> What else do I need to do? I'm still using version 184.0.
I've never used GAE. Aside from the warning and the 403's, does anything else
look wrong? Is the path what you would expect? (It looks like an OS X path; is
that normal for GAE?)
>
> Thanks,
> Mike
>
>
> On Sep 15, 9:25 am, mdipierro wrote:
>> please check trunk in 5 minutes.
>>
>> On Sep 14, 9:56 am, Jonathan Lundell wrote:
>>
>>
>>
>>> Massimo, here's a patch. In rewrite.py, change this:
>>
>>> exec routesfp.read() in symbols
>>
>>> to this:
>>
>>> exec routesfp.read().translate(None, '\r') in symbols
>>
>>> (and test)
>>
>>> I notice that there's something like this elsewhere:
>>
>>> def compile2(code,layer):
>>> """
>>> The +'\n' is necessary else compile fails when code ends in a comment.
>>> """
>>> return compile(code.rstrip().replace('\r\n','\n')+'\n', layer, 'exec')
>>
>>> ...though in the case of the rewrite exec call, there doesn't seem to be a
>>> need for a terminal newline, even if I put a comment on the last line.
Re: [web2py] Re: Routes.py on GAE
On Sep 15, 2010, at 3:46 PM, Michael Ellis wrote:
> The error is reported by GAE Launcher, the test app you use before deploying
> to GAE. Hence the OS X path. Nothing else seems wrong; the app's pages
> render correctly etc.
I don't know. Does routes.py do the right thing for favicon.ico if you run it
on localhost? Do you *have* a favicon.ico in init/static?
A question for Massimo: the stock app.yaml has:
- url: /(?P.+?)/static/(?P.+)
static_files: applications/\1/static/\2
upload: applications/(.+?)/static/(.+)
secure: optional
expiration: "90d"
Why does this have ?P & b but use \1 and \2? Or is there some implicit logic
going on under the covers?
>
>
>
> On Wed, Sep 15, 2010 at 6:16 PM, Jonathan Lundell wrote:
> On Sep 15, 2010, at 2:53 PM, Michael Ellis wrote:
> >
> > Not sure if this is related; apologies if not.
> > I have web2py/routes.py containing
> >
> > """
> > routes_in = (
> > ('/favicon.ico', '/init/static/favicon.ico'),
> > ('/robots.txt', '/init/static/robots.txt'),
> > )
> > routes_out = ()
> > """
> >
> > and app.yaml containing
> >
> > """
> > - url: /(?P.+?)/static/(?P.+)
> > static_files: applications/\1/static/\2
> > upload: applications/(.+?)/static/(.+)
> > secure: optional
> > expiration: "90d"
> > """
> >
> > GAE Launcher at startup is saying:
> >
> > WARNING 2010-09-15 21:43:18,429 dev_appserver.py:1175] Blocking
> > access to static file "/Users/mellis/web2py/applications/init/static/
> > favicon.ico"
> >
> > and thereafter issuing 403's for attempts to get favicon.ico.
> >
> > What else do I need to do? I'm still using version 184.0.
>
> I've never used GAE. Aside from the warning and the 403's, does anything else
> look wrong? Is the path what you would expect? (It looks like an OS X path;
> is that normal for GAE?)
>
>
> >
> > Thanks,
> > Mike
> >
> >
> > On Sep 15, 9:25 am, mdipierro wrote:
> >> please check trunk in 5 minutes.
> >>
> >> On Sep 14, 9:56 am, Jonathan Lundell wrote:
> >>
> >>
> >>
> >>> Massimo, here's a patch. In rewrite.py, change this:
> >>
> >>> exec routesfp.read() in symbols
> >>
> >>> to this:
> >>
> >>> exec routesfp.read().translate(None, '\r') in symbols
> >>
> >>> (and test)
> >>
> >>> I notice that there's something like this elsewhere:
> >>
> >>> def compile2(code,layer):
> >>> """
> >>> The +'\n' is necessary else compile fails when code ends in a comment.
> >>> """
> >>> return compile(code.rstrip().replace('\r\n','\n')+'\n', layer, 'exec')
> >>
> >>> ...though in the case of the rewrite exec call, there doesn't seem to be
> >>> a need for a terminal newline, even if I put a comment on the last line.
>
>
>
Re: [web2py] Re: web2py & Python 2.7
On Sep 15, 2010, at 3:55 PM, mart wrote: > > Had a couple of issues with Massimo's pre-release of 1.84, but has > since been fixed. I'm on Mac os X (10.6) & Ubuntu 10 and all is well > here. Thanks to both of you. I guess I'll take the plunge. OS X here. > > Thanks, > Mart :) > > On Sep 15, 5:08 pm, Vasile Ermicioi wrote: >> yes, I use it already for a few months and everything works fine, both on >> windows (XP) and on linux (CentOS)
Re: [web2py] Re: Routes.py on GAE
On Sep 15, 2010, at 4:39 PM, Michael Ellis wrote:
> Problem resolved, thanks to suggestion from cfh. Added explicit favicon.ico
> handler
That's good, but do we understand why the original didn't work? (Just curious.)
>
>
> - url: /favicon.ico
> static_files: applications/init/static/favicon.ico
> upload: applications/init/static/favicon.ico
>
> There's a bonus. It works without routes.py. That's handy because I didn't
> want to have to version control anything outside my app's directory.
FWIW, I keep routes.py in myapp/private/ and copy (or link) it at installation
time.
>
> Cheers,
> Mike
>
>
> On Wed, Sep 15, 2010 at 6:59 PM, Jonathan Lundell wrote:
> On Sep 15, 2010, at 3:46 PM, Michael Ellis wrote:
>> The error is reported by GAE Launcher, the test app you use before deploying
>> to GAE. Hence the OS X path. Nothing else seems wrong; the app's pages
>> render correctly etc.
>
> I don't know. Does routes.py do the right thing for favicon.ico if you run it
> on localhost? Do you *have* a favicon.ico in init/static?
>
> A question for Massimo: the stock app.yaml has:
>
> - url: /(?P.+?)/static/(?P.+)
> static_files: applications/\1/static/\2
> upload: applications/(.+?)/static/(.+)
> secure: optional
> expiration: "90d"
>
> Why does this have ?P & b but use \1 and \2? Or is there some implicit
> logic going on under the covers?
>
>>
>>
>>
>> On Wed, Sep 15, 2010 at 6:16 PM, Jonathan Lundell wrote:
>> On Sep 15, 2010, at 2:53 PM, Michael Ellis wrote:
>> >
>> > Not sure if this is related; apologies if not.
>> > I have web2py/routes.py containing
>> >
>> > """
>> > routes_in = (
>> > ('/favicon.ico', '/init/static/favicon.ico'),
>> > ('/robots.txt', '/init/static/robots.txt'),
>> > )
>> > routes_out = ()
>> > """
>> >
>> > and app.yaml containing
>> >
>> > """
>> > - url: /(?P.+?)/static/(?P.+)
>> > static_files: applications/\1/static/\2
>> > upload: applications/(.+?)/static/(.+)
>> > secure: optional
>> > expiration: "90d"
>> > """
>> >
>> > GAE Launcher at startup is saying:
>> >
>> > WARNING 2010-09-15 21:43:18,429 dev_appserver.py:1175] Blocking
>> > access to static file "/Users/mellis/web2py/applications/init/static/
>> > favicon.ico"
>> >
>> > and thereafter issuing 403's for attempts to get favicon.ico.
>> >
>> > What else do I need to do? I'm still using version 184.0.
>>
>> I've never used GAE. Aside from the warning and the 403's, does anything
>> else look wrong? Is the path what you would expect? (It looks like an OS X
>> path; is that normal for GAE?)
>>
>>
>> >
>> > Thanks,
>> > Mike
>> >
>> >
>> > On Sep 15, 9:25 am, mdipierro wrote:
>> >> please check trunk in 5 minutes.
>> >>
>> >> On Sep 14, 9:56 am, Jonathan Lundell wrote:
>> >>
>> >>
>> >>
>> >>> Massimo, here's a patch. In rewrite.py, change this:
>> >>
>> >>> exec routesfp.read() in symbols
>> >>
>> >>> to this:
>> >>
>> >>> exec routesfp.read().translate(None, '\r') in symbols
>> >>
>> >>> (and test)
>> >>
>> >>> I notice that there's something like this elsewhere:
>> >>
>> >>> def compile2(code,layer):
>> >>> """
>> >>> The +'\n' is necessary else compile fails when code ends in a
>> >>> comment.
>> >>> """
>> >>> return compile(code.rstrip().replace('\r\n','\n')+'\n', layer,
>> >>> 'exec')
>> >>
>> >>> ...though in the case of the rewrite exec call, there doesn't seem to be
>> >>> a need for a terminal newline, even if I put a comment on the last line.
>>
>>
>>
>
>
>
Re: [web2py] Re: web2py & Python 2.7
On Sep 15, 2010, at 5:03 PM, mart wrote: > > hey, that's right! it was you who fixed the 2.7 issue on os x! > > so, thank YOU! :) No problem (especially since I broke it in the first place with the logging logic...). > > Mart > > On Sep 15, 7:00 pm, Jonathan Lundell wrote: >> On Sep 15, 2010, at 3:55 PM, mart wrote: >> >> >> >>> Had a couple of issues with Massimo's pre-release of 1.84, but has >>> since been fixed. I'm on Mac os X (10.6) & Ubuntu 10 and all is well >>> here. >> >> Thanks to both of you. I guess I'll take the plunge. OS X here. >> >> >> >>> Thanks, >>> Mart :) >> >>> On Sep 15, 5:08 pm, Vasile Ermicioi wrote: >>>> yes, I use it already for a few months and everything works fine, both on >>>> windows (XP) and on linux (CentOS) >> >>
[web2py] accepts [was: misunderstandings]
On Sep 16, 2010, at 7:26 AM, Michael Ellis wrote: > > I was never much bothered by either of those issues, but there is one > bit of 'magic' that did (and to some extent still does) confuse me. > I'm wondering if it might be worthwhile to give an detailed > explanation what goes on in form.accepts(). > > When I first saw the idiom > > if form.accepts(): > ... > return dict(form=form) > > my assumption was that the call to form.accepts() was somehow > rendering and transmitting the page and waiting for a user response. > But then, I wondered how that could be since the form isn't passed to > the view until the return() is executed. Then I tried tracing a > controller and saw that it was being called multiple times. I got > lost down in the gluon code and more or less gave up trying to find > out exactly how the rabbit gets into the hat. Now I just use it and > trust that it works, but it still bothers me not to know what's going > on under the hood. I've had the same reaction. The key to my understanding form.accepts, fwiw, was reading accepts itself. Keep in mind that web2py encourages form self-submission. That implies that the same code (controller/function) typically needs to run twice: once to create the page+form for display, and again to handle the form's submission. So form.accepts() is telling you whether it's the first time through, form creation (False) or the second, form submission (True). It's a little more complicated than that because of validation and error handling, but that's it in a nutshell.
Re: [web2py] accepts [was: misunderstandings]
On Sep 16, 2010, at 10:08 AM, Michael Ellis wrote: > Thanks, Jonathan. That's approximately what I had reasoned it must be doing, > but couldn't state as clearly as you have. > > So, if I'm now understanding it correctly, form.accepts() is roughly > equivalent to the following conditions: > > (request contains submitted form elements) and > (form key matches) and > (all elements pass validation) That's pretty much it. And if it's false, you need to check form.errors for the case in which the submission has errors. > > The 'magic' is simply that clicking the submit button sends a second request > to the controller that created it. So the form object only seems to persist; > in actuality, it's recreated from scratch when the second request comes in. Right. And the form submits to the same controller because you tell it to (or let it do so by default). It's always *possible* to submit it elsewhere, but setting the forms action. But that can get very confusing. > > All of which explains why I was unable to store extra info in the form object > at view time and have it available after form.accepts() came back True. Yeah. Depending on what you're after, you can create a hidden form element and get it back in vars, or maybe put it in session. > > Is that a fair summary of how it works? I think so, yes. Now if only DAL objects were as easy to understand > > > On Thu, Sep 16, 2010 at 11:04 AM, Jonathan Lundell wrote: > On Sep 16, 2010, at 7:26 AM, Michael Ellis wrote: > > > > I was never much bothered by either of those issues, but there is one > > bit of 'magic' that did (and to some extent still does) confuse me. > > I'm wondering if it might be worthwhile to give an detailed > > explanation what goes on in form.accepts(). > > > > When I first saw the idiom > > > > if form.accepts(): > > ... > > return dict(form=form) > > > > my assumption was that the call to form.accepts() was somehow > > rendering and transmitting the page and waiting for a user response. > > But then, I wondered how that could be since the form isn't passed to > > the view until the return() is executed. Then I tried tracing a > > controller and saw that it was being called multiple times. I got > > lost down in the gluon code and more or less gave up trying to find > > out exactly how the rabbit gets into the hat. Now I just use it and > > trust that it works, but it still bothers me not to know what's going > > on under the hood. > > I've had the same reaction. The key to my understanding form.accepts, fwiw, > was reading accepts itself. Keep in mind that web2py encourages form > self-submission. That implies that the same code (controller/function) > typically needs to run twice: once to create the page+form for display, and > again to handle the form's submission. > > So form.accepts() is telling you whether it's the first time through, form > creation (False) or the second, form submission (True). It's a little more > complicated than that because of validation and error handling, but that's it > in a nutshell. > > >
Re: [web2py] Re: accepts [was: misunderstandings]
On Sep 16, 2010, at 10:51 AM, Michael Ellis wrote: > Thanks Massimo (and Jonathan), > > I think the complexity is not so much of a problem. As you noted, it works > very well. It's just that it does so much that a bit more explanation is > needed so new users can understand how it works. > > I'd be in favor of putting your detailed description (plus a bit of > explanation about how the controller gets called twice) in the Forms and > Validation chapter, somewhere near the sentence that begins "The full > signature of the accepts method is the following:" > > Cheers, > Mike Massimo's note raises another matter that can be confusing. I was describing FORM.accepts(), which I tend to use quite a bit, and is somewhat simpler than SQLFORM.accepts(), which calls it (though it still does all the validation work). The idea is still the same, and the API pretty much as well. > > > On Thu, Sep 16, 2010 at 1:26 PM, mdipierro wrote: > assuming form=SQLFORM(db.table,record_id) > > > form.accepts(request.vars,session,formname='xxx',hideerror=False,dbio=True) > > does the following > 1) if not request.vars._formname=='xxx' then form is not being self > submitted, generate a CSRF-prevention security key and store it in > session, return False > 2) if not request.vars._formkey==CSRF-key-in-session, this is a double > form submission or a a CSRF attack, return False > 3) use the depth first tree traversal algorithm to find all the INPUT, > SELECT and TEXTAREA objects in the form, check if they have a > corresponding entry in request.vars and validate it accordingly. If it > does not pass validation store the error in form.errors[fieldname] and > modify the form by injecting error messages in it (unless > hideerror=True). When validating each INPUT object, all validators are > executed in order, if one passes, it filters request.vars.fieldname > into form.vars.fieldname > 4) for SQFORMS if dbio==True (default) and there are no form.errors it > does a db.table.insert(**form.vars) or > db(db.table.id==record_id).update(**form.vars) depending on whether > this is a create for or an update form (determined by the presence of > the record_id in form definition). If this is a create form, the id > returned by insert is stored in form.vars.id > 5) If here and no errors return True > > This is a nutshell. It is a bit more complicated because it needs to > deal with the odd behavior of select and checkboxes vs text input, > repeated fields names, the presence of Widgets which may override the > field validators and the way errors are to be displayed. > > SQLFORM.accepts calls FORM.accepts (very similar to each other) are > the most complex piece of code in web2py. Not the one I am most happy > with. If I were to re-do it I would redo it differently (in particular > because of how widgets are dealt with) but the API is clean and it > works well. > > Massimo > > On Sep 16, 12:08 pm, Michael Ellis wrote: > > Thanks, Jonathan. That's approximately what I had reasoned it must be > > doing, but couldn't state as clearly as you have. > > > > So, if I'm now understanding it correctly, form.accepts() is roughly > > equivalent to the following conditions: > > > > (request contains submitted form elements) and > > (form key matches) and > > (all elements pass validation) > > > > The 'magic' is simply that clicking the submit button sends a second request > > to the controller that created it. So the form object only *seems* to > > persist; in actuality, it's recreated from scratch when the second request > > comes in. > > > > All of which explains why I was unable to store extra info in the form > > object at view time and have it available after form.accepts() came back > > True. > > > > Is that a fair summary of how it works? > > > > On Thu, Sep 16, 2010 at 11:04 AM, Jonathan Lundell > > wrote: > > > > > On Sep 16, 2010, at 7:26 AM, Michael Ellis wrote: > > > > > > I was never much bothered by either of those issues, but there is one > > > > bit of 'magic' that did (and to some extent still does) confuse me. > > > > I'm wondering if it might be worthwhile to give an detailed > > > > explanation what goes on in form.accepts(). > > > > > > When I first saw the idiom > > > > > > if form.accepts(): > > > > ... > > > > return dict(form=form) > > > > > > my assumption was that the call to form.accepts() was somehow > > > > rendering and transmitting the page
Re: [web2py] Re: Recent changes to rewrite.py break threaded environments
On Sep 16, 2010, at 1:04 PM, mdipierro wrote:
>
> I believe this was fixed. try 1.85.2 posted yesterday
Perhaps, but it might be a case we haven't considered. Jonathan, if 1.85.2 does
not fix the problem, I can suggest two alternatives.
If you are *not* using application-specific routing, call rewrite.select() at
the beginning of your thread. This will initialize the routes attribute to the
global values (or default values if you have no routes.py).
If you *are* using app-specific routing, I think I'll need to enhance
rewrite.select(), which I ought to do anyway.
Please let us know, first, if 1.85.2 fixes the problem.
Massimo, the reason I think it might not fix it is that thread.routes is
initialized for the current thread in main, in the rewrite.select() call. If
the app creates a new thread, it's going to have a new rewrite.thread object,
with no routes attribute.
I think.
>
> On Sep 16, 2:26 pm, "Jonathan Z." wrote:
>> I'm kicking off a threaded process. As part of the "run" method, I'm
>> calling: env("application", import_models=True) in order to work with
>> the web2py environment inside the context of my thread. As a result,
>> models are parsed and the following exception is raised:
>>
>> Traceback (most recent call last):
>> File ".../web2py/gluon/restricted.py", line 188, in restricted
>> exec ccode in environment
>> File "applications/app/models/db.py", line 32, in
>> auth = Auth(globals(), db)
>> File ".../web2py/gluon/tools.py", line 804, in __init__
>> self.settings.login_url = self.url('user', args='login')
>> File ".../web2py/gluon/tools.py", line 762, in url
>> f=f, args=args, vars=vars)
>> File ".../web2py/gluon/html.py", line 228, in _URL
>> return URL(*args, **kwargs)
>> File ".../web2py/gluon/html.py", line 206, in URL
>> return XML(rewrite.filter_out(url, env))
>> File ".../web2py/gluon/rewrite.py", line 183, in filter_out
>> if thread.routes.routes_out:
>> AttributeError: 'thread._local' object has no attribute 'routes'
>>
>> As soon as URLs are parsed during Auth initialization, the thread hits
>> a case where an invalid "routes" attribute is dereferenced within
>> rewrite.py. My threaded code was working until the following change
>> was rolled into 1.84.x: "moved DAL and routes to thread.local"
Re: [web2py] Why the pattern return dict(form=form)?
On Sep 16, 2010, at 6:41 PM, Bruno Rocha wrote:
> In Python the constructor dict() creates a dictionary, so doing
> dict(name='Tom') will create a dictionary and
> is the same as doing
> {'name':'Tom'}
>
The key here, Tom, is that dict() is a function call, and in dict(name="tom"),
we're looking at a named argument (the argument with the name 'name' has the
value 'tom'), not an assignment.
So with return dict(form=form) (not return(form=form), which wouldn't work),
you're returning a Python dictionary (which is what dict() returns) that has a
key named 'form' whose value is form, the object you created in your
controller. The key string happens to be the same as the name of the object,
but that's just a coincidence. Or a convenience.
Re: [web2py] Re: Forms with hidden fields
On Sep 17, 2010, at 6:25 AM, mdipierro wrote:
>
> ERRATA:
>
> I like to define
>
> def HiddenField(*a,**b):
>a['writable']=b['readable']=False
>return Field(*a,**b)
I *think* you mean:
b['writable']=b['readable']=False
>
> and use
>
> db.defiend_table('mytable',Field('name'),HiddenField('manager'))
and db.define_table(...
>
> On Sep 17, 8:22 am, mdipierro wrote:
>> I like to define
>>
>> def HiddenField(*a,**b):
>> a['writable']=b['readable']=False
>>
>> and use
>>
>> db.defiend_table('mytable',Field('name'),HiddenField('manager'))
>>
>> On Sep 17, 6:07 am, "Martin.Mulone" wrote:
>>
>>> To hide a field:
>>> Field('out','boolean',writable=False,readable=False)
>>
>>> And computed fields in
>>> book:http://web2py.com/book/default/chapter/06#Computed-Fields
>>
>>> On 17 sep, 05:58, Fabio Alessandro Locati wrote:
>>
Hi,
I'm trying to make a form with a hidden field, but I haven't found the way
to do it :(.
>>
I have a table:
db.define_table('partners',
Field('name','string'),
Field('out','boolean'))
>>
I want to ask to the user the name of the partner and, based on the name of
the page, the value of 'out'. I was thinking into making two different
pages
one that has - at code level - out=1 and the other one that had out=0. How
can I do this, without showing to the user the existence of the 'out'
field?
>>
Thanks :)
>>
>>
Re: [web2py] Re: Recent changes to rewrite.py break threaded environments
On Sep 16, 2010, at 10:44 PM, mdipierro wrote:
>
> Jonathan,
>
> I misunderstood your problem. You should not spawn threads from a
> web2py app. This is not just because the current routing mechanism
> does not support it. This is a very general with all web applications
> because threads are managed by the web server which starts/stops and
> kills them. If your thread spawns a new thread and the parent is
> killed by the web server you may end up with a memory leak.
>
> Please explain what you are trying to achieve, perhaps show us some
> code, and I am sure there is another way.
Here's a quick patch to rewrite.filter_out that should fix the problem for
URL() as long as app-specific routes are not in use:
def filter_out(url, e=None):
"called from html.URL to rewrite outgoing URL"
+if not hasattr(thread, 'routes'):
+select()# ensure thread.routes is set (for application threads)
if thread.routes.routes_out:
items = url.split('?', 1)
if e:
Massimo, this will be a little confusing, since there are two Jonathans on this
(message) thread, and both of us are using application threads.
Here's my case:
The application is a manager for a collection of servers, from tens to possibly
hundreds. On the central management page, I create a table that summarizes the
status of the servers. I get the status by sending an xmlrpc query to each
server, and the response can take several seconds (say 2-10).
Because serializing these requests can take too long, I create a thread per
server to make the query and wait for the response. CPU time for such a request
is nil, so all the threads complete in approximately the time for the slowest
one.
The code is very simple and very clean.
No doubt I could accomplish something like it with Ajax, and effectively a
request thread for each server. But I hesitate to rely on the web server's
thread pool, assuming it has one big enough, and an Ajax solution wouldn't be
so straightforward, I don't think.
>
> Massimo
>
> On Sep 16, 2:26 pm, "Jonathan Z." wrote:
>> I'm kicking off a threaded process. As part of the "run" method, I'm
>> calling: env("application", import_models=True) in order to work with
>> the web2py environment inside the context of my thread. As a result,
>> models are parsed and the following exception is raised:
>>
>> Traceback (most recent call last):
>> File ".../web2py/gluon/restricted.py", line 188, in restricted
>> exec ccode in environment
>> File "applications/app/models/db.py", line 32, in
>> auth = Auth(globals(), db)
>> File ".../web2py/gluon/tools.py", line 804, in __init__
>> self.settings.login_url = self.url('user', args='login')
>> File ".../web2py/gluon/tools.py", line 762, in url
>> f=f, args=args, vars=vars)
>> File ".../web2py/gluon/html.py", line 228, in _URL
>> return URL(*args, **kwargs)
>> File ".../web2py/gluon/html.py", line 206, in URL
>> return XML(rewrite.filter_out(url, env))
>> File ".../web2py/gluon/rewrite.py", line 183, in filter_out
>> if thread.routes.routes_out:
>> AttributeError: 'thread._local' object has no attribute 'routes'
>>
>> As soon as URLs are parsed during Auth initialization, the thread hits
>> a case where an invalid "routes" attribute is dereferenced within
>> rewrite.py. My threaded code was working until the following change
>> was rolled into 1.84.x: "moved DAL and routes to thread.local"
Re: [web2py] Re: Recent changes to rewrite.py break threaded environments
On Sep 17, 2010, at 8:24 AM, mdipierro wrote:
>
> I will take the patch and you may be fine if your thread does not
> access db.
Here's a slightly more complete patch. This should maintain backward
compatibility with apps that don't use app-specific routing. One that does can
call rewrite.select(app='name') at the start of a new thread.
This won't help when globals are based on threading.local, though; that's a
nastier problem.
diff -r 3645edf51f22 gluon/rewrite.py
--- a/gluon/rewrite.py Fri Sep 17 08:40:21 2010 -0500
+++ b/gluon/rewrite.py Fri Sep 17 08:50:17 2010 -0700
@@ -150,14 +150,15 @@
logger.debug('%s: [%s] -> %s (not rewritten)' % (tag, key, default))
return (default, query, original_uri)
-def select(e=None):
+def select(env=None, app=None):
"""
select a set of rewrite params for the current request
called from main.wsgibase before any URL rewriting
"""
-app = None
-if e and params.routes_app:
-(app, q, u) = filter_uri(e, params.routes_app, "routes_app")
+if app:
+thread.routes = params_apps.get(app, params)
+elif env and params.routes_app:
+(app, q, u) = filter_uri(env, params.routes_app, "routes_app")
thread.routes = params_apps.get(app, params)
else:
thread.routes = params # default to base rewrite parameters
@@ -180,6 +181,8 @@
def filter_out(url, e=None):
"called from html.URL to rewrite outgoing URL"
+if not hasattr(thread, 'routes'):
+select()# ensure thread.routes is set (for application threads)
if thread.routes.routes_out:
items = url.split('?', 1)
if e:
>
> On Sep 17, 10:20 am, Jonathan Lundell wrote:
>> On Sep 16, 2010, at 10:44 PM, mdipierro wrote:
>>
>>
>>
>>> Jonathan,
>>
>>> I misunderstood your problem. You should not spawn threads from a
>>> web2py app. This is not just because the current routing mechanism
>>> does not support it. This is a very general with all web applications
>>> because threads are managed by the web server which starts/stops and
>>> kills them. If your thread spawns a new thread and the parent is
>>> killed by the web server you may end up with a memory leak.
>>
>>> Please explain what you are trying to achieve, perhaps show us some
>>> code, and I am sure there is another way.
>>
>> Here's a quick patch to rewrite.filter_out that should fix the problem for
>> URL() as long as app-specific routes are not in use:
>>
>> def filter_out(url, e=None):
>> "called from html.URL to rewrite outgoing URL"
>> +if not hasattr(thread, 'routes'):
>> +select()# ensure thread.routes is set (for application threads)
>> if thread.routes.routes_out:
>> items = url.split('?', 1)
>> if e:
>>
>> Massimo, this will be a little confusing, since there are two Jonathans on
>> this (message) thread, and both of us are using application threads.
>>
>> Here's my case:
>>
>> The application is a manager for a collection of servers, from tens to
>> possibly hundreds. On the central management page, I create a table that
>> summarizes the status of the servers. I get the status by sending an xmlrpc
>> query to each server, and the response can take several seconds (say 2-10).
>>
>> Because serializing these requests can take too long, I create a thread per
>> server to make the query and wait for the response. CPU time for such a
>> request is nil, so all the threads complete in approximately the time for
>> the slowest one.
>>
>> The code is very simple and very clean.
>>
>> No doubt I could accomplish something like it with Ajax, and effectively a
>> request thread for each server. But I hesitate to rely on the web server's
>> thread pool, assuming it has one big enough, and an Ajax solution wouldn't
>> be so straightforward, I don't think.
>>
>>
>>
>>> Massimo
>>
>>> On Sep 16, 2:26 pm, "Jonathan Z." wrote:
>>>> I'm kicking off a threaded process. As part of the "run" method, I'm
>>>> calling: env("application", import_models=True) in order to work with
>>>> the web2py environment inside the context of my thread. As a result,
>>>> models are parsed and the following exception is raised:
>>
>>>> Traceback (most recent call last):
>>>> File ".../web2py/gluon/restricted.py", lin
Re: [web2py] URL error in appadmin
On Sep 17, 2010, at 4:06 PM, Avik Basu wrote:
>
> Hi,
>
> I get the following error in appadmin.py which I copied over from the
> welcome app in version 1.85.2:
Are you running 1.85.2? It sounds like you might be running something earlier.
>
> Traceback (most recent call last):
> File "/Volumes/Data/avikbasu/web2py/gluon/restricted.py", line 188,
> in restricted
>exec ccode in environment
> File "/Volumes/Data/avikbasu/web2py/applications/FWv9_1_Avik/
> controllers/appadmin.py", line 40, in
>URL('index')], [T('state'), False,
> File "/Volumes/Data/avikbasu/web2py/gluon/html.py", line 188, in URL
>raise SyntaxError, 'not enough information to build the url'
> SyntaxError: not enough information to build the url
>
> Any ideas?
>
> Thanks,
> Avik
Re: [web2py] Re: URL error in appadmin
On Sep 17, 2010, at 4:44 PM, Avik Basu wrote:
>
> Yes, I'm sure I'm running 1.85.2. i copied over appadmin.py and the
> associated views to my applications. What is strange though is that I
> can run the welcome app without any problem (http://127.0.0.1:8000/
> welcome/appadmin/index), but not the version I copied into my
> application (http://127.0.0.1:8000/FWv9_1_Avik/appadmin/index). Is
> there some other file I need to copy?
I'm not seeing anything.
Is it possible that you're altering request in your model(s)?
>
> Avik
>
> On Sep 17, 7:24 pm, Jonathan Lundell wrote:
>> On Sep 17, 2010, at 4:06 PM, Avik Basu wrote:
>>
>>
>>
>>> Hi,
>>
>>> I get the following error in appadmin.py which I copied over from the
>>> welcome app in version 1.85.2:
>>
>> Are you running 1.85.2? It sounds like you might be running something
>> earlier.
>>
>>
>>
>>
>>
>>> Traceback (most recent call last):
>>> File "/Volumes/Data/avikbasu/web2py/gluon/restricted.py", line 188,
>>> in restricted
>>>exec ccode in environment
>>> File "/Volumes/Data/avikbasu/web2py/applications/FWv9_1_Avik/
>>> controllers/appadmin.py", line 40, in
>>>URL('index')], [T('state'), False,
>>> File "/Volumes/Data/avikbasu/web2py/gluon/html.py", line 188, in URL
>>>raise SyntaxError, 'not enough information to build the url'
>>> SyntaxError: not enough information to build the url
>>
>>> Any ideas?
>>
>>> Thanks,
>>> Avik
Re: [web2py] Re: URL error in appadmin
On Sep 17, 2010, at 11:50 PM, Avik Basu wrote:
>
> There is nowhere I can see that I am altering request in the models.
> What is the specific reason that request would break the URL
> function? Any other ideas what the problem could be?
The URL function requires, at a minimum, app, controller and function names. In
a call like the one that's blowing out, that supplies only a function name, the
app & controller names come from request, which URL knows about magically.
I'm at a loss here; I was hoping Massimo might have an idea.
If you're willing, I can give you a debug print or two to stick in there, and
at least we can see what's missing, exactly.
>
> Avik
>
> On Sep 17, 7:57 pm, Jonathan Lundell wrote:
>> On Sep 17, 2010, at 4:44 PM, Avik Basu wrote:
>>
>>
>>
>>> Yes, I'm sure I'm running 1.85.2. i copied over appadmin.py and the
>>> associated views to my applications. What is strange though is that I
>>> can run the welcome app without any problem (http://127.0.0.1:8000/
>>> welcome/appadmin/index), but not the version I copied into my
>>> application (http://127.0.0.1:8000/FWv9_1_Avik/appadmin/index). Is
>>> there some other file I need to copy?
>>
>> I'm not seeing anything.
>>
>> Is it possible that you're altering request in your model(s)?
>>
>>
>>
>>
>>
>>> Avik
>>
>>> On Sep 17, 7:24 pm, Jonathan Lundell wrote:
>>>> On Sep 17, 2010, at 4:06 PM, Avik Basu wrote:
>>
>>>>> Hi,
>>
>>>>> I get the following error in appadmin.py which I copied over from the
>>>>> welcome app in version 1.85.2:
>>
>>>> Are you running 1.85.2? It sounds like you might be running something
>>>> earlier.
>>
>>>>> Traceback (most recent call last):
>>>>> File "/Volumes/Data/avikbasu/web2py/gluon/restricted.py", line 188,
>>>>> in restricted
>>>>>exec ccode in environment
>>>>> File "/Volumes/Data/avikbasu/web2py/applications/FWv9_1_Avik/
>>>>> controllers/appadmin.py", line 40, in
>>>>>URL('index')], [T('state'), False,
>>>>> File "/Volumes/Data/avikbasu/web2py/gluon/html.py", line 188, in URL
>>>>>raise SyntaxError, 'not enough information to build the url'
>>>>> SyntaxError: not enough information to build the url
>>
>>>>> Any ideas?
>>
>>>>> Thanks,
>>>>> Avik
Re: [web2py] Re: URL error in appadmin
On Sep 18, 2010, at 9:46 AM, Avik Basu wrote:
>
> Sure, I'm happy to help debug. Send me the print statements when you
> get a chance.
Here's a starting point. In gluon/html.py, you'll find this:
if not (application and controller and function):
raise SyntaxError, 'not enough information to build the url'
...which is where the message below is coming from. We want to see a little
more of the state of the world here. So I'm thinking something like:
if not (application and controller and function):
if r:
msg = 'URL: a=%s c=%s f=%s r.a=%s r.c=%s r.f=%s' %
(application,controller,function,r.application,r.controller,r.function)
else:
msg = 'URL: a=%s c=%s f=%s r=%s' %
(application,controller,function,r)
raise SyntaxError, msg
> Avik
>
> On Sep 18, 12:39 pm, Jonathan Lundell wrote:
>> On Sep 17, 2010, at 11:50 PM, Avik Basu wrote:
>>
>>
>>
>>> There is nowhere I can see that I am altering request in the models.
>>> What is the specific reason that request would break the URL
>>> function? Any other ideas what the problem could be?
>>
>> The URL function requires, at a minimum, app, controller and function names.
>> In a call like the one that's blowing out, that supplies only a function
>> name, the app & controller names come from request, which URL knows about
>> magically.
>>
>> I'm at a loss here; I was hoping Massimo might have an idea.
>>
>> If you're willing, I can give you a debug print or two to stick in there,
>> and at least we can see what's missing, exactly.
>>
>>
>>
>>
>>
>>> Avik
>>
>>> On Sep 17, 7:57 pm, Jonathan Lundell wrote:
>>>> On Sep 17, 2010, at 4:44 PM, Avik Basu wrote:
>>
>>>>> Yes, I'm sure I'm running 1.85.2. i copied over appadmin.py and the
>>>>> associated views to my applications. What is strange though is that I
>>>>> can run the welcome app without any problem (http://127.0.0.1:8000/
>>>>> welcome/appadmin/index), but not the version I copied into my
>>>>> application (http://127.0.0.1:8000/FWv9_1_Avik/appadmin/index). Is
>>>>> there some other file I need to copy?
>>
>>>> I'm not seeing anything.
>>
>>>> Is it possible that you're altering request in your model(s)?
>>
>>>>> Avik
>>
>>>>> On Sep 17, 7:24 pm, Jonathan Lundell wrote:
>>>>>> On Sep 17, 2010, at 4:06 PM, Avik Basu wrote:
>>
>>>>>>> Hi,
>>
>>>>>>> I get the following error in appadmin.py which I copied over from the
>>>>>>> welcome app in version 1.85.2:
>>
>>>>>> Are you running 1.85.2? It sounds like you might be running something
>>>>>> earlier.
>>
>>>>>>> Traceback (most recent call last):
>>>>>>> File "/Volumes/Data/avikbasu/web2py/gluon/restricted.py", line 188,
>>>>>>> in restricted
>>>>>>>exec ccode in environment
>>>>>>> File "/Volumes/Data/avikbasu/web2py/applications/FWv9_1_Avik/
>>>>>>> controllers/appadmin.py", line 40, in
>>>>>>>URL('index')], [T('state'), False,
>>>>>>> File "/Volumes/Data/avikbasu/web2py/gluon/html.py", line 188, in URL
>>>>>>>raise SyntaxError, 'not enough information to build the url'
>>>>>>> SyntaxError: not enough information to build the url
>>
>>>>>>> Any ideas?
>>
>>>>>>> Thanks,
>>>>>>> Avik
Re: [web2py] Re: URL error in appadmin
On Sep 18, 2010, at 9:46 AM, Avik Basu wrote: > > Sure, I'm happy to help debug. Send me the print statements when you > get a chance. FWIW, I just did the same thing (move the current appadmin into my own app) and it seems to work OK; at least I can access appadmin/index OK.
Re: [web2py] Re: URL error in appadmin
On Sep 18, 2010, at 11:40 AM, Avik Basu wrote:
>
> When I replace the code in gluon/html.py, I still keep getting the
> same SyntaxError ('not enough information to build the url') which
> seems strange since that is not even in the code anymore.
>
> I am sort of new to debugging the gluon code so I maybe making some
> simple mistake. I did delete the html.pyc file. Do I need to restart
> the server?
I would assume so, given the message, and especially if you're not seeing
html.pyc getting recreated.
>
> On Sep 18, 2:31 pm, Jonathan Lundell wrote:
>> On Sep 18, 2010, at 9:46 AM, Avik Basu wrote:
>>
>>
>>
>>> Sure, I'm happy to help debug. Send me the print statements when you
>>> get a chance.
>>
>> FWIW, I just did the same thing (move the current appadmin into my own app)
>> and it seems to work OK; at least I can access appadmin/index OK.
Re: [web2py] Re: URL error in appadmin
On Sep 18, 2010, at 11:52 AM, Avik Basu wrote:
>
> After restarting the server, I get the following error:
>
> SyntaxError: URL: a=index c=None f=None r=None
I was afraid of that, and I can't explain it.
Please check that line 219 of gluon/compileapp.py is:
environment['URL'] = html._gURL(request)
And you might want to quit your server, delete all the .pyc files in gluon, and
restart.
Do you do anything tricky with globals() or the URL symbol in your models?
And let's try one more printing attempt:
if not (application and controller and function):
if r:
msg = 'URL: a=%s c=%s f=%s r.a=%s r.c=%s r.f=%s' %
(application,controller,function,r.application,r.controller,r.function)
else:
msg = 'URL: a=%s c=%s f=%s r=%s u=%s' %
(application,controller,function,r,URL.__name__)
raise SyntaxError, msg
>
> On Sep 18, 2:46 pm, Jonathan Lundell wrote:
>> On Sep 18, 2010, at 11:40 AM, Avik Basu wrote:
>>
>>
>>
>>> When I replace the code in gluon/html.py, I still keep getting the
>>> same SyntaxError ('not enough information to build the url') which
>>> seems strange since that is not even in the code anymore.
>>
>>> I am sort of new to debugging the gluon code so I maybe making some
>>> simple mistake. I did delete the html.pyc file. Do I need to restart
>>> the server?
>>
>> I would assume so, given the message, and especially if you're not seeing
>> html.pyc getting recreated.
>>
>>
>>
>>
>>
>>> On Sep 18, 2:31 pm, Jonathan Lundell wrote:
>>>> On Sep 18, 2010, at 9:46 AM, Avik Basu wrote:
>>
>>>>> Sure, I'm happy to help debug. Send me the print statements when you
>>>>> get a chance.
>>
>>>> FWIW, I just did the same thing (move the current appadmin into my own
>>>> app) and it seems to work OK; at least I can access appadmin/index OK.
Re: [web2py] Re: URL error in appadmin
On Sep 18, 2010, at 12:52 PM, Avik Basu wrote:
>
> Line 219 of gluon/compileapp.py is as you described it. I also deleted
> the whole gluon directory and downloaded the latest source of web2py
> before restarting the server. Also, as far as I can tell, I am not
> doing anything tricky with Globals or the URL symbol in my models.
>
> I now get the following syntax error:
>
> SyntaxError: URL: a=index c=None f=None r=None u=URL
Thanks.
I realized after I sent that last request that the __name__ of URL might not be
significant at this point, because we're inside the URL() function.
This might be worth a try. In appadmin.py, near the beginning (after the
imports, but before response.menu is set):
logger = logging.getLogger('web2py')
logger.warning('appadmin url.name=%s' % URL.__name__)
What you *should* see is _URL. That's what I see if I stick it in my own
appadmin.
>
>
>
>
> On Sep 18, 3:33 pm, Jonathan Lundell wrote:
>> On Sep 18, 2010, at 11:52 AM, Avik Basu wrote:
>>
>>
>>
>>> After restarting the server, I get the following error:
>>
>>> SyntaxError: URL: a=index c=None f=None r=None
>>
>> I was afraid of that, and I can't explain it.
>>
>> Please check that line 219 of gluon/compileapp.py is:
>>
>> environment['URL'] = html._gURL(request)
>>
>> And you might want to quit your server, delete all the .pyc files in gluon,
>> and restart.
>>
>> Do you do anything tricky with globals() or the URL symbol in your models?
>>
>> And let's try one more printing attempt:
>>
>>if not (application and controller and function):
>>if r:
>>msg = 'URL: a=%s c=%s f=%s r.a=%s r.c=%s r.f=%s' %
>> (application,controller,function,r.application,r.controller,r.function)
>>else:
>>msg = 'URL: a=%s c=%s f=%s r=%s u=%s' %
>> (application,controller,function,r,URL.__name__)
>>raise SyntaxError, msg
>>
>>
>>
>>
>>
>>> On Sep 18, 2:46 pm, Jonathan Lundell wrote:
>>>> On Sep 18, 2010, at 11:40 AM, Avik Basu wrote:
>>
>>>>> When I replace the code in gluon/html.py, I still keep getting the
>>>>> same SyntaxError ('not enough information to build the url') which
>>>>> seems strange since that is not even in the code anymore.
>>
>>>>> I am sort of new to debugging the gluon code so I maybe making some
>>>>> simple mistake. I did delete the html.pyc file. Do I need to restart
>>>>> the server?
>>
>>>> I would assume so, given the message, and especially if you're not seeing
>>>> html.pyc getting recreated.
>>
>>>>> On Sep 18, 2:31 pm, Jonathan Lundell wrote:
>>>>>> On Sep 18, 2010, at 9:46 AM, Avik Basu wrote:
>>
>>>>>>> Sure, I'm happy to help debug. Send me the print statements when you
>>>>>>> get a chance.
>>
>>>>>> FWIW, I just did the same thing (move the current appadmin into my own
>>>>>> app) and it seems to work OK; at least I can access appadmin/index OK.
Re: [web2py] Re: URL error in appadmin
On Sep 18, 2010, at 1:12 PM, Avik Basu wrote:
>
> do i need to import logging?
Yes. But sticking it in your view is fine, I think.
>
> On Sep 18, 4:10 pm, Jonathan Lundell wrote:
>> On Sep 18, 2010, at 12:52 PM, Avik Basu wrote:
>>
>>
>>
>>> Line 219 of gluon/compileapp.py is as you described it. I also deleted
>>> the whole gluon directory and downloaded the latest source of web2py
>>> before restarting the server. Also, as far as I can tell, I am not
>>> doing anything tricky with Globals or the URL symbol in my models.
>>
>>> I now get the following syntax error:
>>
>>> SyntaxError: URL: a=index c=None f=None r=None u=URL
>>
>> Thanks.
>>
>> I realized after I sent that last request that the __name__ of URL might not
>> be significant at this point, because we're inside the URL() function.
>>
>> This might be worth a try. In appadmin.py, near the beginning (after the
>> imports, but before response.menu is set):
>>
>> logger = logging.getLogger('web2py')
>> logger.warning('appadmin url.name=%s' % URL.__name__)
>>
>> What you *should* see is _URL. That's what I see if I stick it in my own
>> appadmin.
>>
>>
>>
>>
>>
>>> On Sep 18, 3:33 pm, Jonathan Lundell wrote:
>>>> On Sep 18, 2010, at 11:52 AM, Avik Basu wrote:
>>
>>>>> After restarting the server, I get the following error:
>>
>>>>> SyntaxError: URL: a=index c=None f=None r=None
>>
>>>> I was afraid of that, and I can't explain it.
>>
>>>> Please check that line 219 of gluon/compileapp.py is:
>>
>>>> environment['URL'] = html._gURL(request)
>>
>>>> And you might want to quit your server, delete all the .pyc files in
>>>> gluon, and restart.
>>
>>>> Do you do anything tricky with globals() or the URL symbol in your models?
>>
>>>> And let's try one more printing attempt:
>>
>>>>if not (application and controller and function):
>>>>if r:
>>>>msg = 'URL: a=%s c=%s f=%s r.a=%s r.c=%s r.f=%s' %
>>>> (application,controller,function,r.application,r.controller,r.function)
>>>>else:
>>>>msg = 'URL: a=%s c=%s f=%s r=%s u=%s' %
>>>> (application,controller,function,r,URL.__name__)
>>>>raise SyntaxError, msg
>>
>>>>> On Sep 18, 2:46 pm, Jonathan Lundell wrote:
>>>>>> On Sep 18, 2010, at 11:40 AM, Avik Basu wrote:
>>
>>>>>>> When I replace the code in gluon/html.py, I still keep getting the
>>>>>>> same SyntaxError ('not enough information to build the url') which
>>>>>>> seems strange since that is not even in the code anymore.
>>
>>>>>>> I am sort of new to debugging the gluon code so I maybe making some
>>>>>>> simple mistake. I did delete the html.pyc file. Do I need to restart
>>>>>>> the server?
>>
>>>>>> I would assume so, given the message, and especially if you're not
>>>>>> seeing html.pyc getting recreated.
>>
>>>>>>> On Sep 18, 2:31 pm, Jonathan Lundell wrote:
>>>>>>>> On Sep 18, 2010, at 9:46 AM, Avik Basu wrote:
>>
>>>>>>>>> Sure, I'm happy to help debug. Send me the print statements when you
>>>>>>>>> get a chance.
>>
>>>>>>>> FWIW, I just did the same thing (move the current appadmin into my own
>>>>>>>> app) and it seems to work OK; at least I can access appadmin/index OK.
Re: [web2py] Re: URL error in appadmin
Massimo, any ideas?
On Sep 18, 2010, at 1:24 PM, Avik Basu wrote:
>
> I put this:
> {{=URL.__name__}}
>
> in the view of my index page and it showed
> URL
>
> (not _URL as you said)
>
>
> Also, I don't know if its helpful to mention that the latest format
> for the URL function is not working anywhere in my app, not just in
> appadmin. So, if I put:
>
> {{=URL('index')}}
>
> in my index page, I get the same syntax error that I had in appadmin.
That's good to know.
You could try this (you'll need to import gluon.html):
{{=gluon.html._gURL(request).__name__}}
That's what the global URL should be.
I think you were saying that this works OK in the other apps, right? You could
stick similar logic into welcome, for comparison purposes, good vs bad. You
might have to delete the welcome/compiled directory.
By way of background, the URL logic was updated not all that long ago. Have a
look at html._gURL, and then compileapp.build_environment() to see how it's
being used. URL is being replaced by the closure (I think it's a closure)
_gURL(request), so the value of request gets bound to the URL call, without
having to supply it all the time.
Also, a single argument to the original URL is treated as the application,
whereas the closure treats it as the function. We see the former in the syntax
error print below, more evidence that we're not invoking the closure.
>
> On Sep 18, 4:10 pm, Jonathan Lundell wrote:
>> On Sep 18, 2010, at 12:52 PM, Avik Basu wrote:
>>
>>
>>
>>> Line 219 of gluon/compileapp.py is as you described it. I also deleted
>>> the whole gluon directory and downloaded the latest source of web2py
>>> before restarting the server. Also, as far as I can tell, I am not
>>> doing anything tricky with Globals or the URL symbol in my models.
>>
>>> I now get the following syntax error:
>>
>>> SyntaxError: URL: a=index c=None f=None r=None u=URL
>>
>> Thanks.
>>
>> I realized after I sent that last request that the __name__ of URL might not
>> be significant at this point, because we're inside the URL() function.
>>
>> This might be worth a try. In appadmin.py, near the beginning (after the
>> imports, but before response.menu is set):
>>
>> logger = logging.getLogger('web2py')
>> logger.warning('appadmin url.name=%s' % URL.__name__)
>>
>> What you *should* see is _URL. That's what I see if I stick it in my own
>> appadmin.
>>
>>
>>
>>
>>
>>> On Sep 18, 3:33 pm, Jonathan Lundell wrote:
>>>> On Sep 18, 2010, at 11:52 AM, Avik Basu wrote:
>>
>>>>> After restarting the server, I get the following error:
>>
>>>>> SyntaxError: URL: a=index c=None f=None r=None
>>
>>>> I was afraid of that, and I can't explain it.
>>
>>>> Please check that line 219 of gluon/compileapp.py is:
>>
>>>> environment['URL'] = html._gURL(request)
>>
>>>> And you might want to quit your server, delete all the .pyc files in
>>>> gluon, and restart.
>>
>>>> Do you do anything tricky with globals() or the URL symbol in your models?
>>
>>>> And let's try one more printing attempt:
>>
>>>>if not (application and controller and function):
>>>>if r:
>>>>msg = 'URL: a=%s c=%s f=%s r.a=%s r.c=%s r.f=%s' %
>>>> (application,controller,function,r.application,r.controller,r.function)
>>>>else:
>>>>msg = 'URL: a=%s c=%s f=%s r=%s u=%s' %
>>>> (application,controller,function,r,URL.__name__)
>>>>raise SyntaxError, msg
>>
>>>>> On Sep 18, 2:46 pm, Jonathan Lundell wrote:
>>>>>> On Sep 18, 2010, at 11:40 AM, Avik Basu wrote:
>>
>>>>>>> When I replace the code in gluon/html.py, I still keep getting the
>>>>>>> same SyntaxError ('not enough information to build the url') which
>>>>>>> seems strange since that is not even in the code anymore.
>>
>>>>>>> I am sort of new to debugging the gluon code so I maybe making some
>>>>>>> simple mistake. I did delete the html.pyc file. Do I need to restart
>>>>>>> the server?
>>
>>>>>> I would assume so, given the message, and especially if you're not
>>>>>> seeing html.pyc getting recreated.
>>
>>>>>>> On Sep 18, 2:31 pm, Jonathan Lundell wrote:
>>>>>>>> On Sep 18, 2010, at 9:46 AM, Avik Basu wrote:
>>
>>>>>>>>> Sure, I'm happy to help debug. Send me the print statements when you
>>>>>>>>> get a chance.
>>
>>>>>>>> FWIW, I just did the same thing (move the current appadmin into my own
>>>>>>>> app) and it seems to work OK; at least I can access appadmin/index OK.
Re: [web2py] Re: failed import of a module
On Sep 18, 2010, at 2:46 PM, mdipierro wrote: > > Not all modules can go in the modules folder. Some of them exepect to > be in sys.path There's a variety of sys.path editing in web2py, but I think it's not entirely consistent.
Re: [web2py] Re: URL error in appadmin
On Sep 18, 2010, at 3:46 PM, Avik Basu wrote:
>
> I tried the following command in both my app (where URL) and the
> welcome app (where URL does not fail):
>
> {{=gluon.html._gURL(request).__name__}}
>
> and the result for both apps was:
>
> _URL
>
> Does that provide any clues?
It verifies that both apps are really running with the right code. But for some
reason, it seems to be messed up at the time that you run any controller in
your app. That's a puzzle to me.
I appreciate your patience...
So, here's something we can try. In your first (alphabetically) model, create a
dict:
urldebug = dict()
urldebug['model1name'] = URL.__name__
The idea will be to trace URL.__name__ as we progress through a request. So at
the beginning of each model file:
urldebug['model2name'] = URL.__name__
...and one more at the end of your last model.
Then one more in one of your failing controllers (that is, failing if you try
to call URL with one argument; not actually failing, because we want to get to
the view).
Then pass urldebug to your view, and dump it there. {{=BEAUTIFY(urldebug)}}
will do the trick.
Hopefully we'll see the name change from _URL to URL at some point in the
sequence, and then we can go lion hunting.
>
> On Sep 18, 5:03 pm, Jonathan Lundell wrote:
>> Massimo, any ideas?
>>
>> On Sep 18, 2010, at 1:24 PM, Avik Basu wrote:
>>
>>
>>
>>
>>
>>
>>
>>> I put this:
>>> {{=URL.__name__}}
>>
>>> in the view of my index page and it showed
>>> URL
>>
>>> (not _URL as you said)
>>
>>> Also, I don't know if its helpful to mention that the latest format
>>> for the URL function is not working anywhere in my app, not just in
>>> appadmin. So, if I put:
>>
>>> {{=URL('index')}}
>>
>>> in my index page, I get the same syntax error that I had in appadmin.
>>
>> That's good to know.
>>
>> You could try this (you'll need to import gluon.html):
>>
>> {{=gluon.html._gURL(request).__name__}}
>>
>> That's what the global URL should be.
>>
>> I think you were saying that this works OK in the other apps, right? You
>> could stick similar logic into welcome, for comparison purposes, good vs
>> bad. You might have to delete the welcome/compiled directory.
>>
>> By way of background, the URL logic was updated not all that long ago. Have
>> a look at html._gURL, and then compileapp.build_environment() to see how
>> it's being used. URL is being replaced by the closure (I think it's a
>> closure) _gURL(request), so the value of request gets bound to the URL call,
>> without having to supply it all the time.
>>
>> Also, a single argument to the original URL is treated as the application,
>> whereas the closure treats it as the function. We see the former in the
>> syntax error print below, more evidence that we're not invoking the closure.
>>
>>
>>
>>
>>
>>> On Sep 18, 4:10 pm, Jonathan Lundell wrote:
>>>> On Sep 18, 2010, at 12:52 PM, Avik Basu wrote:
>>
>>>>> Line 219 of gluon/compileapp.py is as you described it. I also deleted
>>>>> the whole gluon directory and downloaded the latest source of web2py
>>>>> before restarting the server. Also, as far as I can tell, I am not
>>>>> doing anything tricky with Globals or the URL symbol in my models.
>>
>>>>> I now get the following syntax error:
>>
>>>>> SyntaxError: URL: a=index c=None f=None r=None u=URL
>>
>>>> Thanks.
>>
>>>> I realized after I sent that last request that the __name__ of URL might
>>>> not be significant at this point, because we're inside the URL() function.
>>
>>>> This might be worth a try. In appadmin.py, near the beginning (after the
>>>> imports, but before response.menu is set):
>>
>>>> logger = logging.getLogger('web2py')
>>>> logger.warning('appadmin url.name=%s' % URL.__name__)
>>
>>>> What you *should* see is _URL. That's what I see if I stick it in my own
>>>> appadmin.
>>
>>>>> On Sep 18, 3:33 pm, Jonathan Lundell wrote:
>>>>>> On Sep 18, 2010, at 11:52 AM, Avik Basu wrote:
>>
>>>>>>> After restarting the server, I get the following error:
>>
>>>>>>> SyntaxError: URL: a=index c=None f=None r=None
>>
>>>>>> I was
Re: [web2py] Re: URL error in appadmin
I should also mention that if I were able to reproduce the problem here, I'd look at it with a debugger, watching URL in the global namespace of a request. So if that's a possibility
Re: [web2py] Re: URL error in appadmin
On Sep 18, 2010, at 4:58 PM, Avik Basu wrote: > > I tried your suggestion and tracked the error to the following line > which was in my db.py: > > from gluon.sqlhtml import * Ah, that's good to put to rest. sqlhtml does from html import * I guess they must all end up in the namespace. It doesn't hurt sqlhtml, because the only place it calls URL it explicitly includes request: self.url = URL(r=request,args=request.args) There are other reasons to avoid import *, so the fix is to be more selective. I'll look at getting rid of import * in sqlhtml, too. > > I guess this import overrided the URL function. When I took it out, > everything works. Thanks so much for your patience and helping me get > through this issue so methodically! The web2py community is quite > exceptional. > > Avik > > > > On Sep 18, 7:07 pm, Jonathan Lundell wrote: >> I should also mention that if I were able to reproduce the problem here, I'd >> look at it with a debugger, watching URL in the global namespace of a >> request. So if that's a possibility
Re: [web2py] Re: Deploying web2py on linux (Redhat or others) on cpanel or other ways
On Sep 20, 2010, at 6:25 AM, mdipierro wrote:
>
> somehow the web server is not settings the environment variable
> REMOTE_ADDR that should contain the address of the remote client.
Is this possibly normal for fcgi?
We could change e['REMOTE_ADDR'] to e.get('REMOTE_ADDR', 'localhost'), like we
do for HTTP_HOST; most routes formulas don't care about it.
>
> On Sep 20, 7:49 am, Rahul wrote:
>> Any Guesses? Still waiting for an answer..
>> Also routes.py is mystic for deployment - I have created a new one
>> from scratch containing only the below two lines - as mentioned in
>> slice #68
>> FYI on cpanel I have the below directory structure -
>> $HOME//public_html//web2py
>>
>> also www is a directory that is exposed at "$HOME//www" - It
>> creates an exact copy of all the contents in public_html directory
>>
>> -routes.py
>>
>> routes_in=(('/web2py/(?P.*)','/\g'),)
>> ...
>> routes_out=(('/(?P.*)','/web2py/\g'),)
>> -
>>
>> when running ./dispatch.fcgi I get this error now
>>
>> ==ERROR===
>> The above is a description of an error in a Python program, formatted
>> for a Web browser because the 'cgitb' module was enabled. In
>> case you
>> are not reading this in a Web browser, here is the original
>> traceback:
>>
>> Traceback (most recent call last):
>> File "/home/flockbir/public_html/flockbird.com/web2py/gluon/contrib/
>> gateways/fcgi.py", line 580, in run
>> protocolStatus, appStatus = self.server.handler(self)
>> File "/home/flockbir/public_html/flockbird.com/web2py/gluon/contrib/
>> gateways/fcgi.py", line 1266, in handler
>> result = self.application(environ, start_response)
>> File "/home/flockbir/public_html/flockbird.com/web2py/gluon/
>> main.py", line 304, in wsgibase
>> environ = rewrite.filter_in(environ)
>> File "/home/flockbir/public_html/flockbird.com/web2py/gluon/
>> rewrite.py", line 171, in filter_in
>> (path, query, original_uri) = filter_uri(e,
>> thread.routes.routes_in, "routes_in", e['PATH_INFO'])
>> File "/home/flockbir/public_html/flockbird.com/web2py/gluon/
>> rewrite.py", line 142, in filter_uri
>> (e['REMOTE_ADDR'],
>> KeyError: 'REMOTE_ADDR' -->
>> ENDS HERE
>>
>> What could be wrong ? Any suggestions are welcome
>>
>> Rahul
Re: [web2py] upgrade from 1.84.1 to 1.85.3 fails due to the following error ..
On Sep 20, 2010, at 8:07 AM, dustin.b wrote:
>
> hi i simply upgraded from 1.84.1 to 1.85.1 and get a ticket. i
> narrowed down the issue to this:
This logic is wrong on its face:
if 'username' in table_user.fields:
if self.settings.login_userfield:
userfield = self.settings.login_userfield
elif 'username' in table_user.fields:
userfield = 'username'
else:
userfield = 'email'
A temporary workaround would be to set login_userfield
>
> db.py
>
>
> auth.settings.hmac_key = 'sha512:97655ab8-04d0-4321-
> b8fa-84f525fb8fe0' # before define_tables()
>
> db.define_table(
>auth.settings.table_user_name,
>Field('username', length=128, default='', unique=True),
>
>Field('password', 'password', length=512,
> readable=False, label='Password'),
>Field('registration_key', length=512,
> writable=False, readable=False, default=''),
>Field('reset_password_key', length=512,
> writable=False, readable=False, default=''),
>Field('registration_id', length=512,
> writable=False, readable=False, default=''))
>
> custom_auth_table = db[auth.settings.table_user_name] # get the
> custom_auth_table
> custom_auth_table.username.requires =
> IS_NOT_EMPTY(error_message=auth.messages.is_empty)
>
> #custom_auth_table.password.requires = [IS_STRONG(), CRYPT()]
>
> auth.settings.table_user = custom_auth_table # tell auth to use
> custom_auth_tabl
>
> auth.define_tables() # creates all needed
> tables
> .
>
> test.py (controller)
>
> def myLogin():
>
>username = "peter"
>password = "pass"
>
>user = auth.login_bare(username, password)
>if not user:
>return "failed"
>else:
>return "ok"
> ...
>
> by invoking the test controllers myLogin function i get :
>
> Traceback (most recent call last):
> File "D:\DEV\python\web2py\stable\web2py_src\web2py\gluon
> \restricted.py", line 188, in restricted
>exec ccode in environment
> File "D:/DEV/python/web2py/stable/web2py_src/web2py/applications/
> error/controllers/test.py", line 23, in
> File "D:\DEV\python\web2py\stable\web2py_src\web2py\gluon
> \globals.py", line 96, in
>self._caller = lambda f: f()
> File "D:/DEV/python/web2py/stable/web2py_src/web2py/applications/
> error/controllers/test.py", line 15, in iphoneLogin
>user = auth.login_bare(username, password)
> File "D:\DEV\python\web2py\stable\web2py_src\web2py\gluon\tools.py",
> line 1306, in login_bare
>user = self.db(table_user[userfield] == username).select().first()
> UnboundLocalError: local variable 'userfield' referenced before
> assignment
>
> in:
>
> def login_bare(self, username, password):
> ..
>elif 'username' in table_user.fields:
>userfield = 'username'
>else:
>userfield = 'email'
>passfield = self.settings.password_field
>user = self.db(table_user[userfield] ==
> username).select().first() < local variable 'userfield'
> referenced before assignment
>
>password = table_user[passfield].validate(password)[0]
>if user:
>if not user.registration_key and user[passfield] ==
> password:
>user = Storage(table_user._filter_fields(user,
> id=True))
>
> seems to be there is no userfield 'username' anyhow?
>
> interestingly it works with 1.84.1 as expected
>
> for testing here the project if your interested:
> http://rapidshare.com/files/420164051/web2py.app.error.w2p
Re: [web2py] Re: upgrade from 1.84.1 to 1.85.3 fails due to the following error ..
On Sep 20, 2010, at 8:21 AM, mdipierro wrote: > > fixed in trunk As long as you're fixing tools.py, here's the output from pyflakes: tools.py:23: redefinition of unused 'thread' from line 18 tools.py:371: 'constants' imported but unused tools.py:372: 'pyme' imported but unused tools.py:1876: local variable 'response' is assigned to but never used tools.py:1890: local variable 'e' is assigned to but never used tools.py:1994: local variable 'old_requires' is assigned to but never used tools.py:2624: local variable 'request' is assigned to but never used tools.py:3668: redefinition of unused 'thread' from line 23 tools.py:3668: 'time' imported but unused
Re: [web2py] Re: Deploying web2py on linux (Redhat or others) on cpanel or other ways
On Sep 21, 2010, at 5:32 AM, mdipierro wrote:
>
> What you see it the output of the web2py function
>
> redirect(URL('index'))
>
> so I think it is working.
That part is working, but the the underlying problem seems to be that all that
stuff is indeed missing from the environment. If you google one of the error
messages, you'll see that a lot of people have the same problem.
This post might be useful (or the stuff it links to):
http://forums.asmallorange.com/topic/8555-django-problem/page__st__20
>
> On Sep 21, 3:53 am, Rahul wrote:
>> I have made the changes as suggested by Jonathan -
>> changes
>> e['REMOTE_ADDR'] to e.get('REMOTE_ADDR', 'localhost'),
>> ---
>>
>> now it does not give me the REMOTE_ADDR Error. It shows the below
>> text..
>>
>> -bash-3.2$ ./dispatch.fcgi
>> WSGIServer: missing FastCGI param REQUEST_METHOD required by WSGI!
>> WSGIServer: missing FastCGI param SERVER_NAME required by WSGI!
>> WSGIServer: missing FastCGI param SERVER_PORT required by WSGI!
>> WSGIServer: missing FastCGI param SERVER_PROTOCOL required by WSGI!
>> Status: 303 SEE OTHER
>> Content-Type: text/html; charset=UTF-8
>> Location: /web2py/welcome/default/index
>> Content-Length: 73
>>
>> You are being redirected here> a>-bash-3.2$
>> ---
>>
>> I am confused what url would I need to access. Also does the above
>> output mean, It is working now?
>> Can we ignore Status 303 SEE OTHER Error ?
>>
>> My public_html structure is as follows
>>
>> $HOME/
>> |--->public_html
>>|-> .htaccess
>>|-> dispatch.fcgi
>>|-> directory
>> |-> .htaccess
>> |-> dispatch.fcgi
>> |-> web2py directory
>> |-> All files &
>> folders + dispatch.fcgi &
>> .htaccess
>>
>> Please suggest -
Re: [web2py] Re: welcome app normalize hack ie and html5 ready
On Sep 22, 2010, at 12:01 PM, mdipierro wrote: > > I love this and I would like to include it in the web2py but I have > three problems: > > 1) it no longer uses ez.css for layout (id had the options for left > and right sidebars for example) > 2) there is extra space between header-manu, menu-content, content- > footer. If a user were to replace the header background with an image, > there would a separation with the menu bar for example. > 3) I would still like the flash to be black because works better on a > colored background. > > Do you think these can be put back? It's good; I really like the idea of a bare-bones scaffold. It'd be nice if the css were a little closer to validating. I understand that it's bleeding edge, but still It'd also be nice if the flash didn't obscure the top links. > > Massimo > > On Sep 22, 12:33 pm, "Martin.Mulone" wrote: >> welcome app normalize hack ie and html5 ready >> >> I made some changes to welcome app, based on thishttp://html5boilerplate.com/ >> and other stuff. >> >> * Added support ie 6.0 png transparency (hack) >> * Normalize all tags >> * Support for html 5 (future), usinghttp://www.modernizr.com/, that >> detect if your browser can handle it >> * Different hack for different browser problems >> >> * I neutralize the style of layout, center to the browser, etc. >> * I remove all nonesense divs (ez-css), html is also a language code >> so header, footer, page, sidebar names make sense to me. >> * Added test css, to test ul li ol code, etc in the page. >> * Added link to documentation and resources >> * Added javascript show_notification, is the same that flash but with >> and icon that show is ok, warning or error. >> >> See in actionhttp://web2pytesting.appspot.com/welcome/ >> >> Source:http://web2pytesting.appspot.com/welcome/static/welcome.zip >> >> Tellme what you think
Re: [web2py] Re: welcome app normalize hack ie and html5 ready
On Sep 22, 2010, at 1:47 PM, Martin.Mulone wrote: > > i know this need testing, i made this in hours so i think there are > many errors, and i am going to fix. I am going to test in all > browsers, ie, chrome. I think this is never going to validate because > of the hacks, but the hacks allow that its show likely the same in all > browser. Agreed. I like that you've made some attempt to document the hacks, and it'd be nice if the validators allowed you to provide a list of expected deviations.
Re: [web2py] routes.py routes_app and defaults
On Sep 23, 2010, at 4:34 AM, Albert Abril wrote: > I have in the root of web2py the routes.py configured with that: > > default_application = 'arritmia'# ordinarily set in base routes.py > default_controller = 'default' # ordinarily set in app-specific routes.py > default_function = 'index' # ordinarily set in app-specific routes.py > > > Ok, so when i access to the main url, web2py redirects me to > localhost:8000/arritmia/default/index , right? > > Now i wanna define that, when I access: > http://localhost:8000/bio/ > It should redirect me to: > http://localhost:8000/arritmia/bio > where bio is a controller+view into arritmia app. A point of clarification: unless you're actually rewriting a URL (with routes_in, etc), http://domain.com/bio will be interpreted as application=bio. The usage of default_application is pretty simplistic, and in particular it never "inserts" an application into a URL. I agree that the kind of "default" that Albert is expecting here would be useful, but for now at least, you have to use routes_in and routes_out to achieve it. > > But i wanna to define it, in routes.py at the root of the application. > > How i define that? > > Should i config routes_app in routes.py at the root of the web2py dir? >
