OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 13:11

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




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

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

Я реализовал тот интерфейс библиотекаря, о котором мы согласились выше, и у себя его с января встроил в компилятор. Никаких нареканий по интерфейсу и реализации, я его опубликовал в ветку dev20.

Но далее я взялся встраивать библиотекарь в компилятор-песочницу, еще Иван Андреич сделал переход к трехслойной файловой системе (USE/CUSTOM/STANDARD). И вот что я обнаружил.

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


Оказалось, что спецификация файла для чтения и для записи - разные вещи. Например, если компилятор хочет прочитать символьнй файл модуля М, то он вызовет GetSpec, и тот вернет ему локатор, указывающий на существующий файл - скажем, на этаже STANDARD. Затем компилятор решит, что нужно создать новый символьный файл для М. Однако тот же локатор, который возвращает GetSpec, нельзя использовать - он ведь указывает в STANDARD.

Я попробовал сначала добавить процедуру GetWrSpec, которая должна всегда возвращать локатор для записи, т.е. в USE. Ее оказалось достаточно.
Но все-таки при этом интерфейсе библиотекарь не полностью распоряжается библиотечными файлами. Все из-за Files.File.Register: например, компилятор получил от GetWrSpec указание, где должен создаваться файл; он его создает, и потом регистрирует. А если это был временный, ненужный в дальнейшем файл? Тогда его не нужно бы регистрировать. Но компилятор-то об этом не знает!

Тогда для компилятора-в-песочницу я пошел еще дальше:

MODULE CrossLib;

TYPE
Librarian* = POINTER TO ABSTRACT RECORD (StdLib.Librarian) END;

PROCEDURE (l: Librarian) Old* (IN mod: ARRAY OF CHAR; what: INTEGER): Files.FIle, NEW, ABSTRACT;
PROCEDURE (l: Librarian) New* (IN mod: ARRAY OF CHAR; what: INTEGER): Files.File, NEW, ABSTRACT;
PROCEDURE (l: Librarian) Register* (f: Files.File; IN mod: ARRAY OF CHAR; what: INTEGER), NEW, ABSTRACT;

PROCEDURE (lib: Librarian) Close* (f: Files.File), NEW, ABSTRACT;
(** Компилятор вызывает, когда "попользовался" старым символьным файлом *)

PROCEDURE (lib: Librarian) Drop* (f: Files.File), NEW, ABSTRACT;
(** Компилятор вызывает, когда компиляция не удалась, чтобы удалить (незарегистрированные) кодовый и символьный файлы; или когда новый символьный файл не отличается от старого *)

И в компиляторе-в-песочницу заменил GetSpec на Old, New и Register. Теперь вся логика работы компилятора с файлами вынесена в библиотекаря, и он как угодно может файлами жонглировать.

Такой ход позволил мне сделать спецбиблиотекаря, который позволяет запускать компилятор-в-песочницу "вхолостую": т.е. артефакты создаются, но не регистрируются (и после сборки мусора автоматически пропадают). Это нужно для проверки полноты и согласованности списков компиляции: возможно ли откомпилировать <список модулей> на базе папки <STANDARD>? Ранее для проверки полноты и согласованности мне приходилось делать выкопировку <списка модулей> в новую папку, запускать в ней ББ и там запускать компиляцию. Теперь эта рутинная задача решается автоматически, и мой рабочий процесс ускорился. Также, я экспериментирую про пакетный менеджер (коробейник, выходит, раз у нас BlackBox), и там тоже оч полезно компилировать в песочницу и филигранно управлять файлами.

Итог:
Предлагаю включить компиляцию-в-песочницу прямо в СР2: благодаря изящной архитектуре СР2 изменения незначительные и касаются всего двух модулей: DevCPM и DevCompiler. Прилагаю архив с поправленными модулями.

В DevCompiler добавлены тж команды для топологической сортировки и компиляции списков модулей. Эти поправки - другим цветом. Я полагаю, они были бы полезны тоже, хотя это другой вопрос (трудоемко выпиливать обратно эти поправки из моих личных модулей).


