Kate

В своих поисках "моего редактора" остановился на Kate/KWrite (на Википедии). NumPad наконец-то заработал как я люблю :-). Правда я уже переучился удалять строки клавишей F8, приходится обратно переучиваться на Ctrl+Y, это действие можно переназначить к KWrite, но вот некоторые другие, например сохранение или поиск - нет. KWrite требует некоторое время на свою загрузку (это неудобно), я привык работать так, что открываю некоторый текст/код лишь на несколько секунд для, например, копирования в буфер обмена 1, 2 строк (на этом фоне время требуемое на загрузку редактора ощутимо некомфортно). Хотя этот редактор и является меньшим из зол, тем не менее он не лишен некоторых маленьких и традиционных проблем. Традиционных для самой системы на Linux (Debian на Gnome, в моем случае), как я пологаю. Например, нормально не работает буфер обмена. Т.е., если ты закрыл редактор из которого ты копируешь текст, то ты не сможешь вставить этот текст в другом экземпляре этого приложения или любом другом приложении (текст из буфера обмена теряется). В общем, такое безобразие я наблюдал и в других приложениях. Еще одна мелкая, но неприятная бяка заключается в том, что при закрытии приложения, если документ был изменен, вылазит диалог подтверждения сохранения изменений, но фокус этот диалог не получает, он остается на главном окне редактора. Приходится использовать Alt+Tab, что бы вернуться к диалогу и выбрать кнопку. Я редко пользуюсь мышой, хотя так было бы проще разобраться с диалогом.

p.s. Наконец-то поправили редактор в Blogger'е. При выделении текста в стиле Shift+Ctrl+стрелки, окно редактора исчезало и вызывался предпосмотр, немало нервов он мне потрепал (я работаю в Opera). Теперь буду писать чаще :-).

Windows vs. Linux

Сегодня снес винду (Windows 2000 Professional). Приятно. Не потому что винда, а потому что мне нравится её удалять.
Причины банальные, хотя появились новые аргументы. Во первых эта редиска опять обрасла непонятно чем и стала очень долго грузиться. Собственно уже год как её загрузка стала происходить невыносимо долго. Так же возникли проблемы с некоторым софтом, причины которых мне не понятны и оказались не устранимы переустановкой этого софта. Во первых, перестали собирать бинарные дистрибутивы Python приложений. Сборку я осуществляю py2exe и вообщем то к самому процессу сборки нареканий нет. Но вот при запуске полученного дистрибутива выдается ошибка, точно не помню, что то в pythondll, то ли не удается загрузить, то ли в нем какой то сбой, вспомню допишу. Библиотека python24.dll лежит тут же и по размеру один в один та же что и библиотека, которая находится в папке самого Python. Интересно то что после замены этой библиотеки, той что лежит в папке Python, дистрибутив начинает нормально работать, вроде бы (не помню деталей :-). Во вторых, возникла проблема с VMWare, этот зверь запускался раз через раз. Гостевая система валилась при загрузке биоса. Была закономерность - чем меньше устройств для системы настроено тем больше вероятность что эта система запустится. Кажется была 100% что система будет работать при отсутствии жестких дисков и оптических устройств. Ну и в третьих. То что меня добило окончательно и я то почему я последнюю неделю работаю под линухом (Debian Etch) и почему я с удовольствием сношу винду :-). После загрузки системы в течении нескольких минут сетевые устройства не работали. Они нормально включались, выключались сколько угодно раз. Но ни один узел в сети не был доступен. Вообще никак.
Сейчас я несчастный пользователь линуха. Очень не комфортно работать. Не хватает Far'а. Для несведующих, это не только синие панельки. Настроить mc под себя мне не удалось, найти редактор (я перебрал, наверное, десятка два) так же не удалось. Потихоньку начал разбираться в линуховом терминале (меня больше консольные приложения интересуют) и начал понимать, что это, вроде как :-), проблемы самого терминала, а не консольных приложений. Элементарный пример. Для навигации по тексту в редакторе я использую клавишы курсора, PgUp, PgDn, Home, End расположенные на NumPad'е. Половина редакторов на отрез отказывается работать с NumPad :-). (Сильно долго в настройках я конечно же не ковырялся.) Так же я использую Ctrl + стрелки для перемещения от слова к слову. Из оставшихся половина отказывается так работать. Для маркировки текста я привык удерживать Shift и менять свою привычку не намерян. Еще ряд редакторов отваливаются. Ну и на последок при выделении текста (Shift) я перемещаюсь по нему удерживая Ctrl + NumPad стрелки (т.е. маркирую одно или несколько слов). Последний тест никто не смог пройти. Так же у редакторов проблемы с переключением кодировки. Я работаю с KOI8-R, UT8, CP866, CP1251 и рядом других. Вообщем, я очень сильно расстроен положением дел в линухе.
Пойду переустанавливать винду на QEmu :-).

Pyglet & Spineless

