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


#1

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

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

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

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

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


Информационная поддержка продукта
#2

#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


#11

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


#12

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

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

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


#13

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

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


#14

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

И что?


#15

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


#16

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

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


#17

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


#18

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


#19

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


#20

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