Вложения:
Sandbox.zip [33.15 КБ]
Скачиваний: 190
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 11 Май, 2021 16:25 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Кажется, тема не очень актуальна ))

Но для полноты: Иван Денисов справедливо отметил, что непонятно, что делать с содержимым архива. Уточняю:
1) Во-первых, смотреть: на те изменения, которые предложены в DevCPM и DevCompiler
2) А чтобы испробовать компиляцию в песочницу, я дошлю еще командный модуль, чтобы было удобнее пробовать.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Утренняя мысль. А не кажется ли вам, что получилась что-то близкое к альтернативной реализация для Files? Зачем тогда называть это новой сущностью "библиотекарь"? Может сделать такой DevFiles, который будет устанавливаться перед компиляцией, и потом возвращаться обычный назад?


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Да, сходство есть, соглашусь; как в интерфейсе, так и в реализации. Но все-таки библиотекарь в DevLib - это не совсем каталог файлов. Это отделенная логика работы компилятора с модульными ипостасями.


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
В Телеграм-чате "BlackBox 2.0" Иван преложил вот такое изменение в интерфейс библиотекаря:
Цитата:
PROCEDURE GetExtSpec* (mod, cat: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name);
на запись
PROCEDURE GetIntSpec* (mod, cat: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name);
на чтение


У меня вот такие соображения.

1) Я предлагал библиотекарь для унификации вычисления путей во всем каркасе, а не для
Цитата:
чтобы брать кодовые файлы из одного места пока среда работает и "развертывается" динамической загрузкой, а артефакты компиляции была возможность складывать в другое место.


Еще раз: моя задача была собрать в едином месте все вычисления путей, чтобы это не было "размазано" по каркасу и по прикладным подсистемам.

2) Я делал перекрестный компилятор, и в нем потребовался специализированный библиотекарь, именно в силу перекрестности. Опишу в следующем сообщении.
Почему потребовалось указание "направления" в том интерфейсе, который Иван предлагает - IntSpec/ExtSpec - мне не понятно, и Иван не пояснил, какую, например, задачу он решает.

3) Поясню. Допустим, нужно перекомпилировать модуль ПрилМ, импортирующий ПрилН, причем в ПрилМ добавлена экспортированная переменная. Компилятор для этого издаст запросы:

А) Прочесть Прил/Сим/Н.осф - прочесть символы импортированного модуля
Б) Прочесть Прил/Сим/М.осф - прочесть прежнюю версию символов компилируемого модуля М
В) Создать новый файл Ф в Прил/Сим - записать обновленную символьную информацию для М
Г) Зрегистрировать Ф под именем М.осф - зарегистрировать обновленный символьный файл

В этом сценарии путь везде один и тот же - Прил/Сим. Так работает StdDialog.GetSubLoc в прежних версиях, так работает StdLibrarian, который мы согласовали ранее, и реализацию которого я предложил.
Заметьте, что компилятор нигде не указывает направление IntSpec или ExtSpec. Для этого в прежних ББ не было предусмотрено ничего.

Усложнение происходило в файловой системе ББ. Они и ранее была двухэтажной, а в версии 2.0 мы экспериментируем с трехэтажной. Но это усложнение было аккуратно реализовано внутри ФС, и никуда вне модуля Files не расползалось.

Из-за многоэтажности запросы А и Б приведут к рабочему этажу, если соответствующий файл есть в рабочем этаже; или к стандартному этажу, если в рабочем этаже нет соответствующего файла.
Запрос В гарантированно приведет к рабочему этажу.
Т.е. локатор - везде один и тот же, Прил/Сим. Но для Files.dir.Old(Ф1) модуль ФС решает, что Прил/Сим => РАБОЧИЙ/Прил/Сим/Ф1, если там есть Ф1, или СТАНДАРТНЫЙ/Прил/Сим/Ф1, если в рабочем нет Ф1. А для Files.dir.New модуль ФС решает безусловно, что Прил/Сим => РАБОЧИЙ/Прил/Сим.

