Логика работы скриптов

Программное обеспечение Rule Engine
1

не знаю куда куда приткнуть, но есть некоторые вопросы по логике работы скриптов.

просмотр правил вроде в документации описан, а что происходит с кодом вокруг правил? Допустим есть скрипт, где описаны переменные (на верхнем уровне) и некоторые функции и правила.
Как все это видится в системе? Если срабатывает правило из этого скрипта и меняет переменные, они остаются в измененном состоянии до следующего срабатывания правила из скрипта? или после окончании работы правила данные скрипта стираются из памяти?
А если в миллисекунды правило срабатывает несколько раз, что происходит?
А если в одном случае правило отработало быстро, а в другом какая то задержка? Например ждет ответа от оборудования.
Если два одновременно работающих правила вызывают функция из этого скрипта, это будут два разных экземпляра функции? ее внутренние переменные не пересекутся?

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

И да, в движке 2.0 декларировано изолированное исполнение скриптов. А что же происходит в первом? То есть функции или правила из разных скриптов могут пересекаться?

Извиняюсь, может не внимательно читал, но не нашел ответы на эти вопросы.

3

Здравствуйте, maxim2!
Много серьезных вопросов. Давайте попробуем разобраться.

В текущей версии движка правил (основанном на Duktape) переменные и функции, задаваемые вне кода (то что вы подразумеваете под “верхним уровнем”) находятся в глобальном пространстве имен и доступны из любого сценария. В статье “Движок правил wb-rules 1.7” в самом начале приводится пример, как видятся глобальные переменные сейчас (текущий вариант работы движка называется там, по понятным причинам, “раньше”).
Попробуйте выполнить примеры кода и посмотреть, как все будет отрабатывать.

В описании текущего движка на Github по поводу глобальных переменных явно сказано что “Во избежание труднопредсказуемого поведения в функциях, фигурирующих в when, asSoonAs и whenChanged не рекомендуется использовать side effects, т.е. менять состояние программы (изменять значение глобальных переменных, значений параметров, запускать таймеры и т.д.) Следует особо отметить, что система не даёт никаких гарантий по тому, сколько раз будут вызываться эти функции при просмотрах правил.”

Значения глобальных переменных, если с ними аккуратно обращаться, хранятся неизменными и доступными для всех сценариев на время работы runtime-среды движка. Если вы остановите и перезапустите движок правил, все вновь присвоенные значения будут утеряны. Все, что вы хотите сохранить, определяйте как параметры виртуальных устройств (смотрите раздел “Объект dev”) или же храните в файловой системе, вызывая системные функции.

Цитата из документации на Github : “Глобальные переменные и функции, определения которых удалены из правил, также не удаляются до перезагрузки движка правил (service wb-rules restart). В то же время удаление определений правил и виртуальных устройств отслеживается и обрабатываются, т.е. если, например, удалить правило из .js-файла, то это правило более срабатывать не будет.”

Далее в следующем комментарии.

4

Движок правил, хотя это может быть неочевидным, — однопоточный. То есть классической логики прерываний, когда одновременно возникло два события, и движок одновременно бросается их обрабатывать, — нет. Источником событий является, в основном, последовательная очередь mqtt-сообщений, которые в порядке поступления обрабатываются движком. Кроме того, выполнение кода могут инициировать таймерные функции.
Таким образом, миллисекунды – не миллисекунды: все будет обработано последовательно. Движок будет дожидаться выполнения всех синхронных операций. Обычно для операций с непредсказуемым временем выполнения используются асинхронные вызовы с callback-функциями, которые будут вызваны тогда, когда результат операции завершится.
Таким образом важно не перегружать обработчики событий долгоисполняемыми фрагментами кода – все будет тормозить и зависать.

Далее в следующем комментарии.

5

Да, еще в описании не сказано, что если вы скрипте есть самовызываемые функции, то при нажатии кнопки Save они будут выполнены, однократно.

В начальном списке не было, но хочется еще понять,

Глобальные переменные и функции, определения которых удалены из правил, также не удаляются до перезагрузки движка правил

а если функция не удаляется, а изменяется, после нажатия Save уже работает новая?

эти мелочевки оказались важны скорее не для работы контроллера, а для написания и отладки кода.

6

Все там сказано, хотя это и так понятно человеку, знающему javascript.

7

покажите не знающему.

8

См. раздел “Создание однотипных правил” на странице Wiki.

Что бы проинициализировать правила, нужно проинтерпретировать js-файл, т.е. выполнить код, который в нем располагается.

Например, defineRule(...) – это уже выполнение кода, который должен запуститься после нажатия Save. Иначе, система не получила бы информацию о правилах в файле.

Еще, рекомендую: https://learn.javascript.ru/first-steps

9

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

Функции и правила из разных файлов скриптов в текущей версии движка пересекаются. За тем, чтобы этого не происходило, надо следить при написании кода, поскольку нет гарантированного порядка, в какой момент исполнения функция будет определена в первый раз, а в какой – переопределена из другого скрипта.

10

В заключение хотелось бы отметить, что экспериментировать с кодом не только можно, но и нужно. Для понимания всего того, в какой последовательности и как выполняется код, на этапе разработки вставляйте печать отладочных сообщений log(); везде, где можно.
Вывод можно смотреть в окне, которое открывается в браузере при нажатии на “гаечный ключ”:
%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5
%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5859×451 16.5 KB

11

я уже один раз заметил, вы относитесь к людям которые считают, что если им что-то очевидно, то и всем тоже должно быть очевидно. К сожалению у нас в России почему то такие люди преобладают в разработках конечных устройств. И именно по этому эти устройства или софт не пользуется популярностью.
Вот именно по этому Apple в мгновение ока завоевала рынок смартфонов. Потому что девайсы под windows ce и прочие были абсолютно не user-пригодными, и именно из за того, что разработчики ставили во главу угла “ведь очевидно же”.

12

Я предполагаю, что команда Wiren Board выбрала популярный javascript в т.ч. потому, что надеется, что хотя бы по поводу синтаксиса языка и правил его работы не будет “глупых” вопросов. Потому что в сети есть куча хороших ресурсов, учебников, форумов, а на каждом компьютере сейчас стоит тренажер javascript в виде браузера.

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

Вы, как бы, тоже это поймите, пожалуйста, и отнеситесь к этому с пониманием.

1 лайк
13

Python — высокоуровневый язык программирования общего назначения, ориентированный на повышение производительности разработчика и читаемости кода. Синтаксис ядра Python минималистичен. В то же время стандартная библиотека включает большой объём полезных функций.

хотя я по нему тоже не спец. Но лично мне его код намного понятнее. Как и многим другим.

1 лайк
14

Кому-то понятен, а кому-то не понятен. А кого-то вообще тошнит от необходимости выравнивать блоки кода пробелами. А кто-то вообще проклял создателей после выхода Python 3.

И что?

15

в вашем ответе можно легко заменить слово Python на Javascript.

16

Нельзя, потому что в javascript нет выравнивания кодовых блоков пробелами и он обратно совместим.

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

17

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

18

Вы отстали от жизни на 20 лет.

19

аккуратнее, не слишком далеко убегите вперед, вас могут не догнать.

20

Всем привет! Уважаемые @unicode и @maxim2, я не могу вам запретить обсуждать здесь, что лучше: Python или Java Script. Но, к сожалению, в таких обсуждениях будет очень сложно уловить вопросы для техподдержки. Так что призываю делать это в какой-нибудь одной теме, а мы в неё будем заходить пореже.

4 лайка