Конечно пользователь должен понимать как создавать схему. Но Вы гребете все под свой уровень ,что не верно.Сообщение от Владимир Ситников
Предлагаю в этой ветке спор уже закончить. Все же ветка создана для сбора багов. За баги, о которых Вы сообщили спасибо, будем работать над ними.
Последний раз редактировалось wal79; 29.08.2017 в 13:16.
программер
Задумайтесь над тем, как определяется "является ли что-то багом или нет".
Является багом, значит "результат ОЛ не соответствует ожидаемому". Это самое ожидаемое должно откуда-то возникать.
И тут вы говорите, что "описание правил вычисления ОЛ схемы" пользователям не нужно, т.к. они просто схемотехники, и им без разницы как вычисляется схема, лишь бы ОЛ не падало.
Я не просто так в этой теме вопросы задаю про "правила вычисления". Они имеют самое прямое отношение к тому, что считается багом, а что нет.
Вот в 1.9.141.11543 взяли и поменяли подход работы с макросами:
Что значит эта самая "прозрачность"? О какой "неправильной логике работы речь"? Как раз на подобные вопросы обычно и отвечает спецификация (которой у ОЛ нет, т.к. схемотехникам пофиг). При этом, в спецификации зачастую приводятся примеры, показывающие пограничные случаи.Релиз 1.9.141
Убрана "прозрачность" макроса при анализе схемы
Рассмотренный ранее сценарий работы фрагмента кода как в макросе, так и просто в схеме отменен за неправильностью логики работы.
Вы настаиваете на том, что единственный способ понять "что вернёт схема" это "запустить в ОЛ". Что ж. Печально. Это означает то, что так и будут ошибки выявляться (или вообще не выявляться) точечно типа "на такой-то схеме линия задержки снова не так работает", а "простосхемотехники" будут по-прежнему брюзжать, что "в нормальных схемных редакторах вообще без обратных связей/линий задержки обходятся".
Последний раз редактировалось Владимир Ситников; 29.08.2017 в 14:02.
Печально это звучит или нет, но Вы верно сказали что на 100% удостовериться в правильности работы следует запустить симулятор. Именно такие требования и ставились. Я понимаю Ваше желание понять специфику работы. Обратные связи преподнесли в свое время много сюрпризов, о которых не задумывались при разработке лоджике, да и не только обратные связи. Исторически лоджик рос, не знаю даже какое слово будет звучать более правильно, спонтанно что ли... Смысл я надеюсь понятен, иначе разъяснить не могу. Спецификации нет, это факт. Да что там, справки по сути толковой нет, только краткая справка и далеко не по всем функциям лоджика. Работаем над этим. Больше сказать нечего.
программер
Очень интересное признание. Т.е. делали так как кому на ум взбредет. Не солидно как-то все это.
Господа овеновцы, найдите наконец толкового исполнителя для разработки адекватной среды для ПР. XXI век на дворе.
Последний раз редактировалось Вольд; 30.08.2017 в 13:22.
Разработчик, во первых указал что не знает какое слово подобрать, поэтому не стоит передергивать и самостоятельно делать выводы как делался лоджик. Продукт делался от обратной связи тех кто с ним продолжительное время работает и сделал ни один проект для производства. Когда же сделали попытку послушать всех любопытствующих, со своими представлениями о IDE, так и пошли критические ошибки
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Если в стане разработчиков разброд и шатания, то другого результата и быть не может.
Нет у разработчиков четкой идеологии и представления о предмете.
Последний раз редактировалось Вольд; 30.08.2017 в 13:34.
есть хорошая статья по поводу изолированности разработчиков, от таких как Вы https://habrahabr.ru/company/retailrocket/blog/336430/, жаль что модераторы не придерживаются такого принципа
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Каждый думает в меру своего развития. Что я подразумевал под спонтанностью. Первоначально были предъявлены определенные требования к продукту ОЛ. Согласно этим требованиям была разработана архитектура приложения. Требования были просты и задачи перед продуктом ставились простые. Увидев
положительную реакцию пользователей впоследствии стали ставиться все более накрученные требования. Политика была направлена на обратную связь от пользователей. Да, курс продукта менялся, иногда даже слишком кардинально. Иногда доходило до кардинальной переработке архитектуры и знаний о предметной области. И до сих пор мое мнение не изменилось насчет обратной связи. Что продукт прежде всего должен учитывать желание рынка, пользователей. Конечно вы должны понимать что кардинальные перемены в архитектуре влекут за собой баги. Проблема ОЛ в том что он выходит на рынок сырой, так сказать с пылу жару. Вы можете критиковать разработчиков как угодно. Может лоджику далеко до каких-то других продуктов конкурентов. Но этот продукт имеет немаловажный плюс: реактивность обратной связи пользователей. Лоджик создавался как продукт в котором легко создавать алгоритмы простой и средней тяжести. Такое было одно из требований. Поэтому многие вещи скрыты от пользователей. Можете дальше ругать лоджик и разработчиков на чем свет стоит. Понятно, что всем не угодишь.
программер
В той схеме, о которой мы говорим вы пытаетесь линию задержки превратить в обратную связь. Вот вы создали макрос, назначение которого просто задержать сигнал на цикл. Вы используете этот макрос в схеме, зацикливая его. И логично что вы увидите двойную задержку.
программер
Ваши права
Ответить с цитированием