DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 11:12

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 188 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8 ... 10  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 17 Июнь, 2018 22:31 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Степан Митькин писал(а):
Всё правильно. ДРАКОН изображает алгоритм, а не данные.
Можно составить алгоритм, который запускает 5 насосов.

Вот вот. В Драконе можно передать часть схемы как параметр в другую схему?
Вы же вазражаете на мои слова, когда я сказал, что в Драконе невозможно сделать аналог функции wait.
Приведённая мной функция wait принимает длительность ожидания в секундах и блок кода, который возвращает true/false в зависимости от того нужно ли продолжать ждать.

Степан Митькин писал(а):
Вложение:
nasosy.png

Если икона запуска каждый раз запускает новый процесс, то невозможно сослаться на запущенный.
Невозможно сложить насосы в массив и обработать их единообразно. Предложенная запись едва ли однозначна. Что, если алгоритм управления 3им насосом уже запускался и получаестя, что работают 2 процесса? Какой из них остановится?

Да и сам copy-paste стиль программирования (раз 3 насоса, то упомянем запуск для каждого явно) часто приводит к опечаткам.

Я рассчитывал на то, что Дракон-схемы в связке с ST будет удобнее использовать вместо SFC (я про МЭК61131)
По факту же, Дракон схемы в этой области не работают.

Конечно, можно использовать иконы действий вместо обычных строк, а иконы развилок вместо if, но толку от такого программирования ровным счётом ноль.

В начале этой темы PSV100 разобрал факт, что Дракон схемы не указывают на семантику выполнения. Для кооперативной многозадачности как раз очень важно знать в какой момент управление будет передано в операционную систему.
Тут Дракон схемы снова буксуют.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 18 Июнь, 2018 11:34 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
Владимир Ситников писал(а):
Вот вот. В Драконе можно передать часть схемы как параметр в другую схему?

Нет, нельзя. Как это можно сделать где-то ещё? lamba-hell не предлагать.

Владимир Ситников писал(а):
Что, если алгоритм управления 3им насосом уже запускался и получаестя, что работают 2 процесса? Какой из них остановится?

У меня такая ситуация возникает. Каждый пользователь в DrakonHub может иметь только один процесс поиска на сервере.
Когда пользователь запускает новый процесс поиска, этот новый процесс сначала прибивает уже существующий.
Процесс поиска реализован конечным автоматом, который крутится внутри файбера.

Но как решить эту проблему на уровне синтаксиса, с ДРАКОНом или без ДРАКОНа?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 18 Июнь, 2018 12:18 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Степан Митькин писал(а):
У меня такая ситуация возникает. Каждый пользователь в DrakonHub может иметь только один процесс поиска на сервере.
Когда пользователь запускает новый процесс поиска, этот новый процесс сначала прибивает уже существующий.
Процесс поиска реализован конечным автоматом, который крутится внутри файбера.

Но как решить эту проблему на уровне синтаксиса, с ДРАКОНом или без ДРАКОНа?

Я не говорю, что любая задача должна решаться непосредственно синтаксисом Дракона или "недракона".
По сути, Дракон схемы отражают граф выполнения (control flow graph), а data flow graph они не показывают.

Грубо: если бы из иконы "запуск процесса" отходила вторая ветка (пунктирная или ещё какая), олицетворяющая "запущенный процесс", который можно было бы поместить в хранилище, то можно было бы на картинке показать: вот мы стартуем поиск, ссылку на процесс сохраняем, и сможем найти её и прервать предыдущий поиск если понадобится.

Сейчас же "запуск процесса" сделан в виде "fire and forget", и вообще не остаётся никаких возможностей прервать "тот самый" экземпляр процесса.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 18 Июнь, 2018 13:33 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Степан Митькин писал(а):
У меня такая ситуация возникает. Каждый пользователь в DrakonHub может иметь ....................

Полезно посмотреть, кто не видел
https://drakonhub.com/


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 18 Июнь, 2018 22:25 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Владимир Паронджанов писал(а):
Степан Митькин писал(а):
У меня такая ситуация возникает. Каждый пользователь в DrakonHub может иметь ....................

Полезно посмотреть, кто не видел
https://drakonhub.com/

Это нечто новое? А прежние пароли сохраняются?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 19 Июнь, 2018 13:01 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
TAU писал(а):
https://drakonhub.com/
Это нечто новое? А прежние пароли сохраняются?

DRAKON Editor Web был переименован в DrakonHub.
Прежние пароли, диаграммы и проекты сохраняются.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Июнь, 2018 18:46 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
PSV100 писал(а):
А такой -- уже из разряда "а то и более":

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

Ранее и был акцент на "кристальной ясности" паттерна "билдеров", предлагаемого в Kotlin. Пример был из "Guide to kotlinx.coroutines by example" от самих разработчиков ("Selecting deferred values"):
https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#selecting-deferred-values

