TDD's revenge

Попробовал себя в "рисовании" комиксов. То, что получилось - ниже:

А теперь о серьёзном. Я сейчас собираюсь перевести RSS на feedburner.google.com. Надеюсь, проблем не возникнет и все подписчики просто ничего не почувствуют. Однако, если вы за своим RSS-агрегатором замечали проблемы с обработкой редиректов или неперевариванием feedburner - пишите, будем разбираться :)

Знакомьтесь: Geany!

Введение

Я уже писал, что мне очень нравится редактор SciTE и поэтому я его постоянно использую, например, при программировании на Python. Однако в GTK версии есть несколько недостатков:

• Открытие большого числа вкладок невозможно - не работает прокрутка и multiline
• Глюки с юникодом - если написать \что-то при редактировании TeX документа, получим несуразные символы. Эти же несуразные неудаляемые символы также иногда появляются в строке поиска
• Нет нормальной интеграции с shell. В итоге для простейшей проверки конструкции в ipython приходится переключаться на терминал

Естественно, можно было бы подправить это в самом SciTE, но зачем, если всё уже сделано? Представляю вам Geany - простейший редактор с замашками IDE(которые, в принципе, не мешают :) ) основанный на том же движке, что и SciTE - на Scintilla.

На этом скриншоте он уже немного подконфигурирован для моего удобства. Возможности Geany:

• Подсветка, фолдинг - аналогично SciTE
• Нормальные табы
• Поддержка VTE
• Symbol explorer
• Плагины(в числе встроенных FileBrowser, SplitWindow и т.д.)
• Автодополнение по символам(неплохое, но для Python хотелось бы лучше. Geany - Open Source, так что возможно это желание будет реализовано)
• Автозакрытие тегов
• Сессии

Более подробно хотелось бы остановится на поддержке VTE. Благодаря ей в Geany есть полноценный терминал! Насколько это удобно можно понять, прочитав следующий раздел.

Конфигурирование

В этом разделе я хочу дать описание моего рабочего окружения в Geany. Оно не блещет уникальностью, но весьма удобно. Конечный внешний вид - на скриншоте выше. По пунктам:

1. Ставим. Я просто выполнил "emerge -av geany". Думаю, в остальных Linux дистрибутивах его можно поставить сходным же образом. Для Windows пользователей - есть инсталляторы
2. Убираем Sidebar, дабы сэкономить площадь
3. Задаем комбинации клавиш для удобного перемещения по табам
4. Настраиваем терминал - самая интересная часть. Я выбрал себе темную темку и запустил внутри screen - в итоге я могу переключаться между логами сервера, ipython и дополнительными консолями. Для меня терминал в Geany - самый важный инструмент. В нём я работаю с git и hg, в нём я отлаживаю приложение, в нём же я и лажу по файлам("geany file_name" открывает файл в новой вкладке). Таким образом, терминал мне заменяет File Browser, Debugger и VCS Inegration
5. Настраиваем шрифт, остальные комбинации клавиш и интерфейс по вкусу

У меня в screen не заработала клавиша Backspace, пришлось биндить. Ниже - кусок конфигурационного файла screen (.screenrc), который делает screen юзабльным:

bindkey -d ^@ stuff ^? # пофикс backspace
hardstatus on
hardstatus alwayslastline
hardstatus string "%{Gk}| %-w%{+u}%n %t%{-}%+w |%=(%l) %d/%m %c"

До сих пор нормально не работает скролл на мышке, прокрутка вверх генерит "^[[A". Если у кого-то есть уже решение - поделитесь :) Если разберусь сам - проапдейчу.

Выводы

Geany - отличный редактор, полностью покрывающий мои запросы. На данный момент я использую его для Python разработки и редактирования TeX файлов. Для С++ же я предпочитаю IDE Anjuta, хоть Geany можно использовать и здесь.

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, предлагаю посмотреть вот сюда

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 информации, судя по отличной документации он правильно работает с указателями на функции, которые бросают исключения, и умеет находить ошибки даже в тех случаях, когда они делятся между несколькими модулями компиляции. В общем, отличный инструмент, спасибо создателям :)