Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
t
Page not found (404)
Request Method:GETRequest
URL:http://127.0.0.1:8000/delete_issue//
Using the URLconf defined in LibraryManagementSystem.urls, Django tried
these URL patterns, in this order:
admin/
[name='index'] a
dd_book/ [name='add_book']
view_books/ [name='view_books']
view_book
Anyone else have any thoughts on if I should submit this for consideration
into the core?
Cal
On Tue, Dec 20, 2011 at 8:16 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:
> Comments below, apologies for the email signature on previous emails!
>
> On Tue, Dec
Comments below, apologies for the email signature on previous emails!
On Tue, Dec 20, 2011 at 7:56 PM, Paul McMillan wrote:
> > Place a try/catch for MemoryError on the exception handler to send back a
> > simple exception traceback to the browser.
>
> Yes, this makes sense, as long as we are su
Hi Alex,
Please note, I am already using a try/catch block on MemoryError, and this
does indeed resolve the problem.
I think at the very least, we should attempt to generate the text
exception, and if it fails due to a particular circumstance, then it will
just fall back to doing whatever it orig
On Tue, Dec 20, 2011 at 1:56 PM, Paul McMillan wrote:
> > Place a try/catch for MemoryError on the exception handler to send back a
> > simple exception traceback to the browser.
>
> Yes, this makes sense, as long as we are sure the memory error is
> raised by Django code, not user code.
>
> > In
> Place a try/catch for MemoryError on the exception handler to send back a
> simple exception traceback to the browser.
Yes, this makes sense, as long as we are sure the memory error is
raised by Django code, not user code.
> Include a configuration settings option to limit the maximum payload i
Hey,
So, we have a few clients who use Django for processing large amounts of
data in a single query.
If an exception is raised in development, the get_traceback_html() method
fails with a MemoryError, and in the event that it doesn't, you end up with
huge variable data print outs making the debu
Why not to give ability to chose by the developer?
if settings.VERBOSE_DEBUG:
as it is
else:
tabbed view
or
DEBUG_VIEW = 'tabbed'
DEBUG_VIEW = 'default'
etc...
IMHO: DEBUG_VIEW is better and more extensible in future.
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
You receive
class EasyWin(object):
def process_exception(self, request, *args, **kwargs):
if not request.is_ajax(): return
impot traceback
return HttpResponse(traceback.format_exc())
On Jun 10, 1:11 pm, Daniel Watkins
wrote:
> On Thu, Jun 09, 2011 at 08:31:44PM -0700, Valentin Golev wrote:
> >
On Thu, Jun 09, 2011 at 08:31:44PM -0700, Valentin Golev wrote:
> What I'd really like is a stacktrace in a plain text in the html
> commentary ("") on the very top of the page.
I've opened https://code.djangoproject.com/ticket/16227 with patch
attached.
Regards,
Dan
--
You received this mess
For me, it would definitely be a good idea to change the error page a
bit, so at least the actual error message is not in grey but in black,
and bigger. People tend not to see it right now, because it looks
unimportant.
Wim
--
You received this message because you are subscribed to the Google Gr
On Jun 10, 3:34 am, Dougal Matthews wrote:
> On Friday, 10 June 2011 at 04:31, Valentin Golev wrote:
> > What I'd really like is a stacktrace in a plain text in the html
> > commentary ("") on the very top of the page.
>
> +1
>
> This would actually be very useful when debugging Ajax calls in brow
On Friday, 10 June 2011 at 04:31, Valentin Golev wrote:
> What I'd really like is a stacktrace in a plain text in the html
> commentary ("") on the very top of the page.
+1
This would actually be very useful when debugging Ajax calls in browsers. I
often find myself reading the HTML particular
What I'd really like is a stacktrace in a plain text in the html
commentary ("") on the very top of the page.
This really would save me from curl's output reading nightmare without
losing all browser-understandable happiness
On Jun 9, 6:16 pm, Idan Gazit wrote:
> The technical 500 page does disp
The technical 500 page does display a lot of information, but debugging a
failure is all about information.
#11834 is helpful (dims django frames) without getting in the way (hiding
things). For now, this is a good example of a helpful change with minimal
negative impact.
I'm sure the 500 page
On 9 juin, 10:51, Tom Evans wrote:
> I disagree entirely. The stack trace is the first thing I look at, and
> whilst we need to make it easy for people to learn django, we
> shouldn't be hiding essential information from people - even if it is
> just hidden in a separate 'tab'.
Me too. Why is
about manipulating the traceback at all. Why
would I not want to see where it went wrong inside Django? I also
don't buy the 'too much information' argument, I have never been in a
situation where a crash report has too much information - most of the
time it doesn't have enough.
Besi
Hi Mateusz,
I think, adding a link at top, getting you to the end of traceback
would be suitable and would work 96% of times.
e.g, top line with exception type and URL could be a link moving you
to the end of traceback, where the exception happened.
What do you think?
Smart (colored) traceback
Colored output of the trackeback does not solve my problem of scrolling few
screens in order to find whats happening, or use cmd-F key to quick jump.
I think this is not a good way to do this.
What's I am thinking is a tabs at the top which manipulates with visibility
of certain divs of error pa
This ticket might be a part of what you're looking for:
https://code.djangoproject.com/ticket/11834
It proposes to dim the django parts of the stacktrace, so the code
which most likely caused the error stands out better, which is
certainly something I'd love to see.
There's some similar ideas disc
Hi,
I have been thinking about this for quite a long time.
Can you make an error display page less verbose?
I mean not to exclude those useful information, but to initially fold (hide)
them.
Fold those items:
- Python path at the top yellow background.
- (Hide or fold) django traceback entries
On Sun, Sep 20, 2009 at 2:49 PM, zweb wrote:
>
> When I try to download a file through django in IE , I get
>
> [Sun Sep 20 05:34:20 2009] [error] [client 127.0.0.1] response =
> func(request, response), referer: http://www.com
> [Sun Sep 20 05:34:20 2009] [error] [client 127.0.0.1] Fil
When I try to download a file through django in IE , I get
[Sun Sep 20 05:34:20 2009] [error] [client 127.0.0.1] response =
func(request, response), referer: http://www.com
[Sun Sep 20 05:34:20 2009] [error] [client 127.0.0.1] File "/home/
pmc/webapps/test/lib/python2.5/django/http/util
I will Take care in Future.
Regards
A
On Mar 2, 1:43 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On 3/1/07, mralokkp <[EMAIL PROTECTED]> wrote:
>
> > I guess This Group could help me.
>
> No, actually you were right to post the question to django-users.
> This list is for discussion of
On 3/1/07, mralokkp <[EMAIL PROTECTED]> wrote:
> I guess This Group could help me.
No, actually you were right to post the question to django-users.
This list is for discussion of developing Django itself, not questions
about using it.
Thanks!
Jacob
--~--~-~--~~~---
Hello All
I don't know that this Question is asked here or not but I am stuck in
a problem.
The Problem is here
http://groups.google.com/group/django-users/browse_thread/thread/921e8e8f5a68ec7a
I guess This Group could help me.
Thanks in Advance.
A
--~--~-~--~~~---~--
27 matches
Mail list logo
