OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 03 Ноябрь, 2024 03:23

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




Начать новую тему Ответить на тему  [ Сообщений: 118 ]  На страницу 1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения: #046 Библиотекарь модулей
СообщениеДобавлено: Воскресенье, 27 Декабрь, 2020 15:19 
Модератор
Аватара пользователя

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

Антон Дмитриев на примере конкретных задач и DevCPM предложил создать такой сервис для доступа к исходникам и символьным/кодовым файлам. Полностью поддерживаю эту идею с дополнением, что ее необходимо расширить до всех документов, которые формируют "модуль".

В плане интерфейса предлагаю оттолкнуться от
PROCEDURE StdDialog.GetSubLoc (mod: ARRAY OF CHAR; cat: Files.Name; OUT loc: Files.Locator; OUT name: Files.Name)

Чтобы не дублировать операции Files, библиотекарь должен давать координаты документов. На мой взгляд, в нем обязательны две операции -- получить конкретный документ и получить список документов для модуля.
Код:
MODULE Librarian;
   TYPE Mod* = ABSTRACT RECORD
      res*: INTEGER
   END;
   PROCEDURE (m: Mod) GetDocLoc (IN ident, cat, lang, key: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name), NEW, ABSTRACT;
   PROCEDURE (m: Mod) DocList (IN ident, cat, lang, key: ARRAY OF CHAR): DocInfo, NEW, ABSTRACT;

   TYPE DocInfo = POINTER TO EXTENSIBLE RECORD
      next*: Info;
      cat*, lang*, key*: ARRAY 64 OF CHAR
   END;
ident -- идентификатор модуля
cat -- ключ категории Mod, Docu, Code, Sym, Rsrc.
lang -- языковой ключ для документации и ресурсов
key -- дополнительный ключ для ресурсов, которых у модуля может быть несколько.
Подсистемы, у которых есть "внемодульная" документация и ресурсы (Strings, Menus), закрываются как модули. Например ident = "Text".

Так закрываются все стандартные соглашения.

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

Это касательно документов модуля.

Второе, что необходимо, это получение списка доступных модулей. Например, для DevRBrowser / карты разработчика (ipuiK293).
Код:
   PROCEDURE (d: Directory) SubList (): IdentInfo, NEW, ABSTRACT;
   PROCEDURE (d: Directory) ModList (IN sub: ARRAY OF CHAR): IdentInfo, NEW, ABSTRACT;

   TYPE IdentInfo = POINTER TO EXTENSIBLE RECORD
      next*: IdentInfo;
      ident*: ARRAY 256 OF CHAR
   END;


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Библиотекарь модулей
СообщениеДобавлено: Воскресенье, 27 Декабрь, 2020 16:52 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Все так.
Модуль в КП - это текст. Модуль в ББ - несколько сложнее: это совокупность текста, символьного и кодового представления (файла), а также можно к модулю отнести и его "образ" в памяти ЭВМ, когда модуль загружен (в терминах Сообщения - added to the system). (Прим: в памяти ЭВМ модуль - это совокупность Метаданных, Машкодов, Дескриптора и Переменных)
Ну и если уж совсем претендовать на полноту - "останки" модуля после его удаления из системы (выгрузки) тоже сюда можно отнести (это Дескриптор).

Действительно, когда мы говорим "В модуле М есть переменная П", это может относиться к любому из перечисленных представлений.

За неимением устоявшегося и, возможно, более подходящего термина, буду называть эти все "проявления" модуля его ипостасями.

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

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

Назовем здесь такой интерфейс Библиотекарем - Librarian. Вот он, например:
Код:
DEFINITION Lib;

   IMPORT Files;
   
   CONST
      (* hypostases *)
      source = 0; symbols = 1; code = 2; docu = 3;

   TYPE
      Name = ARRAY 256 OF CHAR;
      Librarian = POINTER TO ABSTRACT RECORD
         PROCEDURE ThisSpec (IN mod: Name; hypostasis: INTEGER; OUT loc: Files.Locator; OUT name: Files.Name; OUT type: Files.Type), NEW, ABSTRACT;
         (* Translate (mod, hypostatis) ⇒ (loc, name, type) *)
      END;

   VAR
      lib*, stdLib-: Librarian;

END HrLib.

Где его применять и что с него взять.

Летом я публиковал небольшой проект Cross; по опыту использования с тех пор, его стоит назвать Sandbox - песочница. Это - дубликат компилятора СР2 с единственным отличием: он умеет брать символьные файлы импортируемых модулей не из папки ББ, а откуда укажут; и выкладывать артефакты компиляции тоже не в папку ББ, а куда укажут. Это позволяет мне, например, сделать папку Sandbox, в ней - Sub/Mod/, разместить там файл Module.odc с текстом модуля SubModule. И тогда SandboxCompiler.Compile создаст Sandbox/Code/Module.odc и Sandbox/Sym/Module.osf. При этом я могу указать, что брать символьные файлы следует из папки, например, bb18; а могу - что из папки bb17. Это оч удобно, если я правлю модули, от которых зависит работа не только моего приложения, но и всего ББ, т.е. ИДЕ, "мастерской" программиста: мастерская всегда остается работоспособной, даже если я ошибся в критически важных модулях.
Изменения для этого потребовались совершенно незначительные в единственном модуле DevCPM (SandboxCPM) в процедурах OldSym, NewSym, RegisterSym, NewCode, RegisterCode, CloseSym, CloseCode.

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

Это позволит (проще) реализовать Песочницу; что еще важнее - систематизировать работу со сборками ББ для разных платформ: реализации библиотекаря можно поручить разбираться, как и куда складывать модульные ипостаси для той или иной платформы, или разрядности целевой платформы, или версии ББ, или еще каких нужно вариантов. Также можно систематизировать работу стыковщика: он должен будет научиться работать с библиотекарем, сообщать ему, какова, напр., целевая платформа, затем получать от него модули и собсно стыковать их. При этом все "переменные разделены": библиотекарь - выделенный компонент, отвечающий за систематизацию доступа к ипостасям модулей; компилятору, стыковщику, отладчику, прочим инструментам делать это не нужно.
Кроме того, откроется возможность, например, организовать хранение ипостасей не в файловой системе, а, к примеру, в БД, или в едином мегафайле, или в сетевом хранилище, и т.д. Что подготовит ББ к пересадке на мобильные, напр., платформы )).

В Гершеле я экспериментировал (-ую) с библиотекарем; HrM использует его, и, например, Гершель выкладывает артефакты компиляции не в папку ББ, а в Hr/Demo/Mod/ , Code/, Sym/; когда придет пора Гершелю стать наравне с СР2 - достаточно будет подменить реализацию библиотекаря, и ипостаси окажутся аккуратно разложенными в подсистемные папки в папке ББ.

И да, я согласен с Евгением, что нужно в Библиотекаря ввести и понятие ресурсов и документации подсистемы. Однако с этим я не экспериментировал. Предполагаю, это заслуживает отдельной процедуры:
Код:
PROCEDURE (lib: Librarian) ThisSubSpec (IN sub: Name; hypostases: INTEGER): Files.Locator, NEW, ABSTRACT;

Если же отображение имени модуля в имена документов - неоднозначное, то... Ну, в этом особом случае я бы предложил ввести процедуру в расширении Librarian:
Код:
   TYPE Lib = POINTER TO RECORD (Lib.Librarian) ... END;
   PROCEDURE (lib: Lib) TheseDocs (IN mod: Name): DocList, NEW;

Хотя для задач перечисления я предпочитаю использовать не связные списки, а сканеры или чтецы. Нечто подобное у меня было в EdTools, тоже опубликован на форуме летом:
Код:
   TYPE
      Shelve = POINTER TO RECORD ... END;
      (* "Полочка": папка, в которой есть структура подсистем ББ *)
      PROCEDURE (sh: Shelve) NewReader (old: Shelver): Shelver, NEW;
      
      Shelver = POINTER TO RECORD   (* Перечислитель содержимого "полочки" *)
         type*: INTEGER;   (* eot, modu, docu, rsrc, arbi *)
         modName*: Ident;   (* module name, valid iff .type = modu *)
         loc*: Files.Locator;   (* if applicable, determines the text's file and locator *)
         fname*: Files.Name;
      END;
      PROCEDURE (sh: Shelver) Read, NEW;


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Библиотекарь модулей
СообщениеДобавлено: Воскресенье, 27 Декабрь, 2020 18:07 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
1) Антон, не совсем понятно, как будет организовываться перечисления модулей. Если посредством Files.Locator, то, выходит, что для специфической организации хранения, кроме Librarian придется реализовывать Files.Directory, который навешивать поверх Files.dir, чтобы давать списки модулей. Причем эти списки будут увязаны не на модуль, а на ипостаси. Это порождает проблему получения списка модулей. Потому что у модуля, например, может не быть исходника, но может быть документация.

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

3) Согласен, что сканер является более общим механизмом чтения для перечислений.

4) Files.type в качестве коордианты для Files в общем случае необходим, точно. И, похоже, библиотекарь снимает необходимость в Files.objType и Files.symType.

5) Использование целых кодов для ипостасей наряду с плюсами, на мой взгляд, имеет свой минус. Сложнее расширить стандартный список, если это понадобится. И проще запутаться в расширениях, когда там коды начнут пересекаться. На цепочках глобально пересечься сложнее. Поэтому для общего интерфейса я предложил цепочки, хотя есть варианты решения с кодами. Например
Код:
DEFINITION ipuiK431;

   IMPORT TextModels, ipuiK433;

   CONST
      tCode = 3;
      tDCode = 8;
      tDDocu = 6;
      tDMod = 5;
      tDRsrc = 9;
      tDSym = 7;
      tDocu = 1;
      tMod = 0;
      tRsrc = 4;
      tSym = 2;
...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Библиотекарь модулей
СообщениеДобавлено: Воскресенье, 27 Декабрь, 2020 19:32 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Далее следуют "мысли вслух", а не законченное взвешенное предложение.

Про перечисление: я делал перечислитель "всего подряд" (Shelver) с помощью Read, а клиент из этого "всего подряд" выбирал тексты модулей (shelver.type = modu). Предполагаю, по аналогии с текстовыми чтецами, можно:

PROCEDURE (rd: Reader) Read*, NEW, ABSTRACT; (* все подряд, что есть *)
PROCEDURE (rd: Reader) ReadMod*, NEW, ABSTRACT; (* только модули *)
PROCEDURE (rd: Reader) ReadCode*, NEW, ABSTRACT; (* только кодовые *)

А поверх этого чтеца можно сделать сканер, который перебирает помодульно, а не поипостасьно:
Код:
TYPE
   ModScanner = RECORD
      mod: Name;
      hypostases: SET;  (* можно, наэн, и цепочки как-то сделать, или булевы флаги *)
   END;

Анализируя .hypostases можно выяснить, какие ипостаси модуля имеются в распоряжении Библиотекаря, и дальше к ним получить доступ с помощью ThisSpec.

Откуда берутся чтецы: у меня был Shelve, наэн ему на смену как раз библиотекарь:
PROCEDURE (lib: Librarian) NewReader* (old: Reader): Reader, NEW, ABSTRACT;

Наверноe, чтобы перечислять подсистемы тоже нужен свой чтец:
PROCEDURE (lib: Librarian) NewSubReader* (old: SubReader): SubReader, NEW, ABSTRACT;
А может и не стоит заморачиваться с отдельным чтецом для подсистем, сделать так:
PROCEDURE (lib: Librarian) GetNextSub* (VAR sub: Name), NEW, ABSTRACT;
И если нужно перечислить модули или ипостаси одной подсистемы, то:
PROCEDURE (lib: Librarian) NewReaderFor* (IN sub: Name; old: Reader): Reader, NEW, ABSTRACT;



Документацию и ресурсы тоже надо бы в общий интерфейс. Документацию модуля можно рассматривать как одну из его ипостасей, и Обозначать константой docu (целой или строковой). Ресурс, если он один - тоже можно. "Один документ - к одному модулю" - это соглашение ББ, на него завязан отладчик (показ точки останова) и редактор (переход к исходнику), поэтому ему место в общем интерфейсе, кмк.