Причём это элементарный примерчик запуска пула процессов и ожидания результата от одного любого из них. И именно такой стиль дисциплины построения кода/моделей является типовым (встречается сплошь и рядом), характерен в целом для ООП-парадигмы "билдеров", что было (и есть) и в Groovy (откуда "билдеры" заимствовались), и в Ruby (Groovy есть "Ruby" для Java).
Владимир Ситников писал(а):
PSV100 писал(а):
В итоге есть и последствия в виде вынужденного дублирования функционала как "await -> onAwait", "receive -> onReceive" и т.д.

О каком дублировании речь?

Такие операции как "await", блокирующие исполнение "по месту" и семантически выражающие получение результатов, требуют своей реализации и в форме "события для Select-билдера" аля "onAwait", где нет блокировки исполнения "по месту" и вставляется "хук" для функции "select" (т.е. одна и та же семантическая операция имеет две формы реализации).
Такова особенность в API из-за паттерна "билдеров" (что есть "стандарт" для платформы), который возник при штамповании шаблонов HTML/JSON/XML и т.п., т.е. для построения DOM (Document Object Model) -- DOM и есть концептуальная основа тамошней "DSL-платформы" в целом. На таком же принципе основана и функция "select": слепили "DOM" (в конструкторах-лямбдах) и "ждём" срабатывания какого-то "события" в этом "DOM"-е.
Владимир Ситников писал(а):
На тему configurable semantics in FSM есть исследование и рабочая интеграция с С кодом: https://github.com/z9luo/BSML-mbeddr
Вполне может быть, что семантика состояний должна настраиваться по удобству конкретного алгоритма.
К слову, в той статье один из режимов был syntactic big-step maximality. Т.е. когда "стабильные" состояния FSM размечаются руками программиста, и система выполняет переходы до тех пор, пока не дойдёт до стабильного.

Толковое обобщение "автоматной парадигмы". К слову, в том же Kotlin об автоматах речь лишь в контексте "implementation details" механизма suspend-функций (возникающую трансформацию кода можно интерпретировать как автомат), какого-то целенаправленного API для "автоматной парадигмы" пока, вроде как, не заметно:
https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md#state-machines

В статье упоминаются "синхронные" языки моделирования, которые "автоматную парадигму" (со своей спецификой) отражают в том числе и в "алгоритмической" форме (аля "сделай раз, сделай два, сделай три"). Соответственно имеют и адаптированные алгоконструкции, к примеру, схематично:
Код:
...
loop
  ...
  x = susp_fn1(...);
  ...
  y = susp_fn2(...);
  ...
each z > 0
...

Цикл вида "loop...each" является "ожидающим", интерпретируется как "автоматное супер-состояние" с внутренними "состояниями"/автоматами. Каждый раз, когда выполняется блокировка, к примеру, пусть на "suspend-функциях" (аля "susp_fn1(...)" выше) и осуществляется "ожидание", условие цикла также анализируется, и при срабатывании его "события" осуществляется прерывание тела цикла и новая итерация -- сработал переход или "шаг в себя" для "супер-состояния" (цикл, в свою очередь, может включать в себя и вложенную композицию прочих блоков, в т.ч. и параллельных процессов и т.д.).

Некую эмуляцию подобных конструкций можно сделать и в Kotlin, но в целом построение API "автоматной парадигмы" не простое дело, и блоки как цикл выше в случае "многоуровневости" вложенных конструкций не очень то наглядны. Альтернативы в виде "плоских" систем уравнений в тех же "синхронных" языках, т.е. декларативный стиль дефиниций, имеют и свои достоинства.
В общем, акцентировать на парадигмах Kotlin-а в частности -- на данный момент второстепенное дело. Главное -- понимать как моделировать в голове или на бумажке с карандашом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Июнь, 2018 18:51 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
Ещё немного про выразительность.
Известно, что "бесконечное ожидание" едва ли хорошо. Наверняка нужно как-то обрабатывать ситуацию "систему заклинило".

Так вот. Можно сделать функцию wait(timeLimit: Int, condition: () -> Boolean), которая будет принимать ограничитель по времени (напр, в секундах).

Тогда программа может выглядеть так:
Код:
suspend wait(timeLimit: Int, condition: () -> Boolean) {
  set t;
  while(!t) {
    if (condition()) return;
    yield;
  }
  // В случае "не дождались" можно кинуть исключение, вернуть false и тому подобное.
}

suspend atFloor() {
    while(true) { // если поменять на for(i in 1..3), то будет 3 попытки закрыть дверь
        openDoor();
        set t;
        wait(5) { !closeButton() }
        closeDoor();
        wait(10) {
            if (closedDoor()) {
                // Return прерывает функцию atFloor. Можно написать return@atFloor для наглядности.
                return; // дело сделано, можно принимать решение куда ехать.
            }
            !blockedDoor()
        }
    }
    throw new IllegalStateException("лифт сломался, идите пешком")
}

