на самом деле есть ещё один фокус -"элемент пустышка" (NOP), этим элементом является граница макросаСообщение от melky
а когда макрос без "эфемерной оболочки", этой пустышки нет.
Подробнее объяснять в пятницу вечером - я пас.
на самом деле есть ещё один фокус -"элемент пустышка" (NOP), этим элементом является граница макроса
а когда макрос без "эфемерной оболочки", этой пустышки нет.
Подробнее объяснять в пятницу вечером - я пас.
начинающий профессионал
з.ы. На самом деле все ломается, просто совпало так, что показалось...
По моему мнению, последние SEL никак не должны ломать код, который стоит до них, так как именно с них нет каких либо связей в основной код. только на самих себя...
Ответ тут простой: ОЛ не учитывает координаты элементов при компиляции программы. Я, конечно, исходников не видел, но, полагаю, координаты не учитываются.
Поэтому это для человека легко понять "справа-слева", а с точки зрения алгоритма, никаких "справа" и "слева" нет. Есть просто клубок связей.
Из которых произвольная становится обратной в зависимости от фазы луны.
Чего тут непонятного?
Ещё момент: в момент, когда "замыкается" круг (ну, когда создают первую связь, которая в итоге образует кольцо) среда ещё как-то может обнаружить неладное и сказать, что так делать не нужно.
Но если потом удалят какую-то другую связь, которая участвовала в этом кольце и разорвут кольцо, то что должна сделать среда?
Вернуть первую из ранга обратных в ранг простых? Оставить как есть?
В общем, я пока считаю, что "неявных обратных связей" быть не должно, и подобные программы должны падать на этапе компиляции.
Тут уже передавали мои слова, что в связи с такими проблемами у пользователей, введем оповещение о подобных неявных обратных связях. Вопрос в том, что конкретно сделать компилятору в таких случаях. Как Вы предлагаете крах на этапе компиляции или просто предупреждение, но разрешить выполнение?! Конечно, с Вами согласен, что вариант с "крахом" обеспечит корректную работу макроса в любом случае. Но тогда старые макросы и проекты к сожалению не будут работать до полного устранения проблемы обратных связей. Вы, как пользователи, согласны пойти на это? Или сделать опциональной? Как Вас, пользователей, устроил бы вариант исполнения такого обнаружения?
программер
предложу своё мнение:
1) обратную связь нужно подсвечивать, но не в редакторе, а в симуляторе. наверно лучше опционально, как это ща сделано с подсвечиванием изменений.
2) неявная обратная связь обязательно должна быть вНЕ вложенных макросов.
Последний раз редактировалось AI!; 24.10.2016 в 11:12.
начинающий профессионал
Владимир Ситников последний пример посмотрите. Конечные SEL объединенные по управляющему входу каким образом могут влиять на общее выполнение программы вне зависимости где они установлены? , хоть где их ставь, на основной код по связям они не должны оказывать влияния.
Отключите управляющий вход и основной код работает как ни в чем не бывало.
ч.т.д.
Проблема в "блуждающей" неявной "обратной" связи (новый термин)
Сделал её явной, что бы не блуждала, и всё сразу заработало!
PS в алгоритм не вникал, просто сравнивал поведение с указанным выше "клубком управляющих связей" и без них.
Последний раз редактировалось AI!; 21.10.2016 в 21:46.
начинающий профессионал
AI! Вот уж никогда бы не подумал, что сигнал на счетчик это блуждающая связь ...
Каким же таким образом именно эта связь неявная обратная ?
Блуждающая обратная связь на то и блуждающая, что она не обязательно тут.
есть кольцо: -CTN1-EQ-RS1-TOINT-SEL-TOBOOL- и снова -CTN1-,
и в зависимости от того с какой стороны компилятор посмотрит на это кольцо, та связь и будет обратной...
ЕЩЁ РАЗ - есть кольцо, значит есть обратная связь!
PS а вот вам пример, который правильно работает с клубком и неправильно без оного..
(честно говоря лень выяснять где в этом кольце на этот раз обратная связь, предоставлю эту возможность вам)
Последний раз редактировалось AI!; 21.10.2016 в 22:13.
начинающий профессионал
AI!, все, что вы сделали, это заменили FTRIG на RTRIG и заработало ?
Ваши права
Ответить с цитированием