Я предлагал в расширение выносить "Один модуль-много документов" или "-много ресурсов". Поскольку это особый случай в вашей "вселенной" ББ. Однако, если сделать перечислитель, как я выше описал Reader, то он, кмк, может вполне перечислить множественные документы, относящиеся к одному модулю. Либо вам придется сделать собственную реализацию Библиотекаря (что кмк вытекает из того, что вы расширяете стандартное соглашение ББ), и к ней - собственную реализацию перечислителя, а уж в ней-то можно один-ко-многим реализовать, как будет удобно для ваших задач.

Т.о. Files.Locator как "агрегатор" модулей или ипостасей или чего бы то ни было я не предлагаю; кмк, переделывать реализацию Files не придется.


Еще, мне кажется, что перечислитель (чтец) модулей - это больше средство для системных задач: построить "энциклопедию" всего, что есть в такой-то папке ББ; произвести такое-то действие со всеми модулями такой-то подсистемы и т.п. Поэтому ему место где-то в Dev (чтобы можно было "отбросить отработавшую ступень" в окончательном приложении). Но он должен быть определен вместе с Librarian. Возможно, надо оговорить, что NewReader может вернуть NIL? И это будет означать, что перечислители в данной установке ББ недоступны. В то же время ThisSpec должна отрабатывать в обязательном порядке.


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Антон, соглашение один-ко-многим для ресурсов -- стандартное для ББ.
Docu/Tut-3 писал(а):
Rsrc Directory with the subsystem's resource documents.
For example, for module "FormCmds" there is file "Form/Rsrc/Cmds".
There may be zero, one, or more resource files for one module. If there are several files, the second gets a suffix "1", the third a suffix "2", and so on. For example, "Form/Rsrc/Cmds", "Form/Rsrc/Cmds1", "Form/Rsrc/Cmds2", etc...
Плюс стандарт для ББ -- наличие измерения "язык" для документации и ресурсов. Поэтому даже для документации тоже получается один-ко-многим с учетом языка.

Интерфейс читалки для перебора подсистем/модулей на мой взгляд выглядит лучше списков а-ля Files.dir.FileList(). Типы ипостасей в методы, мне кажется, не стоит зашивать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Библиотекарь модулей
СообщениеДобавлено: Понедельник, 28 Декабрь, 2020 23:07 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Евгений, выходит, я ошибся, вы совершенно правы. Спасибо за отсылку. Выходит, что соглашение сложнее, чем я полагал; значит, придется усложнять и интерфейс. Например так:
Код:
   
   TYPE Lang* = ARRAY ? OF CHAR; (* есть ли соглашение о длине наимен. языка? *)

   PROCEDURE GetModSpec (IN mod: Name; hypostasis: INTEGER; IN lang: Lang; OUT loc: Files.Locator; OUT name: Files.Name; OUT type: Files.Type), NEW, ABSTRACT;
   (** Get module _mod_'s _hypostasis_ spec; _lang_ valid iff _hypostasis_ = documod. Pre: _hypostasis_ IN { mod, code, sym, documod } *)

   PROCEDURE (lib: Librarian) GetRsrcSpec (IN sub: Name; num: INTEGER; OUT loc: Files.Locator; OUT name: Files.Name; OUT type: Files.Type), NEW, ABSTRACT;

   PROCEDURE (lib: Librarian) GetDocuSpec (IN sub, name: Name; IN lang: Lang; OUT loc: Files.Locator; OUT name: Files.Name; OUT type: Files.Type), NEW, ABSTRACT;
    (** Get spec for subsystem _sub_'s document called _name_ in language _lang_ *)


(Подумал, может, Get лучше, чем This, поскольку This обычно с процедурами-функциями используется: Files.dir.This(): Files.Locator, а Get, кмк, намекает на VAR/OUT параметры)

А перечислитель:
Код:
  CONST documod = ?; (* individual module documentation *)
      docu = ?; (* subsystem documentation *)

  TYPE
   Reader = POINTER TO ABSTRACT RECORD
     what*: INTEGER;   (* eot, modu, documod, docu, rsrc, other *)
     name*: Name;
        (* .what IN { modu, documod } => module name, IN { docu, rsrc } => sub name *)
     num*: INTEGER;    (* valid iff .what = rsrc *)
     lang*: Lang;  (* valid iff .what = docu *)
     loc*: Files.Locator;   (* if applicable, determines the text's file and locator *)
     fname*: Files.Name;
     ftype*: Files.Type;
   END;


Что скажете?

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

Я предлагаю, когда мы "устаканим" проект интерфейса, попробовать сделать на нем практические задачи: вы - свою (Карта разработчика), я - свою (Песочницу, может и Shelver заменить в EdTools). Чтобы удостовериться, что это практично, а не умозрительно только. И подкорректировать интерфейс по результатам.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Библиотекарь модулей
СообщениеДобавлено: Среда, 30 Декабрь, 2020 03:37 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Антон, в первом блоке у ресурсов name не потерялось? Плюс у ресурсов тоже должен быть параметр "язык". Text/Rsrc/Strings -- язык по-умолчанию, Rsrc/en/Strings -- на английском, Rsrc/ru/Strings -- на русском и т.п.

Для файла ресурса мы используем произвольный суффикс, а не номер. Но, надо отметить, что практика обособленных ресурсов для модуля применяется, когда модуль рассматривается, как отдельный компонент. Прежде всего она связана с текстовыми ресурсами -- https://oberoncore.ru/library/temir_opr ... _ble_kboks

В плане соглашений, вроде так и должно быть. В текстах документации ББ полной формализации нет, недостающие детали я выискивал в коде инструментов ББ, когда занимался вопросом перечисления модулей. Заметка на эту тему: https://oberoncore.ru/library/temir_raz ... materialov

По карте разработчика. Документ карты должен строиться по данным от перечислителя. Данных должно быть достаточно, чтобы с ними можно было при необходимости сходить в библиотекарь за любым "документом".

По-поводу перечислителя. Если мы обратимся к "Компонентному ПО" Пфистера (https://oberoncore.ru/library/pfister_c ... _software4), то модуль КП в ББ -- это "минимальный компонент". А "компонент" -- это в т.ч. "единица упаковки, развертывания и загрузки".
Пфистер писал(а):
Компонент является единицей упаковки, развертывания и загрузки...В Component Pascal наименьшим компонентом является модуль
Подсистема, как сложилось на практике, -- это набор "компонентов", собранных по некоторому критерию. Сравните Text и Dev. Ниже выделение мое.
Docu/Tut-3 писал(а):
For the BlackBox Component Builder, it is a convention that collections of related components, called subsystems, are placed into separate directories; all of which are located directly in the BlackBox directory. There are subsystems like System, Std, Host, Win, Text, Form, Dev, or Obx. The whole collection of subsystems is called the BlackBox repository. The basic idea behind the repository's structure is that everything that belongs to a component (code files, symbol files, documentation, resources) are stored together in a systematic and simple directory structure, according to the rule

Keep all constituents of a component in one place.
Нужно учитывать эту "правоприменительную" практику для уже существующих подсистем и модулей, которая порождает некоторую путаницу. Есть минимальные "компоненты" равные одному модулю. Есть "компоненты" равные подсистеме. Есть "компоненты" из нескольких модулей в подсистеме. Поэтому мы не можем, грубо говоря, перебрать каталоги в корне, приравнять их к списку подсистем, а список подсистем к списку "компонентов". Мы должны как-то получить этот список "компонентов" в "репозитории". И нужно явно обозначить "компонент" как сущность, которая в общем случае не равна ни модулю ни подсистеме.
Код:
PROCEDURE (d: Directory) ComponentList (): IdentInfo, NEW, ABSTRACT; (* или вариант с читалкой -- для "компонентов" *)

Далее для "компонента" в смысле единицы упаковки мы получаем перечислитель и перебираем содержимое "компонента" -- модули с их ипостасями (исходник, документация (м.б. несколько документов), кодовые/символьные файлы (в случае мульти-оберона их несколько)), документацию и ресурсы -- на "компонент".

В идеале нужно закрыть стандартные соглашения ББ, подразумевая component=subsystem, и оставить некоторый запас для расширяемости.

Код:
 CONST documod = ?; (* individual module documentation *)
      docu = ?; (*  component documentation *)

  TYPE
   Reader = POINTER TO ABSTRACT RECORD
     what*: INTEGER;   (* eot, modu, documod, sym, code, docu, rsrc, other *)
     name*: Name; (* или просто ARRAY ... OF CHAR? *)
        (* .what IN { modu, documod, sym, code } => module name, IN { docu, rsrc } => document name (не тождественно filename). Если хотим обозначить привязку ресурса к модулю, равно имени модуля *)
     key*: ARRAY ... OF CHAR;    (* дополнительный ключ, пустое значение = документ по умолчанию. Варианты применения:
what = modu -- вариантный модуль в мульти-обероне,
what = sym/code -- платформозавимый модуль в мульти-обероне,
what = rsrc -- "индекс" ресурса name, например, привязанного к модулю
what = documod, "индекс" документа
*)
     lang*: Lang;  (* valid iff .what = docu, documod, rsrc -- ARRAY ... OF CHAR? *)

(*Не дублировать -- ходить в GetSpec?*)
     loc*: Files.Locator;   (* if applicable, determines the text's file and locator *)
     fname*: Files.Name;
     ftype*: Files.Type;
   END;

 PROCEDURE GetSpec (IN component, name, key, lang: ARRAY OF CHAR; what: INTEGER; OUT loc: Files.Locator; OUT name: Files.Name; OUT type: Files.Type), NEW, ABSTRACT;


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3805
А, что если предусмотреть пока только Mod/Code/Sym, чтобы было попроще решение? Отображения один в один.
А то ведь для кросс-компилятора больше и не нужно. А то уже как-то очень сложно... с кучей языков и т.п.


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

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 125
Откуда: Equestria
Я вообще для кросс компиляции сделал просто установку целевой директории и выполнение команд в контексте этой директории. И всё.
(надо только сделать это в виде вьюшки, что бы автоматом устанавливало директорию, а то иногда забываю после перезагрузки ББ и получается беда)
https://files.catbox.moe/33rdxy.odc


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3805
Концепция библиотекаря хороша тем, что тогда не требуется для кросскомпиляций и линковок делать разные названия для папки Host

Когда-то Иван Кузьмицкий и Пётр Кушнир пошли по этому пути, чтобы разные папки платформенно-зависимых модулей хранить в разных директориях:
https://gitlab.molpit.org/Ikuzmitsky/blackbox-sdl
x86sdlhost
x86win32host

А с библиотекарем переименовывать Host модули будет не обязательно для кросс-разработки.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3805
Ещё идея, которая была. Это попробовать испытать третий уровень рабочих директорий.
И тогда может компилятору можно указывать приоритеты, чтобы брал скажем из второй, если там нет, то из третьей,и потом из первой, а складывал "артефакты" в третью:
Код:
DevCompiler.SetPaths("2-3-1->3");


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Евгений, ряд соображений.

компоненты - мне кажется, это уже смежная, но все же иная, задача. Одно дело (1) - стандартизация доступа к имеющимся де-факто артефактам (модулям, ресурсам, документам); другое дело (2) - установление соответствия компонентов и артефактов, компонентов и подсистем.

(2) - это уже больше про "менеджер коробочек", менеджер компонентов (компонентор?), и, кмк, заслуживает отдельного проектирования.

Я предлагаю пока остаться в рамках (1). Репозиторий определен как совокупность всех подсистем ББ. И покуда для хранения репозитория используется ФС, других источников сведений о том, какие имеются подсистемы, нет, кроме собсно ФС. И конечно, легко залезть "грязными руками" и напортачить в репозитории, и тогда перечислитель сойдет с ума. Но если вообразить, напр, ББ внутри браузера, то там грязными руками не влезешь в файловую систему, видную ББ.

И еще: две смежные, но отличные задачи - это (А) "получить координаты такого-то артефакта" и (Б) "перечислитель" репозитория. То, что мы обсуждали в зуме - это ведение "вариативных" модулей, компиляция, стыковка их в исполнимые файлы - это все закрывается (А). Другие системные инструменты - как карта, как у меня EdTools - требуют (Б).
Выходит, что (А) должно использоваться в загрузчике модулей, не так ли? Т.е. компоноваться в стартовый файл - в абсолютно все приложения на ББ.
А (Б) - задача узкоспециальная, необязательно ее таскать везде.

(А) решается процедурами GetSpec, а (Б) - перечислителем.

Далее, языки можно рассматривать как вариативность ресурсов, аналогично вариативности модулей: модули м.б. вариативны по архитектуре ЭВМ, по базовой системе, по версии ББ, и т.д. А ресурсы - по языку. И тогда с вариативностью ресурсов надо так же поступать, как с вариативностью модулей - "отодвигать" ее на откуп расширениям; чтобы проще был базовый интерфейс. Всамделе, есть же понятие "текущего" языка, и с ним-то и должен базовый интерфейс работать - т.е. де факто без указания языка. Это хорошо согласуется с модульной декомпозицией ББ: понятие языка появляется в Dialog, а это оч далеко от StdLoader.


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Антон, согласен с делением на (1) и (2). В том смысле, что для загрузки, компиляции и сборки с поддержкой вариативности модулей достаточно получения коордиант (1), перечисления не нужно. Можно (2) отделить и отложить. В зуме, насколько я помню, речь шла и об этой задача тоже, потому что функциональность (2) используется стандартными инструментами ББ.

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

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

Код:
PROCEDURE GetSpec (IN component, name: ARRAY OF CHAR; what: INTEGER; OUT loc: Files.Locator; OUT name: Files.Name; OUT type: Files.Type), NEW, ABSTRACT;


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3805
Вроде такой интерфейс весьма минималистичный.
component бы только в терминах внутренних обозначений бб заменить на sub
Код:
PROCEDURE GetSpec (IN sub, name: ARRAY OF CHAR; what: INTEGER;
     OUT loc: Files.Locator; OUT name: Files.Name; OUT type: Files.Type), NEW, ABSTRACT;


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


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Коллеги, хочу уточнить: кмк, я где-то раньше в примерах сделал ошибку, и теперь получается неоднозначный текст; надеюсь, что мы соглашаемся с одной и той же интерпретацией, а не с разными. Я имел в виду не глобальную процедуру, а типовую:

PROCEDURE (lib: Librarian) GetSpec (IN sub, name: ARRAY OF CHAR; what: INTEGER;
OUT loc: Files.Locator; OUT name: Files.Name; OUT type: Files.Type), NEW, ABSTRACT;

А вы?


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Евгений Темиргалеев писал(а):
В зуме, насколько я помню, речь шла и об этой задача тоже, потому что функциональность (2) используется стандартными инструментами ББ.

Верно, припоминаю. Значит, у меня не отложилось.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3805
adimetrius писал(а):
Коллеги, хочу уточнить: кмк, я где-то раньше в примерах сделал ошибку, и теперь получается неоднозначный текст; надеюсь, что мы соглашаемся с одной и той же интерпретацией, а не с разными. Я имел в виду не глобальную процедуру, а типовую:

PROCEDURE (lib: Librarian) GetSpec (IN sub, name: ARRAY OF CHAR; what: INTEGER;
OUT loc: Files.Locator; OUT name: Files.Name; OUT type: Files.Type), NEW, ABSTRACT;

А вы?

А зачем тип? Чем меньшее ООП, тем код понятнее. Это чтобы было разом несколько библиотекарей?


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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4708
Откуда: Россия, Орёл
Иван Денисов писал(а):
А зачем тип? Чем меньшее ООП, тем код понятнее. Это чтобы было разом несколько библиотекарей?

Да, чтобы иметь разные реализации.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3805
А всё понял, конечно, там ведь ABSTRACT стоит.


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
adimetrius писал(а):
PROCEDURE (lib: Librarian) GetSpec (IN sub, name: ARRAY OF CHAR; what: INTEGER;
OUT loc: Files.Locator; OUT name: Files.Name; OUT type: Files.Type), NEW, ABSTRACT
+


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

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


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

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


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

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