Взяли и сделали отдельную функцию wait для частоупотребимой операции "дождаться".

С Дракон-схемами такое, очевидно, невозможно, т.к. Дракон не оперирует понятием данных.
С P-схемами такое возможно? Едва ли

Если речь про "лямбда-выражения" в аргументах функций, то на Дракон-е какие-то попытки возможны, но с нарушением семантики элементов схем:
https://forum.drakon.su/viewtopic.php?p=76879

В Р-схемах лямбду можно задавать так:
Вложение:
susp_atfloor.png
susp_atfloor.png [ 18.99 КБ | Просмотров: 7546 ]

Используется "дуга-ключ" (двойная дуга с "разорванной" конечной вершиной) -- операция "сопоставление" (аля "pattern matching"). В данном случае "сопоставляется" действие, и блок под дугой раскрывает содержимое лямбды-аргумента (вызов "wait(...)" можно указать и как предикат над дугой).
Схемки соответствуют оригиналу "в лоб" (вместе с "досрочными" выходами -- для простоты используется структурный переход с "#" -- на конец всей структуры, операция "yield" задана как пустая двойная дуга-петля).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Июнь, 2018 19:04 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
В редакторе Тышова есть реверанс в подобную сторону: то ли у схемы, то ли у листа можно указывать "режим трансляции", который влияет на результирующий код (1 действие==1 состояние FSM, 1 ветка == 1 состояние FSM и тому подобное)
...
В Дракон-схемах вопрос "семантики результирующего FSM" тоже не проработан
...
К слову, в той статье один из режимов был syntactic big-step maximality. Т.е. когда "стабильные" состояния FSM размечаются руками программиста, и система выполняет переходы до тех пор, пока не дойдёт до стабильного.
...
Вполне может быть, что нужно не искать идеальный вариант компиляции Дракон-схемы в FSM, а делать несколько настраиваемых вариантов

Если те же Р-схемы в своей основе есть лишь "графические структуры" ("выросшие" из графов переходов), требующие нагрузки предметным технологическим языком, то в Дракон-е есть свой жёсткий "syntactic" -- определённые синтаксис и семантика, и какие-то их частные интерпретации (с нарушением правил и/или какими-то дополнениями) может быть и возможны (отчасти вынужденные меры в практике), но в рамках частных методик -- в этом же и проблематика.
И по ходу дела, этот "syntactic" имеет и последствия. На форуме возникло вполне справедливое замечание:
https://forum.drakon.su/viewtopic.php?f=78&t=6263#p101824

Т.е. кроме выражения операции "ожидания" необходимо отражать и факт передачи управления куда-то условному диспетчеру -- возникает разрыв маршрутной линии с выходом из алгоритма и последующим возвратом в алгоритм -- возникает новый вход -- вся "метафора" должна быть явной согласно принципам Дракон-а, как и блок-схем (операции аля "пауза" в блок-схемах блокируют поток (или они есть "пустые" действия определенной длительности) -- нет переключения/перехода внутри рассматриваемой алгоритмической системы).
Концепция алгоритмов с использованием, к примеру, тех же suspend-функций в итоге должна быть в стиле:
Вложение:
susp_func.png
susp_func.png [ 15.88 КБ | Просмотров: 7544 ]

, где через пунктирную линию выполняется попытка отразить косвенные управленческие связи, в т.ч. возникает и эмуляция "силуэта" -- подчеркивается, что "входы" есть части единого алгоритма.

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

По-видимому, стиль "функций-состояний" Зюбина и есть самый адекватный для блок-схем, на чём неоднократно акцентировалось:
https://forum.drakon.su/viewtopic.php?f=142&t=6246#p101655

"Фукнции-состояния" и есть "разрывы управления и новые входы", ожидания возникают лишь в начале "состояния". Вертикальная организация "таблиц" способствует восприятию постепенного продвижения по "состояниям" в случае их линейной упорядоченности, часто возникающей (внутри "состояния" могут быть обычные "силуэты" с горизонтальной направленностью). По-видимому, необязательно задавать явные имена "состояний" при наличии лишь операции "в следующее" (возможна и автоматическая генерация номеров состояний или каких-то буквенных обозначений).
"Таблицы" рядом могут раскрывать смежные процессы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Июнь, 2018 19:13 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
Или с другой стороны: можно сделать Дракон-схему для управления насосом. Но невозможно указать, что по этой схеме теперь будут работать 5 насосов (у каждого из них может быть своё текущее состояние и своя активная икона на схеме). Иными словами, на уровне Дракон схем нет понятия 'запущенный экземпляр' схемы.

