Идея написания библиотеки работы с конечными автоматами на Nemerle пришла давно, вот здесь началась развиваться тема на форуме: http://rsdn.ru/forum/nemerle/3716028.aspx
Все это время я потихоньку развивал проект, сейчас библиотека вошла в рабочую фазу, реализованы основные функции семантики автоматов UML. С выходом Nemerle.Peg добавились новые возможности создания языка DSL. Подобные библиотеки есть во всех языках, например boost::statechart в C++, Sanford.StateMachineToolkit, SimpleStateMachine — C# State Machine Library — Boo and Rhino DSL, StaMa, Stateless. Хотелось бы иметь и такую же в Nemerle, плюсы от использования Nemerle очевидны, это удобный разбор dsl языка описания автомата (в аналогичных библиотеках как правило неудобно создавать сами диаграммы), анализ на этапе компиляции, генерация высокоэффективного кода, практически полное отсутствие динамических конструкций ускоряющие код. Идея хорошо себя оправдала, я тестировал аналогичные автоматы Sanford.StateMachineToolkit и моей библиотеки, разница в скорости в плюс библиотеки на Nemerle была в десятки раз. Все это говорит о том что аналогов подобной библиотеки в мире нет, остальные библиотеки проигрывают в скорости и удобстве описания автомата, все это дает причину опубликовать библиотеку для широкого использования. Хотел спросить есть ли у сообщества согласие на хостинг библиотеки в snippets, я хотел назвать Nemerle.Statechart.
Текущие возможности библиотеки таковы:
— язык описания диаграммы состояний представляет собой текстовый dsl вида
state Parked
{
EngineStarted => IdleInNeutral;
}
state IdleInNeutral
{
EngineKilled => Parked;
GearEngaged => IdleInGear;
}
state IdleInGear
{
GearDisengaged => IdleInNeutral;
GasApplied => RacingAlong;
}
state RacingAlong
{
BrakeApplied => IdleInGear;
CarCrashedIntoTree => CarDestroyed;
}
state CarDestroyed
{
}
Здесь изображен плоский автомат, библиотека включает большинство из возможностей uml автоматов, например такой автомат:
можно дополнить сторожевыми условиями, входными выходными действиями и получить в конечном счете что то типа:
[statechart(<#
flags : auto_initial, transition_completed_events debug;
state A
{
(H) => D;
$>;
$<;
b => E;
f => D; // cross
state B
{
0 / init_action => C;
(H*) => E;
$>;
$<;
b => D; // cross
d => D;
f [test_guard1] / f_action =>@;
k => A;
c => E;
_ => D;
state C
{
$>;
a / A;
$<;
b [test_guard2] => E;
m =>@;
}
state E
{
$>;
$<;
i => D;
j => A;
o /final_action1 => final;
}
}
state D
{
$>;
$<;
e => B;
n => B.H;
}
g => H;
}
#>
)]
class PathCoverFsm
{
//[GuardFor(test_guard1)]
test_guard1() : bool// {get;set;}
{
true
}
test_guard2 : bool// {get;set;}
{
get
{
true
}
}
test_guard3 : bool// {get;set;}
{
get
{
true
}
}
}
}
вся эта штука потом парсится, анализируется и в конечном счете получается код класса содержащие определения состояний, события обработчики для действий, входных, выходных и при переходах и это можно использовать в другом коде. Сама обработка событий основывается на виртуальных методах.
весь список возможностей на текущий день:
— парсинг метаттрибута текстового описания автомата
— анализ путей переходов
— генерация представления автомата в класс
— анализ и генерация истории shallow и deep history
— переходы по умолчанию из исторических состояний
— сторожевые условия
— встраиваемые члены сторожевых условий
— конечные состояния (final)
— начальные состояния (initial)
— действия при входе и выходе
— сброс истории при переходе в конечное состояние (check spec)
— приоритет переходов вложенных классов
— внутренние переходы
еще не достает до полноты:
-terminal pseudostate
-do activity
-choice
-junction
-fork and join pseudostates
-orthogonal regions
-local and external transitions
-deffered events
Что скажет сообщество на сей творческий порыв
от макросов до вариантов
и массой всяких преимуществ
благодаря nemerle-братству
программеров жизнь стала лучше
Re: библиотека автоматов состояний Nemerle.Statechart
Здравствуйте, CodingUnit, Вы писали:
CU>Хотел спросить есть ли у сообщества согласие на хостинг библиотеки в snippets, я хотел назвать Nemerle.Statechart.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CodingUnit, Вы писали:
CU>>Хотел спросить есть ли у сообщества согласие на хостинг библиотеки в snippets, я хотел назвать Nemerle.Statechart.
VD>Все будут только "за".
VD>Только делать теперь это нужно через создание fork-а и размещения пул-реквеста на github. Тут рядом это все описано. Почитай, плиз. VD>http://www.rsdn.ru/forum/nemerle/4336310.1.aspx
CU>>еще не достает до полноты: CU>> -terminal pseudostate CU>> -do activity CU>> -choice CU>> -junction CU>> -fork and join pseudostates CU>> -orthogonal regions CU>> -local and external transitions CU>> -deffered events
VD>Еще бы понимать что все это значит .
Это элементы семантики UML автомата, все это я разъясню в процессе описания библиотеки, скажу вкратце,
что будет в библиотеке:
текущие возможности:
— создание иерархических автоматов UML, с поддержкой входных, выходных действий, начальные, конечные, исторические состояния
будущие возможности из описанных выше:
— terminal pseudo state — терминальное состояние при котором автомат должен завершатся
— do activity это деятельность которую автомат должен осуществлять в состоянии, то есть некоторый поток который должен работать
— orthogonal regions — ортогональные области, это области в которых автомат пребывает одновременно, то есть параллельно в двух и более состояниях, ака параллелизм, моделируется с помощью многопоточности
— junction — сложный переход, в котором может быть одно событие но на пути много разных разветвлений в разные состояния по разным сторожевыми условиям
— fork and join это псевдосостояния помогающие разделить поток на несколько параллельных, join синхронизирует потоки
— local and external это разные виды переходов, local не вызывает выход из состояния при переходе, подразумевается переход в подсостояние
— deffered events — отложенные события, события которые должны откладываться до лучших времен
VD>Скажет — давай! Только к этому делу еще нужно качественное описание и побольше примеров.
Описание постараюсь набросать, начну с некоторого начального описания библиотеки на примерах, которое потом внесу в документацию библиотеки.
Библиотека Nemerle.Statechart это ответ сообщества Nemerle на запрос автоматного, реактивного и событийного программирования, в ней предполагается внести перспективные функции, возможные с помощью системы метапрограммирования Nemerle. Сама библиотека представлена в виде макроса, который делится на три части:
— парсер (основанный на Nemerle.Peg) который обеспечивает преобразование текстового описания автомата в дерево
— анализ дерева автомата, это статический анализ, переходов, действий, проверка на правильность описания, обработка и создания структур для генерации
— генерация автомата в запускаемый код, в виде класса, в котором представлены подклассы состояний, переменные текущего состояния, историй, событий действий которые срабатывают при входах, выходах из состояний и переходах
Для чего все это нужно?
Автоматы состояний — это поведенческая абстракция, которая помогает разделить общее поведение системы или класса на некоторое множество разных состояний, соединенных переходами и реагирующими на события. Как известно новейшие языки и платформы делают шаги в сторону реактивности и событийности, введение в язык конструкции делегатов, событий, помогает строить поведение классов с помощью концепции событийного программирования.
Цитата из википедии:
Событи́йно-ориенти́рованное программи́рование (англ. event-driven programming; в дальнейшем СОП) — парадигма программирования, в которой выполнение программы определяется событиями — действиями пользователя (клавиатура, мышь), сообщениями других программ и потоков, событиями операционной системы (например, поступлением сетевого пакета).
Как правило, в реальных задачах оказывается недопустимым длительное выполнение обработчика события, поскольку при этом программа не может реагировать на другие события. В связи с этим при написании событийно-ориентированных программ часто применяют автоматное программирование.
Событийно-ориентированное программирование, как правило, применяется в трех случаях:
при построении пользовательских интерфейсов (в том числе графических);
при создании серверных приложений в случае, если по тем или иным причинам нежелательно порождение обслуживающих процессов;
при программировании игр, в которых осуществляется управление множеством объектов.
Применение и плюсы автоматов состояний широко известны, такой подход позволяет строить поведение системы визуально, на практике я столкнулся с тем что гору if else конструкций можно преобразовать в несколько легко представляемых состояний, разделенных переходами, которые визуально легко представляются и переносятся в код, при этом код понятен, и чист, легко расширяется, обдумывается и отлаживается из за того что описание автомата легко представляется в виде диаграммы.
В автоматном программировании, поведение системы или класса может легко расширяться, за счет добавления состояний или переходов, а не модификации логики, в какой то мере это часто лучше рекурсии и даже удобных match конструкций.
Вот здесь интересные статьи по системам работающим по событиям: http://www.excode.ru/art6033p2.html http://www.ict.edu.ru/vconf/files/3195.rtf здесь
В процессе жизненного цикла система или класс системы, может менять свое состояние, как реакция на внешние события, в каждом состоянии объект себя ведет по разному. Автоматы состояний можно использовать при моделировании поведения графического интерфейса, как реакции на действия пользователя, различные приложения с множеством разных режимов работы в которых система ведет себя по разному, моделирование объектов реального мира, например в играх солдат может быть в нескольких состояниях: стоит, бежит, лежит, стреляет, оружие достано, говорит, спит, целится в каждом из этих состояний он меняет свой внешний вид (что может осуществлятся при входе в это состояние), и по другому реагирует на внешние события, например может споткнутся если бежит, на какие то события он может не реагировать в определенных состояниях, а в каких то наоборот может, например стреляет в ответ на выстрел, что не может делать если оружие не достано или если он спит.
Разные потоки workflow, цикл жизни объекта, разные протоколы легко реализуются на автоматах, причем эта библиотека с легкостью даст возможность автоматизировать классы, и использовать в системах реального времени, где требуется высокая вычислительная скорость, поскольку за счет статического анализа, изменения состояний и переходы осуществляются очень быстро, как правило это сводится к присваиванию полю класса, нескольких вызовов и запуска событий.
Практически любая сложная логика может быть описана автоматами, автоматы начали применятся и исследоваться с середины прошлого века, в разных научных кругах, отечественных и зарубежныхх разработках.
Сначала применялись различные подходы такие как детерменированные и недетерменированные автоматы, автоматы Мили и Мура, затем Д.Харел разработал более сложную и полную семантику автоматов, иерархических автоматов, в которых состояния группировались на основе принципа Или и И, Или когда автомат находится в одном из состояний, И когда в нескольких (параллельных). Введены разные теории семантики автоматов, которые были объеденены в стандарте UML.
Я вкратце опишу диаграммы и их составляющие, для тех кто не знаком с диаграммами состояний UML, а рассмотрю их интерпретацию в языке описания автоматов в библиотеке и представлю несколько примеров.
вся диаграмма представляет собой ориентированный граф, вершинами которого являются состояния, а переходы дугами.
Диаграмма состоит из композитных состояний, которые включают другие подсостояния, с одним возможно неявным верхним состоянием.
Когда состояние находится во внутреннем состоянии, то активны и все его родительские состояния.
— черный кружок со стрелкой есть начальное состояние, когда автомат начинает работу он входит в верхнее начальное состояние, переход из которого осуществляется в одно из подсостояний, когда автомат входит в композитное состояние через переход, то он входит в его начальное состояние, в которое осуществляется переход из начального состояния
Вот диаграмма состояний телефона:
Система телефона находится в одном из следующих состояний:
1) Сначала система входит в состояние Idle, то есть телефон ожидает и пребывает в нем
2) Когда наступает событие lift receiver то есть поднята трубка, осуществляется переход из состояния Idle в состояние Active при этом сначала вызывается действие get dial tone — получить сигнал выдачи гудка (?),
3) При входе в состояние Active, переход осуществлятся сразу в его начальное псевдосостояние, из которого сразу же система переходит в состояние Dial Tone то есть проигрывание гудка
4) do / play dial tone — обозначает деятельность внутри состояния, то есть состояние осуществляет активность проигрывает гудок
5) при наступлении события after 15 sec, то есть после 15 секунд, телефон переходит в состояние Time-out в котором постоянно проигрывает сообщение, из этого состояния он может выйти только если положена трубка caller hangs up переход из родительского состояния Active, то есть принадлежащий ко всем внутренним состояниям, если автомат находится в любом из подсостояний Active то событие caller hangs up выводит из него автомат и переводит в состояние Idle то есть если кладем трубку то телефон ожидает
6) Далее последовательно автомат переходит по соотв. событиям состояния Connecting (соединения), Ringing (звонит), Busy, Talking
Дальнейшее обсуждение диаграммы состояний я думаю лишне, должна быть уже понятна концепция, весь этот автомат текстово можно представить в следующем виде (в будущем надеюсь сделать перевод графического представления из редактора автоматически в автомат):
// макроаттрибут statechart
[statechart(<#
flags : auto_initial; // начальные флаги автомата
// определяем состояние Idle
state Idle
{
lift_receiver / get_dial_tone => Active; // переход: событие / действие => конечное состояние
}
// определяем состояние Active
state Active
{
caller_hangs_up / disconnect => Idle; //
terminate => $0; // переход в конечное состояние
state DialTone
{
do / play_dial_tone; // внутренняя активность (пока не поддерживается)
after15_sec => TimeOut;
dial_digit => Dialing;
}
state TimeOut
{
}
state Dialing
{
dial_digit [incomplete] => @; // переход со сторожевым условием в себя
after15_sec => TimeOut;
dial_digit [invalid] => Invalid;
dial_digit [valid] / connect => Connecting;
}
state Invalid
{
do / playMessage;
}
state Connecting
{
connected => Ringing;
busy => Busy;
}
state Busy
{
do / play_busy_tone;
}
state Ringing
{
do / play_ringing_tone;
callee_answers / enable_speech => Talking;
}
state Talking
{
callee_hangs_up => Pinned;
}
state Pinned
{
callee_answers => Talking;
}
}
#>)
class PhoneFsm
{
}
Далее после компиляции макрос должен проанализировать автомат и создать методы, он создаст действия при переходах, do хотя пока и не поддерживается, его можно заменить входными действиям, можно описать ключевые слова используемые в языке:
state Имя // состояние
{
entry / action; // действие при входе
exit / action2; // действие при выходе
_ =>
(H*) => Имя2;// историческое состояние, автомат запоминает последнее состояние при выходе, переход в это состояние возвращает запомненное состояние
// * означает Deep History - глубокая история которая запоминает подсостояние на любой глубине вложенности
// стрелочка означает переход по умолчанию из исторического состояния, если нет истории осуществляется он
state Имя2
{
$>; // входное действие (альтернативный синтаксис) для него создается событие внутри класса,
// к которому можно присоединить обработчик запускающийся при входе в состояние
$<; // выходное действие
trigger [guard] / action => State3; // событие [сторожевое условия] / действие при переходе => Состояние
// сторожевые условия вычисляются при наступлении события, если оно истинно значит переход сработает
(H) // историческое состояние Shallow - запоминает верхнее подсостояние этого состояния
evt => final; // переход в конечное состояние, при этом композитное состояние завершается
}
}
state State3
{
exit
{
Something2 // действие при входе 1
Something3 // действие при входе 2
} // другой синтаксис для входного действия
A => Имя.H; // переход в историческое состояние
}
Тут я описал основной синтаксис, оставшуюся семантику UML думаю со временем включу, парсер пока не распознает сложные и ошибки и выдает обычные сообщения которые в него заложены, синтаксис расширяем если у кого есть мысли как его улучшить, анализатор и генератор тоже если будут найдены баги или если будут советы по улучшению архитектуры можно поправить. На этом сообщение завершаю, после рассмотрю остальные аспект и дам больше примеров. Я сделал пулл реквест библиотеки, когда она будет добавлена в git ее можно скачать и попробовать. Буду рад любым комментариям и вопросам.
от макросов до вариантов
и массой всяких преимуществ
благодаря nemerle-братству
программеров жизнь стала лучше
Здравствуйте, CodingUnit, Вы писали:
CU>Хотел спросить есть ли у сообщества согласие на хостинг библиотеки в snippets, я хотел назвать Nemerle.Statechart.
Вот я сейчас крамолу скажу, но, имхо, лучше ее сделать отдельным проектом. Проекты в снипетах просто забываются. При случае, даже некуда пальцем ткнуть, сказав вот есть проект на немерле (ибо многие небезосновательно считают снипеты просто пачкой недоделанных сэмплов, в которых сам черт ногу сломит).
А так у нее будет собственный репо, со своим Readme.md, своим хозяином и возможностью ее форкать, создавать issues и видеть, что ее кто-то развивает. Или не развивает. Но можно легко скачать ее, собрать и посмотреть. Отдельный собственный проект провоцирует на написание какой-никакой доки лежащей прямо в проекте. Ее можно добавить в снипеты как submodule и никуда она не потеряется. Да и вообще надо больше проектов на nemerle, хороших и разных, чтобы интересующиеся могли их найти на гитхабе по языку. О ней можно рассказать в блоге и дать ссылку на репо, а не папку в одном большом каталоге репо компилятора. В конце концов, глядя на нее человек может заинтересоваться языком, а глядеть на нее в репозитарии немерла левый человек просто не будет.
Вобщем я знаю, Влад не одобрит, но решать тебе. Думай сам. Библиотека явно интересная и заслуживает отдельного проекта. Да и это: https://github.com/languages/Nemerle не дело, доказывай потом, что на nemerle, кроме компилятора, можно что-то написать.
Re[2]: библиотека автоматов состояний Nemerle.Statechart
Здравствуйте, Ziaw, Вы писали:
Z>Вот я сейчас крамолу скажу, но, имхо, лучше ее сделать отдельным проектом. Проекты в снипетах просто забываются.
Да ладно. Много забытых? Проекты забываются когда их забрасывают.
Z>При случае, даже некуда пальцем ткнуть, сказав вот есть проект на немерле (ибо многие небезосновательно считают снипеты просто пачкой недоделанных сэмплов, в которых сам черт ногу сломит).
Z>А так у нее будет собственный репо, со своим Readme.md, своим хозяином и возможностью ее форкать, создавать issues и видеть, что ее кто-то развивает. Или не развивает. Но можно легко скачать ее, собрать и посмотреть. Отдельный собственный проект провоцирует на написание какой-никакой доки лежащей прямо в проекте.
Если это библиотека претендующая на поставку в составе немерала, то до релизного состояния ей самое место в сниппетах.
Z> Ее можно добавить в снипеты как submodule и никуда она не потеряется.
ОК. Добавь какой-нибудь проект в сниппеты в виде submodule. Поглядим как это выглядит.
Z>Да и вообще надо больше проектов на nemerle, хороших и разных, чтобы интересующиеся могли их найти на гитхабе по языку.
Да кто же спорит то? Все согласны. Но отдельный проект имеет как преимущества, так и недостатки. Такие проекты нельзя использовать как тесты и рано или поздно они могут перестать компилироваться на текущей версии.
Z>О ней можно рассказать в блоге и дать ссылку на репо, а не папку в одном большом каталоге репо компилятора. В конце концов, глядя на нее человек может заинтересоваться языком, а глядеть на нее в репозитарии немерла левый человек просто не будет.
Все это можно и нужно делать без оглядки на то где находится проект.
Более того! Намного важнее довести проект до релизного состояния (когда его можно будет полноценно использовать).
Проблема большинства проектов не в том, что они не там находятся, в том что они так и не выходят из стадии экспеременов на коленке.
Z>Вобщем я знаю, Влад не одобрит, но решать тебе. Думай сам. Библиотека явно интересная и заслуживает отдельного проекта. Да и это: https://github.com/languages/Nemerle не дело, доказывай потом, что на nemerle, кроме компилятора, можно что-то написать.
Я не ретроград. Пока что этой библиотеке самое место в сниппетах. Но если идея с сабмоудями прокатит, то почему бы и нет?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: библиотека автоматов состояний Nemerle.Statechart
Здравствуйте, VladD2, Вы писали:
VD>Да ладно. Много забытых? Проекты забываются когда их забрасывают.
Забыть о проекте на своем гитхаб-аккаунте сложнее. Особенно если фоловеры есть и баги подкидывают.
VD>Если это библиотека претендующая на поставку в составе немерала, то до релизного состояния ей самое место в сниппетах.
А зачем она в составе стандартной поставки немерла? Это явно не библиотека общего назначения. Впрочем, если надо сабмодуль поможет.
VD>ОК. Добавь какой-нибудь проект в сниппеты в виде submodule. Поглядим как это выглядит.
Ок. Я только одну проблему вижу.
VD>Да кто же спорит то? Все согласны. Но отдельный проект имеет как преимущества, так и недостатки. Такие проекты нельзя использовать как тесты и рано или поздно они могут перестать компилироваться на текущей версии.
Какие проекты в снипетах сейчас используются как тесты? Имхо только те, которые в состав инсталятора входят. Так они в любом случае будут собираться с с инсталятором.
VD>Все это можно и нужно делать без оглядки на то где находится проект.
Что делать? Писать и закрывать баги в репо немерла? Или страницу в вики создавать?
VD>Проблема большинства проектов не в том, что они не там находятся, в том что они так и не выходят из стадии экспеременов на коленке.
Это другая проблема.
VD>Я не ретроград. Пока что этой библиотеке самое место в сниппетах. Но если идея с сабмоудями прокатит, то почему бы и нет?
Прокатит, если проект самодостаточен и не ссылается на другие проекты в снипетах.
Re[4]: библиотека автоматов состояний Nemerle.Statechart
Здравствуйте, Ziaw, Вы писали:
Z>Забыть о проекте на своем гитхаб-аккаунте сложнее. Особенно если фоловеры есть и баги подкидывают.
Да ладно. Погляди когда в твои рельсы последний раз комит был.
Z>А зачем она в составе стандартной поставки немерла? Это явно не библиотека общего назначения. Впрочем, если надо сабмодуль поможет.
Библиотек общего назначения не бывает. Библиотеки всегда решают какую-то задачу.
КА могут применяться чуть ли не для решения любой задачи. Это скорее вопрос знаний и дизайна. Не применяют их обычно из-за того, что в нетривиальных случаях их реализация сложнее чем другие подходы. Если же такая библиотека будет в стандартной поставке, то это по любому будет удобно потребителям.
VD>>ОК. Добавь какой-нибудь проект в сниппеты в виде submodule. Поглядим как это выглядит.
Z>Ок. Я только одну проблему вижу.
Какую?
Z>Какие проекты в снипетах сейчас используются как тесты?
Почти все. Они же собираются переодически.
Z>Имхо только те, которые в состав инсталятора входят. Так они в любом случае будут собираться с с инсталятором.
Ну, и на фиг нужно их выносить в отдельные репозитории?
Z>Что делать? Писать и закрывать баги в репо немерла? Или страницу в вики создавать?
И то, и другое, и третье.
VD>>Проблема большинства проектов не в том, что они не там находятся, в том что они так и не выходят из стадии экспеременов на коленке.
Z>Это другая проблема.
Не-а. Это основная проблема. Остальное — мелочи.
VD>>Я не ретроград. Пока что этой библиотеке самое место в сниппетах. Но если идея с сабмоудями прокатит, то почему бы и нет?
Z>Прокатит, если проект самодостаточен и не ссылается на другие проекты в снипетах.
Ну, попробуй на каком-нить мелком проекта для начала.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: библиотека автоматов состояний Nemerle.Statechart
Здравствуйте, VladD2, Вы писали:
Z>>Прокатит, если проект самодостаточен и не ссылается на другие проекты в снипетах.
VD>Ну, попробуй на каком-нить мелком проекта для начала.
Если будет все ОК, то можно будет и другие проекты вынести.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: библиотека автоматов состояний Nemerle.Statechart
Здравствуйте, CodingUnit, Вы писали:
CU>Идея написания библиотеки работы с конечными автоматами на Nemerle пришла давно, вот здесь началась развиваться тема на форуме: CU>http://rsdn.ru/forum/nemerle/3716028.aspx
Здравствуйте, Ziaw, Вы писали:
VD>>Да ладно. Погляди когда в твои рельсы последний раз комит был.
Z>8го июня.
А до этого сколько коммитов не было? Я ссылки на проект давал, а мне отвечали, что он заброшен.
Z>Там проблема в использовании MVC3 и VS2010.
Что за проблема? Могу попробовать подсобить в ее решении.
Вообще, поддержку MVC3 и Разора надо сделать. Хотя на мой взгляд — это все вариации на тему каменного топора, но с политической точки зрения это делать нужно. Вебом занимаются 90% народа. Так что это первое на чем новички могут пробовать язык.
VD>>Библиотек общего назначения не бывает. Библиотеки всегда решают какую-то задачу.
Z>
Ага. И никак иначе. Бывают конечно сборники вроде дотнтной библиотеки, но по факту они состоят и множества специализированных.
Z>>>Какие проекты в снипетах сейчас используются как тесты?
VD>>Почти все. Они же собираются переодически.
Z>Кем?
Мной, например. Да большая часть проектов в станадартных тестах задействована.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: библиотека автоматов состояний Nemerle.Statechart
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
Z>>А зачем она в составе стандартной поставки немерла? Это явно не библиотека общего назначения. Впрочем, если надо сабмодуль поможет.
VD>Библиотек общего назначения не бывает. Библиотеки всегда решают какую-то задачу.
VD>КА могут применяться чуть ли не для решения любой задачи. Это скорее вопрос знаний и дизайна. Не применяют их обычно из-за того, что в нетривиальных случаях их реализация сложнее чем другие подходы. Если же такая библиотека будет в стандартной поставке, то это по любому будет удобно потребителям.
Я с Владом полностью согласен такая библиотека хороша была бы в стандартной поставке, КА могут применяться где угодно, я без них сейчас не мыслю сложной разработки, в boost есть подобная библиотека, а boost это практически добавление к стандартной библиотеке c++, которая хорошо стандартизириуется и имеет высокое качество.
Z>>Что делать? Писать и закрывать баги в репо немерла? Или страницу в вики создавать?
VD>И то, и другое, и третье.
Я пока не хочу особо широко распространяться о библиотеке сейчас хорошо бы протестировать ее и дать Nemerle сообществу как инструмент, может быть в будущем, посмотрим... Размещения в сниппеты будет более чем достаточно.
Сегодня продолжу обсуждение возможностей библиотеки и автоматного подхода. Хочу заметить что используя автоматы можно моделировать объекты реального мира, в прошлый раз обсуждали модель телефона, таким образом можно моделировать что угодно, например: чайник, светофор, лифт, кодовая панель, телевизор, автомат продажи еды, банкомат, собака, вплоть до создания робота выполняющего разные действия. Программа тоже может являтся автоматом, gui реагирует на воздействия пользователя, кнопки должны включаться выключаться в определенной последовательности. Сегодня я покажу как можно автоматизировать часть логики приложения и gui на простом примере, этот пример есть в тестах библиотеки.
Задача такова, всем известны приложения типа word, которые отслеживают изменения в файлах и не дают выйти из приложения если файл не был сохранен, gui при этом тоже реагирует и если файл открыт то его название пишется в заголовке окна, если изменен часто выводится * после имени файла, такую логику можно пытаться писать влоб, но отлаживать такой код будет сложно, долго придется выслеживать ошибки, чтобы логика соответствовала, которые еще могут в будущем проявится неожиданно, можно нанять штат тестеров и исправлять логику, а можно пойти автоматным подходом и нарисовать диаграмму состояний, она должна выглядеть примерно так:
Логика такова:
1) При запуске приложения оно входит в состояние Ожидание через переход из начального псевдосостояния при входе в состояние выключаются кнопки сохранения, в заголовке отображается название программы
2) Далее пользователь может либо открыть файл либо создать новый, если он открывает файл, то срабатывает переход из состояния Не Нужно Сохранение, по открытию и если файл открыт успешно, выходит из состояния Ожидание при этом запускается выходное действие включается кнопка сохранения, заходит в состояние Сохраненный через начальное состояние в Не Нужно Сохранение, при этом при входе в состояние Сохраненный в надписи начинает отображаться имя файла и запоминается последний сохраненный файл
3) Далее пользователь может открывать новые файлы и логика будет повторяться если программа была в состоянии Сохраненный никаких предупреждений писаться не будет
4) Далее пользователь производит некоторые действия в программе и изменяет данные так что они разняться с файлом это событие изменение, которое запускает переход из Сохраненный в Измененный при этом автомат выходит из состояния Сохраненный входит в Нужно Сохранение запускает действие при входе кнопка сохранения включается всегда в этом состоянии, поскольку файл нуждается в сохранении, при этом в надписи отображается звездочка (*) рядом с именем файла что означает что данные изменены.
5) В этом состоянии пользователь может принудительно сохранить файл тогда автомат перейдет в состояние Сохраненный, если он выберет Новый файл или Открыть файл, то программа ему сообщит что файл нуждается в сохранении и даст вопрос о сохранении, при этом пользователь может отвергнуть или согласится или отменить процедуру, если он выберет Новый Файл и соглашается на сохранение то данные сохраняются и создается новый файл, при этом автомат перейдет в состояние Новый Файл который также требует чтобы данные были сохранены, в надписи при этом отображается не имя файла а некое имя представляющее новые данные
6) Если пользователь запросит выход из приложения то оно будет вести себя в зависимости от текущего состояния, если оно было сохранено то ничего не будет сказано, если было в состоянии Нужно Сохранение то будет запрошено сохранение
7) Далее все повторяется в зависимости от того что делает пользователь в приложении
Как видите логика легко описывается в рантайме если диаграмма продумана логика начинает работать сразу не требует никакой отладки и доводки, поиска ошибок, если что то не так работает то надо переосмыслить диаграмму и может стоить добавить действие при входе или перенести переход во внешнее состояние и все магически начинает работать
На языке библиотеки подобный автомат можно представить так, более подробный пример смотри в тестах (когда будет принят пуллреквест):
[statechart(<#
// флаги auto_initial автоматически добавляет в композитное состояние начальный переход в первое подсостояние
// transition_completed_events — генерирует обработчик который оповещает о том что произошло событие (нужно при отладке)
flags : auto_initial transition_completed_events;
0 => Ожидание; // начальный переход
state НенужноСохранение
{
$> / СохранениеВыкл; // действие при входе
НовыйФайл => НужноСохранение;
ОткрытФайл =>@; // переход в себя
state Сохранен
{
$> / НадписьИмяФайла ПоследнийФайлТек; // действие при входе 2 действия
Сохранение =>@; // переход в себя
Изменение => Измененный;
}
state Новый
{
$> / НадписьФайл ПоследнийФайлПустой;
}
state Измененный
{
$> / НадписьИзменен;
}
}
#>
)]
public class FileFsm
{
}
Далее генерируется на основе описания класс автомата, который можно использовать во внешнем коде. Вот как выглядит класс в рефлекторе:
Здесь показано тело класса Transition — это методы переходов они выполняют действия и выдают результирующее состояние,
также там видны события для действий, чтобы автомат делал что либо полезное к его событиям подключают внешние действия, типа как вывод в строку заголовка окна,
также есть стандартные методы определения состояния IsInState(st), Initiate() — запуск автомата
здесь показаны вложенные классы состояний, они представляют из себя варианты, в них генерируются виртуальные методы обработки событий
вот так выглядит тело одного из методов
вот так выглядит функция перехода
начальный
обычный
тело класса, события
это тело запуска события
метод Switch просто проверяет результат на null и присваивает текущей переменной cur_state если произошел переход
Вот вообщем и весь автомат, осталось в библиотеке реализовать семантику параллельных состояний, кое какие псевдосостояния и полезные функции, аттрибуты, флаги, опции, сейчас уже можно строить неплохие автоматы на ней.
На этом обсуждение закончу, потом дам больше примеров и описаний, до новых встреч.
от макросов до вариантов
и массой всяких преимуществ
благодаря nemerle-братству
программеров жизнь стала лучше
Re[7]: библиотека автоматов состояний Nemerle.Statechart
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
VD>>>Да ладно. Погляди когда в твои рельсы последний раз комит был.
Хочу задать вопрос по архитектуре автомата, встала задача сделать внутреннюю активность то есть параллельную деятельность осуществляемую в автомате, специфика в том что асинхронное действие надо прерывать когда автомат захочет.
Я начал реализовывать через поток Thread, но код тяжеловат каждый раз приходится запускать создавая новый объект Thread и останавливать через Abort Join, есть возможности в библиотеке Rx Extensions, но не очень хорошо ссылаться на внешнюю библиотеку, может известны другие более экономичные подходы для реализации отменяемых асинхронных действий?
от макросов до вариантов
и массой всяких преимуществ
благодаря nemerle-братству
программеров жизнь стала лучше
Re[8]: библиотека автоматов состояний Nemerle.Statechart
Здравствуйте, CodingUnit, Вы писали:
CU>Хочу задать вопрос по архитектуре автомата, встала задача сделать внутреннюю активность то есть параллельную деятельность осуществляемую в автомате, специфика в том что асинхронное действие надо прерывать когда автомат захочет. CU>Я начал реализовывать через поток Thread, но код тяжеловат каждый раз приходится запускать создавая новый объект Thread и останавливать через Abort Join, есть возможности в библиотеке Rx Extensions, но не очень хорошо ссылаться на внешнюю библиотеку, может известны другие более экономичные подходы для реализации отменяемых асинхронных действий?
Такие вещи нужно реализовывать на базе пула потоков. В .net 4 есть библиотека упрощающая подобные задачи (см. класс Task). Пул потоков позволяет не тратить время на создание потоков и распределяет работу между имеющимися процессорами, так как старается выделять столько процессоров сколько нужно для их загрузки (ни больше, и не меньше).
Поток лучше не прерывать исключением, а использовать идеологию токенов отмены (cancellation token). По сути это навортоты над простым приемом — предаем в функцию ссылку на некий флаг и проверяем его все время. Если он поднят, то завершаем выполнение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: библиотека автоматов состояний Nemerle.Statechart
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, CodingUnit, Вы писали:
CU>> Текущие возможности библиотеки таковы
FDS>Не собирается что-то проект из сниппетов (966 ошибок). Там что-то надо сделать, чтоб собрался?
Через MSBuild билдится нормально, только GitVеrsion не работает
Здравствуйте, FDSC, Вы писали:
FDS>>Не собирается что-то проект из сниппетов (966 ошибок). Там что-то надо сделать, чтоб собрался?
FDS>Через MSBuild билдится нормально, только GitVеrsion не работает
Данная библиотека испльзует возможности которые доступны только при сборке компилятора из исходников (т.е. использует компилятор последней версии).
variant_option я добавил совсем недавно.
Собрать компилятор из исходников довольно просто. Нужно только предварительно поставить VS 2010 SP1 и VS SDK 2010. Далее остается только скачать исходники и запустить DevBuildQuick-4.cmd.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Собрать компилятор из исходников довольно просто. Нужно только предварительно поставить VS 2010 SP1 и VS SDK 2010. Далее остается только скачать исходники и запустить DevBuildQuick-4.cmd.
Влад, я собрал компилятор без VS SDK (у меня пиратка и SDK не ставится), вроде бы без ошибок (убрал _Integration и все упоминания о VSIntegration из проекта NemerleAll). Только ругался на версию (я руками поправил с 1.0.0.9999 на 1.0.0.87 — GitVersion не знаю как там должен работать, но не работает). Так что странно, что VS всё равно не собирает Видать, я всё-таки криво собрал
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, VladD2, Вы писали:
VD>>Собрать компилятор из исходников довольно просто. Нужно только предварительно поставить VS 2010 SP1 и VS SDK 2010. Далее остается только скачать исходники и запустить DevBuildQuick-4.cmd.
FDS>Влад, я собрал компилятор без VS SDK (у меня пиратка и SDK не ставится),
Какая еще пиратка? VS никак не защищена и на просторах торрентов туча инсталяторов из МСДН-а.
FDS>вроде бы без ошибок (убрал _Integration и все упоминания о VSIntegration из проекта NemerleAll). Только ругался на версию (я руками поправил с 1.0.0.9999 на 1.0.0.87 — GitVersion не знаю как там должен работать, но не работает). Так что странно, что VS всё равно не собирает Видать, я всё-таки криво собрал
Это не серьезно. Интеграция может работать только на последних версиях сборок компилятора. Не странно, что все валится.
ЗЫ
VS SDK можно скачать в виде iso. Ссылка пробегала где-то на хабре. Думаю гугль ее ищет влет. Попробуй его поставить.
Кроме того VS SDK может не ставиться потому что это не та версия. Нужно поставить SP1 для VS 2010 и уже потом ставить соответствующую версию VS SDK. Если попытаться поставить неверную версию, то будет облом. Может быть именно это и произошло в твоем случае.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Кроме того VS SDK может не ставиться потому что это не та версия. Нужно поставить SP1 для VS 2010 и уже потом ставить соответствующую версию VS SDK. Если попытаться поставить неверную версию, то будет облом. Может быть именно это и произошло в твоем случае.
Ага, оказалось, что у меня SP1 поставлен, а SDK, наоброт, старой версии.
Запустил DevBuildQuick-4.cmd — прошло без ошибок (правда с какими-то предупреждениями), но всё равно в VS нефига ничего не собирается с огромным кол-вом ошибок, гит на pull пишет
.
Видать, я всё-таки криво собрал 