OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Суббота, 19 Июнь, 2021 05:36

Часовой пояс: UTC + 3 часа




Начать новую тему Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.  [ Сообщений: 42 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 10 Январь, 2021 22:58 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4531
Откуда: Россия, Орёл
Понятно какие: которые привнёс Центр совершенно необоснованно. На случай "а вдруг когда надо будет".

Предлагаю убрать и, тем самым, повысить нашу внутреннюю совместимость. Это гораздо важнее совместимости со сборкой Центра.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Январь, 2021 23:48 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4619
Откуда: Россия, Орёл
По-моему, пока единственный реальный выхлоп этих методов проявился в мульти-обероне в виде дополнительного обременения:
Вложение:
mob-host-files.png
mob-host-files.png [ 2.82 КБ | Просмотров: 732 ]
И в System -- Files_16 + Files_17. Поэтому согласен, лучше откатиться к эталонному интерфейсу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 04:40 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3096
Shared и Closed необходимы, чтобы была возможность избежать TRAP в NewWriter.

Ваш фикс с убиранием ассертов и возвращения NIL противоречит линии Oberon microsystems, которые его туда как раз в своих последних версиях добавили. Из соображений более раннего обнаружения ошибки там вставлены ассерты.

https://blackboxframework.org/stable/bl ... anges.html
#22 (Bug, 2015-02-10): HostFiles.NewWriter violating the specification
Код:
According to the specification (System/Docu/Files) in case of read-only files (shared) NewWriter should return NIL. The current implementation, however, generates a TRAP. The specification needs to be aligned with the implementation. In order to be able to avoid the TRAP, two new File methods (Shared() and Closed()) should be introduced that return the file's current state.

Reported by Ilya Ermakov, 2009-10-12.


Прошу перед дальнейшим обсуждением внимательно прочитать эту ветку:
https://forum.blackboxframework.org/vie ... &t=77#p700

Идеи возвращения совместимости с 1.6, ИМХО, лучше оставить, чтобы уже не ругаться из-за этого вопроса.
Кросс-платформенная версия несовместима с версией 1.6. Дальнейшая герметизация, внедрения Тайлера и Гершеля могут внести новые корректировки.

В мультиобероне не понимаю зачем поддерживается версия 1.6 - она уже устарела на 5 лет. Там много багов, и многие подсистемы или точнее "пакеты расширения функциональности Блэкбокса" (расширения) с ней несовместимы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 10:02 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 558
Откуда: Москва
Иван Денисов писал(а):
В мультиобероне не понимаю зачем поддерживается версия 1.6 - она уже устарела на 5 лет. Там много багов, и многие подсистемы или точнее "пакеты расширения функциональности Блэкбокса" (расширения) с ней несовместимы.

Есть 2 проблемы:
1. Неизменность интерфейсов. Если используется такое ООП, то интерфейс - это и обременение. Эта проблема общая, касается и Files, и Log, и Kernel.ThisMod. Если интерфейсы меняются, то возможны 4 варианта:
1.1 Не менять интерфейсы - то, что предлагает Борис Валерьевич,
1.2 Просто поменять интерфейс и проигнорировать совместимость с предыдущими версиями (то, что делал Центр). Любой программист обычного С поднимет это на смех.
1.3 Добавить еще интерфейсы, типа Files2. Так делал Microsoft в COM. Новые методы Closed, Shared будут в новом интерфейсе Files2. Где надо, реализуют.
1.4 Дополнительные конструкции в виде типов/процедур. Ну типа PROCEDURE (fs: FileState) Closed(f: File): BOOLEAN.

2. На производстве есть система управления требованиями от заказчика. И если программист скажет "не понимаю" и "устарела" - то данное ПО уберут из эксплуатации вместе с "устаревшим" программистом. Поэтому ранее разработанное ПО должно работать и сопровождаться.
Да, в МультиОбероне есть решение, как купировать "энтузиазм" Центра в части Files_16, Files_17.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 10:26 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4531
Откуда: Россия, Орёл
Вроде всё логично, но есть детали. :)
Иван Денисов писал(а):
Ваш фикс с убиранием ассертов и возвращения NIL противоречит линии Oberon microsystems, которые его туда как раз в своих последних версиях добавили. Из соображений более раннего обнаружения ошибки там вставлены ассерты.
Линия Oberon microsystems закончилась в 2013 году.

Иван Денисов писал(а):
Идеи возвращения совместимости с 1.6, ИМХО, лучше оставить, чтобы уже не ругаться из-за этого вопроса.
Это не вопрос совместимости с 1.6, это вопрос неизменности интерфейсов. Как Дмитрий Викторович и указывает.

Иван Денисов писал(а):
Кросс-платформенная версия несовместима с версией 1.6. Дальнейшая герметизация, внедрения Тайлера и Гершеля могут внести новые корректировки.
Если несовместимость будет сниматься только перекомпиляцией, то всё нормально.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 10:36 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4531
Откуда: Россия, Орёл
Напомню, что решение было предложено сразу: viewtopic.php?f=124&t=1948
Зачем Центр куда-то понесло с изменением интерфейса -- совершенно непонятно. При введении 64-битных файлов почему-то не было сделано простой замены INTEGER на LONGINT. Хотя логика абсолютно та же: зачем поддерживать совместимость с устаревшим 1.6? Там последствий испугались и сделали Files64.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 15:38 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3096
Борис Рюмшин писал(а):
Напомню, что решение было предложено сразу: viewtopic.php?f=124&t=1948
Зачем Центр куда-то понесло с изменением интерфейса -- совершенно непонятно.

Вполне аргументированно отказались от вашего предложенного решения, так как NIL и при переполнении кучи будет. Почитайте обсуждения Центра, пожалуйста.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 15:41 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3096
Дмитрий Дагаев писал(а):
2. На производстве есть система управления требованиями от заказчика. И если программист скажет "не понимаю" и "устарела" - то данное ПО уберут из эксплуатации вместе с "устаревшим" программистом. Поэтому ранее разработанное ПО должно работать и сопровождаться.
Да, в МультиОбероне есть решение, как купировать "энтузиазм" Центра в части Files_16, Files_17.

Так а зачем для нового компилятора то поддерживать старые проекты? Поддержка осуществляется инструментарием в котором на тот момент сделан проект. Есть у меня, скажем, один проект в компиляторе Astrobe, так я его и компилирую старой версией компилятора. Апдейты не покупаю. Зачем менять, если работает.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 15:43 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3096
Борис Рюмшин писал(а):
При введении 64-битных файлов почему-то не было сделано простой замены INTEGER на LONGINT. Хотя логика абсолютно та же: зачем поддерживать совместимость с устаревшим 1.6? Там последствий испугались и сделали Files64.

Files64 было сделано отдельно, потому что это было не исправление недочёта, а нововведение. Не всем нужны большие файлы.
А тут же речь про топологический изъян реализации HostFiles. Невозможно было обойти АВОСТ. Это было исправлено.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 15:49 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3096
Борис Рюмшин писал(а):
Вроде всё логично, но есть детали. :)
Иван Денисов писал(а):
Ваш фикс с убиранием ассертов и возвращения NIL противоречит линии Oberon microsystems, которые его туда как раз в своих последних версиях добавили. Из соображений более раннего обнаружения ошибки там вставлены ассерты.
Линия Oberon microsystems закончилась в 2013 году.

Так они ведь основывались на некоторой практике и опыте, или тут не стоит доверять их программным инженерам? Крис Барроус ведь выяснил, что они документацию не обновили, а добавили ASSRTы в код раньше. Как писали в Центре, тут всё логично, чтобы выявить ошибку как можно раньше. Иначе тот же ассерт потом сработает при разыменовывании NIL. И это может произойти намного позднее в коде.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 16:28 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4531
Откуда: Россия, Орёл
Мне интересно посмотреть, кто уже использовал на практике эти расширения.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 16:31 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4531
Откуда: Россия, Орёл
Иван Денисов писал(а):
Так они ведь основывались на некоторой практике и опыте, или тут не стоит доверять их программным инженерам? Крис Барроус ведь выяснил, что они документацию не обновили, а добавили ASSRTы в код раньше. Как писали в Центре, тут всё логично, чтобы выявить ошибку как можно раньше. Иначе тот же ассерт потом сработает при разыменовывании NIL. И это может произойти намного позднее в коде.