'запуск/останов параллельного процесса'. Это каждый раз один и тот же экземпляр процесса запускается? Или каждый раз новый процесс?
Можно ли запустить 3 процесса, чтобы они работали согласно схеме 'работа насоса', а потом остановить 3ий?
...
Если икона запуска каждый раз запускает новый процесс, то невозможно сослаться на запущенный.
Невозможно сложить насосы в массив и обработать их единообразно. Предложенная запись едва ли однозначна. Что, если алгоритм управления 3им насосом уже запускался и получаестя, что работают 2 процесса? Какой из них остановится?

Да и сам copy-paste стиль программирования (раз 3 насоса, то упомянем запуск для каждого явно) часто приводит к опечаткам.
...
Сейчас же "запуск процесса" сделан в виде "fire and forget", и вообще не остаётся никаких возможностей прервать "тот самый" экземпляр процесса.

У Зюбина методика спецификаций на уровне "алгоритмов про рыбалку" (т.е. чтоб и для "домохозяек"). Есть распределение/привязка доступа переменных по процессам и т.д. Сами процессы подразумеваются "уникальные", т.е. конкретные экземпляры. Напрашиваются какие-то расширения для введения семантики массивов процессов или их "пулов".
Скорее всего, необходима какая-то динамическая модульность, чтобы "программа" как синглтон (процессы и ведь ещё и данные) могла быть представлена и как тип аля "активный объект" (или как "задача" в Ada и т.п.). Тогда имеется возможность использовать и "экземпляры", и их "пулы" и т.п., и операции "пуск/останов" адаптировать для "множественных" аргументов (что и так имеется у Зюбина) и пр. По аналогии с "классами" в проекте Ceu (ранее уже была ссылка, проект также старается быть для "домохозяек" на уровне "бейсика"):
http://ceu-lang.org/


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Июнь, 2018 19:29 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
По сути, Дракон схемы отражают граф выполнения (control flow graph), а data flow graph они не показывают.

Грубо: если бы из иконы "запуск процесса" отходила вторая ветка (пунктирная или ещё какая), олицетворяющая "запущенный процесс", который можно было бы поместить в хранилище, то можно было бы на картинке показать: вот мы стартуем поиск, ссылку на процесс сохраняем, и сможем найти её и прервать предыдущий поиск если понадобится.

Ну да, блок-схемы -- упорядоченный граф именно передачи управления. Какую-то передачу данных по операциям приходится выражать как-то косвенно, напр.:
https://forum.drakon.su/viewtopic.php?p=93258#p93228
https://forum.drakon.su/viewtopic.php?p=93258#p93258

Если под "data flow graph" подразумевается "классическая" модель "реактивных" потоков данных (управление "через данные"):
Программирование потоков данных

, то в блок-схемах с их отражением есть проблемка. На Р-схемах структура процессов может быть задана так (параллельная композиция процессов в "теле" SomeObj):
https://forum.drakon.su/viewtopic.php?f=142&t=6246&start=20#p101703

И то, с позиции семантики графов переходов или сетей работ, дуги, выражающие процесс, должны быть с двунаправленной связью вида: "<-------->", что означает цикличность или переход в начало сразу же из конечной вершины. Можно не отражать явную направленность (подразумевая двустороннее отношение между вершинами) в стиле:
Вложение:
dataflow.png
dataflow.png [ 3.34 КБ | Просмотров: 7539 ]

, где используются штрихи для дуг. Двойным штрихом выделяется множество процессов (в данном случае n процессов proc3, в оригинале примера по ссылке выше об этом нет речи). Дугу со штрихом можно принять как "поглощающую", тогда под ней можно вставить структуру процесса, т.е. вписать само содержимое процесса если необходимо. И дополнительно можно указать подачу данных через вспомогательные пунктирные линии.
Т.е. таким способом выделяются все типовые варианты "потоковой" параллельности в структуре процессов:

Изображение

Р-схемы представляют из себя композицию структур, для алгоритмики подразумевается композиция переходов/автоматов. И политика работы параллельных процессов зависит от семантики оператора их параллельной композиции (в оригинальном примере подразумевается бесконечное циклическое исполнение процессов (со своими исполнителями) до останова извне. И, к примеру, если соблюдается понятие автоматного "big-step" в разрезе всего "||"-оператора, то для группы процессов как "data parallelism" возможна round-robin политика передачи данных по тактам автомата (на 1-такте данные получает 1-й процесс в группе, на 2-м -- 2-й и далее по кругу)).