Все эти запросы разрешаются НЕ библиотекарем, а файловой системой. Библиотекарь и компилятор остаются простыми - с их т.зр. существует единственный путь Прил/Сим, без дифференциации на IntSpec/ExtSpec.

Все это прекрасно работало ранее и работает сейчас в 2.0.

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

Замечу, что при разделении на IntSpec/ExtSpec возникает неясность "на следующем шаге". Вот вы запросили ExtSpec, записали туда файл, закрыли. Вскоре вам потребовалось его прочесть (вы снова компилируете). Теперь IntSpec приведет вас куда? к старой версии? Или к новой? Если эти процедуры в библиотекаре, то решать это должен он. А как он это будет решать?

Кроме того, библиотекарь мыслился как сервис для всего каркаса и всех приложений. Это что, выходит, все должны всегда дифференцировать - я хочу читать сейчас, а сейчас писать? Чем обосновано такое усложнение для третьих лиц?
Это было бы колоссальное усложнение. И пока даже не ясно, чем оно могло бы быть обосновано.


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

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

Задача: есть рабочий ББ 1.7; а нужно скомпилировать ББ 2.0, т.е. производный, но все-таки другой набор модулей.

Пусть ББ17 находится в папке БАЗА, а ББ20 в папке ББ20. Нужно скомпилировать, напр, модуль СтдДиалог. Очевидно, что нужно брать текст из ББ20/Стд/Мод/Диалог, и складывать артефакты в ББ20/Стд/Сим, /Код. Очевидно тж, что эти пути не имеют вообще никакого отношения к текущему библиотекарю и вообще к текущему ББ, его ФС, его рабочему и стандартному этажам.
Поэтому для перекрестной компиляции я сделал отдельный модуль CrossCPM на основе DevCPM, и в нем указал, как и где компилятор должен брать тексты и символы модулей, и куда складывать.

Но это совершенно отдельная задача. И она потребовала отдельного решения. Для нее не нужно менять интерфейс стандартного библиотекаря и втягивать эти частные решения в общий ББ.
Кроме того, даже для этой частной задачи не потребовалось “Получить пути для некоторого вида артефактов”. Компилятор запрашивает конкретно: один раз - чтение символьного файла, один раз - запись, и еще один раз - запись кодового файла. Все. Вопрос “где должен на запись располагаться артефакт такого-то типа для такой-то подсистемы” - нигде не встает.

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

Поэтому я не вижу оснований для дифференциации “на чтение” и “на запись” в интерфейсе библиотекаря.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 17:40 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
скромно замечу, что Lament Configuration всё через библиотекаря пускает: и компилятор, и документацию, и ресурсы, и небо, и аллаха. для чего, конечно, интерфейс библиотекаря тоже пришлось расширить. и да, библиотекарю пришлось научится кроме путей возвращать Files.File. rationale: во-вторых, немного уменьшается паста в пользователях библиотекаря. и во-первых, никто не сказал, что библиотекарь обязан возвращать именно стандартные файлы, а не какие-то совсем другие (добавлять свой драйвер FS при этом может быть не обязательно).

также Lament Configuration реализует полноценную кросс-компиляцию — тоже благодаря библиотекарю.

создавать файлы, однако, библиотекарю пришлось потому что в целом кросс-комиплятор может импортировать символы из Sym/Win, например, а писать новые в Sym/WinMdi. то есть, локатор для чтения и локатор для записи в общем случае не обязаны совпадать. опять же: я научил библиотекаря таким штукам, чтобы иметь больше контроля: у нас библитека строгая, не «вон там на полке книгу возьми», а: «стоять-бояться! сейчас всё принесу, дёрнешься сам — расстрел!»

кстати, построитель заголовков окон в StdWindows за названиями подкаталого подсистем (типа "Mod", "Docu") тоже ходит к библиотекарю. и в других местах ходят (хотя я ещё не везде поправил, конечно).

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