Это точно. Они на опыте основывались и собственной идеологии. Поэтому поставили ASSERT, и не тронули базовый класс. Поставили не совсем корректно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 19:43 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1372
Иван Денисов писал(а):
В мультиобероне не понимаю зачем поддерживается версия 1.6 - она уже устарела на 5 лет.

А зачем в вашей сборке поддерживается Office 20-летней давности?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 19:53 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3096
Trurl писал(а):
Иван Денисов писал(а):
В мультиобероне не понимаю зачем поддерживается версия 1.6 - она уже устарела на 5 лет.

А зачем в вашей сборке поддерживается Office 20-летней давности?

Там оставлен только последний вариант интерфейсов, и он всё ещё отлично работает с новым офисом ;)
Более новые привязки пока никто не сделал.
И сборка не моя... я мэйнтейнер, помогаю вести дело. Это общий дистрибутив.
P.S. Хотя понял, что тут сарказм сокрушается сразу на все варианты сборок кроме 1.6 :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Январь, 2021 20:56 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3096
Борис Рюмшин писал(а):
Иван Денисов писал(а):
Так они ведь основывались на некоторой практике и опыте, или тут не стоит доверять их программным инженерам? Крис Барроус ведь выяснил, что они документацию не обновили, а добавили ASSRTы в код раньше. Как писали в Центре, тут всё логично, чтобы выявить ошибку как можно раньше. Иначе тот же ассерт потом сработает при разыменовывании NIL. И это может произойти намного позднее в коде.

Это точно. Они на опыте основывались и собственной идеологии. Поэтому поставили ASSERT, и не тронули базовый класс. Поставили не совсем корректно.

Может тут проголосовать надо?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2021 12:02 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4531
Откуда: Россия, Орёл
Можно и проголосовать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2021 12:18 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3096
Борис Рюмшин писал(а):
Можно и проголосовать.

Есть на форуме голосовалка?
Только вот текст для голосования надо обсудить коллективно.
У Хельмута есть документ с описанием различий
http://www.zinnamturm.eu/pac/BlackBox-2 ... Center.txt

B01: HostFiles.NewWriter "returns" Trap 21 instead of NIL
viewtopic.php?t=1948
viewtopic.php?t=6169

issue-#22: HostFiles.NewWriter violating the specification
https://forum.blackboxframework.org/viewtopic.php?t=77
https://redmine.blackboxframework.org/issues/22
https://forum.blackboxframework.org/viewtopic.php?t=170

Через гугл транслейт
Код:
Реализация HostFiles.NewWriter нарушает спецификацию. Согласно спецификации (System / Docu / Files) в случае файлов только для чтения NewWriter должен возвращать NIL. Однако реализация BlackBox 1.6 генерирует трап. Спецификацию необходимо согласовать с реализацией.

Об этом сообщает Илья Ермаков, 2009-10-12.

Oberon Core или Framework Center?

Решение Oberon Core согласовало реализацию (HostFiles) со спецификацией (Files).

Решение BlackBox Framework Center (Проблема № 22) согласовало спецификацию (Файлы) с реализацией (HostFiles). Чтобы избежать TRAP, следует ввести два новых метода File (Shared () и Closed ()), которые возвращают текущее состояние файла.

Заметки

Иван Денисов
Аргумент состоял в том, что невозможно узнать, есть ли общий доступ к файлу или нет, с помощью фреймворка. Вот почему эта ловушка становится неизбежной.

В документации по файлам есть одно правило.

Открытие файла в общем режиме - это правило BlackBox; открытие файла в монопольном режиме - нечастое исключение.

Итак, эта проблема не должна возникнуть, если вы следуете этому правилу.

Однако как предотвратить TRAP в редких исключениях? Это означает, что программист должен предоставить эту проверку с помощью собственных переменных модуля и обеспечить строгую инкапсуляцию переменных файлов.

Один файл можно открыть с помощью dir.Old, другой - с помощью dir.New. Вы не можете отличить, создаете ли вы file.NewWriter или нет, имея только переменную Files.File.


