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.