Умный человек - с лёгкостью решает любые проблемы. Мудрый - их не создаёт.
https://vk.com/a.matica
Объясняю:
1) В проекте была связка write to FB + CTU.
2) Да, параметр CTU не обновлялся
3) Но блок write to FB пытался записать в CTU какую-то муть. И лишь ошибка в ОЛ была тем самым звеном, которое удерживало схему в работоспособном состоянии
4) Если теперь "ошибку исправить", то write to FB таки сможет записать свою муть в CTU, схема начнёт работать по-другому и, соответственно, может случиться авария на производстве.
Разумеется, такое не в каждом проекте может быть. Но полностью исключать такое нельзя. Поэтому трезвый подход (с точки зрения ОВЕН) состоит в том, чтобы рассматривать эту "особенность поведения ОЛ" именно как особенность поведения, а не как "ошибку, которую просто исправляем и всего делов". Повторюсь: править это поведение можно и нужно, но не просто "теперь это работает так-то", а так, чтобы старые проекты не ломались.
В общем, ключевое слово -- обратная совместимость.
Зачем писать всякую муть про гадание? Я не гадаю, а реальных примерах рассматриваю аргументы.
Поосторожнее со словами.
Когда умные обсуждают программные средства, то вы слушайте, и учитесь (если хотите).
И, напомню вам, что моё предположение о принципе работы ОЛ-ПР оказалось полностью верным. Так что вместо многозначительных многоточий лучше бы слушали умных людей и учились.
Мне (как и любому другому пользователю ОЛ) должно быть совершенно без разницы в каком средстве сделан блок CTU. Я уверен, что ОВЕН могут починить блок CTU. И я уверен, что эта починка не затребует хоть сколько-нибудь существенных ресурсов.
Почему именно они не чинят -- я вообще без понятия. Может, программисты в отпуске, может забылась задача в общем списке, может все заняты на проекте owencloud. Да мало ли причин?
Я же говорил про другое: даже, если организационных проблем нет (т.е. волшебная палочка взмахнула, программисты есть, тестировщики есть, все готовы починить связку write to FB + CTU), то всё равно есть техническая проблема. Вот нельзя просто взять и изменить поведение старого блока CTU -- это может сломать имеющиеся ОЛ проекты. Я не пытаюсь угадать/предполагать причину того, что ОВЕН не исправляет эту "ошибку".
Почему же не делается?! Делается и уже очень давно, иначе развитие лоджика застопорилось бы много лет назад. Когда задумывался лоджик ряд вещей было упущено, цели лоджику ставились другие, не такие как сейчас. Насчет того, что что-то разработчики не сделали, какие-то задачи упустили... Есть оперативный план, в него входят задачи, сортируются по приоритетам. Если какая-либо задача не была сделана, значит коэффициент важности и трудозатратности этой задачи не в верху списка.
Дать доступ к CTU - задача как менее приоритетная так и более трудозатратная. Как rovki уже сказал этот блок выполнен как гибрид. Он и не макрос и не элементарный блок. Поэтому есть определенные сложности. Никто не говорит что они нерешаемые, но время будет потрачено.
программер
Вы меня неправильно поняли. В том сообщении (#221) я не спрашивал "почему в ОЛ не исправляется конкретная ошибка с CTU". Я спрашивал почему в ОЛ не встречается подход, когда среда обнаруживает устаревшие конструкции кода и предлагает пользователю обновить их до работоспособных.
Возьмём для примера те же "неявные линии задержки". Сейчас ОЛ 1.9 обнаруживает циклы и говорит "у вас тут цикл". Предлагает ли ОЛ заменить одну из связей на линию задержки? Нет. Могла бы? Могла.
Точно так же: "Вообще говоря, у вас тут используется <<write to FB + CTU>>. Такая конструкция не работает. Хотите заменить её на <<write to FB + CTUD>>?" И варианты <<Да, конечно>>, <<Нет, и так сойдёт>>. Иными словами, само "устранение проблемы" можно свести к тому, чтобы среда просто предлагала пользователю исправить CTU на CTUD (ну или как называется рабочий блок в ОЛ). Т.е. CTU переделывать не нужно, прошивку обновлять не нужно. Достаточно просто на стороне ОЛ сделать замену CTU блока на рабочий. Я не призываю именно к такому варианту решения. Я просто показываю пример, как может приносить пользу механизм "нашли устаревший код и предложили пользователю упростить-исправить".
Если оказывается, что про подобные автоподсказки думали и они не поместились в бюджет, то, конечно, печально. Ну, делали же подкраску циклов из связей. Наверняка несложно было бы за одно сделать и замену связи на линию задержки с подтверждения пользователя.
PS. Про то, почему не решается конкретная проблема с CTU меня не интересует (как я и писал в #226) и я прекрасно понимаю что такое приоритеты.
Последний раз редактировалось Владимир Ситников; 19.05.2017 в 22:23.
Последний раз редактировалось rovki; 19.05.2017 в 22:51.
электронщик до мозга костей и не только
Я правильно понял о чем Вы говорите...
CTU+WriteToFb не существует, поэтому анализатору и не надо ничего делать. Со старыми проектами тут проблем как раз таки такой нет, какую Вы описываете. Тут только решение проблемы с "гибридными" блоками.
А вот кстати насчет циклических связей... Есть задача похожая задача.
программер