OberonCore https://forum.oberoncore.ru/ |
|
#046 Библиотекарь модулей https://forum.oberoncore.ru/viewtopic.php?f=134&t=6700 |
Страница 4 из 6 |
Автор: | adimetrius [ Понедельник, 10 Май, 2021 17:01 ] | ||
Заголовок сообщения: | Re: #046 Библиотекарь модулей | ||
Коллеги, Я реализовал тот интерфейс библиотекаря, о котором мы согласились выше, и у себя его с января встроил в компилятор. Никаких нареканий по интерфейсу и реализации, я его опубликовал в ветку 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 добавлены тж команды для топологической сортировки и компиляции списков модулей. Эти поправки - другим цветом. Я полагаю, они были бы полезны тоже, хотя это другой вопрос (трудоемко выпиливать обратно эти поправки из моих личных модулей).
|
Автор: | adimetrius [ Вторник, 11 Май, 2021 16:25 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Кажется, тема не очень актуальна )) Но для полноты: Иван Денисов справедливо отметил, что непонятно, что делать с содержимым архива. Уточняю: 1) Во-первых, смотреть: на те изменения, которые предложены в DevCPM и DevCompiler 2) А чтобы испробовать компиляцию в песочницу, я дошлю еще командный модуль, чтобы было удобнее пробовать. |
Автор: | Иван Денисов [ Среда, 12 Май, 2021 05:31 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Утренняя мысль. А не кажется ли вам, что получилась что-то близкое к альтернативной реализация для Files? Зачем тогда называть это новой сущностью "библиотекарь"? Может сделать такой DevFiles, который будет устанавливаться перед компиляцией, и потом возвращаться обычный назад? |
Автор: | adimetrius [ Среда, 12 Май, 2021 12:07 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Да, сходство есть, соглашусь; как в интерфейсе, так и в реализации. Но все-таки библиотекарь в DevLib - это не совсем каталог файлов. Это отделенная логика работы компилятора с модульными ипостасями. |
Автор: | adimetrius [ Понедельник, 13 Февраль, 2023 15:57 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
В Телеграм-чате "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 приведет вас куда? к старой версии? Или к новой? Если эти процедуры в библиотекаре, то решать это должен он. А как он это будет решать? Кроме того, библиотекарь мыслился как сервис для всего каркаса и всех приложений. Это что, выходит, все должны всегда дифференцировать - я хочу читать сейчас, а сейчас писать? Чем обосновано такое усложнение для третьих лиц? Это было бы колоссальное усложнение. И пока даже не ясно, чем оно могло бы быть обосновано. |
Автор: | adimetrius [ Понедельник, 13 Февраль, 2023 15:58 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Теперь по поводу перекрестной компиляции. Задача: есть рабочий ББ 1.7; а нужно скомпилировать ББ 2.0, т.е. производный, но все-таки другой набор модулей. Пусть ББ17 находится в папке БАЗА, а ББ20 в папке ББ20. Нужно скомпилировать, напр, модуль СтдДиалог. Очевидно, что нужно брать текст из ББ20/Стд/Мод/Диалог, и складывать артефакты в ББ20/Стд/Сим, /Код. Очевидно тж, что эти пути не имеют вообще никакого отношения к текущему библиотекарю и вообще к текущему ББ, его ФС, его рабочему и стандартному этажам. Поэтому для перекрестной компиляции я сделал отдельный модуль CrossCPM на основе DevCPM, и в нем указал, как и где компилятор должен брать тексты и символы модулей, и куда складывать. Но это совершенно отдельная задача. И она потребовала отдельного решения. Для нее не нужно менять интерфейс стандартного библиотекаря и втягивать эти частные решения в общий ББ. Кроме того, даже для этой частной задачи не потребовалось “Получить пути для некоторого вида артефактов”. Компилятор запрашивает конкретно: один раз - чтение символьного файла, один раз - запись, и еще один раз - запись кодового файла. Все. Вопрос “где должен на запись располагаться артефакт такого-то типа для такой-то подсистемы” - нигде не встает. (Дальше появилась задача поддержки версионности. Для этого оказалось удобно использовать нечто, напоминающее рабочий и стандартный этаж, и операцию “наложения” рабочего на стандартный. Но, опять же, это частная задача и для нее - частное решение) Поэтому я не вижу оснований для дифференциации “на чтение” и “на запись” в интерфейсе библиотекаря. |
Автор: | arisu [ Понедельник, 13 Февраль, 2023 17:40 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
скромно замечу, что 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 тоже ходит к библиотекарю на поклон. |
Автор: | Борис Рюмшин [ Понедельник, 13 Февраль, 2023 17:48 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
arisu писал(а): библиотекарю пришлось научится кроме путей возвращать Files.File. Ну я тоже предлагал и такой вариант сделать, так как это удобно. Однако, на самом деле, как мне кажется, мы крутимся около немного более расширенного понимания локатора и дополнительного интерфейса в Files. А библиотекарь задумывался, скажем так, для унификации обращения к подсистемам. |
Автор: | arisu [ Понедельник, 13 Февраль, 2023 18:34 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Борис Рюмшин писал(а): Однако, на самом деле, как мне кажется, мы крутимся около немного более расширенного понимания локатора и дополнительного интерфейса в Files. А библиотекарь задумывался, скажем так, для унификации обращения к подсистемам. я сначала думал, кстати, всё сделать через дополнительный слой FS, но потом передумал: не дело FS знать про какие-то там модули и прочее. даже если это просто транслятор поверх основной. омики вон тоже не стали делать открытие локализованой документации через FS-надстройку, а ручками проверяют пути.кстати, это бы тоже надо библиотекарю поручить, потому что каша получилась. |
Автор: | Иван Денисов [ Понедельник, 13 Февраль, 2023 18:46 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Я попозже дам более развернутый ответ, и особо ни на чем не настаиваю, однако мне нравятся библиотекари, и хочется сделать хорошо и надолго, чтобы предусмотреть нужды на будущее. Я подготовлю хороший пример. Однако отмечу то, что сразу очевидно. Никакие трюки с файловой системой не заменят то, что исходники мы отсчитываем от одного локатора, а артефакты компиляции складываем в иное место. Так что никак это невозможно решить трюками файловых систем. |
Автор: | Борис Рюмшин [ Понедельник, 13 Февраль, 2023 18:57 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Да нет, дело не в трюках ФС. |
Автор: | arisu [ Понедельник, 13 Февраль, 2023 19:07 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Иван Андреевич, вы гляньте в LC тоже. там интерфейс библиотекаря был продиктован чисто практическими нуждами — может, это вам даст какие-то дополнительные идеи (которые я потом смогу к себе утащить ;-). я не к тому, что его напрямую копировать надо, а просто в качестве одного из возможных источников вдохновения. |
Автор: | adimetrius [ Понедельник, 13 Февраль, 2023 20:34 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Коллеги, нельзя смешивать несмешуемое. Файлы - низкоуровневое понятие. Подсистемы, модули, артефакты компиляции, документы, ресурсы - это высокоуровневые понятия, которые могут один-к-одному совпадать с файлами, но не обязаны. Библиотекарь - сервис для высокоуровневых понятий. ФС - сервис для низкоуровневых понятий. Не надо их смешивать. Библиотекарь как раз предназначен для траснляции с высокого уровня на низкий. Если удобно получать от библиотекаря файлы - можно дополнить модуль StdLibrarian вспомогательной модульной процедурой, которая будет опираться на StdLibrarian.lib, получать от него локатор и имя и возвращать файл. Но модульной, а не типовой-абстрактной. Я пояснял в чате, почему библиотекарь должен возвращать локатор и имя, а не файл: потому что документ в окне (текст модуля) привязывается к локатору и имени, а не к файлу. То, что arisu описал про Lament Configuration - это как раз подмена Files.Directory на библиотекаря. Борис где-то писал, что трехэтажность можно бы реализовать в библиотекаре, не задевая ФС. Да, можно, примерно как arisu описал. Но тогда нужно обязать всех пользоваться библиотекарем для доступа к любым файлам. (А как обязать, не закрыв доступ к Files.dir - не знаю ) Ранее в этой теме было обсуждение, как язык включить как одну из "осей" при трансляции в файловые координаты. Тогда решили освоиться для начала с модулями (текст+машкод+символы), а потом уж браться за язык документов. Так что да, эту часть в библиотекаря стоит добавить. Но разные вызовы на чтение и на запись - нет. Во-первых, это дублирование того, что уже делается в многоэтажной ФС; во-вторых, - я уже описал проблему "следующего шага": вы прочли файл, записали его, закрыли, затем прочли снова - а он не изменился. Это кошмар программиста. Так можно из ББ сделать Windows скоро. "Чтобы не реализовывать руками такой поиск в каждом месте" - нужно сделать модульные процедуры, а не дополнять расширяемые интерфейсы. Мы же не в джава-мире, где все - это метод, и по умолчанию все overridable. Если мы вводим расширяемую типовую процедуру, мы тем самым используем другую методику проектирования и предполагаем, что кто-то когда-то изменит реализацию, и должны быть готовы к этому - это гораздо сложнее и ответственнее. А если что-то нужно просто для удобства - пожалте вам модульные процедуры. Это нерасширяемые, неизменные части программы. |
Автор: | adimetrius [ Понедельник, 13 Февраль, 2023 20:46 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Если у вас в LC компилятор должен по сложным правилам куда-то складывать артефакты - для разных платформ, например, как вы описывали, что, в дальнейшем, может быть признано вполне приемлемым и для ББ - то почему бы вам не внести эти изменения в DevCPM? Если эти особенности относятся именно к компилятору (а имеено так и есть, как я понимаю), зачем это правила и их реализацию выносить на общий уровень? А вообще, DevCPM, кмк, дожил до перемен. По изначальному авторскому замыслу это - интерфейс к машине для синт. анализатора и генератора кода. Нужна другая машина - меняешь модуль. Но было бы удобно, не меняя весь DevCPM, поменять то, что внутри него отвечает за ввод-вывод. Т.е. выделить небольшой абстрактный интерфейс для ввода-вывода (в т.ч. ошибок). Тогда, не меняя модуль, можно подменять устройство ввода-вывода внутри него, и продолжать пользоваться остальной частью компилятора. Кому угодно - плоские файлы читать, в консоль ошибки писать; кому надо - по этажам раскладывать; кому надо - по архитектурам. Но это нужно сделать именно в DevCPM, это узел в компиляторе, а не во всем ББ. По моему опыту: я для перекрестной компиляции продублировал все компиляторные модули: CrossCPS, CrossCPV и т.д., и в них единственная поправка - это использование IMPORT DevCPM := CrossCPM. Если бы выделить узел ввода-вывода в DevCPM и сделать его заменяемым - такое дублирование (и связанные с ним трудовые расходы) можно сократить. И, думаю, Иван смог бы реализовать в этом узле чтение плоских текстов, и arisu - компиляцию для разных платформ. |
Автор: | arisu [ Понедельник, 13 Февраль, 2023 21:09 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
adimetrius писал(а): Если у вас в LC компилятор должен по сложным правилам куда-то складывать артефакты - для разных платформ, например, как вы описывали, что, в дальнейшем, может быть признано вполне приемлемым и для ББ - то почему бы вам не внести эти изменения в DevCPM? Если эти особенности относятся именно к компилятору (а имеено так и есть, как я понимаю), зачем это правила и их реализацию выносить на общий уровень? почему только к компилятору? StdLoader тоже грузит объектные файлы из arch-подкаталогов. документация может находиться в arch-подкаталогах (опционально перекрывая общую для конкретной системы). ресурсы тоже могут. исходные тексты модулей могут. всё это использует один и тот же механизм для нахождения нужных вещей — и он вполне логично укладывается к концепцию библиотекаря.adimetrius писал(а): Но было бы удобно, не меняя весь DevCPM, поменять то, что внутри него отвечает за ввод-вывод. ну вот я всё это и пустил через библиотекаря, компилятор больше вообще не занимается открытием/созданием файлов и документов сам, а просит библиотекаря это сделать.adimetrius писал(а): (в т.ч. ошибок) а это уже есть: маркеры. надо просто вместо прямого использования DevMarkers сделать там фабрику, да подпилить интерфейсы.adimetrius писал(а): Если бы выделить узел ввода-вывода в DevCPM и сделать его заменяемым - такое дублирование (и связанные с ним трудовые расходы) можно сократить. И, думаю, Иван смог бы реализовать в этом узле чтение плоских текстов, и arisu - компиляцию для разных платформ. эм… так это уже сделано: библиотекарь. вот оно ровно так в LC и работает. разве что надо вместо view для исходных текстов отдавать reader — но view там нужен для маркеров. вот этот интерфейс осталось продумать ещё. всё это отлично укладывается в концепцию библиотекаря, по-моему.
|
Автор: | Борис Рюмшин [ Понедельник, 13 Февраль, 2023 21:11 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
adimetrius писал(а): Борис где-то писал, что трехэтажность можно бы реализовать в библиотекаре, не задевая ФС. Да, можно, примерно как arisu описал. Но тогда нужно обязать всех пользоваться библиотекарем для доступа к любым файлам. (А как обязать, не закрыв доступ к Files.dir - не знаю ) И да и нет. Я как раз пытаюсь сказать, что это не библиотекарь, а скорее какой-то интерфейс управления монтированием.. или виртуальными ФС что ли. Чтобы их можно было стыковать в нужном порядке. У нас нечто такое было реализовано, но не совсем чисто, чтобы это предложить в ББ. |
Автор: | arisu [ Понедельник, 13 Февраль, 2023 21:13 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
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. оно немного избыточное, потому что я пока не занимался минимизацией. |
Автор: | Борис Рюмшин [ Понедельник, 13 Февраль, 2023 21:15 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Arisu, у вас не тот библиотекарь, который изначально задумывался. Это уж точно. Тем более в BBLC он каких-то эпических габаритов. В общем, я согласен с Антоном, что многовато возлагается функций туда, где это явно не планировалось. |
Автор: | Иван Денисов [ Понедельник, 13 Февраль, 2023 21:16 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Так, я пока до какого-то внимательного ознакомления просто оставлю актуальный вариант, который предложил после обсуждения в чате, и после обсуждения с Борисом и после правок. Я пока ещё не могу подключиться к внимательному изучению аргументов Антона, и к созданию примеров, почему хотелось бы предусмотреть направления. Это позднее и вдумчиво! Код: 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. Инструмент низкоуровневый и с лаконичным интерфейсом. |
Автор: | arisu [ Понедельник, 13 Февраль, 2023 21:27 ] |
Заголовок сообщения: | Re: #046 Библиотекарь модулей |
Борис Рюмшин писал(а): Arisu, у вас не тот библиотекарь, который изначально задумывался. Это уж точно. Тем более в BBLC он каких-то эпических габаритов. я вижу библиотекаря как средство для доступа к данным подсистем. если нам что-то надо из подсистемы: исходник, доку, ресурс, объектник, символьный файл — никто не должен руками лазить по FS, добывая это. вообще не должен про FS думать, и про расположение тоже. вот у нас есть чёрный ящик «библиотекарь» — он всё знает про подсистемы, надо ходить к нему. половина функций там просто чтобы избежать копипасты, потому что я его встраивал «на живую», чтобы получить предварительную рабочую версию. интерфейс можно вдумчиво вычистить (и я это потом сделаю).но идея именно такая: не просто получаем какие-то пути где-то в FS к каким-то частям подсистем, а в принципе весь доступ к подсистемам роутим через библиотекаря. по уму он вообще должен возврашать не файлы, а ридеры и райтеры — просто я ещё это не сделал. но идея именно такая. p.s.: как вариант — библиотекаря вообще уничтожить, и действительно сделать это нашлёпкой над FS, со своим префиксом. и везде использовать пути типа "SUBSYS:Std/Mod/Abc.odc". но я идею библиотекаря сохранил, потому что мне нравится, что он не подразумевает хранение подсистем на файловой системе, и в принципе какие-то понятия файлов (см. выше про то, что надо возвращать Reader и Writer вместо File в будущем). |
Страница 4 из 6 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |