OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 64 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 19 Январь, 2021 14:20 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 479
Итак, что мы имеем на данный момент?

Код:
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 *)


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

Всё так?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 19 Январь, 2021 16:18 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3091
Перечислитель через next простой? Ну и его в Dev, наверное, надо поместить. DevLib, к примеру.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 19 Январь, 2021 17:34 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4519
Откуда: Россия, Орёл
В Dev то зачем? Другим сервисам внутренним он не пригодится в отсутствии Dev?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 19 Январь, 2021 21:25 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 479
Борис Рюмшин писал(а):
В Dev то зачем? Другим сервисам внутренним он не пригодится в отсутствии Dev?


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Среда, 20 Январь, 2021 06:26 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3091
Борис Рюмшин писал(а):
В Dev то зачем? Другим сервисам внутренним он не пригодится в отсутствии Dev?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Среда, 20 Январь, 2021 13:27 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 479
Иван Денисов писал(а):
А... если припомнить рассказ Евгения, то получается, что он хотел для конфигуратора запуска использовать его. Тогда надо не в Dev. Ну тогда получается StdLibrarian?


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Среда, 20 Январь, 2021 13:52 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Четверг, 21 Январь, 2021 07:46 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3091
Вообще-то в таком случае получается, что библиотекарь должен быть частью модуля StdLoader...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Четверг, 21 Январь, 2021 12:05 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4519
Откуда: Россия, Орёл
Ну частью, наверно, нет. А вот то, что он в Std должен находится, пожалуй, согласен. Ещё бы мнение тов. Темиргалеева на этот счёт услышать.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3091
Дело в том, что StdLoader линкуется в пускач, и поэтому если выделить отдельный модуль, то опять получим расширение зависимостей.
У нас ведь уже HostEnv и Utf (в версиях для ~ Windows) появилились в списках линковки. А так ещё и StdLibrarian будет. А так, если в состав StdLoader включить, то не придется расширять список для линковки.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Пятница, 22 Январь, 2021 10:52 
Администратор

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


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3091
Борис Рюмшин писал(а):
StdLoader никем не импортируется, а после такого включения будет. Надо думать.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Пятница, 22 Январь, 2021 17:20 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4519
Откуда: Россия, Орёл
Скажем так. StdLoader может быть и не доступен, если его функции выполняет другой модуль.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Пятница, 22 Январь, 2021 21:15 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Суббота, 23 Январь, 2021 10:06 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3091
Trurl писал(а):
Подсказка: всегда можно создать NonStdLoader.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 25 Январь, 2021 00:01 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4619
Откуда: Россия, Орёл
Считаю, что библиотекарь должен быть отдельным модулем. Подсистема Std для него подходит (StdDialog.GetSubLoc). Реализацию библиотекаря не стоит делать ни частью StdLoader, ни его альтернативной версии. Замена механизма поиска не обязтельно подразумевает замену механизма загрузки.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 25 Январь, 2021 00:13 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4619
Откуда: Россия, Орёл
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, и любые другие специфические для реализаций.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 25 Январь, 2021 00:58 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4619
Откуда: Россия, Орёл
Кстати, есть еще один момент. Получение координат кодовых файлов загрузчиком и компилятором в общем случае требуют разных правил. Например, для кросс-компиляции получение исходников/символьных/кодовых переключается в другое место, а загрузка кодовых должна идти откуда шла.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 25 Январь, 2021 01:45 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 479
Евгений Темиргалеев писал(а):
Меня смущают следующие моменты:
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:04, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 25 Январь, 2021 02:00 
Аватара пользователя

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

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

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


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

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

END DevCPM.

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


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

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


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

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


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

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