web2py 2.4.7 is Out

[Massimo Di Pierro]

I posted web2py 2.4.7. Includes mostly bug fixes.

[Alan Etkin]

El viernes, 24 de mayo de 2013 14:56:11 UTC-3, Massimo Di Pierro escribió:

I posted web2py 2.4.7. Includes mostly bug fixes.

Codenamed?

[Derek]

Navy Platinum Bulldog 

[Anthony]

On Friday, May 24, 2013 7:00:42 PM UTC-4, Derek wrote:

Navy Platinum Bulldog 

 

No cheating. ;-)

[Massimo Di Pierro]

LOL

[LightDot]

On a more serious note, release tag in mercurial and git states R-2.7.4, should be R-2.4.7... Should this be fixed to prevent any future confusion?

Regards,
Ales

[Massimo Di Pierro]

I re-tagged trunk. I will post 2.4.8 asap since I am not sure how to remove a tag.

[Niphlod]

in hg to delete a bookmark

hg tag --remove <bookmark name>

in git instead its

git tag -d <bookmark name>
git push origin :refs/tags/<bookmark name>

PS: github doesn't hold the new tag name yet. To propagate tags you have to issue
git push origin --tags

[LightDot]

This should fix it nicely.

Btw, I see jQuery 1.10.0 has been included in the trunk. This would probably be a good moment to also upgrade Bootstrap to 2.3.2. Should be a drop-in replacement for 2.2.2.

Regards,
Ales

[Mika Sjöman]

I agree

I think it confuses people allot who are starting with web2py since many try to use online themes, but they break because web2py uses an old version of bootstrap.

Cheers

[Marin Pranjić]

looks like bootstrap 2.3.2 fixed few issues but introduced more

--
 
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[LightDot]

I opened an issue to track this:
http://code.google.com/p/web2py/issues/detail?id=1510

On Sunday, May 26, 2013 10:58:08 AM UTC+2, Niphlod wrote:

[Massimo Di Pierro]

So... should be upgrade bootstrap? I did not try the new one. Does it break menus?

[Marin Pranjić]

bootstrap 2.3.1 broke middle mouse click and there was a request for 2.3.2 for a long time, but 2.3.2 breaks dropdown menus on some mobile devices.
according to this comment it should be fixed next week, so we should wait until then.

Marin

[Aurelio Tinio]

Hi Massimo,

  If you don't mind, could you elaborate on what these bugfixes are? We've just upgraded our system to use v2.4.6 and trying to assess if it's worth it to do the upgrade to v2.4.7 before our launch. Specifically, we've noticed a possible memory leak with our deployment and currently investigating if this might have been due to our upgrade to v2.4.6 and if so, if this bug has been fixed in the latest version.

Thanks,

Aurelio

[Massimo Di Pierro]

The only memory leak I am aware of is when one use the TAG helper. It is fixed in trunk and will be foxed in 2.4.8 but it is not fixed in 2.4.6. I am not aware of other memory leaks.

[Aurelio Tinio]

Thanks for the prompt response Massimo. It doesn't look like we are using the TAG helper for our application but good to know nonetheless.

Cheers.

[Massimo Di Pierro]

Let me know if you can isolate the reason for your memory leak. There are two known potential causes for leaks. 1) you use cache too much in ram without clearing the cache; 2) you create instances of objects with a __del__ method (this may create circular references which cannot be garbage collected). None of the web2py classes have a __del__ method but third party libraries may.

[Aurelio Tinio]

Hi Massimo,

  I haven't been able to isolate the reason for our memory leak other than having it be triggered when encountering an unknown page (i.e. 404 page). The investigation continues and will definitely keep you posted, especially if the problem is with web2py and not our own application code.

Curious though.. for the memory leaks that you have found in the past, what is your process like to track them down? Do you have a preferred python memory profiler that you use, etc.. ? I'm currently looking into the use of Heapy and/or objgraph but figured it wouldn't hurt to ask you before I dive deeper.

Thanks,

Aurelio

ps If this is now way off topic for this thread, happy to repost the question as a new topic. Please, just let me know.

[Massimo Di Pierro]

I do not have a good answer but with of all I would try isolate the problem. Can you reproduce it with the built-in web server? Can you reproduce it with a smaller application? Can you reproduce it with am app that does not use cache? etc. If you could post a minimalist code to reproduce it, others could try it too.

[Aurelio Tinio]

Hi Massimo,

  We've been able to track down the issue which appeared like a memory leak. It seems to be an issue with our use of routes.py. We've been able to reproduce the issue with the built-in web server, a smaller application (included 'welcome' app) that does not use cache. I've prepared the following changeset to show steps to reproduce, with routes.example.py actually being used as routes.py:

https://github.com/tinio/web2py/commit/71eb2bee2ca1c7d733bacb7d9da73b1be62f870b

With those changes, as soon as an unknown 404 page is hit (such as http://127.0.0.1:8000/welcome/dfsfdf) the amount of memory used by the python web2py process increases dramatically, quickly in a few seconds.

https://www.evernote.com/shard/s4/sh/7de982fa-c03c-4177-8471-65945c7d6fe3/51b7cbf3248039057b9ae73bb2564434

https://www.evernote.com/shard/s4/sh/1b211f97-3bc1-430a-b937-3804771fe455/dfab496d33b7eb9d2cc904ff34af5600

I'm guessing our use of routes.py is incorrect, regardless as promised I thought I'd post to get your thoughts. This wasn't immediately obvious to us and might be a common pitfall for others that should have safeguards in code. Tracking it down, it seems to be an issue with gluon/rewrite.py getting caught in an infinite loop. As a quickfix, for our copy of web2py we've put in an else break to ensure getting out of the loop.

https://github.com/tinio/web2py/commit/c174f4d331d24153b4fc5d2cbb00871db83b62d2

I still don't fully understand what is being done in the try_rewrite_on_error function so confidence in this patch is minimal. Again, any thoughts or feedback would be appreciated.

Thanks,

Aurelio

[Massimo Di Pierro]

Thank you for letting us know. Others had reported a memory leak with routes.py but we had never been able to isolate it. Now you narrowed down the problem. We will try reproduce and fix it asap!

[Massimo Di Pierro]

Thank you again for reporting this. there is a possible solution in trunk, proposed by Jonathan. Would you be able to check it?

[Aurelio Tinio]

Welcome and thank you for quickly posting the solution. I've gone ahead and applied the following changeset:

https://github.com/web2py/web2py/commit/1509559e78e858282a7726c6f6cfc553952823e2

to our web2py copy and it looks to have solved the problem. Woot!