Андрей Светлов
Как связаться с ребятами из divmod.org?
То, что я доделал к их epsilon.modal у них же помечено как todo: fix this bug.
В процессе дальнейшей работы мы скорее всего еще несколько расширим функциональность (нам важны конечные автоматы, а у них почти-почти то).
Я не прочь отправить им патч к модулю и тесту - авось включат.
Кстати, их тест весь модуль не покрывал - была нестыковочка.
Вот только на их trac guest новый тикет создать не может. А почтового адреса, чтобы послать письмо, я так и не нашел.
Что делать?

Хм. С полгода назад я регистрировался на их trac и открывал тикеты.

Если хочешь написать разработчикам - пиши Жан-Полю Кальдерону (exarkun at twistedmatrix.com), но он весьма… эээ… своеобразный человек, так что лучше открывай тикет, аттач патч и юнит-тест, ставь приоритет тикета highest, в ключевых словах указывай review.

P.S. Это ничего, что все ссылки на Twisted Matrix; в Divmod работают ровно те же люди, так что и email, и dev process у них одинаковы.

P.P.S. Ну или в IRC

Андрей Светлов
aspn - простенько до неудобства. У меня каждое состояние - довольно большая вещь, скорее не атом, а режим работы программы. Так удобнее. Иначе состояний появляется бесчетное множество и прописывать переходы между ними становится затруднительно.

То, что aspn пример прост до безобразия – я согласен и сразу говорил. Более того, он немного заточен под задачи парсинга.

Однако, не вижу противоречий между простым механизмом, обеспечивающим переходы и большими состояниями. Может я конечно что-то не понимаю, но поскольку у вас уже все работает – то это ХОРОШО.
Спасибо вам, узнал новые готовые имплементации КА для питона. :-)

Вот еще пара моментов, относящихся к автоматам.

1) Для меня автомат – это переменная, показывающая состояние, плюс некая логика, которая обеспечивает реагирование на события. Т.е. как бы в терминах сиплюсизма: описание автомата – это некий класс, а конкретный автомат – это экземпляр класса. Тогда можно (по идее) работать с несколькими однотипными автоматами одновременно, используя ссылку на переменную состояния в коде. Но… (см. ниже)

2) Почему-то почти всегда подразумевается, что вся программа – это один автомат, либо это совокупность параллельно работающих разных автоматов. И никогда не рассматривается случай (по крайней мере мне не попадалось) в явном виде: группа однотипных автоматов, работающих параллельно. Например, у меня игра с несколькими игроками. Есть автомат, отвечающий за логику игры, и группа автоматов, отвечающих за состояние игроков. В упоминавшемся IAR Visual State я не нашел способа создать массив однотипных автоматов. Это главная причина, почему я его не использую. А вообще, как с этим жить в других либах (например, в epsilon.modal)? Что вобще диктует на эту тему ваш здравый смысл?

Алексанр, можно на “ты”? Мне так удобней.

epsilon.modal - всего лишь класс, описывающий автомат. Наследуйся от него и делай свои автоматы. Размножай их, вкладывай друг в друга - все можно. В терминах игры это будет: автомат логики игры, по автомату на игрока, по автомату на компьютерного персонажа (NPC) и т.д. (автоматы на персонажа так и стремятся к вложенности). Это обычные экземпляры классов с мутирующим поведением. Не за счет if/switch, а за счет изменения интерфейса.
Данные общие для всего экземпляра, а методы переключаются на лету при смене состояния. При этом, как ты заметил, есть __enter__, __exit__. И, что немаловажно для меня, набор методов тоже мутирует в зависимости от состояния. Имена этих методов - входные сигналы. При этом к каждому цепляется список параметров (для каждого метода разный). А если из состояния нет нужного перехода - нет и нужного метода. Хорошая трансляция из UML в код.

IAR рассчитан на embedded programming. Когда я писал под Atmel ATMega контроллеры (три года занимался) - постоянно делал простые конечные автоматы. Прописывал все руками, и совмещал несколько в параллельной работе (несколько таймеров, АЦП и входы, изменение сигнала на которых позволяло возбуждать прерывание сильно помогали). Но только при специфицеском кодировании. Выход из узких микропроцессорных рамок позволил применять подход гораздо шире.

Помимо gamedev автоматы очень полезны в internet клиентах . Сеть - ненадежная штука, сообщения приходят негарантированно (возможны отказы) и с непостоянной задержкой. А если ты при этом работаешь с несколькими серверыми (лицензий, биллинга, игровым)?
Без автоматов очень трудно.

Если нужно, готов выложить примеры

Андрей Светлов
Алексанр, можно на “ты”? Мне так удобней.

Да, конечно.

Андрей Светлов
epsilon.modal - всего лишь класс, описывающий автомат. Наследуйся от него и делай свои автоматы. Размножай их, вкладывай друг в друга - все можно. В терминах игры это будет: автомат логики игры, по автомату на игрока, по автомату на компьютерного персонажа (NPC) и т.д. (автоматы на персонажа так и стремятся к вложенности). Это обычные экземпляры классов с мутирующим поведением. Не за счет if/switch, а за счет изменения интерфейса.

Я как раз думал примерно в таком направлении.

Андрей Светлов
Если нужно, готов выложить примеры

Может быть удастся немного пообщаться на семинаре (после)завтра.

Буду рад. На прошлом так на тебя насели по вопросам о Bazaar, что было не подступиться

Андрей Светлов
… Это обычные экземпляры классов с мутирующим поведением. Не за счет if/switch, а за счет изменения интерфейса.
Данные общие для всего экземпляра, а методы переключаются на лету при смене состояния. При этом, как ты заметил, есть __enter__, __exit__. И, что немаловажно для меня, набор методов тоже мутирует в зависимости от состояния. Имена этих методов - входные сигналы. При этом к каждому цепляется список параметров (для каждого метода разный). А если из состояния нет нужного перехода - нет и нужного метода. Хорошая трансляция из UML в код.

Перечитал еще раз внимательно. Все правильно. Вот эта фраза ключевая собственно:

Данные общие для всего экземпляра, а методы переключаются на лету при смене состояния

Наконец-то понял как это удобно реализовать и на Си: набор методов сделать таблицей и переключать указатель на таблицу в зависимости от состояний. Тогда можно отказаться от бесконечных switch. Но тут точно придется искать пути для автоматической генерации кода таких таблиц.

Есть еще несколько вопросов, хотелось бы обсудить.
/me Попробую сформулировать в следующем ответе.

Да, ты хорошо уловил суть. И структура с указателями на функции - хорошее решение для С. В питоне это создается автоматически при генерации класса.
Если опишешь DSL, то написать генератор, кажется, не сложно и не долго.