Фичи и баги OWEN Logic

[wal79]

Угу.
Я Вас сразу предупреждал.
Тупиковый путь.
Либо при анализе неявно "разворачивать" макрос, и анализировать схему с "подставленными" макросами, т.е. без макросов как таковых, либо никакой "прозрачности".
Вот бы ещё как-то победить необходимость переподставлять макрос в схему после редактирования макроса...

Ну тут можно долго разглагольствовать о том кто о чем говорил и предупреждал. Владимиром тогда было высказано как замечание, я глубоко тогда не копнул. Я рассматриваю любое ваше пожелание или замечание. Либо соглашаюсь с ним либо отвергаю. Тогда мне показалось заманчивой затеей, хотя повторюсь что никогда не говорил что макрос абсолютно прозрачен. Видимо меня не так поняли. Анализатор (транслятор) конечно же должен учитывать макрос . Макрос для него как inline функция. И представленное Владимиром предложение о "прозрачности" макроса в итоге концептуально неверно. Сейчас, посовещавшись со специалистами в предметной области, я удостоверился что мои сомнения оправданы. Схемы в том варианте и должны работать по разному.

[RomX]

У Вас макрос KnTtr был с 4 входами, а стал с 3. Так? Вы его заменяли на схеме в итоге?

Изначально отредактировал макрос. Убрал вход. При этом обычно другие экземпляры макросов подсвечиваются красным и их надо перевставлять. Тут этого не произошло. В дальнейшем я их перевставил и баг прошел.

[pop70]

Ну тут можно долго разглагольствовать о том кто о чем говорил и предупреждал.

Да не. Я ж не в укор.
Меня как раз по тому предложению и напрягло то, что макрос в общем случае НЕ ФУНКЦИЯ, а, как минимум, ПРОЦЕДУРА (а ещё точнее - объект, имеющий "собственное состояние"). А анализ схемы ведётся как для функции. Поэтому устранить неоднозначность поведения с обратными связями "вокруг макроса", пытаясь учитывать обратные связи внутри него ("прозрачность" без развёртывания), как минимум, очень сложно, как максимум невозможно.

Ну да ладно....
А вот можно ли как-то проработать вопрос с тем, чтобы редактирование макроса не требовало его перевставки в основную схему?
Просто, решение с перевставкой противоречит принципу структурированности программ.
Ну, т.е., если есть программа, использующая компоненты, то редактирование компонента не должно требовать его переопределения в программе.
Иначе получается ерунда.
Пишешь программу, используя десяток экземпляров одного компонента, и при небольшом изменении самого компонента - заново перерисовывать всю программу?
Не логично и не удобно. Даже если количество входов/выходов изменится - это не повод для требования перевставки.

[wal79]

И ещё один баг внутри ФБ VLV1, в режиме симуляции. Вложение 32832

А в окне просмотра переменных что показывают переменные inc и saw?

[wal79]

Да не. Я ж не в укор.
Меня как раз по тому предложению и напрягло то, что макрос в общем случае НЕ ФУНКЦИЯ, а, как минимум, ПРОЦЕДУРА (а ещё точнее - объект, имеющий "собственное состояние"). А анализ схемы ведётся как для функции. Поэтому устранить неоднозначность поведения с обратными связями "вокруг макроса", пытаясь учитывать обратные связи внутри него ("прозрачность" без развёртывания), как минимум, очень сложно, как максимум невозможно.

Ну да ладно....
А вот можно ли как-то проработать вопрос с тем, чтобы редактирование макроса не требовало его перевставки в основную схему?
Просто, решение с перевставкой противоречит принципу структурированности программ.
Ну, т.е., если есть программа, использующая компоненты, то редактирование компонента не должно требовать его переопределения в программе.
Иначе получается ерунда.
Пишешь программу, используя десяток экземпляров одного компонента, и при небольшом изменении самого компонента - заново перерисовывать всю программу?
Не логично и не удобно. Даже если количество входов/выходов изменится - это не повод для требования перевставки.

Вы не правы. Изменив количество входов Вы меняете сигнатуру функции. Здесь должны быть вмешательство со стороны пользователя. А если Вы меняете только тело функции, то переустановка макроса на схеме и не требуется. Единственно, есть баг, к сожалению существующий уже на протяжении не одного релиза, если редактируете макрос со вложенностью более 1, то в том макросе, где используется редактирующийся макрос обновление сразу не наступит. Нужно будет заново переоткрыть макрос. Об этом я знаю, и надеюсь будет время в ближайшие сроки исправить.

Конечно, можно сделать то, что Вы хотите, но это уже будет в качестве дополнительного функционала.

[wal79]

Изначально отредактировал макрос. Убрал вход. При этом обычно другие экземпляры макросов подсвечиваются красным и их надо перевставлять. Тут этого не произошло. В дальнейшем я их перевставил и баг прошел.

Мда... Чудеса. Видимо есть какой-то сценарий, когда макрос не отметился как критически измененный. Не могли бы Вы воспроизвести и описать последовательность действий прямо по-шагово.

[pop70]

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

Не обязательно. В ОЛ неиспользуемые входы инициализируются 0. Ошибки не будет, если новый вход будет никуда не подключен.
Если входов уменьшится, то просто связь к удалённому входу "повиснет в воздухе". Т.е., просто удалится.
Т.е., на языке .net все макросы имеют на входах значения "по умолчанию". Добавляется входная переменная, инициализированная по умолчанию 0 - и никаких ошибок, и от пользователя ничего не требуется.
Перерисовать в схему новый фб вместо старого - тоже никаких проблем быть не должно.
Ну так мне кажется. Хотя, Вам "изнутри" виднее, конечно.

[anthrwpos]

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

Вообще по общепринятой терминологии, макрос - это идентификатор, который транслируется в некий неизменный участок кода.
Сколько раз его транслятор встретит - столько раз вместо него вставит этот участок.
Функция - это идентификатор, который компилируется в адрес вызова, по которому начинается сама функция.

У нас в ОЛ таки макросы или функции?=)

upd: Ура, сами макросы работают адекватно. Но появился новый бажок - не отслеживается состояние флоат переменных.bug.PNG
Проект тот-же, на картинке внутренности макроса VLV

[wal79]

Вообще по общепринятой терминологии, макрос - это идентификатор, который транслируется в некий неизменный участок кода.
Сколько раз его транслятор встретит - столько раз вместо него вставит этот участок.
Функция - это идентификатор, который компилируется в адрес вызова, по которому начинается сама функция.

У нас в ОЛ таки макросы или функции?=)

Если внимательно прочитаете, то я сказал inline функция. Компилятор встречая ее каждый раз встраивает тело функции в код.

[wal79]

Не обязательно. В ОЛ неиспользуемые входы инициализируются 0. Ошибки не будет, если новый вход будет никуда не подключен.
Если входов уменьшится, то просто связь к удалённому входу "повиснет в воздухе". Т.е., просто удалится.
Т.е., на языке .net все макросы имеют на входах значения "по умолчанию". Добавляется входная переменная, инициализированная по умолчанию 0 - и никаких ошибок, и от пользователя ничего не требуется.
Перерисовать в схему новый фб вместо старого - тоже никаких проблем быть не должно.
Ну так мне кажется. Хотя, Вам "изнутри" виднее, конечно.

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