В блок-схемах и Дракон-е маршрутная линия явно выражает передачу управления, в т.ч. и в контексте "параллельных линий". Даже если "параллельные действия" обернуть каким-то циклом, то всё равно всегда происходит запуск/завершение действий. Поэтому для тех же "потоков" необходимы "автоматные диалекты", мол, к примеру, выполняется вызов "методов" у каких-то ООП-объектов, и состояние данных сохраняется в "объектах". Соответственно возникает и потребность в каких-то диалектах моделирования насчёт совместного доступа к объектам (собственно то, проблематика понимания, что исполняется: функция/процедура/метод, где хранятся состояния данных, передача операндов операциям, совместный доступ и т.д. существует не только в рамках "потоков").


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Июнь, 2018 19:38 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Владимир Ситников писал(а):
непонятно что хотел сказать автор

Вы автор кода про "а то и более"? Разумеется, нет.

PSV100 писал(а):
Причём это элементарный примерчик запуска пула процессов и ожидания результата от одного любого из них.

Я прекрасно понимаю откуда взялся этот пример, и считаю, что авторы kotlin-coroutines-informal.md выбрали неудачный пример. К вам-то в том примере претензий нет.

PSV100 писал(а):
Такие операции как "await", блокирующие исполнение "по месту" и семантически выражающие получение результатов, требуют своей реализации и в форме "события для Select-билдера" аля "onAwait", где нет блокировки исполнения "по месту" и вставляется "хук" для функции "select" (т.е. одна и та же семантическая операция имеет две формы реализации).

Тут я согласен. Если хочетя использовать Deferred в контексте select, то, да, может оказаться полезной конструкция onAwait.
Но, честно говоря, не думаю, что вариант "select" и вариант "async" это "одна и та же семантическая операция".
Всё-таки, вариант "select" и сделан как раз для того, чтобы "await multiple suspending functions simultaneously", а вариант "async" для последовательного выполнения. Там, где у нас могут прилететь события одновременно ставим select. Там где хотим "последовательного" выполнения select не ставим.

PSV100 писал(а):
Такова особенность в API из-за паттерна "билдеров" (что есть "стандарт" для платформы)

Это другой вопрос. Там же никто не заставляет select'ом пользоваться?
Не заставляет. То, что любая конструкция в Kotlin'е рано или поздно превращается в builder это да. Тут ничего не поделаешь. Язык, похоже, специально затачивали на type-safe builders.


PSV100 писал(а):
Толковое обобщение "автоматной парадигмы"

Вот тут я не знаю. Особо литературу не читал, но, похоже, от "семантической разбивки big-steps не уйти".
Похоже, имеет смысл подумать в Драконе о каких-то отметках о "стабильных" состояниях (ну, чтобы автомат прокручивался до "стабильного" состояния и ни в коем случае не останавливался на промежуточных).


PSV100 писал(а):
К слову, в том же Kotlin об автоматах речь лишь в контексте "implementation details" механизма suspend-функций (возникающую трансформацию кода можно интерпретировать как автомат)

Тут полностью согласен. Повторюсь: я всё время говорил про suspend functions. Именно кирпичик на базе которого можно построить тот или иной механизм FSM.


PSV100 писал(а):
Некую эмуляцию подобных конструкций можно сделать и в Kotlin, но в целом построение API "автоматной парадигмы" не простое дело, и блоки как цикл выше в случае "многоуровневости" вложенных конструкций не очень то наглядны. Альтернативы в виде "плоских" систем уравнений в тех же "синхронных" языках, т.е. декларативный стиль дефиниций, имеют и свои достоинства.

На Kotlin можно сделать и так и так. И одновременно.
Грубо говоря, "select" это и есть "плоская" система из onReceive :)
Т.е. можно часть задачи выразить через select, а часть через async. И никаких проблем.

PSV100 писал(а):
В общем, акцентировать на парадигмах Kotlin-а в частности -- на данный момент второстепенное дело. Главное -- понимать как моделировать в голове или на бумажке с карандашом.

Я имел ввиду именно suspend functions.
Т.е. возможность из Kotlin кода получать либо императивный код (который выполняет команды последовательно), либо FSM код (который хранит состояние FSM и может возвращать управление, но при этом запоминать "где сейчас находимся")

Возможно, нужно делать подобное и в Дракон-схемах. А, возможно, стоит считать, что Дракон-схемы всегда выполняются в suspend режиме.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Июнь, 2018 19:58 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
PSV100 писал(а):
И по ходу дела, этот "syntactic" имеет и последствия. На форуме возникло вполне справедливое замечание:
https://forum.drakon.su/viewtopic.php?f=78&t=6263#p101824

Тут вы путаете.
syntactic означает, что "пользователь" (программист) явно определяет "стабильные" состояния (в которых FSM возвращает управление в диспетчер).

