Re: GSoC 2013- Pylons.Pyramid -- Better Debug tools

[Blaise Laflamme]

Hi,

we have a project in the air to make the debugtoolbar not injected in the html page but instead rendered inside an iframe or in a different window. With that feature we also have the interest of keeping x number of requests in memory so you can access multiple requests like ajax ones not available to the current request. Me and raydeo have discussed this project at pycon and will probably sprint on it at breckenridge, and the project will probably be a new one.

So I think those ideas should be separated from the current debug toolbar project. However the current project need more love so if you are interested you're welcome to give a hand.

On Thursday, 25 April 2013 07:56:41 UTC-4, bro...@brodul.org wrote:

Hi, 

my name is Andraz Brodnik 'brodul' from Slovenia, Ljubljana. 

I am finishing my studies at the faculty of electrical engineering in Ljubljana.

I am working with python for the last two years, before that I was a linux system administrator.

To also develop web dev skills I started developing in Pyramid (Jinja2, SQLAlchemy, Alembic) about half year ago. Because of great potential of unittesting web APIs and great local python support from other OSS hackers (Domen Kozar and many others).

I would like to contribute back to the community and get more experience working with larger community and code base, not just pushing small patches.

So I would like to improve the debug tools for pyramid. As this is proposed on the wiki on Pyramid GitHub page, with the primary focus on the debugtoolbar.

Here is a list of things I would like to improve:

debugtoolbar:

- Review open bugs close them if they have already been fixed

- Fix open bugs

- Better Unicode handling

- Better extension support

- ZODB extension (transaction amount ... )

Other:

- The debug interactive console has a lot of bugs

- Better integration of Jinja2 into traceback on template error

I don't understand what is meant by the task:

Overall cleanup of debugger toolbar (Make it so doesn't embed itself into the site HTML)

I will be honored to get some feedback. 

Andraz Brodnik 'brodul'

[Jonathan Vanasco]

for the new debugtoolbar, could you (please) look into not making it trigger multiple requests / events ?  that's been a pain in the ass when debugging event subscribers.  

[Michael Merickel]

Better isolation is a major motivation behind the new debugger. That and being able to debug ajax/api requests. Don't worry, what we have in ours heads (not on paper) is the bees knees!

On Thu, Apr 25, 2013 at 4:00 PM, Jonathan Vanasco <jona...@findmeon.com> wrote:

for the new debugtoolbar, could you (please) look into not making it trigger multiple requests / events ?  that's been a pain in the ass when debugging event subscribers.  

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jonathan Vanasco]

On Thursday, April 25, 2013 7:33:03 PM UTC-4, Michael Merickel wrote:

Better isolation is a major motivation behind the new debugger. That and being able to debug ajax/api requests. Don't worry, what we have in ours heads (not on paper) is the bees knees!

sweet! 

[John Anderson]

On Thu, Apr 25, 2013 at 4:56 AM, <bro...@brodul.org> wrote:

Hi, 

my name is Andraz Brodnik 'brodul' from Slovenia, Ljubljana. 

I am finishing my studies at the faculty of electrical engineering in Ljubljana.

I am working with python for the last two years, before that I was a linux system administrator.

To also develop web dev skills I started developing in Pyramid (Jinja2, SQLAlchemy, Alembic) about half year ago. Because of great potential of unittesting web APIs and great local python support from other OSS hackers (Domen Kozar and many others).

I would like to contribute back to the community and get more experience working with larger community and code base, not just pushing small patches.

So I would like to improve the debug tools for pyramid. As this is proposed on the wiki on Pyramid GitHub page, with the primary focus on the debugtoolbar.

 

Hello Andraz,

There are only 4 days left to submit proposals, so make sure you make the time to submit an official proposal on http://www.google-melange.com and we can help you refine the proposal once.   Did the information in the previous e-mails help you understand what we were thinking? 

[bro...@brodul.org]

Tnx, for the reply. 

Tnx for your opinions and plans. 

I will look into similar solutions/tool-bars to improve AJAX debugging .

[bro...@brodul.org]

On Thursday, April 25, 2013 9:00:20 PM UTC+2, Blaise Laflamme wrote:

Hi,

we have a project in the air to make the debugtoolbar not injected in the html page but instead rendered inside an iframe or in a different window. With that feature we also have the interest of keeping x number of requests in memory so you can access multiple requests like ajax ones not available to the current request. Me and raydeo have discussed this project at pycon and will probably sprint on it at breckenridge, and the project will probably be a new one.

So I think those ideas should be separated from the current debug toolbar project. However the current project need more love so if you are interested you're welcome to give a hand.

Blaise, tnx for your feedback. I support the idea of making the iframe separated toolbar a new project. Do you think that I should implement AJAX support in the current project or leave it aside?

Tnx in advance

Andraz Brodnik 

[bro...@brodul.org]

Hello Andraz,

There are only 4 days left to submit proposals, so make sure you make the time to submit an official proposal on http://www.google-melange.com and we can help you refine the proposal once.   Did the information in the previous e-mails help you understand what we were thinking? 

Hi,

Done,

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/brodul/1# 

Sorry for triple post.

Tnx for the time. 

[Jonathan Vanasco]

I'm just going to wishlist something.  not sure if it is doable or not... but I get stuff like this a lot in my Tracebacks

    TypeError: __init__() got an unexpected keyword argument 'ssl_verify'

The reason is that i sometimes end up forking a library to patch it.  ( in this case, Twython ).  The problem / deficiency in reporting is that the traceback doesn't have any information about the file that has the __init__ function.  seeing that would make things a lot easier for me to do integrated tests on.  i'm not sure if the traceback can be easily extended to have that info, but if it's just adding a kwarg to something, I'd love to see that sort of info in there.  

[Blaise Laflamme]

I do think making the toolbar separated would need too much refactoring in the current codebase. I would probably keep the current toolbar working as it is, there's a lot of possible improvements for the current toolbar, and they'll serve the next one.