а, кажется непонятно вышло. в общем, Lament Configuration реализует архитектуры наподобие механизма локализации документации: для архитектуры `BooGooHoo` сначала смотрим в `<dir>/BooGooHoo/<filename>`, потом в `<dir>/BooGoo/<filename>`, потом в `<dir>/Boo/<filename>`, потом (опционально, зависит от типа ресурса) в `<dir>/<filename>`. но пишем всегда в `<dir>/BooGooHoo/<filename>`.

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

p.s.: кстати, StdLoader в Lament Configuration тоже ходит к библиотекарю на поклон.


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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
arisu писал(а):
библиотекарю пришлось научится кроме путей возвращать Files.File.

Ну я тоже предлагал и такой вариант сделать, так как это удобно.

Однако, на самом деле, как мне кажется, мы крутимся около немного более расширенного понимания локатора и дополнительного интерфейса в Files. А библиотекарь задумывался, скажем так, для унификации обращения к подсистемам.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 18:34 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Борис Рюмшин писал(а):
Однако, на самом деле, как мне кажется, мы крутимся около немного более расширенного понимания локатора и дополнительного интерфейса в Files. А библиотекарь задумывался, скажем так, для унификации обращения к подсистемам.
я сначала думал, кстати, всё сделать через дополнительный слой FS, но потом передумал: не дело FS знать про какие-то там модули и прочее. даже если это просто транслятор поверх основной. омики вон тоже не стали делать открытие локализованой документации через FS-надстройку, а ручками проверяют пути.

кстати, это бы тоже надо библиотекарю поручить, потому что каша получилась.


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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 18:57 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Да нет, дело не в трюках ФС.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 19:07 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Андреевич, вы гляньте в LC тоже. там интерфейс библиотекаря был продиктован чисто практическими нуждами — может, это вам даст какие-то дополнительные идеи (которые я потом смогу к себе утащить ;-). я не к тому, что его напрямую копировать надо, а просто в качестве одного из возможных источников вдохновения.


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

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

Если удобно получать от библиотекаря файлы - можно дополнить модуль StdLibrarian вспомогательной модульной процедурой, которая будет опираться на StdLibrarian.lib, получать от него локатор и имя и возвращать файл. Но модульной, а не типовой-абстрактной.

Я пояснял в чате, почему библиотекарь должен возвращать локатор и имя, а не файл: потому что документ в окне (текст модуля) привязывается к локатору и имени, а не к файлу.

То, что arisu описал про Lament Configuration - это как раз подмена Files.Directory на библиотекаря.

Борис где-то писал, что трехэтажность можно бы реализовать в библиотекаре, не задевая ФС. Да, можно, примерно как arisu описал. Но тогда нужно обязать всех пользоваться библиотекарем для доступа к любым файлам. (А как обязать, не закрыв доступ к Files.dir - не знаю :shock: )

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

Но разные вызовы на чтение и на запись - нет. Во-первых, это дублирование того, что уже делается в многоэтажной ФС; во-вторых, - я уже описал проблему "следующего шага": вы прочли файл, записали его, закрыли, затем прочли снова - а он не изменился. Это кошмар программиста. Так можно из ББ сделать Windows скоро.

"Чтобы не реализовывать руками такой поиск в каждом месте" - нужно сделать модульные процедуры, а не дополнять расширяемые интерфейсы. Мы же не в джава-мире, где все - это метод, и по умолчанию все overridable. Если мы вводим расширяемую типовую процедуру, мы тем самым используем другую методику проектирования и предполагаем, что кто-то когда-то изменит реализацию, и должны быть готовы к этому - это гораздо сложнее и ответственнее. А если что-то нужно просто для удобства - пожалте вам модульные процедуры. Это нерасширяемые, неизменные части программы.


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

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

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

Но было бы удобно, не меняя весь DevCPM, поменять то, что внутри него отвечает за ввод-вывод. Т.е. выделить небольшой абстрактный интерфейс для ввода-вывода (в т.ч. ошибок). Тогда, не меняя модуль, можно подменять устройство ввода-вывода внутри него, и продолжать пользоваться остальной частью компилятора. Кому угодно - плоские файлы читать, в консоль ошибки писать; кому надо - по этажам раскладывать; кому надо - по архитектурам. Но это нужно сделать именно в DevCPM, это узел в компиляторе, а не во всем ББ.

По моему опыту: я для перекрестной компиляции продублировал все компиляторные модули: CrossCPS, CrossCPV и т.д., и в них единственная поправка - это использование IMPORT DevCPM := CrossCPM.
Если бы выделить узел ввода-вывода в DevCPM и сделать его заменяемым - такое дублирование (и связанные с ним трудовые расходы) можно сократить. И, думаю, Иван смог бы реализовать в этом узле чтение плоских текстов, и arisu - компиляцию для разных платформ.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 21:09 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
adimetrius писал(а):
Если у вас в LC компилятор должен по сложным правилам куда-то складывать артефакты - для разных платформ, например, как вы описывали, что, в дальнейшем, может быть признано вполне приемлемым и для ББ - то почему бы вам не внести эти изменения в DevCPM? Если эти особенности относятся именно к компилятору (а имеено так и есть, как я понимаю), зачем это правила и их реализацию выносить на общий уровень?
почему только к компилятору? StdLoader тоже грузит объектные файлы из arch-подкаталогов. документация может находиться в arch-подкаталогах (опционально перекрывая общую для конкретной системы). ресурсы тоже могут. исходные тексты модулей могут. всё это использует один и тот же механизм для нахождения нужных вещей — и он вполне логично укладывается к концепцию библиотекаря.

adimetrius писал(а):
Но было бы удобно, не меняя весь DevCPM, поменять то, что внутри него отвечает за ввод-вывод.
ну вот я всё это и пустил через библиотекаря, компилятор больше вообще не занимается открытием/созданием файлов и документов сам, а просит библиотекаря это сделать.

adimetrius писал(а):
(в т.ч. ошибок)
а это уже есть: маркеры. надо просто вместо прямого использования DevMarkers сделать там фабрику, да подпилить интерфейсы.

adimetrius писал(а):
Если бы выделить узел ввода-вывода в DevCPM и сделать его заменяемым - такое дублирование (и связанные с ним трудовые расходы) можно сократить. И, думаю, Иван смог бы реализовать в этом узле чтение плоских текстов, и arisu - компиляцию для разных платформ.
эм… так это уже сделано: библиотекарь. вот оно ровно так в LC и работает. разве что надо вместо view для исходных текстов отдавать reader — но view там нужен для маркеров. вот этот интерфейс осталось продумать ещё. всё это отлично укладывается в концепцию библиотекаря, по-моему.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 21:11 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
adimetrius писал(а):
Борис где-то писал, что трехэтажность можно бы реализовать в библиотекаре, не задевая ФС. Да, можно, примерно как arisu описал. Но тогда нужно обязать всех пользоваться библиотекарем для доступа к любым файлам. (А как обязать, не закрыв доступ к Files.dir - не знаю :shock: )

И да и нет. Я как раз пытаюсь сказать, что это не библиотекарь, а скорее какой-то интерфейс управления монтированием.. или виртуальными ФС что ли. Чтобы их можно было стыковать в нужном порядке. У нас нечто такое было реализовано, но не совсем чисто, чтобы это предложить в ББ.


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

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
adimetrius писал(а):
"Чтобы не реализовывать руками такой поиск в каждом месте" - нужно сделать модульные процедуры, а не дополнять расширяемые интерфейсы.

ну вы посмотрите же, ну! ;-)
Код:
DEFINITION StdLibrarian;

   IMPORT Files;

   CONST
      OK = 0;
      RootSub = "<<ROOT>>";
      SYSdir = "System";
      code = 0;
      docu = 4;
      moddocu = 3;
      rsrc = 5;
      source = 2;
      symbol = 1;

   TYPE
      FileInfo = POINTER TO RECORD
         next: FileInfo;
         loc: Files.Locator;
         name: Files.Name;
         length: INTEGER;
         type: Files.Type;
         modified: RECORD
            year, month, day, hour, minute, second: INTEGER
         END;
         attr: SET;
         (fi: FileInfo) Path (OUT path: ARRAY OF CHAR), NEW
      END;

      Librarian = POINTER TO ABSTRACT RECORD
         res: INTEGER;
         (lib: Librarian) GetKindDirName (kind: INTEGER; OUT dirname: DirName), NEW, ABSTRACT;
         (lib: Librarian) GetKindFileType (kind: INTEGER; OUT ftype: Files.Type), NEW, ABSTRACT;
         (lib: Librarian) GetSpec (IN sub, name: ARRAY OF CHAR; kind: INTEGER; OUT loc: Files.Locator; OUT fname: Files.Name; OUT ftype: Files.Type), NEW, ABSTRACT;
         (lib: Librarian) GetSubLocator (IN sub: ARRAY OF CHAR): Files.Locator, NEW, ABSTRACT;
         (lib: Librarian) Root (): Files.Locator, NEW, ABSTRACT;
         (lib: Librarian) SplitName (IN name: ARRAY OF CHAR; VAR head, tail: ARRAY OF CHAR), NEW, ABSTRACT
      END;

      ArchIterator = RECORD
         (VAR it: ArchIterator) Done (): BOOLEAN, NEW;
         (VAR it: ArchIterator) InitArchOnly (baseloc: Files.Locator), NEW;
         (VAR it: ArchIterator) InitWithCommon (baseloc: Files.Locator), NEW;
         (VAR it: ArchIterator) Next (): Files.Locator, NEW
      END;

      DirName = ARRAY 16 OF CHAR;

   VAR
      askNewFiles: BOOLEAN;
      lib-: Librarian;
      stdLib-: Librarian;
      useFilesStdDir: BOOLEAN;

   PROCEDURE GetFileSpec (IN unsname: ARRAY OF CHAR; kind: INTEGER; OUT loc: Files.Locator; OUT fname: Files.Name; OUT ftype: Files.Type);
   PROCEDURE GetSpec (IN sub, name: ARRAY OF CHAR; kind: INTEGER; OUT loc: Files.Locator; OUT fname: Files.Name; OUT ftype: Files.Type);
   PROCEDURE ListAllFilesInAllSubs (includeRoot: BOOLEAN; kind: INTEGER): FileInfo;
   PROCEDURE ListAllFilesInSub (IN sub: ARRAY OF CHAR; kind: INTEGER): FileInfo;
   PROCEDURE NewFile (IN unsname: ARRAY OF CHAR; kind: INTEGER; OUT outfname: Files.Name): Files.File;
   PROCEDURE NewStdLibrarian (loc: Files.Locator): Librarian;
   PROCEDURE OldFile (IN unsname: ARRAY OF CHAR; kind: INTEGER): Files.File;
   PROCEDURE OldFileInSub (IN sub, name: ARRAY OF CHAR; kind: INTEGER; OUT loc: Files.Locator): Files.File;
   PROCEDURE OldFileInSubLang (IN sub, name, language: ARRAY OF CHAR; kind: INTEGER; OUT loc: Files.Locator): Files.File;
   PROCEDURE OldFileInSubPath (IN sub, name: ARRAY OF CHAR; kind: INTEGER; OUT loc: Files.Locator; OUT path: ARRAY OF CHAR): Files.File;
   PROCEDURE OldFileNoSplit (IN sub: ARRAY OF CHAR; IN name: Files.Name; kind: INTEGER): Files.File;
   PROCEDURE RemoveArchSubPart (VAR arch: ARRAY OF CHAR);
   PROCEDURE SetLib (librarian: Librarian);
   PROCEDURE SplitName (IN name: ARRAY OF CHAR; VAR head, tail: ARRAY OF CHAR);

END StdLibrarian.

оно немного избыточное, потому что я пока не занимался минимизацией.


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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Arisu, у вас не тот библиотекарь, который изначально задумывался. Это уж точно. Тем более в BBLC он каких-то эпических габаритов.

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


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Так, я пока до какого-то внимательного ознакомления просто оставлю актуальный вариант, который предложил после обсуждения в чате, и после обсуждения с Борисом и после правок. Я пока ещё не могу подключиться к внимательному изучению аргументов Антона, и к созданию примеров, почему хотелось бы предусмотреть направления. Это позднее и вдумчиво!

Код:
DEFINITION Librarian;

   IMPORT Files;

   TYPE
      Librarian = POINTER TO ABSTRACT RECORD
         res: INTEGER;
         (lib: Librarian) GetExtSpec (IN mod, cat: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name), NEW, ABSTRACT;
         (lib: Librarian) GetIntSpec (IN mod, cat: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name), NEW, ABSTRACT;
         (lib: Librarian) SplitName (IN name: ARRAY OF CHAR; VAR head, tail: ARRAY OF CHAR), NEW, ABSTRACT
      END;

   VAR lib-, stdLib-: Librarian;

   PROCEDURE NewStdLibrarian (loc: Files.Locator): Librarian;
   PROCEDURE SetLib (librarian: Librarian);

END Librarian.


Что лично меня тревожит, что тут для простоты интерфейса пренебрегли
Files (d: Directory) GetFileName (name: Name; type: Type; OUT filename: Name)
И сразу возвращаем имя. Я эту штуку GetFileName считаю рудиментарной, моя б воля, я бы её нигде в ББ не использовал. Она просто соединяет две строки точкой в Windows и в Linux. А для мака не знаю, как там актуально обстоят дела.

также прокомментирую почему из Std перенесли в System, так как Борис считает, что Std мы перегрузили тем, для чего эта посистема вовсе не предназначена. Там разные одномодульные инструменты лежат. А я её трактовал как кросс-платформенную стандартную реализацию фреймворка. Что там делать с другими модулями пока не придумал, я ещё осмысливаю сей факт. Может и стоит чуть поменять понимание Std, чтобы не увеличивать число подсистем. Но памятуя, что и Евгений изначально предлагал библиотекаря в System (хотя могу помнить не верно), у меня лично нет возражений, чтобы это было в System. Инструмент низкоуровневый и с лаконичным интерфейсом.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 21:27 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Борис Рюмшин писал(а):
Arisu, у вас не тот библиотекарь, который изначально задумывался. Это уж точно. Тем более в BBLC он каких-то эпических габаритов.
я вижу библиотекаря как средство для доступа к данным подсистем. если нам что-то надо из подсистемы: исходник, доку, ресурс, объектник, символьный файл — никто не должен руками лазить по FS, добывая это. вообще не должен про FS думать, и про расположение тоже. вот у нас есть чёрный ящик «библиотекарь» — он всё знает про подсистемы, надо ходить к нему. половина функций там просто чтобы избежать копипасты, потому что я его встраивал «на живую», чтобы получить предварительную рабочую версию. интерфейс можно вдумчиво вычистить (и я это потом сделаю).

но идея именно такая: не просто получаем какие-то пути где-то в FS к каким-то частям подсистем, а в принципе весь доступ к подсистемам роутим через библиотекаря. по уму он вообще должен возврашать не файлы, а ридеры и райтеры — просто я ещё это не сделал. но идея именно такая.

p.s.: как вариант — библиотекаря вообще уничтожить, и действительно сделать это нашлёпкой над FS, со своим префиксом. и везде использовать пути типа "SUBSYS:Std/Mod/Abc.odc". но я идею библиотекаря сохранил, потому что мне нравится, что он не подразумевает хранение подсистем на файловой системе, и в принципе какие-то понятия файлов (см. выше про то, что надо возвращать Reader и Writer вместо File в будущем).


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

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


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

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


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

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