Фичи и баги OWEN Logic

[wal79]

Появился новый баг.

Проект в студию...

[wal79]

Это всё понятно, но ведь так не должно быть.

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

[wal79]

Не знаю, от релиза нового, или от нового макроса, стало выскакивать такое сообщение.

Значит так... Начинаю выкладывать результаты своих анализов... Насчет этого замечания... С явными связями надо быть аккуратнее (как облегчить работу с ними я еще подумаю ). Дело в том что работа схемы зависит от порядка исполнения этих самых обратных связей. И если выставить эти самые порядки (долго разбираться со схемой не стал выставил порядки экспериментальным путем) то переполнения схемы не будет и макрос будет работать исправно. А если на порядки забить и оставить их по умолчанию одинаковыми, то компилятор сам решает в каком порядке будет их анализировать. Отсюда могут возникнуть проблемы несоответствия работы макроса в редакторе и макроса в самом проекте. Поэтому будьте, пожалуйста, внимательны.
Попутно выявляя причины данного замечания нашел пару мест, где могу немного оптимизировать и улучшить немного работу этих самых явных обратных связей. Но из всего сказанного хочу выделить одно! При создании явных обратных связей не забывайте пожалуйста и про их порядки исполнения. Пока программно к этому не принуждаю, но возможно так и сделаю.
С дальнейшими замечаниями продолжаю разбираться...

[AI!]

Кто к Вам не хотел прислушиваться? И про какое слабое место компилятора Вы говорите?

не хотелось бы отвлекать вас от более важной пробмы, но если если это поможет сядьте по удобнее, и слушайте.

1) не буду приводить много примеров, приведу один но самай яркий.
- это проблема с длинной стеком
(которая частично решена в следующих версиях, но суть проблемы, или т.н. "слабое место" осталось!)
- слабое место компилятора в том, что он даже "симметричные" (AND, OR, ADD) блоки не считает таковыми.
т.е. компилятор никогда сам не поменяет входящие связи местами, и не станет обрабатывать их в обратном порядке.
(в данном примере мне получилось значительно снизить длину стека поменяв местами связи в схеме)
PS и динамический стек не убрал эту проблему, а только замаскировал её.

2) почему я думаю, что проблема возможно в этом? - приведу тоже один пример.
- это уже законченный проект макроса, с которым вы разбираетесь (который я дал ранее)
- в этой схеме тоже выдаётся ошибка нулевой длинны стека.
- НО если поменять местами 2 входа у блока ADD (внизу, посередине схемы), один вход константа "1", второй - SEL
то ошибка исчезнет!!! что и наводит меня на мысль, что причина проблемы одна и та же (т.н. "слабое место")

[AI!]

возможно я не прав, и проблема в другом:

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

(т.е. для компилятора важно в каком порядке он их перебирает,
если это так - то может просто пробовать сортировать их по какому то критерию?)

[wal79]

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

[Василий Кашуба]

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

Ждём-с.

[rovki]

А есть ли ограничения по количеству уровней вложения макросов в макросы >?

[wal79]

А есть ли ограничения по количеству уровней вложения макросов в макросы >?

Ограничений не будет...

[AI!]

Ограничений не будет...

что, и рекурсии возможны будут?