Поиск по блогу

среда, 9 апреля 2014 г.

Зачем я установил gtConsole в сборку Kali

Итак, я осваиваю iPython... и последних три месяца упражнялся с Notebook. Когда изучаешь конкретные команды, небольшие фрагменты..., то формат этот очень удобен. Но вот, наконец, дошло дело и до изучения чужих программ.
Что они там напрограммировали? Без нормальной документации (очень часто), с ошибками... Но свой код писать дольше, мне надщо практиковаться на чужих примерах.
И для начала... надо осовить дебаггер. А Notebook бросать не хочется, тем более, что есть %gtconsole (волшебная команда подключение консоли к пространству имен, созданному в текущей notebook)

И вроде бы..., как я здорово рассудил... да вот выясняется , что "gtconsole" просто не установлена, ставлю..., и тут выясняется, что теперь их две...
Словом, план такой.
Читаю документацию и собираю здесь ссылки
Потом нахожу и смотрю видеоролики
Потом здесь пишу выводы
In [2]:
%quickref
In []:
[Using the Python debugger (pdb)](http://ipython.org/ipython-doc/dev/interactive/reference.html#using-the-python-debugger-pdb)
<br/>[A Qt Console for IPython](http://ipython.org/ipython-doc/dev/interactive/qtconsole.html)
<br/>[Using IPython for interactive work](http://ipython.org/ipython-doc/dev/interactive/index.html)
<br/>[The Python Debugger](https://docs.python.org/2/library/pdb.html#debugger-commands)
<br/>[bdb  Debugger framework](https://docs.python.org/2/library/bdb.html)
<br/>[]()
<br/>[]()
<br/>[]()
In [3]:
%connect_info
{
  "stdin_port": 51567, 
  "ip": "127.0.0.1", 
  "hb_port": 43312, 
  "key": "7caba039-9962-487b-bd0c-07439fa1db55", 
  "shell_port": 33306, 
  "iopub_port": 47005
}

Paste the above JSON into a file, and connect with:
    $> ipython <app> --existing <file>
or, if you are local, you can connect with just:
    $> ipython <app> --existing kernel-d94c04ba-f958-4872-b880-c7fefb98d63c.json 
or even just:
    $> ipython <app> --existing 
if this is the most recent IPython session you have started.

Using the Python debugger (pdb)

from Using the Python debugger (pdb)

Running entire programs via pdb

pdb, the Python debugger, is a powerful interactive debugger which allows you to step through code, set breakpoints, watch variables, etc. IPython makes it very easy to start any script under the control of pdb, regardless of whether you have wrapped it into a ‘main()’ function or not. For this, simply type %run -d myscript at an IPython prompt. See the %run command’s documentation for more details, including how to control where pdb will stop execution first.
For more information on the use of the pdb debugger, see Debugger Commands in the Python documentation.

Post-mortem debugging

Going into a debugger when an exception occurs can be extremely useful in order to find the origin of subtle bugs, because pdb opens up at the point in your code which triggered the exception, and while your program is at this point ‘dead’, all the data is still available and you can walk up and down the stack frame and understand the origin of the problem.
You can use the %debug magic after an exception has occurred to start post-mortem debugging. IPython can also call debugger every time your code triggers an uncaught exception. This feature can be toggled with the %pdb magic command, or you can start IPython with the --pdb option.
For a post-mortem debugger in your programs outside IPython, put the following lines toward the top of your ‘main’ routine:
import sys

from IPython.core import ultratb

sys.excepthook = ultratb.FormattedTB(mode='Verbose',

color_scheme='Linux', call_pdb=1)

The mode keyword can be either ‘Verbose’ or ‘Plain’, giving either very detailed or normal tracebacks respectively. The color_scheme keyword can be one of ‘NoColor’, ‘Linux’ (default) or ‘LightBG’. These are the same options which can be set in IPython with --colors and --xmode.
This will give any of your programs detailed, colored tracebacks with automatic invocation of pdb.


Посты чуть ниже также могут вас заинтересовать

Комментариев нет:

Отправить комментарий