Как раз ниже вы приводите, что "нужно бы сделать пунктирную линию" или разрыв. Это и есть syntactic "big step".
Как именно отмечать (пунктиром, или разрывом или иконкой) -- фиг знает. Тут нужно думать. Я про то, что в языке схем должно быть явное обозначение, что "вот это стабильное состояние", а "вот эти состояния" будут прокручиваться вместе без возврата в диспетчер.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Июнь, 2018 11:00 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
Читателю ДРАКОН-схемы иногда нужно знать, как ведёт себя алгоритм в той или иной иконе. Где ждёт внешнего события, где передаёт управление диспетчеру. Я сначала согласился с мнением TAU, что автор схемы должен такие вещи указывать: рисовать пунктирную линию вместо сплошной, например.

Но потом я понял, что такие дополнительные детали добавлять в язык не надо. Поясню. Вы ожидаете, когда пользователь нажмёт кнопку, в иконе Ввод. Этого события можно ждать год. Поэтому TAU говорит: рисуй пунктир! Покажи, что алгоритм здесь залипает! Владимир Ситников добавляет: хочу видеть, когда управление переходит диспетчеру! Покажи это на схеме!
Но ведь автор уже сказал "ждать" иконой Ввод. Значит, дополнительные средства типа пунктира избыточны. Не рисуйте пунктир, не делайте лишнюю работу.

Но передачу контроля хотелось бы видеть. Как быть? Я предлагаю дополнительные автоматические средства визуализации.

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

- Дополнительные. Подсветка будет видна, только если поставить галочку в настройках. Кому нужно, пусть ставит галочку. Остальные хотят знать только суть — последовательность шагов алгоритма.

