Short version: In 6.0, the debugger seems more apt to show, in the Call Stack window, a module prefixed with 'frozen', and when it does, although F6 and F7 stepping does advance the execution (as judged by the Call Stack), the editor does not show the execution point in the code.
The Django 1.8 tutorial "polls" example. Using Django 1.8.14. with Python 3.5.2 64 bit on Windows 7-64.
The tutorial is set up to the point of the first 'manage runserver'.
The real problem I'm trying to troubleshoot is why runserver takes 20 secs or more (to get to the first console message), and 40 secs in the WingIDE debugger.
Oddly, on Linux Mint 18, from linux command line, 'manage runserver' takes only about two secs, though running in Linux WingIDE debugger takes about forty secs.
To troubleshoot, I'm tracing into the code to determine which import or function call is causing the delay.
A top-level issue is that for some reason django/__init__.py setup() is called twice (*) before the first console message (and a third time after). Each of those first two calls takes half the overall delay. (Placing print statements at top and bottom of that function is informative.)
Within the setup() function, it's the statement from django.utils.log import configure_logging that incurs the delay, though that narrows it down little, as that import drags in many others.
One culprit appears to be _bootstrap.py _load_unlocked(spec) (in the core python libraries) when it attempts to load 'django.db.models'.
That function calls spec.loader.exec_module(module), which is actually _bootstrap_external.py.
When debugging in 6.0b, Step Into will allow execution to go to that module, but will not show the execution point in the editor. The Call Stack shows <frozen _bootstrap_external.py...>
In 5.1.12-1, execution continues into _bootstrap_external.py, with the editor display tracking execution properly. And the Call Stack does not show frozen. (Though I did see 'frozen' at some point, but couldn't reproduce it.)
So, not sure what's up with that.
(*) As an aside, debugging Django at all seems a bit hit or miss, as I haven't figured out the role of the autoreload() apparatus -- what causes it to reload, and implications for debugging.
Graham Wideman via wingide-users wrote:
> Short version: In6.0, the debugger seems more apt to show, in the Call Stack window, a module prefixed with 'frozen', and when it does, although F6 and F7 stepping does advance the execution (as judged by the Call Stack), the editor does not show the execution point in the code.
Failure to show the stack position will be fixed in beta2 (coming
soon). In think in beta1 as a work-around you can go up/down the stack
to get it to show the right position.
The slowness of debugger is a separate issue. Are you seeing that also
in Wing 5.1.12 for this code, or only Wing 6?
In some cases we've seen this caused by Django loading some large
dataset from a database in a way that really brings out the debugger
overhead, but if you're starting with a new instance and in the tutorial
that doesn't seem like it should be the issue in your case.
You may also want to try a more recent Django, in case it's something
that has been fixed in Django.
Wingware | Python IDE
The Intelligent Development Environment for Python Programmers