Ход модельного времени

[k-alexandrovsky]

http://rdo.rk9.bmstu.ru/help/help/rdo_studio_rus/html/work_model/work_model_frame.htm

[k-alexandrovsky]

@aurusov, @bogachev-pa Вопрос по замедлению DPT Search и по поводу оповещений об изменении состояния системы. Хочется обсудить, что нужно считать атомарной операцией в search'е, и между какими операциями нужно вставлять delay? Потому что я задумался об анимации, и о том, когда ее оповещать об изменениях. Потому что search весьма свободно жонглирует слепками состояния системы, являясь этакой машиной времени.

P.S. Еще я отвязал масштаб от скорости ядра. Я решил, что так правильнее, потому что они регулируют разные сущности.

[aurusov]

С поиском сложно. Старое РДО разбивало задачу на две разных

1. Поиск мог прерваться, отдать управление ядру с результатом must_continue. В следующий цикл моделирования ядро понимало, что надо передать управление прошлой задаче. И так до тех пор, пока поиск не возвращал статус завершения done.
2. А вот когда поиск прерывается - это решает сам поиск. В старом РДО он работает 1/40 секунды. Сколько успел нагенерить, столько и успел. В общем выглядит, как кооперативная многозадачность. В питоне для этого есть yield.

Можно запилить такую же схему и в новом РДО. Если придумаешь что-то лучше, то давай обсудим. Важно иметь в виду трассировку и построитель графа поиска - хочется чтобы они работали во время поиска и выводили информацию постепенно. Даже граф :) Чтобы было видно, как он строится в динамике.

[k-alexandrovsky]

То есть с точки зрения скорости моделирования в старом РДО было примерно так: 1/40с на поиск => delay от ползунка скорости моделирования => 1/40с на поиск => delay ...?

Сейчас поиск ищет до победного в основном потоке, но при этом он подписан на прерывание моделирования, и ему выставляется флаг прерывания, тогда не будет порождено новых вершин и будет восстановлено начальное состояние ресурсов. Наверное, можно как то расширить этот механизм, вдруг мы захотим прервать поиск, не прерывая самого моделирования.

Что касается трассировки - тут уже сделан механизм, в котором Database рассылает оповещения о том, что у нее появилась новая запись. Теперь я думаю, что нужно сделать оповещения о событиях поиска - открыта вершина / порождена вершина, например. Первое можно использовать для анимации, чтобы показывать наглядно процесс решения, а второе вкупе с первым пригодится построителю графов. Единственное, я не знаю, надо ли делать эти оповещения глобальными или нет. В первом случае очень просто на них подписаться, но у класса DPTSearch придется спросить, что за поиск сейчас идет. Либо у каждого поиска свои оповещения, что избавляет от необходимости куда-то лезть, но тогда довольно сложно будет реализовывать механизм подписки на всех, ведь мы вроде как хотим замедлять поиск ползунком, хотя бы для анимации.

[aurusov]

Да, про поиск и задержку так. На консультации говорил, что тебе надо посмотреть и понять работу старого РДО в этом месте

• время
• переход к след. событию

Насчет оповещений. Если уже есть оповещения об изменениях в Database, то зачем еще что-то придумывать для постепенной отрисовки графа ?

[k-alexandrovsky]

зачем еще что-то придумывать для постепенной отрисовки графа?

Чтобы графу не пришлось парсить записи. Но я не знаю, насколько это оправданно.

[aurusov]

Вообще-то это его работа, не переживай. Если всё получится, то можно оформить эту часть графопостроителя в виде отдельного провайдера. Но пока непонятно кому это нужно кроме него самого.

[aurusov]

Задача закрыта, но решли сделать замедление DPT-search в ней же. Замедление нужно для по постепенной отрисовки графа.

[bogachev-pa]

Собственно, было решено в ходе рефакторинга нотификаций вот этим https://github.com/aurusov/rdo-xtext/commit/dd266128622d83f77ef7ff1267f48a76659cc864 коммитом.

Я как-то не сообразил, что из-за этого нотификации надо было, наверное, мержить как фичу, а не как рефакторинг. Так или иначе, я их уже замержил, ну а эта задача решена.