OberonCore
https://forum.oberoncore.ru/

#046 Библиотекарь модулей
https://forum.oberoncore.ru/viewtopic.php?f=134&t=6700
Страница 3 из 4

Автор:  Евгений Темиргалеев [ Понедельник, 25 Январь, 2021 02:09 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Код:
DEFINITION DevCPM;
  VAR lib*: Lib.Librarian;   (* the librarian to use during compilation *)
Поддерживаю такое решение.

Автор:  adimetrius [ Понедельник, 25 Январь, 2021 02:49 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Евгений Темиргалеев писал(а):
Считаю, что библиотекарь должен быть отдельным модулем. Подсистема Std для него подходит (StdDialog.GetSubLoc). Реализацию библиотекаря не стоит делать ни частью StdLoader, ни его альтернативной версии. Замена механизма поиска не обязтельно подразумевает замену механизма загрузки.

Если говорить про внедрение библиотекаря на уровне ББ, то отсюда логично вытекает, что StdLoader должен работать через него. Я представлял себе это как обращение к библиотекарю в StdLoader.ThisObjFile.
Можно сохранить старую версию StdLoader, а новую назвать по-другому. Это позволит собирать пускачи со старой схемой работы без библиотекаря, если это кому-то требуется.

Не представляю, как можно обойтись без линковки библиотекаря с его реализацией в пускач. Схема, когда в пускаче старый StdLoader, а Init выставляет новый не полноценная, потому что тогда библиотекарь не сможет выбирать Init. А этот модуль варьируется в каждой сборке -- он разный для консоли/графики в линуксе, винде и т.д.

Хорошо, когда модулей в пускаче меньше, я это как майнтейнер понимаю, но, с другой стороны, погоня за минимизацией числа модулей в пускаче не должна становиться самоцелью, из-за которой будет снижаться понятность кода, его сопровождаемость и проч.


Я полагаю, в модуле StdLib должен быть абстрактный интерфейс и стандартная реализация (старая процедура ThisObjFile, слегка расширенная). Согласен, что StdLoader должен работать через библиотекаря. При таком раскладе не нужно иметь два StdLoader.

При компоновке придется компоновать StdLib, а если нужна сборка с нестандартным библиотекарем - то и его модуль тоже. (Впрочем, мне пришлось вникать в форматы PE и ELF, и, при необходимости, можно вообще без компоновки "пускача"; было бы желание)

Автор:  Иван Денисов [ Понедельник, 25 Январь, 2021 05:05 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Уловил идею Евгения про загрузку Init. Тогда лучше один загрузчик, чтобы меньше было путаницы. Ок, пусть будет длиннее список сборки. Тогда действительно линковка между StdLib и StdLoader другого модуля MyConf скажем, позволяет решить проблему загрузки альтернативных Init. А теперь ведь ещё и HostGui нужно линковать в Windows сборке, чтобы отличать графические программы от консольных. И для кросс-платформенности всё же нужно Unicode импортировать в ядро. Мы с Александром этот вопрос как-то обсуждали. Идем к сборочному программированию семимильными шагами.

Какой-то такой список я вижу для стантартной сборки с GUI
Unicode Kernel$+ Files Utf HostEnv HostFiles HostGui StdLib StdLoader

Ну и если нужен авторский конфигуратор, который будет читать откуда что грузить, то так
Unicode Kernel$+ Files Utf HostEnv HostFiles HostGui StdLib MyConf StdLoader

Автор:  Trurl [ Вторник, 26 Январь, 2021 12:22 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

adimetrius писал(а):
Я полагаю, в модуле StdLib должен быть абстрактный интерфейс и стандартная реализация

А зачем? Во Вы пишете
Цитата:
При таком раскладе не нужно иметь два StdLoader.

Но когда потребуется что-то добавыит, выяснится, что не нужно иметь два StdLib, проще исправить этот.

Автор:  adimetrius [ Вторник, 26 Январь, 2021 13:05 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Trurl писал(а):
adimetrius писал(а):
Я полагаю, в модуле StdLib должен быть абстрактный интерфейс и стандартная реализация

А зачем?

А как вы предлагаете?

Trurl писал(а):
Но когда потребуется что-то добавить, выяснится, что не нужно иметь два StdLib, проще исправить этот.

Боюсь, что я не понял, что вы имеете в виду под "что-то добавить".
Конкретный пример: я делаю Гершель, это получается "стороннее приложение" по отношению к ББ. Я представляю, что в таком наборе будет три библиотекаря:
1) стандартный в StdLib, который используется в StdLoader и не предполагает каких-либо вариантов
2) еще один - для поддержки компиляции в песочнице, он будет использоваться в DevCPM
3) третий - Гершеле, поскольку у него собственное файловое хозяйство

Это как-то отвечает на ваш запрос?

Автор:  adimetrius [ Вторник, 26 Январь, 2021 13:16 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Коллеги, размышляя над вопросом Trurl, я подумал:

Из моего предыдущего поста 1 и 2 вполне могут быть просто разными переменными (экземплярами) одной реализации. И даже для 3 - Гершеля с его отдельным файловым хозяйством - было бы вполне достаточно еще одного экземпляра стандартной реализации.

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

Может, тогда стоит добавить
Код:
DEFINITION StdLib;

PROCEDURE NewStdLibrarian* (loc: Files.Locator): Librarian;
(** Returns a standard filesystem-based librarian based at _loc.
Pre
  loc # NIL, 20
Post
  RESULT = NIL => impossible to create a standard librarian for the given location
  RESULT # NIL => standard librarian for location _loc created successfully
*)

Автор:  adimetrius [ Вторник, 26 Январь, 2021 13:33 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Евгений, а как вы видите использование библиотекарей для решения ваших задач вариативности? Т.е. где какие вам потребуются расширения, где расположить экземпляры библиотекарей и т.д.?

Автор:  Евгений Темиргалеев [ Среда, 27 Январь, 2021 00:58 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

adimetrius писал(а):
Может, тогда стоит добавить
Код:
DEFINITION StdLib;
PROCEDURE NewStdLibrarian* (loc: Files.Locator): Librarian;
Еще пример, где это востребовано.
Вложение:
x.png
x.png [ 122.29 КБ | Просмотров: 1104 ]

Автор:  Евгений Темиргалеев [ Среда, 27 Январь, 2021 01:18 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

adimetrius писал(а):
Евгений, а как вы видите использование библиотекарей для решения ваших задач вариативности? Т.е. где какие вам потребуются расширения, где расположить экземпляры библиотекарей и т.д.?
Одна реализация нужна для загрузчика. Чтобы использование библиотекаря было его единственным отличием от StdLoader, надо чтобы загрузчик сам ходил в эту реализацию. Если ставить разъем в загрузчик, то он не сможет быть последним модулем в пускаче, который запускает "Init".
Код:
MODULE StdLoaderM;
...
   IMPORT S := SYSTEM, Kernel, Files, Utf8, Lib := XxxxLibrarianForLoader;
...
   PROCEDURE ThisObjFile (VAR name: ARRAY OF CHAR): Files.File;
   BEGIN
      Lib.lib.GetSpec...
Второй библиотекарь нужен для инструментов -- компилятора/линкера. DevCPM.lib, по-моему, для этого вполне подходит.

Автор:  Trurl [ Среда, 27 Январь, 2021 09:09 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

adimetrius писал(а):
Я представляю, что в таком наборе будет три библиотекаря

Я чего-то не понимаю. Вроде предлагался один стандартный библиотекарь, а их уже три.

Автор:  Иван Денисов [ Среда, 27 Январь, 2021 10:35 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

На мой взгляд, в стандартную комплектацию только один загрузчик должен входить и один библиотекарь.

Автор:  adimetrius [ Среда, 27 Январь, 2021 14:10 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Иван Денисов писал(а):
На мой взгляд, в стандартную комплектацию только один загрузчик должен входить и один библиотекарь.


Trurl писал(а):
adimetrius писал(а):
Я представляю, что в таком наборе будет три библиотекаря

Я чего-то не понимаю. Вроде предлагался один стандартный библиотекарь, а их уже три.


Коллеги, давайте договоримся о терминах:

Librarian = POINTER TO ABSTRACT RECORD ... END; (* если это называется интерфейсом библиотекаря, *)
StdLibrarian = POINTER TO RECORD (Librarian) END; (* тогда это - стандартный библиотекарь (1) *)

VAR
lib-, (* это - библиотекарь (текущий? или текучий? :) (2) *)
stdLib-: Librarian; (* это - тоже стандартный библиотекарь )) (3) *)

MODULE DevCPM;
VAR lib*: StdLib.Librarian; (* а это - библиотекарь, которым пользуется компилятор (4) *)

Я полагаю, что для обычной сборки вполне будет достаточно одного стандартного библиотекаря (1); и при работе ББ в динамической памяти будет, вероятно, один "экземпляр" этого стандартного библиотекаря (1), на который будут указывать (2), (3), (4).

При компиляции в песочницу будет, вероятно, создан еще один экземпляр стандартного библиотекаря (1), указатель на него будет помещен в (4).

ПС. В Сообщении о языке нет термина "экземпляр"; это получается безымянная переменная в динамической памяти (referenced variable in free storage).

Автор:  Илья Ермаков [ Среда, 27 Январь, 2021 14:51 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

История с stdImpl... тоже требует какого-то осмысления.

Как бы понятно, для чего это.

Но мне неизвестны случаи, где бы это использовалось - и есть подозрение, что когда понадобится, то std может быть недостаточно (без возможности доступа к стеку реализаций, как у Files - например).

Автор:  Trurl [ Среда, 27 Январь, 2021 18:32 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

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

Автор:  Trurl [ Среда, 27 Январь, 2021 18:43 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

adimetrius писал(а):
Librarian = POINTER TO ABSTRACT RECORD ... END; (* если это называется интерфейсом библиотекаря, *)
StdLibrarian = POINTER TO RECORD (Librarian) END; (* тогда это - стандартный библиотекарь (1) *)

VAR
lib-, (* это - библиотекарь (текущий? или текучий? :) (2) *)
stdLib-: Librarian; (* это - тоже стандартный библиотекарь )) (3) *)

MODULE DevCPM;
VAR lib*: StdLib.Librarian; (* а это - библиотекарь, которым пользуется компилятор (4) *)


И какой из них самый стандартный? Вместо кучи разрозненных процедур получим кучу разрозненных библиотекарей.

Автор:  Илья Ермаков [ Среда, 27 Январь, 2021 19:24 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Trurl писал(а):
Тоже об этом подумал. И даже если теоретически достаточно, все равно предпочтут пропатчить Std.


Ну я не с вариантом "пропатчить" сравнивал - а обычно либо очередная реализация полностью заменяет обычную, либо она наслаивается на предыдущую (как обычно с Files). А чтоб на базовую именно...

Хотя - возврат к базовой реализации (SetDir(std)) - типа, полезен.

Автор:  adimetrius [ Среда, 27 Январь, 2021 21:26 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Trurl писал(а):
adimetrius писал(а):
Librarian = POINTER TO ABSTRACT RECORD ... END; (* если это называется интерфейсом библиотекаря, *)
StdLibrarian = POINTER TO RECORD (Librarian) END; (* тогда это - стандартный библиотекарь (1) *)

VAR
lib-, (* это - библиотекарь (текущий? или текучий? :) (2) *)
stdLib-: Librarian; (* это - тоже стандартный библиотекарь )) (3) *)

MODULE DevCPM;
VAR lib*: StdLib.Librarian; (* а это - библиотекарь, которым пользуется компилятор (4) *)


И какой из них самый стандартный? Вместо кучи разрозненных процедур получим кучу разрозненных библиотекарей.


Коллега, если я правильно ваш вопрос понял, то здесь одна процедура:

PROCEDURE (lib: Librarian) GetSpec (...), NEW, ABSTRACT;
PROCEDURE (lib: StdLibrarian) GetSpec (...);
END GetSpec;

Т.е. реализация собрана в одном месте. Везде, где раньше была куча разрозненных процедур, самостоятельно вычислявших пути к модулям и ресурсам, можно использовать один-единственный вызов.

Автор:  Иван Денисов [ Четверг, 25 Февраль, 2021 09:39 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Кто-нибудь возьмется сделать пробную версию библиотекаря в таком обсуждённом виде? Может в виде ветки, к примеру.

Автор:  adimetrius [ Четверг, 25 Февраль, 2021 18:21 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Я уже пользуюсь, не было времени оформить и отправить, могу сделать на днях

Автор:  adimetrius [ Воскресенье, 14 Март, 2021 22:52 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Загрузил в ветку StdLib модуль StdLib со стандартным библиотекарем и модуль DevCPM, который переводит компилятор на использование библиотекаря. Опробовал DevCPM только на простеньких примерах, предлагаю (и сам буду) опробовать в эксплуатации.
И еще следует опробовать эту 46ю поправку с поправкой 22.

ВНИМАНИЕ! В загруженном StdLib выброшено древнее соглашение об особых Code и Sym для System (на форуме было обсуждение на эту тему). Соответствующие артефакты располагаются в System/Code И System/Sym. На время пробной эксплуатации сделал себе символические ссылки BB/System/Code -> BB/Code и для Sym.

Страница 3 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/