OberonCore
https://forum.oberoncore.ru/

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

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

Итак, что мы имеем на данный момент?

Код:
DEFINITION Lib;
  CONST source* = 0; symbols* = 1; code* = 2; moddocu* = 3 (* module documentation*); docu* = 4 (* arbitrary document *);
    rsrc* = 5;

  TYPE Librarian* = POINTER TO ABSTRACT RECORD END;
 
  VAR lib-, stdLib-: Librarian;

  PROCEDURE (lib: Librarian) GetSpec (IN sub, name: ARRAY OF CHAR; what: INTEGER;
    OUT loc: Files.Locator; OUT fname: Files.Name; OUT ftype: Files.Type), NEW, ABSTRACT;
  (** Returns file locator _loc, name _fname and type _ftype for subsystem _sub's constituent _name of kind _what
  Pre:
    LEN(sub$) + 1 < LEN(Kernel.Name), 20
    LEN(name$) + 1 < LEN(Kernel.Name), 21
  Post:
    loc = NIL
      => constituent not found, fname and ftype undefined
    loc # NIL
      loc, _fname and _ftype identify the file of the requested constituent
  *)

  PROCEDURE SetLib* (lib: Librarian);
  (** Pre: lib # NIL, 20 *)


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

Всё так?

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

Перечислитель через next простой? Ну и его в Dev, наверное, надо поместить. DevLib, к примеру.

Автор:  Борис Рюмшин [ Вторник, 19 Январь, 2021 17:34 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

В Dev то зачем? Другим сервисам внутренним он не пригодится в отсутствии Dev?

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

Борис Рюмшин писал(а):
В Dev то зачем? Другим сервисам внутренним он не пригодится в отсутствии Dev?


А каким, например? У Евгения Карта, в Dev есть Repository, у меня в EdTools перечислитель будет, пожалуй, использоваться. Это все разработческие инструменты.

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

Борис Рюмшин писал(а):
В Dev то зачем? Другим сервисам внутренним он не пригодится в отсутствии Dev?

А... если припомнить рассказ Евгения, то получается, что он хотел для конфигуратора запуска использовать его. Тогда надо не в Dev. Ну тогда получается StdLibrarian?

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

Иван Денисов писал(а):
А... если припомнить рассказ Евгения, то получается, что он хотел для конфигуратора запуска использовать его. Тогда надо не в Dev. Ну тогда получается StdLibrarian?


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

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

Ну не перечислитель, а библиотекарь. Так можно в запуске Setup будет установить другую реализацию Librarian, что если скажем подсистема Host то, брать из HostWin при одной конфигурации и HostLin из другой... Так будет как у Евгения/Петра/Ивана, все хосты лежать в одной сборке ББ. При этом сами модули иметь названия HostConsole и т.п.

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

Вообще-то в таком случае получается, что библиотекарь должен быть частью модуля StdLoader...

Там как раз есть процедура ThisObjFile, которая должна быть реализована через библиотекарь.

Автор:  Борис Рюмшин [ Четверг, 21 Январь, 2021 12:05 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Ну частью, наверно, нет. А вот то, что он в Std должен находится, пожалуй, согласен. Ещё бы мнение тов. Темиргалеева на этот счёт услышать.

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

Дело в том, что StdLoader линкуется в пускач, и поэтому если выделить отдельный модуль, то опять получим расширение зависимостей.
У нас ведь уже HostEnv и Utf (в версиях для ~ Windows) появилились в списках линковки. А так ещё и StdLibrarian будет. А так, если в состав StdLoader включить, то не придется расширять список для линковки.

Автор:  Борис Рюмшин [ Пятница, 22 Январь, 2021 10:52 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

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

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

Борис Рюмшин писал(а):
StdLoader никем не импортируется, а после такого включения будет. Надо думать.

Импорт будет лишь в подсистеме Dev. А в пользовательских программах обычно этой подсистемы нет. Так что не такая большая проблема.

Автор:  Борис Рюмшин [ Пятница, 22 Январь, 2021 17:20 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Скажем так. StdLoader может быть и не доступен, если его функции выполняет другой модуль.

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

Иван Денисов писал(а):
Вообще-то в таком случае получается, что библиотекарь должен быть частью модуля StdLoader...

А давайте его сразу в Kernel засунем.
Подсказка: всегда можно создать NonStdLoader.

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

Trurl писал(а):
Подсказка: всегда можно создать NonStdLoader.

Кстати да...
Kernel.LoaderHook
Если использовать эту штуку, то конфигуратор запуска может установить альтернативный загрузчик, в котором импортирован библиотекарь.
Так что не обязательно StdLoader менять.

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

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

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

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

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

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

adimetrius писал(а):
Код:
DEFINITION Lib;
  CONST source* = 0; symbols* = 1; code* = 2; moddocu* = 3 (* module documentation*); docu* = 4 (* arbitrary document *);
    rsrc* = 5;

  TYPE Librarian* = POINTER TO ABSTRACT RECORD END;
 
  VAR lib-, stdLib-: Librarian;

  PROCEDURE (lib: Librarian) GetSpec (IN sub, name: ARRAY OF CHAR; what: INTEGER;
    OUT loc: Files.Locator; OUT fname: Files.Name; OUT ftype: Files.Type), NEW, ABSTRACT;
  (** Returns file locator _loc, name _fname and type _ftype for subsystem _sub's constituent _name of kind _what
  Pre:
    LEN(sub$) + 1 < LEN(Kernel.Name), 20
    LEN(name$) + 1 < LEN(Kernel.Name), 21
  Post:
    loc = NIL
      => constituent not found, fname and ftype undefined
    loc # NIL
      loc, _fname and _ftype identify the file of the requested constituent
  *)

  PROCEDURE SetLib* (lib: Librarian);
  (** Pre: lib # NIL, 20 *)
В дальнейшем планируем дополнить интерфейсом перечислителей - чтецов.
Меня смущают следующие моменты:
1) Предусловие, проверка которого требует импорта Kernel. Не уверен, что это обязательно необходимо для каждой реализации. Я бы не накладывал на эти цепочки никаких ограничений, потому что именно реализация определяет, как их отображать на конечные координаты.
2) Результаты "нашел", "не нашел" не достаточны. Должен как минимум быть еще один -- "ошибка". Если добавить OUT res: INTEGER к GetSpec или добавить res*: INTEGER к Librarian (как в Files.Locator), мы получим возможность передать штатные коды "нашел", "отсутствует", "ошибка" -- допустим 0, 1 и 2, и любые другие специфические для реализаций.

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

Кстати, есть еще один момент. Получение координат кодовых файлов загрузчиком и компилятором в общем случае требуют разных правил. Например, для кросс-компиляции получение исходников/символьных/кодовых переключается в другое место, а загрузка кодовых должна идти откуда шла.

В сборке с вариантными модулями (https://oberoncore.ru/library/temir_core-vmod) хотя и неявно (без интерфейса библиотекаря) реализованы две разные схемы правил для компиляции/линковки и загрузки.

Сейчас, когда речь идет про одну системную реализацию библиотекаря, мы этот факт пока не учли.

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

Евгений Темиргалеев писал(а):
Меня смущают следующие моменты:
1) Предусловие, проверка которого требует импорта Kernel. Не уверен, что это обязательно необходимо для каждой реализации. Я бы не накладывал на эти цепочки никаких ограничений, потому что именно реализация определяет, как их отображать на конечные координаты.

Хм... да, что-то я лишнего написал... они были бы нужны для OUT Параметров, но это же IN. Пожалуй, согласен: не нужны эти предусловия.
Евгений Темиргалеев писал(а):
2) Результаты "нашел", "не нашел" не достаточны. Должен как минимум быть еще один -- "ошибка". Если добавить OUT res: INTEGER к GetSpec или добавить res*: INTEGER к Librarian (как в Files.Locator), мы получим возможность передать штатные коды "нашел", "отсутствует", "ошибка" -- допустим 0, 1 и 2, и любые другие специфические для реализаций.


Да, поддерживаю, давайте добавим поле res*: INTEGER с кодом ошибки.

Получается:
Код:
DEFINITION Lib;
  CONST source* = 0; symbols* = 1; code* = 2; moddocu* = 3 (* module documentation*); docu* = 4 (* arbitrary document *);
    rsrc* = 5;

  TYPE Librarian* = POINTER TO ABSTRACT RECORD
    res*: INTEGER;    (* result of the last GetSpec call *)
  END;
 
  VAR lib-, stdLib-: Librarian;

  PROCEDURE (lib: Librarian) GetSpec (IN sub, name: ARRAY OF CHAR; what: INTEGER;
    OUT loc: Files.Locator; OUT fname: Files.Name; OUT ftype: Files.Type), NEW, ABSTRACT;
  (** Returns file locator _loc, name _fname and type _ftype for subsystem _sub's constituent _name of kind _what
  Post:
    loc = NIL
      => .res # 0, constituent not found, fname and ftype undefined
    loc # NIL
      res = 0
      loc, _fname and _ftype identify the file of the requested constituent
  *)

  PROCEDURE SetLib* (lib: Librarian);
  (** Pre: lib # NIL, 20 *)
END Lib.

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

Евгений Темиргалеев писал(а):
Кстати, есть еще один момент. Получение координат кодовых файлов загрузчиком и компилятором в общем случае требуют разных правил. Например, для кросс-компиляции получение исходников/символьных/кодовых переключается в другое место, а загрузка кодовых должна идти откуда шла.

В сборке с вариантными модулями (https://oberoncore.ru/library/temir_core-vmod) хотя и неявно (без интерфейса библиотекаря) реализованы две разные схемы правил для компиляции/линковки и загрузки.

Сейчас, когда речь идет про одну системную реализацию библиотекаря, мы этот факт пока не учли.


Я представлял себе это следующим образом:
Код:
DEFINITION DevCPM;

  VAR lib*: Lib.Librarian;   (* the librarian to use during compilation *)

END DevCPM.

Таким образом, компилятор может пользоваться одним библиотекарем, а загрузчик - другим. И для компилятора можно переключать библиотекарей между вызовами DevCompiler.Compile.

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