Решение центра

Йозеф Темпл
Проверяя возвращаемое значение NIL, вы не можете увидеть, доступен ли файл для записи или нет. Почему? Потому что, если системе не хватает памяти, она также возвращает NIL при вызове NEW. Так что возвращение NIL не решает проблемы, кстати, весьма экзотической. Я никогда не испытывал этого и с трудом могу представить, что это актуально на практике. Обычно вы все равно знаете, что делаете со своими файлами.

Если это действительно важно, правильным решением было бы предоставить функцию получения, которая возвращает общее состояние файла. Поскольку возвращаемая информация соответствует параметру «общий» для «Старый», я бы назвал его Shared (), а не Writeable (). Это сделало бы соответствие параметра и геттера явным.

Та же проблема возникает с закрытыми файлами. Насколько мне известно, нет возможности узнать, был ли файл закрыт или нет. Опять же, это не было проблемой в течение многих лет, но это такая же проблема, как и с общими файлами.

Теперь мы можем ввести еще один метод получения с именем Closed (), но если его никто не вызывает, то действительно вопрос, нужен ли он нам вообще и нужен ли он сейчас. Однако, если мы вводим одно, мы должны вводить и другое. Аргумент в пользу их введения сейчас состоит в том, что теперь мы все равно делаем несовместимые двоичные файлы, требуя перекомпиляции всех пользовательских модулей. Таким образом, это изменение не вызовет дополнительной нагрузки на пользователей.

Если есть необходимость в проверке общего или закрытого состояния файла, для этой цели должны быть новые методы функций, естественно названные IsClosed (): BOOLEAN и IsShared (): BOOLEAN.

Возврат NIL, конечно, не является правильным исправлением, потому что NIL также возвращается в случае переполнения кучи.

В дополнение к удалению одного предложения из спецификации, мы должны добавить предварительное условие, которое определяет допустимые состояния при вызове NewWriter.

Вероятно, будет полезно иметь функции Closed () и Shared (), доступные при указании предварительного условия.

Closed () и Shared () относятся к состояниям «закрытый» и «общий». Следовательно, общий доступ подразумевает НЕ закрытый. Это позволяет выполнить проверку предусловия перед вызовом NewWriter и, таким образом, избежать TRAP, если предусловие не выполнено. Это используется редко (никогда), но для полноты картины я бы поддержал их включение.

Это также упростило бы указание предусловия:
Предварительно:
~ f.Closed () 20
~ f.Shared () 21

Энде.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2021 12:28 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3096
Борис Рюмшин писал(а):
Мне интересно посмотреть, кто уже использовал на практике эти расширения.

За примером такой экзотической проблемы надо к Илье Евгениевичу, ведь это он нашел такой случай.
Но так как он не использовал версию Центра, то и примера использования Shared() Closed() у него нет.
Я думаю, что эта проблема должна войти в анналы истории, и даже если мы проголосуем за возвращения интерфейсов, уже у всех зарубки на носу есть на этот счёт, и если вдруг NewWriter вернёт NIL, то припомните Shared() Closed() :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2021 12:38 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4531
Откуда: Россия, Орёл
Иван Денисов писал(а):
Борис Рюмшин писал(а):
Мне интересно посмотреть, кто уже использовал на практике эти расширения.

За примером такой экзотической проблемы надо к Илье Евгениевичу, ведь это он нашел такой случай.

Вот именно экзотичность проблемы и не даёт права на изменение базового класса.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2021 12:42 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9418
Откуда: Россия, Орёл
Иван Денисов писал(а):
Вполне аргументированно отказались от вашего предложенного решения, так как NIL и при переполнении кучи будет. Почитайте обсуждения Центра, пожалуйста.


Переполнение кучи - случай абсолютно вне обычной трассы выполнения ПО на ББ. Его реально обрабатывать только на уровне общего обработчика, а уж никак не как штатный IF в каждом месте.

Если куча переполнена, то в случае реализации HostFiles вообще будет внутренняя ошибка в NewWriter - NIL dereference.

ELSE NEW(w) END;
IF w.base # f THEN


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.  [ Сообщений: 42 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2021, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB