Owen Logic 110b BUGREPORT

[wal79]

#111b релиз.

Интересно кто догадался проверять операции вычитания на переполнение???? Вроде как раньше всё работало. Это же не кодесис! Я не могу кусок ветки не считать! А то что он у меня селектом отсекается потом - это типа не важно???? Слов не хватает - 111 в топку тоже!
Безымянный.png
А ГЛАВНОЕ! Читаем документацию!!!!
Если при выполнении операции на первом входе (V1) значение числа меньше второго (V2), то результатом будет число, полученное сложением младшего числа плюс 0x100000000 (4294967296) минус значение числа большего: [(V1 + 0x100000000) – V2] = Q.

Товарищи программисты, но вы хотя-бы изучите СВОЮ документацию перед посадкой за клавиатуру!


З.Ы. С прорисовкой проблемы пропали.

Программисты тут ни при чем!!! Была команда в симуляции сделать проверку - я сделал так как было сказано! Причина в ограничениях внутреннего ПО прибора. Другой момент, что могу от себя сделать функционал проверки иначе немного. Позволять работать симулятору дальше, но сообщить о переполнении.

[sdy]

Программисты тут ни при чем!!! Была команда в симуляции сделать проверку - я сделал так как было сказано! Причина в ограничениях внутреннего ПО прибора. Другой момент, что могу от себя сделать функционал проверки иначе немного. Позволять работать симулятору дальше, но сообщить о переполнении.

1. Однозначно, но учтите на странице таких ситуаций море - а вообще не очень понятно зачем? При симуляции все значения - видны - подкрасьте отрицательное красным да и всё! Но, самое главное - не симуляция! По факту, проект - не собирается.

2. Не понятна "жалоба" на внутренне ПО. Теперь переход через 0 в запрете? Почему? Хотите сказать реле перегрузится? ОСТОРОЖНО! ТАК ДЕЛАТЬ НЕЛЬЗЯ!

3. Иногда использование особенностей перехода через 0 ОЧЕНЬ НЕОБХОДИМО, например 0 - 1 = $FF...FFF - Максимальное целочисленное число, или полная битовая маска - очень удобно иногда, особенно при построении логики путем умножения.

4. Отрицательные числа - вещь необходимая! Переполнение (переход через 0) - это целенаправленный вариант реализации типа int на word (что и задокументировано в овенлогике ((V1 + 0x100000000) – V2) )! Вообще, отнимать 1 добавляя $FFF...E к числу - ЭТО НОРМАЛЬНО для хорошего программиста, т.к. иногда проще менять константы чем делать кучу ветвлений!

5. НИКОГДА! НИКОГДА! НИКОГДА! НИКОГДА! НИКОГДА! Не меняйте в языке программирования (а овенлогик по сути графический язык) уже работающий задокументированный функционал - ваши покупатели проклянут Вас и не будут покупать вашу продукцию, т.к. не всегда есть возможность откатиться на версии 5-6 летней давности. А самое главное помните - самое ценное у любого программиста - его наработки, он достает оттестированный, облизанный макрос 10 летней давности и вставляет его в проект и уверен - он должен работать! И если его поведение поменяется - то ведь и станок можно загубить и не дай бог человека убить. Кто будет виноват? Поменяли функционал - меняйте название языка. А хотите складывать (вычитать) с контролем переполнения пожалуйста:

5. Если кто-то захотел сделать проверку переполнения - то для этого в ассемблере есть флаги, процессоры от этого как правило не "страдают". Добавьте НОВЫЕ МАКРОСЫ! ПУСТЬ ТАМ БУДЕТ ДВА ВЫХОДА (результат и переполнение)! МЫ ВАМ СКАЖЕМ ТОЛЬКО СПАСИБО. Главное в документацию их не забудьте добавить. В овенлогике катастрофически мало наборов базовых макросов (одна работа с реальными числами чего стоит), пусть растет их ЗАДОКУМЕНТИРОВАННОЕ число, а не меняются функции.

З.Ы. Коллеги помните! В любых более менее серьезных проектах, сперва создаётся документация (описываются интерфейсы, функции, параметры, поведение) и ТОЛЬКО потом делается функционал. Действия в обратном порядке - приводят к тупикам, грубым ошибкам и срывам сроков. Документация может быть плохой, на кусочке бумажки, в виде схемы, но должна быть!

[Евстигнеев Максим]

1. Однозначно, но учтите на странице таких ситуаций море - а вообще не очень понятно зачем? При симуляции все значения - видны - подкрасьте отрицательное красным да и всё! Но, самое главное - не симуляция! По факту, проект - не собирается.

...

З.Ы. Коллеги помните! В любых более менее серьезных проектах, сперва создаётся документация (описываются интерфейсы, функции, параметры, поведение) и ТОЛЬКО потом делается функционал. Действия в обратном порядке - приводят к тупикам, грубым ошибкам и срывам сроков. Документация может быть плохой, на кусочке бумажки, в виде схемы, но должна быть!

Здравствуйте!

Спасибо за замечания. Добавить нечего, всё по делу.

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

Намечен следующий план мероприятий:
На уровне платформы "OWEN Logic":
1. Анализ арифметических операций на соответствие изначальной документации.
2. Приведение функционала к описанию в документации: функционирование Интерпретатора и Симулятора.
3. Расширенное документирование функционала в пользовательской документации.

На уровне изделий:
1. Исправление в программном обеспечении изделий на базе платформы "OWEN Logic".

На организационном уровне:
1. Документирование и перекрытие unit-test-ами данного функционала.

[Алексей Геннадьевич]

Программисты тут ни при чем!!! Была команда в симуляции сделать проверку - я сделал так как было сказано!

Неукоснительное и точное выполнение распоряжений начальства в РФ приравнивается к саботажу.

Причина в ограничениях внутреннего ПО прибора.

На ассемблере команды целочисленного вычитания по-другому стали работать?

Другой момент, что могу от себя сделать функционал проверки иначе немного. Позволять работать симулятору дальше, но сообщить о переполнении.

Верните как было. Проверки на переполнение - это вопросы пользователя.

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

P.S.
И что я в проект ставить теперь должен, после таких "выкрутасов"