Натолкнулся сегодня на библиотеку pyglet. Это библиотека для работы с графикой (в том числе поддерживается работа с OpenGL) и мультимедиа в общем. Попробовал под виндой - примеры работают. Не смейтесь :-). То что работают хотя бы примеры это уже о чем то да говорит, вот последнии версии Spineless (те версии что доступны через SVN) вообще не работоспособны на мой платформе (win2k, ati). К тому же, похоже, Spineless основательно заброшен, хотя поначалу проект выглядел очень перспективным для проектов, требующих, легкие графические реализации. Сайт Spineless за последние пару лет несколько раз переезжал, была какая то активность на сайте некоторое время назад, сейчас же и сайта как такового нет.

PyProcessing

PyProcessing (или просто Processing), отличный инструмент для создания решений, требующих выполнения в многих процессах. Для синхронизации этих процессов существуют такие, всем прекрасно известные по модулю threading, объекты как Lock, Event, Condition и другие, а так же Queue и другие объекты. Так как большую часть времени я работаю под виндой (w2k, что бы быть точным) и когда я натолкнулся на этот пакет была загружена имена эта операционка, естественно все свои тесты я стал проводить под виндой, а через несколько дней появился и "боевой" проект, который я так же стал выполнять и тестировать под виндой (не смотря на то что предполагалось что он будет крутиться на FreeBSD).
Каково же было мое разочарование, когда мне не удалось, даже через час мучений, запустить этот пакет под FreeBSD. Сначала не хватало библиотеки librt, подставил libc, вроде при сборке проглатился. После чего оказалось что не установлены какие-то системные конфигурации (SC_SEMAPHORES и SC_MESSAGE_PASSING), что это такое я не знаю :-(. В общем, поняв, что завести PyProcessing на фрюхе мне не удастся, использовал пакет processing.dummy (разница только в том что dummy создает и синхронизирует потоки, а не процессы). Но тут синхронизация оказалась никудышной, как я понял проблема в модуле Queue в дистрибутиве самого Python 2.4. Сразу два или больше потока могли забрать одни и те же данные из Queue. Короче забил на FreeBSD.
Решил попробовать код на Gentoo (не знаю версию). Собрался пакет без проблем, но работать отказывался ссылаясь на отсутствие некоторых функций (как я понял по сообщению об ошибке) в нативном модуле _processing.so. Короче забил на Gentoo.
Оставалась Debian Etch (это мой домашний десктоп). Тут все прошло идеально, сборка, работа пакета, по используемыми мной компонентами не вызвала никаких нареканий (другие компоненты, например, Condition, SharedArray и т.д. не проверял).
Вот такая вот история. Можно сделать вывод что пакет пусть и очень хорош и полезен, но очень сырой. Использовать его надо с большой осторожностью, так как вероятность того, что он где то не заведется - велика.

Сайт для FreeDune

Сегодня запущен сайт www.freedune.org. Это сайт игрового проекта FreeDune, который "мусолится" :-) мной и другими разработчиками уже пару лет. Сайт появился только сейчас. До этого, для ведения проекта и поддержания заинтересованных в разработке интернетчиков, использовался ресурс www.gamedev.ru и форум на моем сайте, который давно канул в Лету. Теперь информация о проекте будет публиковаться на официальном сайте, да и проект сдвинется с мертвой точки.

Neweb

Есть и еще новость на сегодня.
Значительно обновил код framework'а (имя neweb). Выложил его на сайт. Пока комментировать и открывать код не буду, так как он очень сырой, но к концу этого года, может раньше, обязательно это сделаю. Отмечу пока, что остановился на концепции "нодов" (nodes, узлов), основная идея не сформирована, сказать что-то подробнее не могу. Разве то что ноды поставлены не во главе решения всех задач, а как частный инструмент, который весьма удобен при формировании структуры сайта.

KviD

Сегодня у меня хорошее настроение :-).
Запустился видеоряд (m4v) xvid и некоторых версий divx проигрывателя под KolibriOS, собственно еще конечно не проигрывателя, а только кода, способного крутить видеопоток с частотой ~25 кадров в секунду. Основная радость, тем не менее, порождена не тем что эта штука все же заработала, а тем что ряд проблем решение части которых не было очевидно (да и вообще не предвидилось), а другие были напротив очевидно сложными и продолжительными в разработке. Но. Получилось так что в первом случае мне повезло и вопросы решились чуть ли не сами по собой, а во втором случае - ошибся с прогнозами и все что нужно я сделал в течении суток.
Сейчас этот примитивный проигрыватель и еще немного мусора лежит здесь. Позже, когда сделаю официальный релиз, я выложу полноценную версию в индивидуальном месте хранения :-).

Косяк с Entity в Pygext

Если копать глубже то, наверное, не совсем в Entity, но копать мне пока некогда. Ошибка заключается в том что, если pygext.gl.director.entities.Entity не прикручен к какому либо слою pygext.gl.director.scene.Layer, то при выходе из программы возникает гнусная ошибка, цитирую:

Fatal Python error: (pygame parachute) Segmentation Fault

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Эта ошибка будет возникать стабильно даже в самых элементарных приложениях. Дело в том, что хотя бы один Entity будет создаваться всегда. Этот Entity создается в pygext.gl.mouse.Mouse и является изображением курсора по умолчанию.

p.s. В будущем постараюсь больше времени уделять PyGame, Pygext и просто программированию графики на Python.