Wednesday, January 28, 2009

Debugging with app-engine-patch and pdb

If you ever tried to use pdb in application written using app-engine-patch, you should notice, that pdb is not working here at all. All pdb output is shown directly in browser. Thanks to Antonin Hildebrand from this thread now we have a way to use pdb for debugging GAE applications. Use following code to put trace in your app:

def b():
import pdb, sys
sys.__stdout__.write('\a')
sys.__stdout__.flush()
debugger = pdb.Pdb(stdin=sys.__stdin__, stdout=sys.__stdout__)
debugger.set_trace(sys._getframe().f_back)
#...
#...
##########################
b()#here I want to start tracing
For me it worked without any dev_appserver.py patches. Try it out!

Write in C

Не так давно я довольно круто поменял направление деятельности, чем практически вытеснил язык С++ из своей коммерческой практики. Несмотря на это, я продолжаю его любить и продолжаю использовать в некоторых некоммерческих проектах. Так что, надеюсь, в последующих постах будет как Python, так и С++(не считая всего остального). И как доказательство моей преданности семье С языков, ниже отличный ролик. Улыбнитесь!

Если вы даже после этого не не соглашаетесь, что иногда стоит писать на C, а не, например, Python, предлагаю посмотреть вот сюда

Monday, January 12, 2009

C++: Как поймать опасные исключения

Существует множество мнений по поводу механизма исключений: некоторые называют исключения "скрытым goto", другие же считают исключения отличным механизмом и предлагают его использовать везде и всегда. Единственное, с чем согласны все - исключения нужно использовать с особой осторожностью. Ведь даже с виду совсем безобидный код может привести к тому, что ваше приложение упадёт в самый неподходящий момент.
С++, как многим известно, предоставляет некий механизм спецификации исключений - exceptions spectifications(п.15.4), простейший пример которого представлен ниже:

void foo() throw(Exception1, Exception2)
{
//...
}
В этом небольшом примере функцию foo описывают как функцию, которая может бросить исключения Exception1 и Exception2. Однако, как пишут в Boost Requirements and Guidelines:
The biggest problem with exception-specifications is that programmers use them as though they have the effect the programmer would like, instead of the effect they actually have.
или
Основная проблема со спецификацией исключений в том, что программисты используют их, как будто они работают так, как этого хочет программист, а не так, как они действуют на самом деле
Действительно, попробуйте в функции foo бросить исключение Exception3 и скомпилировать при помощи GCC(другие компиляторы я не использую, но думаю, что они действуют также). Ничего не произошло? И у меня то же самое :)
Т.е., спецификация исключений - вещь относительно бесполезная, а иногда и вредная(некоторые компиляторы не инлайнят функции с exception specifications). Существует много тредов-обсуждений в листе рассылки GCC по поводу возможности вывода предупреждений о несоответствующем спецификации использовании исключений(вот это сообщение - самое полезное, по-моему). В конце концов, подобные запросы отклоняются, ибо "невозможно реализовать из-за сложности межпроцедурного анализа. GCC не предназначен для такого".
Однако, это не остановило проект EDoc++, о котором и хотелось бы рассказать подробней. Он использует пропатченный GCC для анализа кода на ошибки при использовании исключений. Например, у нас есть код:
#include <iostream>
class C1{};
class C2{};

void foo() throw (C1)
{
throw C2();
};

class C
{
public:
~C()
{
foo();
}
};

int main()
{
C c;
}

В этом примере есть несколько ошибок, связанных с исключениями:
  • Не соблюдается спецификация в функции foo
  • Бросается исключение из деструктора
  • Исключение выходит за функцию main, что приводит к аварийному завершению программы
Попробуем проанализировать наш код с использованием EDoc++. Сначала EDoc++ надо собрать, потом проинициализировать окружение. В итоге мы получаем bash-оболочку с приглашением "EDOC ->". Я сохранил вышеприведенный С++ файл в ~/dev/sandbox/t.cpp. Компилируем(все дополнительные опции смотрите в документации к EDoc++):
EDOC -> g++ -fedoc-source -c ~/dev/sandbox/t.cpp -o ~/dev/sandbox/t.o
EDoc++ создает дополнительный файлик, который при опции -fedoc-source попадает в ~/dev/sandbox/t.cpp.edc. Показываем полученные результаты:
EDOC -> edoc --show-all --format simple ~/dev/sandbox/t.cpp.edc 
F: _GLOBAL__D__Z3foov()

F: _GLOBAL__I__Z3foov()

F: foo()

F: __static_initialization_and_destruction_0(int, int)

F: C::~C()

F: main()

ERROR(ECRASH_SPEC): Exception may propogate through restrictive specifier :The function: foo() can throw an exception of type: C2 that is not allowed by its specifier list: throws(C1)
Кажется, лучше сообщение об ошибке и не укажешь. Исправим ошибку - будем делать throw C1; вместо throw C2;. Перекомпилируем и посмотрим:
EDOC -> edoc --show-all --format simple ~/dev/sandbox/t.cpp.edc 
[...skip...]
ERROR(EMAIN_EXC): An exception may propogate out the main function. :The exception: C1 may propagate out the main function which may cause a program abort.

WARNING(WDESTR_EXC): An exception may propogate through a destructor. :Destructor: C::~C(), Exception: C1
Ага! Мы чуть-чуть не упустили исключение за пределы деструктора. Это ужасно. Уберём наконец throw С1; из foo для того чтобы проверить, как EDoc++ отреагирует на спецификацию без реального выбрасывания исключений:
EDOC -> edoc --show-all --format simple ~/dev/sandbox/t.cpp.edc
[...skip...]
Молчит. Т.е., он не принимает во внимание спецификации, если эти спецификации врут, что, в принципе, правильно.
EDoc++ обладает еще множеством достоинств: он поддерживает множество форматов вывода, множество способов хранения .edc информации, судя по отличной документации он правильно работает с указателями на функции, которые бросают исключения, и умеет находить ошибки даже в тех случаях, когда они делятся между несколькими модулями компиляции. В общем, отличный инструмент, спасибо создателям :)

Friday, January 9, 2009

О больших IDE

Я, как и многие другие программисты, начинал свою профессиональную карьеру с позиции Windows разработчика, так что довольно долго для меня создание ПО ассоциировалось с прекрасной IDE - MS Visual Studio. Поэтому, когда я постепенно перешёл на Linux, я первым делом начал искать замену этой среде. Тогда я не очень впечатлился ни одним из соответствующих Open Source решений, потом случайно попробовал Vim, Emacs, SciTE...
Не так давно узнал, что для NetBeans IDE появилась поддержка Python. Это стало поводом посмотреть на эту IDE поближе как на возможного конкурента лидеру - Eclipse+PyDev.

Установка

Как пользователь Gentoo Linux, попробовал поставить NetBeans из portage, но меня остановил некий гнусный пакет(kaffe), который никак не хотел собираться. Более того, NetBeans тянет за собой много зависимостей. Однако, если устанавливать сборку NetBeans с сайта, всё проходит отлично. Установка дополнительного плагина для Python тоже проблем не вызывает(Tools->Plugins). Субъективное очко в пользу Eclipse, который устанавливался из portage без каких-либо проблем

Общие впечатления

Занимает чуть меньше памяти, чем Eclipse, менее глючен и падуч. Однако есть небольшие лаги в GUI. Интерфейс проще, довольно удобен. В целом, очко в пользу NetBeans

Редактор

Редактор мне понравился. Довольно удобный, есть неплохой autocomplete(который в чём-то уступает Eclipse+PyDev, но кое-в-чём его и превосходит), с автоматической подсветкой ошибок и подсказками. Ничья

Управление проектом

Всё сделано довольно просто и удобно. Менее мощно, чем у Eclipse+PyDev, но я не могу сказать, что от этого хуже. Ничья

Запуск, отладка, консоль

Консоль не очень хороша у обоих представителей. А вот с запуском и отладкой - впереди Eclipse+PyDev. В NetBeans мне так и не получилось запустить отладить Django приложение. Возможно, стоит подождать обещанной поддержки Django. Очко в пользу Eclipse

Разное

Чем меня сразу заинтересовала среда NetBeans - так это поддержкой Mercurial out-of-the-box. Субъективное очко в пользу NetBeans

Выводы

Отличная заявка на победу от NetBeans, для такого молодого плагина - очень даже ничего. Но всё же пока не закончено. С другой стороны, Eclipse+PyDev - тоже не идеал, так что я всё также буду продолжать использовать SciTE/Vim/Emacs+pdb+pylint+ipython. И ждать обновлений для NetBeans, чтобы попробовать его снова.

Saturday, January 3, 2009

Ретроспектива-2008 и Перспектива-2009

Этим постом я хотел бы подытожить предыдущий год, а также по примеру Eric Florenzano и Lazy Pythonista рассказать о том, чем я собираюсь занять в будущем. Итак,

2008 год. Наконец-то...

  • ...этот блог стал превращаться из глупого эксперимента в нечто, куда мне интересно писать
  • ...я начал своё знакомство с Python, коим остался несказанно доволен
  • ...я начал своё знакомство с LISP, который меня впечатлил куда слабее
  • ...я попытался подружиться с Haskell, который не очень впечатлился мной :)
  • ...узнал о существовании великолепных Django и Twisted фреймворках
  • ...благодаря изменению области деятельности смог существенно расширить свой опыт в Linux и BSD системах
  • ...приобрел существенный опыт в VOIP
  • ...начал работу над бакалаврской работой, в связи с чем познакомился с потрясающей библиотекой OpenCV и инструментарием LaTeX
  • ...зарегистрировался в Juick, побывал на нескольких конференциях/встречах (Exception, IT Talk), открыл для себя прекрасную XMPP конференцию pythonua@conference.jabber.ru
  • ...начал участвовать в некоторых Open Source проектах

2009 год. Хотелось бы...

  • ...установить стабильный темп написания постов(~2 поста в месяц)
  • ...углубить уклон в сторону Python
  • ...переупрямить Haskell
  • ...не забывать про любимый мною С++. В демонстрационных целях хотелось бы попробовать написать простой и элегантный ORM
  • ...создать что-нибудь стоящее на Erlang
  • ...успешно защитить бакалаврскую работу. Я очень надеюсь, что получится выложить под GPL наработки, связанные с этой работой (TeX классы для пояснительной записки + программа)
  • ...расширить участие в Open Source проектах
  • ...попробовать себя в создании и продаже shareware софта
  • ...начать несколько небольших веб-проектов для души
Всех с прошедшими и наступающими праздниками! Я буду очень стараться, чтобы этот блог в 2009м году был интереснее, чем в прошедшем.