Фичи и баги OWEN Logic

[wal79]

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

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

[anthrwpos]

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

А что такое эта самая прозрачность макроса?

[pop70]

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

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

[wal79]

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

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

[pop70]

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

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

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

[wal79]

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

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

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

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

[pop70]

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

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

[wal79]

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

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

[anthrwpos]

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

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

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

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

[wal79]

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

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

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