Update: I happen to solve this problem by not include .git .DS_STORE in the
"pack custom".
So this problem may have something to do with .git folder.
Hope this help other people in the future.
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py
+1 Here. It does the same thing to me, 2.9.7 appadmin redirects to web2py
admin. 2.9.6 is working correctly.
On Friday, September 5, 2014 10:06:24 PM UTC+2, Niphlod wrote:
>
> because the only change we made was making the access to appadmin more
> secure when web2py is behind a proxy.
>
> Howe
Hi, I got this error message "Unable to install application" when overwrite
existing. Check box checked for overwrite.
I tried to kill web2py sessions and restart both admin and the scheduler
session, as Google suggested. No luck.
I tried to overwrite another simpler app. Then it was fine.
So
Thanks alot massimo, i haven't seen that.
class PostHandler(tornado.web.RequestHandler): """ only authorized parties
can post messages """ def post(self): if hmac_key and not 'signature' in
self.request.arguments: return None if 'message' in self.request.arguments:
message = self.request.arguments
because the only change we made was making the access to appadmin more
secure when web2py is behind a proxy.
However, if you get redirected to admin it shouldn't matter, as the
"change" would affect you accessing admin also.
Seeing the code of appadmin.py (assuming is the latest from 2.9.7) the
Cool!
2014-09-05 2:47 GMT-03:00 Massimo Di Pierro :
> same as 2.9.6 except:
>
> - a few more bug fixes
> - sessions are stores in sessions/XX/YY/ subfolder to avoid proliferation
> of files under the same folder which causes slowdown
> - cache.disk has been rewritten by Leonel and it much better
I've just get back to 2.9.5 and appadmin works. I'm confused :P
On Fri, Sep 5, 2014 at 4:59 PM, Luciano Laporta Podazza <
lucianopoda...@gmail.com> wrote:
> Hi Niphlod,
>
> No, I'm working locally and no proxies at all. Why you ask?
>
>
> On Fri, Sep 5, 2014 at 4:58 PM, Niphlod wrote:
>
>> are
Hi Niphlod,
No, I'm working locally and no proxies at all. Why you ask?
On Fri, Sep 5, 2014 at 4:58 PM, Niphlod wrote:
> are you behind a proxy ?
>
>
> On Friday, September 5, 2014 9:34:12 PM UTC+2, Luciano Laporta Podazza
> wrote:
>>
>> Hello,
>>
>> I was developing an application with web2py
are you behind a proxy ?
On Friday, September 5, 2014 9:34:12 PM UTC+2, Luciano Laporta Podazza
wrote:
>
> Hello,
>
> I was developing an application with web2py
> 2.9.5-trunk+timestamp.2014.03.29.21.54.41 and appadmin worked fine until I
> upgraded to latest 2.9.7.
>
> Now when I access appadm
Hello,
I was developing an application with web2py
2.9.5-trunk+timestamp.2014.03.29.21.54.41 and appadmin worked fine until I
upgraded to latest 2.9.7.
Now when I access appadmin for ANY app(welcome, examples, my app, etc) it
redirects to admin and nothing happens.
Tried cleaning everything,
Yes.
And bear into account that web development is migrating towards js based
interfaces.
On Friday, September 5, 2014 1:37:55 PM UTC-5, Cliff Kachinske wrote:
>
> SQLFORM is still gonna be there, just deprecated. Which I believe means
> bug fixes only at this point.
>
> As long as there ar
This error:
RuntimeError: File /home/gsv/enertek/web2py/applications/welcome/databases/
c8b669d15150d7109e5f7ab36744a5b7_sales_leads.table appears corrupted
As Marin says, makes it seem it's just the table file that got corrupted,
so you didn't lose anything. Just erase it and do a fake migrati
Fixed Thankfully...
1) Renamed the table in the model
2) Uploaded the backup csv file to the renamed table... was about a week
out of date
3) Manually deleted the corrupt file from the database
4) Created a new table with the old table name without fields and set
migrate and fake_migrate to true
SQLFORM is still gonna be there, just deprecated. Which I believe means bug
fixes only at this point.
As long as there are gluon.html and gluon.sqlhtml you can continue as
accustomed.
On Friday, September 5, 2014 1:06:17 PM UTC-4, viniciusban wrote:
>
> I don't agree with killing a way to sen
This is a very intriguing development. It would be interesting to see
real-world usage statistics (what percent of apps are all or mostly js UI, vs.
traditional backend-sends-html UI),
but since that would be pretty hard to get, the next best metric would be for
developers to
give an indication
Version
Enter code here...
web2py™ Version 2.8.2-stable+timestamp.2013.11.28.13.54.07 Python Python
2.7.5+: /usr/local/bin/uwsgi (prefix: /usr) Traceback
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Traceback (most recent call last):
File "/home/gsv/enertek/web2py/gluon/restricted.py", li
I don't agree with killing a way to send formed html to client.
Web2py is for backend development, in spite of most clients run js,
some of them, don't. There are non-js clients. wget is one of them. I
know, it's not widely used, but depending on your application, it is a
client of it.
As I expla
Tried fake_migrate... production site on pythonanywhere so disk space
wasn't the issue... scratching my head with this...
On Saturday, 6 September 2014 02:55:23 UTC+10, Marin Pranjić wrote:
>
> It can happen if you run out of disk space. You should check it.
>
> Btw, maybe just .table got corrupt
It can happen if you run out of disk space. You should check it.
Btw, maybe just .table got corrupted... Make sure to backup everything, and
then do a fake migrate.
Marin
On Fri, Sep 5, 2014 at 6:51 PM, Greg Vaughan
wrote:
> I wasn't working on the site at the time... I was notified by some o
I wasn't working on the site at the time... I was notified by some of the
employees... yes it looks like the table has been dropped... I cannot for
the life of me work out how that could have happened though.
On Saturday, 6 September 2014 02:41:30 UTC+10, Leonel Câmara wrote:
>
> Err wait a minu
Yeah... everything was fine one moment then it all just stopped... when I
looked at the file it was 0kb. I have no idea what happened... cannot
access database admin... site still runs except for the functions that
access that table...
On Saturday, 6 September 2014 02:22:31 UTC+10, Greg Vaugha
Err wait a minute the table has actually been dropped?
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribe
You haven't changed anything in your models right? Just do a fake
migration. Or simply turn migrations off since you don't need them in
production.
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.co
Somehow the sales table in my site has been corrupted... it is now a 0kb
file (was about 600KB). Every other table is fine however. How can I
reconstruct the data in this table? I have a backed up csv which is a
little out of date but would do.
Thanks
Greg
--
Resources:
- http://web2py.com
-
I feel like the only clean approach is to have a LIKE and a ILIKE.
The problem is that we don't have any mechanism to make compatibility
breaking changes.
I think ideally applications should report what version of web2py or of the
DAL they were made for (and if they don't, we assume they're old
Well we are already using the quirk that kills performance. My point is
that irrespective as to the settings on an individual DB, we need two
methods for the framework: (1) case-insensitive and (2) case-sensitive.
The first uses ILIKE (pg) and CONTAINING (firebird) and whatever other DBs
of
Ok
this do the trick:
request.post_vars.consumo_mensual= ConvEtermica(request.vars.tipo
,request.vars.consumo_teorico, request.vars.horas_uso_mes).consumo_mensual()
form1 = SQLFORM(db.energia_termica)
Thanks!
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- h
Solved!!
:D
Richard
On Fri, Sep 5, 2014 at 11:10 AM, Richard Vézina wrote:
> DOH, you right... It just break lazy_table it guess, I forgot about that.
>
> Thanks Derek!
>
> :)
>
> Richard
>
>
> On Thu, Sep 4, 2014 at 5:23 PM, Derek wrote:
>
>> Just set that up after you define the table.
>>
Try request.post_vars instead of request.vars.
On Friday, September 5, 2014 10:54:44 AM UTC-4, JorgeH wrote:
>
> Thanks for your reply:
>
> This does not work:
>
> request.vars.consumo_mensual = ConvEtermica(request.vars.tipo
> ,request.vars.consumo_teorico, request.vars.horas_uso_mes).consumo_
DOH, you right... It just break lazy_table it guess, I forgot about that.
Thanks Derek!
:)
Richard
On Thu, Sep 4, 2014 at 5:23 PM, Derek wrote:
> Just set that up after you define the table.
>
>
> On Thursday, September 4, 2014 1:53:05 PM UTC-7, Richard wrote:
>>
>> Hello,
>>
>> I have a wei
we should NOT use this script because:
- uses apache
- uses an old version of apache
- installs python with a fixed version in a fixed path
- installs a configuration file that is fixed and does not depict the same
configurations we have in linux scripts
IMHO it's time to do a guide on how to use
Thanks for your reply:
This does not work:
request.vars.consumo_mensual = ConvEtermica(request.vars.tipo
,request.vars.consumo_teorico, request.vars.horas_uso_mes).consumo_mensual()
form1 = SQLFORM(db.energia_termica)
and this:
form1.vars.consumo_mensual = ConvEtermica(request.vars.tipo
Make the change before creating the form. But perhaps we should figure out
how to make your computed field work instead.
On Friday, September 5, 2014 9:52:37 AM UTC-4, JorgeH wrote:
>
> Hello
>
> I've been trying to use a compute field that needs to use a class I
> created . But I get the error
I think the big question here is - what's the old behaviour exactly?
This is important because backwards compatibility must be maintained at all
costs.
It doesn't seem to me as if the old behaviour was case insensitive, the old
behaviour was to do whatever the DB was configured to do. Am I righ
+1
On Friday, September 5, 2014 12:56:23 AM UTC-5, Massimo Di Pierro wrote:
>
> Please find attached a welcome4.zip with contains the following files:
>
> controllers/default.py
> views/layout.html
> vides/default/index.html
> modules/jform.py
> static/js/jform.js
> static/js/jform-bootstrap2.js
>
Hello
I've been trying to use a compute field that needs to use a class I created
. But I get the error : TypeError: unhashable type: 'list'
Thus I intend to instead of a computed field, just do the calculations
before processing the form.
if form1.process(session=None, formname='tabla1').
except that except postgresql any database can deal with case-sensitivity
or not at the database level, and doesn't have an ILIKE, so needs to go
through LOWER(), effectively doing a full scan "by default" ditching every
possible index.
Using by default a quirk that kills performances just beca
i am for it ;)
On Friday, September 5, 2014 12:56:23 AM UTC-5, Massimo Di Pierro wrote:
>
> Please find attached a welcome4.zip with contains the following files:
>
> controllers/default.py
> views/layout.html
> vides/default/index.html
> modules/jform.py
> static/js/jform.js
> static/js/jform-bo
Good catch! fixed in trunk.
On Friday, 5 September 2014 08:07:42 UTC-5, Ide wrote:
>
> I have 2 applications which both seem to have a problem with the 'check to
> delete' option in 2.9.6 and 2.9.7. The 'check to delete' label on this tick
> box is now showing up as 'Check to deleteNone'. I don;
I have 2 applications which both seem to have a problem with the 'check to
delete' option in 2.9.6 and 2.9.7. The 'check to delete' label on this tick
box is now showing up as 'Check to deleteNone'. I don;t think it did this
when I was using 2.9.5, although that was a few months ago now, so I ma
@Joe,
let me go back and look at my correspondence about this... we may revert
this change.
On Friday, 5 September 2014 05:34:11 UTC-5, Joe Barnhart wrote:
>
> I'm really unclear on this discussion.
>
> I use postgres (pg) and sqlite a lot. When using web2py on both of them,
> I was doing case
yes, for example if you have a sqlform.grid you can define the search as
keyword in the URL.
>
https://SERVER/application/controller/function?keywords=table.field+starts+with+%22A%22
Am Donnerstag, 4. September 2014 23:37:53 UTC+2 schrieb Douglas Campbell:
> Is it possible to have a default
> Should we put to a vote the default behavior of db(...).like(...)?
The change to LIKE was to mirror the standard SQL and make it
case-sensitive. Unfortunately, most web2py users expect LIKE to be
insensitive.
There really should have been two commands from the beginning, LIKE and
ILIKE (
The difference should be small for gzipped but measurable (don't forget
that you can also gzip json), the reason is that theoretically the same
information could be compressed to the same size, however, the json version
really carries less information as the structure of the document in HTML
te
It's the classic trap we fall into when learing object-oriented
programming. The dictionary is a single INSTANCE of a dict. It's like an
individual and you could give it a name. Let's say its name is David. Now
you load David up with a bunch of data and put him in a list.
Now instead of m
I'm really unclear on this discussion.
I use postgres (pg) and sqlite a lot. When using web2py on both of them, I
was doing case-INsensitive "like" comparisons by default. Yet the
underlying DB systems have opposite native defaults -- pg defaults to
case-sensitive and sqlite defaults to case-
Ok,
but when you use gzip and the html is relatively simple, the difference
between only the data and the complete html is small I would think but the
client would still need to render the thing.
On Friday, September 5, 2014 12:06:26 PM UTC+2, Leonel Câmara wrote:
> Unless they are on a good w
Unless they are on good wireless connection, it should be Quint. In my
experience with mobile apps, what makes things slow is data transfers,
these forms transfer a lot less data. In fact this follows the model I
already use for all my mobile apps, transmit json for compactness, make
html in th
Massimo,
Is this also faster on mobile devices?
They tend to be a little slow with JavaScript is my experience.
On Friday, September 5, 2014 7:56:23 AM UTC+2, Massimo Di Pierro wrote:
> Please find attached a welcome4.zip with contains the following files:
>
> controllers/default.py
> views/la
Hey,
I don't know if this is generally known, but this works:
*{{include var+'.html' }}*
whereas this doesn't:
*{{include '%s.html' % var }}*
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web
On Friday, September 5, 2014 2:05:40 AM UTC-4, Massimo Di Pierro wrote:
>
> I do not like this. Should we put to a vote the default behavior of
> db(...).like(...)? the thing is whatever we do will behave differently than
> before on different databases.
>
The problem is that there's no way to c
51 matches
Mail list logo