Вот анализ поведения икон в ДРАКОНе с точки зрения реального времени и диспетчера:
https://drakonhub.com/read/realtime
Вложение:
realtime.png
realtime.png [ 40.53 КБ | Просмотров: 7518 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Июнь, 2018 11:55 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Степан Митькин писал(а):
Я сначала согласился с мнением TAU, что автор схемы должен такие вещи указывать: рисовать пунктирную линию вместо сплошной, например.

Но потом я понял, что такие дополнительные детали добавлять в язык не надо.
.........................................
Не рисуйте пунктир, не делайте лишнюю работу.
Поддерживаю

Я смотрю с позиции читателя. Пунктир напрягает и заставляет обратить внимание на это место. Как правило, это не нужно.
В данном случае точно не нужно.

Я против пунктира в данном случае, потому что это переусложнение. Любительское переусложнение.

Попытка выпятить незначащую деталь.
В языке ДРАКОН очень много деталей.
Все люди разные. Один захочет акцентировать внимание на одной детали, кто-то — на другой.

Надо смотреть на общую картину и не увлекаться субъективными пристрастиями.

Вместе с тем язык ДРАКОН нельзя считать завершенным; он нуждается в развитии. Например, в тех случаях, когда отсутствует необходимая функциональность. И не только...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Июнь, 2018 12:13 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
http://drakon.su/_media/biblioteka/glav ... _vrem_.pdf
Цитата:
СООБЩЕНИЕ ДЛЯ ПРОГРАММИСТОВ

На рис. 113-123 показаны операторы реального времени, нарисованные внутри алгоритмов.

Поэтому может создаться впечатление, что они реализуются этими алгоритмами (то есть прикладными программами реального времени). Но это не всегда так.

Рассмотрим случай, когда используется Операционная система реального времени (ОСРВ).

В таком случае операторы реального времени реализуются
совместно:
 прикладной программой реального времени;
 дракон-диспетчером, входящим в состав операционной системы реального времени.

Когда в прикладной программе встречается оператор Пауза, происходят события, не показанные на наших рисунках.

А именно, выход из прикладной программы и передача управления в дракон-диспетчер (с одновременной передачей
параметра, записанного в иконе Пауза).

Получив параметр, диспетчер отсчитывает время, указанное в Паузе. Когда время истечет, диспетчер возвращает управление в прикладную программу — в точку, расположенную после иконы Пауза.

Иными словами, всякий раз, когда на рисунке алгоритма изображена Пауза происходят два события:
 выход из прикладной программы (в начале Паузы);
 вход в прикладную программу (в конце Паузы).

Рассмотрим еще один пример — оператор Период. Длительность периода отсчитывает не прикладная программа на рис. 123, а дракон-диспетчер, входящий в состав операционной системы реального времени.

Оператор Период означает выход из прикладной программы. Управление переходит к дракон-диспетчеру (с одновременной передачей параметра 4с).

Через каждые 4 секунды дракон-диспетчер передает управление в начало цикла ЖДАТЬ (точка Z на рис. 123). Если все три условия дают ответ «нет», оператор Период всякий раз возвращает управление в дракон-диспетчер.

Таким образом, функционирование цикла ЖДАТЬ обеспечивается совместными усилиями прикладной программы и дракон-диспетчера.

Этот вывод относится и к другим операторам реального времени.
На рисунках 113-123 показаны алгоритмы, которые имеют одно начало (один вход) и один конец (один выход).

В действительности программы реального времени имеют много входов и много выходов. Дополнительные входы и выходы появляются всякий раз, когда в алгоритм добавляется оператор Пауза, Период и др.

Но эти дополнительные входы и выходы на рисунках не показаны. Они не показаны из эргономических соображений — чтобы не загромождать рисунок.

http://drakon.su/_media/biblioteka/glav ... _vrem_.pdf


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Июнь, 2018 19:32 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
Тут вы путаете.
syntactic означает, что "пользователь" (программист) явно определяет "стабильные" состояния (в которых FSM возвращает управление в диспетчер).

Как раз ниже вы приводите, что "нужно бы сделать пунктирную линию" или разрыв. Это и есть syntactic "big step".
Как именно отмечать (пунктиром, или разрывом или иконкой) -- фиг знает. Тут нужно думать. Я про то, что в языке схем должно быть явное обозначение, что "вот это стабильное состояние", а "вот эти состояния" будут прокручиваться вместе без возврата в диспетчер.

В самих блок-схемах и Дракон-е нет никакого понятия "управленческое состояние" и быть не может -- используемые схемные элементы не имеют соответствующей метафоры (семантики). Если наблюдатель/моделирующий на основании каких-то операций (к примеру, в т.ч. и ввода/вывода) выделяет некие такты автомата -- это лишь его впечатления, но которые он может зафиксировать в виде иных специализированных формализмов за рамками блок-схем/Дракон-а.

А для указания "возврата управления в диспетчер" в синтаксисе Дракон-а/блок-схем (который выше подразумевался под словом "syntactic") есть средство, и не "фиг знает", а специализированное однозначное, именно специально для этого и предназначенное -- икона "вход/выход" (а пунктирные линии в соответствующем примере выше использовались лишь для того, чтобы как-то "добраться" до "выходов/входов" по мотивам эргономических принципов Дракон-а).
Однако, в Дракон-е правила блок-схем нарушаются, или имеется неоднозначное трактование их семантики.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Июнь, 2018 19:46 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Степан Митькин писал(а):
Читателю ДРАКОН-схемы иногда нужно знать, как ведёт себя алгоритм в той или иной иконе. Где ждёт внешнего события, где передаёт управление диспетчеру. Я сначала согласился с мнением TAU, что автор схемы должен такие вещи указывать: рисовать пунктирную линию вместо сплошной, например.

Но потом я понял, что такие дополнительные детали добавлять в язык не надо. Поясню. Вы ожидаете, когда пользователь нажмёт кнопку, в иконе Ввод. Этого события можно ждать год. Поэтому TAU говорит: рисуй пунктир! Покажи, что алгоритм здесь залипает! Владимир Ситников добавляет: хочу видеть, когда управление переходит диспетчеру! Покажи это на схеме!
Но ведь автор уже сказал "ждать" иконой Ввод. Значит, дополнительные средства типа пунктира избыточны. Не рисуйте пунктир, не делайте лишнюю работу.

Но передачу контроля хотелось бы видеть. Как быть? Я предлагаю дополнительные автоматические средства визуализации.

Ваши намерения понятны, и хотелось бы их поддержать, однако "ввод/вывод" длительностью хоть в 10 лет не выражает "ожидание" в том смысле, как Вы разбирали на примерах результатов того же Закревского. Семантика операций "ввода/вывода", кстати как и "паузы" в блок-схемах, никакого переключения контекста (передачи управления диспетчеру, освобождение потока) не предусматривает.
А уважаемый TAU указывает не на "рисуй пунктир!, а то алгоритм здесь залипает!", а прежде всего акцентирует на необходимости указания входа/выхода, как здесь, например:
https://forum.drakon.su/viewtopic.php?f=176&t=6221#p101429

В википедии про Дракон указано:
https://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D
Цитата:
Язык построен за счёт формализации и эргономизации блок-схем алгоритмов, описанных в ГОСТ 19.701-90 и ISO 5807-85.

В ГОСТ-е существуют не "дополнительные автоматические средства визуализации", а конкретно определена операция "ограничитель" или "терминатор":
http://www.pntd.ru/19.701.htm
Цитата:
3.4.2. Терминатор

Символ отображает выход во внешнюю среду и вход из внешней среды (начало или конец схемы программы, внешнее использование и источник или пункт назначения данных).

Все входы/выходы отображаются явно:
Вложение:
19_701_47.jpg
19_701_47.jpg [ 30.47 КБ | Просмотров: 7475 ]

В ГОСТ-е есть и иная операция "передача управления" в виде треугольника -- для "ожиданий" и "событий":
Цитата:
3.3.2.1. Передача управления

Символ отображает непосредственную передачу управления от одного процесса к другому, иногда с возможностью прямого возвращения к инициирующему процессу после того, как инициированный процесс завершит свои функции. Тип передачи управления должен быть назван внутри символа (например, запрос, вызов, событие).

Вложение:
19_701_50.jpg
19_701_50.jpg [ 49.09 КБ | Просмотров: 7475 ]

Однако, эта операция применяется только для "схем взаимодействия программ", где нет "выхода во внешнюю среду и входа из внешней среды", и не применяется в контексте "схем программ" (граф-схем алгоритма).
У Закревского, кстати, аналогично -- свой граф "событий" (в рамках визуальных средств), которые "управляют" действиями такими же, как и в граф-схемах алгоритмов (каждое действие может быть раскрыто своей схемой, фактически, "события" управляют исполнением алгоритмических граф-схем во времени -- организация процесса).
Графический формализм Зюбина не имеет "терминаторов" и основан на вариации "data flow"-схем, однако все входы/выходы (с "разрывами управления") обозначаются также явно вместе с причинами их возникновения.

Владимир Даниелович в пояснениях к иконам "заголовок" и "конец" ничего не указывает насчёт входа/выхода в алгоритм:
https://forum.drakon.su/viewtopic.php?f=62&t=6156

Но выше в теме он уточняет в своей цитате:
https://forum.drakon.su/viewtopic.php?f=142&t=6246&start=80#p101872
Владимир Паронджанов писал(а):
В действительности программы реального времени имеют много входов и много выходов. Дополнительные входы и выходы появляются всякий раз, когда в алгоритм добавляется оператор Пауза, Период и др.

Но эти дополнительные входы и выходы на рисунках не показаны. Они не показаны из эргономических соображений — чтобы не загромождать рисунок.

Т.е., всё-таки, "терминатор" такой же, как и в блок-схемах, ибо сохраняется их понятие "входа/выхода" в алгоритм. Однако, решение не отражать "терминаторы" в схемах и есть из разряда "субъективных пристрастий":
https://forum.drakon.su/viewtopic.php?f=142&t=6246&start=80#p101871
Владимир Паронджанов писал(а):
Надо смотреть на общую картину и не увлекаться субъективными пристрастиями

Если в составе изделия имеется элемент, для которого предусматривается фиксация на схемах в виде предопределённой фигуры/линии с заданной метафорой/семантикой, то этот элемент и должен быть на схеме. К примеру, в контексте материально-технических схем просто немыслимо, чтобы из чертежа выкинули узлы/детали только из каких-то там эргономических соображений.
Если есть желание не отображать "терминаторы", то их тогда необходимо вообще "изъять из обращения" (из "репертуара") и предусмотреть их семантику каким-то иным способом (для решения проблем эргономики). И тогда вообще отказаться от положения "формализации и эргономизации блок-схем".
Однако, всё же необходимо не забывать, что вряд ли "рядовые" пользователи, не перелопатившие талмуды по Дракон-у, глядя на его иконы, будут подразумевать какую-то иную, кардинально отличную у них семантику от семантики схожих фигур в блок-схемах, на что указывал TAU.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Июнь, 2018 19:50 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Степан Митькин писал(а):
Вот анализ поведения икон в ДРАКОНе с точки зрения реального времени и диспетчера:
https://drakonhub.com/read/realtime

Да и, кстати, Вы на своей страничке проигнорировали "терминатор" как важный элемент. Как и на смежной странице по прочим иконам:
https://drakonhub.com/drakon-reference


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Июнь, 2018 20:19 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
PSV100 писал(а):
В самих блок-схемах и Дракон-е нет никакого понятия "управленческое состояние" и быть не может -- используемые схемные элементы не имеют соответствующей метафоры (семантики). Если наблюдатель/моделирующий на основании каких-то операций (к примеру, в т.ч. и ввода/вывода) выделяет некие такты автомата -- это лишь его впечатления, но которые он может зафиксировать в виде иных специализированных формализмов за рамками блок-схем/Дракон-а.

Кхм. Дракон-схема как раз и фиксирует то, как именно должен трактовать её читатель. Скажем, под "развилкой" он должен понимать вполне конкретную операцию: без промедлений ответить на вопрос и пойти по нужной ветке.
Если же наблюдатель будет год кидать монетку под предлогом, что он развилку "так видит", то это неправильная трактовка Д-схемы.

PSV100 писал(а):
А для указания "возврата управления в диспетчер" в синтаксисе Дракон-а/блок-схем (который выше подразумевался под словом "syntactic") есть средство, и не "фиг знает", а специализированное однозначное, именно специально для этого и предназначенное -- икона "вход/выход"

Икона "пауза" является средством передачи управления "в диспетчер"?
Наверняка. Если так, то ваше слово "однозначно" неточное.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 188 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8 ... 10  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot] и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB