OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 29 Март, 2024 02:32

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




Начать новую тему Ответить на тему  [ Сообщений: 118 ]  На страницу Пред.  1, 2, 3, 4, 5, 6
Автор Сообщение
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:47 

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


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

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

Вложение:
direction.png
direction.png [ 87.14 КБ | Просмотров: 4803 ]


Если есть направление, то не надо делать несколько разных библиотекарей, и в один момент времени будет в системе только один библиотекарь. Поэтому это и проще, на мой взгляд, не требует много модификаций вносить в компилятор.

Накидал пример библиотекаря, который точно будет нужен, и поэтому хотелось бы иметь такую возможность.
Что он делает, он позволяет перекомпилировать модули Блэкбокса в любой произвольной папке. Или собрать в ней проект для испытаний.
UPD: Вы можете прямо сейчас проверить, это уже работает в сборке 128 или из ветки `blackbox20`

Код:
MODULE CheckSandBox;

   IMPORT
      Librarian, Kernel, Files, Strings;

   TYPE
      Sandbox = POINTER TO RECORD (Librarian.Librarian)
         from, to: Files.Locator
      END;

   (* SandBox Librarian *)

   PROCEDURE (lib: Sandbox) SplitName (IN name: ARRAY OF CHAR; VAR head, tail: ARRAY OF CHAR);
      VAR i, j: INTEGER; ch, lch: CHAR;
   BEGIN
      i := 0; ch := name[0];
      IF ch # 0X THEN
         REPEAT
            head[i] := ch; lch := ch; INC(i); ch := name[i]
         UNTIL (ch = 0X) OR (ch = ".") OR Strings.IsUpper(ch) & ~Strings.IsUpper(lch);
         IF ch = "." THEN i := 0; ch := name[0] END;
         head[i] := 0X; j := 0;
         WHILE ch # 0X DO tail[j] := ch; INC(i); INC(j); ch := name[i] END;
         tail[j] := 0X;
         IF tail = "" THEN tail := head$; head := "System" END;
      ELSE
         head := "System"; tail := ""
      END
   END SplitName;

   PROCEDURE (lib: Sandbox) GetExtSpec (IN mod, cat: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name);
      VAR head, tail: Kernel.Name;
   BEGIN
      lib.SplitName(mod, head, tail);
      loc := lib.to.This(head);
      IF cat = "Mod" THEN
         loc := loc.This("Mod"); name := tail + ".odc"
      ELSIF cat = "Sym" THEN
         loc := loc.This("Sym"); name := tail + ".osf"
      ELSIF cat = "Code" THEN
         loc := loc.This("Code"); name := tail + ".ocf"
      ELSIF cat = "Docu" THEN
         loc := loc.This("Docu"); name := tail + ".odc"
      ELSIF cat = "Rsrc" THEN
         loc := loc.This("Rsrc"); name := tail + ".odc"
      ELSE
         HALT(20)
      END;
      lib.res := 0
   END GetExtSpec;

   PROCEDURE (lib: Sandbox) GetIntSpec (IN mod, cat: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name);
      VAR head, tail: Kernel.Name;
   BEGIN
      lib.SplitName(mod, head, tail);
      loc := lib.from.This(head);
      IF cat = "Mod" THEN
         loc := loc.This("Mod"); name := tail + ".odc"
      ELSIF cat = "Sym" THEN
         loc := lib.to.This(head);
         loc := loc.This("Sym"); name := tail + ".osf"
      ELSIF cat = "Code" THEN
         loc := loc.This("Code"); name := tail + ".ocf"
      ELSIF cat = "Docu" THEN
         loc := loc.This("Docu"); name := tail + ".odc"
      ELSIF cat = "Rsrc" THEN
         loc := loc.This("Rsrc"); name := tail + ".odc"
      ELSE
         HALT(20)
      END;
      lib.res := 0
   END GetIntSpec;

   PROCEDURE Set* (from, to: ARRAY 256 OF CHAR);
      VAR s: Sandbox;
   BEGIN
      NEW(s);
      s.from := Files.dir.This(from);
      s.to := Files.dir.This(to);
      Librarian.SetLib(s);
   END Set;
   
   PROCEDURE Reset*;
   BEGIN
      Librarian.SetLib(Librarian.stdLib);
   END Reset;

END CheckSandBox.

"CheckSandBox.Set('', 'SandBox')"



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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
arisu писал(а):
Борис Рюмшин писал(а):
Как показало вскры... практическое изучение вопроса, это дело вводится вместо Files.Locator, с заменой много чего ещё. Я думал, что можно как-то дополнить Files ещё одним интерфейсом в дополнение к Locator и Files, но это несколько кардинально, и не уверен, что имеет смысл для обычного ББ.
а почему так? почему нельзя завести своё расширение локатора, и навесить installable FS?

Можно, но объектное хранилище требует несколько большего, чем возможно выразить в виде Locator. Но это уже совершенно другая тема.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Обращаю внимание, что по-умолчанию поведение обеих процедур идентично, поэтому не будет никакой собственно проблемы выбора, если пользуетесь стандартным библиотекарем.
Код:
PROCEDURE (lib: StdLibrarian) GetIntSpec (IN mod, cat: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name);
BEGIN
   lib.GetExtSpec(mod, cat, loc, name)
END GetIntSpec;

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


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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Иван Денисов писал(а):
Однако, как я написал ваше с примером песочницы, — для специалистов открываются большие возможности по диспетчеризации ресурсов.
К сожалению, лишние возможности "для специалистов" потом очень хреново изымаются из оборота. После того как на них навернули не весть чего. Не думаю, что стоит что-то делать только для того, что это может зачем-нибудь когда-нибудь пригодиться.

Ещё раз предлагаю тему прикрыть с минимальным решением и заняться дальнейшей стабилизацией 2.0.


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

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
замечу в скобках, что именно из этой исходной точки я вышел со своим SubsManager: первым делом там как раз и появился раздельный API для «старых» и «новых» файлов. после чего я стал его внедрять в остальную систему — и увидел довольно однообразный набор паттернов использования этого API, которые частично уже оформились, а частично дооформляются в SubsManager. в остальном коде заодно стало меньше копипасты, и остальной код перестал что-либо предполагать про то, как и где на самом деле хранятся документы подсистем.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис Рюмшин писал(а):
Иван Денисов писал(а):
Однако, как я написал ваше с примером песочницы, — для специалистов открываются большие возможности по диспетчеризации ресурсов.
К сожалению, лишние возможности "для специалистов" потом очень хреново изымаются из оборота. После того как на них навернули не весть чего. Не думаю, что стоит что-то делать только для того, что это может зачем-нибудь когда-нибудь пригодиться.

Ещё раз предлагаю тему прикрыть с минимальным решением и заняться дальнейшей стабилизацией 2.0.


Я бы хотел, чтобы вы поняли логику, что я скажем SplitName поместил в расширение по причине того, что это даёт свободу менять разделения модуля на название подсистемы и файла. И направление также даёт степень свободы. Считаю, что в создании постоянных решение в новых инструментах, которые пока ещё не исследованы, важно обеспечить эти самые степени свободы для возможности их изучения без последующих внесений правок в бету, чтобы потом не было мучительно больно. К тому же эксперименты я провёл, которые отметают аргументы Антона, о том, что в Блэкбоксе наличие направлений чему-то вредит. Ничему не вредит, идёт полная перекомпиляция всего ББ по иному локатору. Там однозначно задано, читаем символьный файл, или записываем. Так что я не считаю, что эта степень свободы с направлением лишняя какая-то.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис Рюмшин писал(а):
Предлагаю не заморачиваться и оставить библиотекарь в простом виде
Код:
DEFINITION Librarian;

   IMPORT Files;

   TYPE
      Librarian = POINTER TO ABSTRACT RECORD
         res: INTEGER;
         (lib: Librarian) GetSpec (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.

То есть направление убрать. Библиотекарь штука пока для внутреннего использования, можно и поменять потом. Все остальные вариации на тему -- от лукавого. Потому что тут уже куча точек зрения и сделать надолго, как Иван хочет, явно не получится.

А вот со SplitName уже проблема, потому что он из ядра уехал. На него уже начали в таком виде опираться (конкретно, как на StdLibrarian.SplitName).

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


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

К примеру:
"Sym" - категория для доступа безотносительно направления
"=>Sym" - категория на запись нового символьного файла
"<=Sym" - категория на чтение нового символьного файла

Можно ведь и так сделать, но это создаёт новый синтаксис, а зачем нам новый синтаксис, если уже есть Компонентный Паскаль.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Скажу так, что мне для принятие решения, оставить без направлений или жить дальше с направлениями не хватает опыта. Сейчас я сделал полностью работоспособный вариант с направлениями, и хочу его осмыслить, посмотреть, что будет получаться. Есть уже как минимум два экспериментальных библиотекаря, один для поддержки плоских файлов, другой для песочницы. Оба потребовали минимальных изменений в модулях самого Блэкбокса. Я бы ещё предпочёл импортировать Librarian, в StdLoader, чтобы там убрать дублирование кода. Но это уже и для какого-то проекта отдельно можно делать, где требуется особая система уже на первом этапе загрузки. Если в Librarian скопировать IsUpper из Strings, то тогда не придётся Strings линковать в загрузчик при необходимости.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Код:
DEFINITION Librarian;

   IMPORT Files;

   TYPE
      Librarian = POINTER TO ABSTRACT RECORD
         res: INTEGER;
         (lib: Librarian) GetSpec (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.

Чем мне нравится такой вариант, тем что он будет совместим с уже разработанными системами Антона (но не по константам, а по ключам "Mod", "Sym" и т.п.), а также совместим с 2.0, в компилятор которого уже добавлены направления, где мне надо будет только заменить GetExtSpec(..., "Sym" на GetSpec(..., "SymWrite" , получится — все в выигрыше.

Устроит ли всех участников обсуждения такой итог?


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

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
где мне надо будет только заменить GetExtSpec(..., "Sym" на GetSpec(..., "SymWrite" , получится — все в выигрыше.
может, сделать для этого константы? а то опечататься несложно, да и запоминать, где там "Write", или что ещё… зачем, если машина сама может? ;-) в смысле, строки оставить, просто добавить строковые константы в модуль для удобства.


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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Иван Денисов писал(а):
Я бы ещё предпочёл импортировать Librarian, в StdLoader, чтобы там убрать дублирование кода.

А я бы нет. И дальше буду настаивать на неизменности StdLoader. Объясню почему.

0) Files является достаточно завершённой абстракцией в ББ. Там может чего-то не хватать, но выработана она ещё на опыте ETHOS. Так как все привыкли к традиционным ФС и путям, то локаторы воспринимаются обычно, как указатель на каталог. А это вообще говоря не так.

1) Повторим, библиотекарь, в исходной позиции, это средство для унификации обращения к подсистемам. Он понадобился потому, что подсистемы, хотим мы того или нет, являются неявной частью абстракции файловой системы BlackBox. Так как за счёт этого поддерживается текущая компонентная модель. А хочется сделать эту абстракцию явной.

2) Files почему-то воспринимается как средство обращения к файлам нижележащей ОС. Но это не так. Files - это средство обращения к файлам в рамках файловой системы BlackBox. Происхождение от операционных систем даёт о себе знать. За счёт локаторов, кстати, она может быть не только иерархической, но иметь и более сложную структуру. Если надо системно кувыркаться с файлами ФС Linux/Windows, то для этого нужно делать другое средство.

3) Итого, в модель компонентов попадают Files, StdLoader, SplitName (где бы он не находился), та часть компилятора, которая читает и пишет файлы (Антон на неё указывал).

4) Если пытаться наставить тут расширений на будущее, то это проектно неправильное решение. Нужен опыт? Мы пробовали. По результатам могу сказать, что если менять компонентную модель, то её надо менять целиком: Files, StdLoader, SplitName (где бы он не находился), I/O часть компилятора. Files (в старом виде) при этом может сохраниться для всего остального, просто он выпадает из загрузочного образа и в него встраивается другая реализация, которая соотносится с новой компонентной моделью (если это требуется).

Выводы:

* SplitName я уже пытался отправить в Files, но народ не согласился, в виду того, что это типа не по смыслу. Библиотекарь мог бы тоже стать частью модуля Files, но если он нужен в виде отдельного модуля, то может быть и так. Тогда и со SplitName, да.

* Делать в Библиотекаре точку расширения для изменения принципов компонентной модели неверно. Какими бы благими пожеланиями для разработчиков оно не сопровождалось. Соглашусь с Антоном, что если хочется мочь всё перестраивать, то надо I/O компилятора сделать заменяемой частью.

* Смена компонентной модели в текущем виде требует замены указанных выше частей. Но если хочется, чтобы не требовало, то надо перепроектировать и ввести, начиная с уровня загрузки, соответствующую абстракцию. А это задача не такая тривиальная. Костылями к текущей модели не обойтись.


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

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


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

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

Не делать Int/ExtSpec, а сделать '=>Sym', '<=Sym' - это упрятывание, а не решение. Но работать оно, конечно, будет. Мне не нравится упрятывание совершенно. Это не в духе ББ/КП, как я его понимаю.

Иван: Я сформулировал возражения вида "Существуют задачи, в которых направление приведет к проблемам". Вы построили эксперимент вида "Существует задача, в которой направление не привело к проблемам". Осталось перебрать N-1 эксперимент, чтобы "отмести" мои возражения.

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

Я предложил решение в духе ББ, с использованием абстрактного интерфейса для узла ввода-вывода в компиляторе. Это решение позволит вам решить все обозначенные вами задачи - компиляция ascii текстов, компиляция в песочницу, компиляция отдельных проектов. При этом можно оставить библиотекарь простым и без направлений, как изначально согласовывалось. Какие есть по существу возражения?

Еще такое соображение. В идеологии ББ - не компилировать в песочницу; компилятор и средства разработки живут "внутри" прикладной программы, покамест их не удалят при deployment'е. Компиляция в песочницу (мне) понадобилась только для разработки самого ББ.
Поэтому те средства, которые нужны для "компиляции в песочницу", можно и вовсе не включать в ББ, а иметь в виде дополнения. У меня сейчас это Cross. Я не претендую на втягивание их в ББ. Достаточно ввести крюк в компилятор, на который можно навесить нужное расширение. Которое будет расширять функциональность в заданных проектировщиком крюка границах, а не безгранично за счет упрятываний параметров в литерные массивы.


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

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

я, например, не разделяю идеи о том, что части системы должны быть независимы до состояния «легко от системы отрываются»: система — она на то и система, чтобы одни части пользовались другими. я, например, вижу хуки скорее как то, что ломает стройность системы: они — в идеале — должны быть реализованы как (возможно, отдельный) модуль с абстрактным интерфейсом и фабрикой (буде она нужна), и модуль host/std реализации. ну, по типу того же Files. собственно, основная часть BBCB так и построена. тот же мой SubsManager — это попытка сделать такой универсальный интерфейс для управления подсистемами, которым могут пользоваться все остальные.

с другой стороны — Антон Александрович предлагает специализированый интерфейс ввода/вывода для компилятора, который позволит компилятор более-менее свободно «оторвать» от остальной системы (та самая «герметичность», если я верно понимаю). в случае taken to the extreme такой подход позволяет действительно разобрать систему на очень маленькие составные части и собрать из них что-то другое — но по сути является дополнительной прослойкой между уже существующим в BBCB интерфейсом (file i/o и log в данном случае) и некоей подсистемой.

здесь можно включить демагогию и сказать, что омики ведь делали кросс-версии BBCB, но вводить такую прослойку для компилятора не захотели по какой-то причине. конечно, как и любая демагогия — с небольшой адаптацией она может быть использована для атаки (или поддержки) любого подхода. а на деле разные подходы просто служат разным целям, потому что у каждого есть некое своё видение того, как должен быть устроен «идеальный BBCB». эти видения имеют много общего, но и достаточно разного (трюизм, люблю их).


из этой моей стены текста можно извлечь одну полезную мысль: вам не кажется, что mainline-версия BBCB нуждается в некотором общем, компромиссном, но чётко зафиксированом vision document? потому что даже понятие «консервативности» не у всех совпадает ведь. если там более-менее подробно описать, что и как должно быть в mainline, а что точно нет, и как именно расширять то, что есть (а как не надо) — это позволит потом решать большинство споров автоматически. заодно послужит планом работ, и даже даст некоторую возможность оценивать, насколько работы близки к завершению.

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


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Очень разные мнения, поэтому пусть ещё эти мнения поварятся. Очевидно, что к согласию мы не придём. Я оставлю последний предложенный Борисом вариант, как ни к чему не склоняющий стороннего пользователя. Везде, где в Блэкбоксе явно определено направление, я поставлю соответствующий токен, чтобы мои системы для кросс-компиляции работали без изменений компилятора. Изменять интерфейсы компилятора в версии 2.0 не планируется. Давайте изменения компилятора обсуждать в отдельно. У меня сейчас на это ресурса нет. Есть фокус доделать 2.0 для скорейшей публикации и работы, поэтому взялись утрясать вопрос с библиотекарем.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
из этой моей стены текста можно извлечь одну полезную мысль: вам не кажется, что mainline-версия BBCB нуждается в некотором общем, компромиссном, но чётко зафиксированом vision document? потому что даже понятие «консервативности» не у всех совпадает ведь. если там более-менее подробно описать, что и как должно быть в mainline, а что точно нет, и как именно расширять то, что есть (а как не надо) — это позволит потом решать большинство споров автоматически. заодно послужит планом работ, и даже даст некоторую возможность оценивать, насколько работы близки к завершению

У нас у всех очень разные возможности и ресурсы, разные задачи, проекты и перспективы. Мы согласовываем некоторые интерфейсы, это даётся с большим трудом и скрипом. У меня была одна цель - обновить внешний вид Блэкбокса, интегрировав его с проектом Тайлер, осовременить вид Блэкбокса, сделав так, чтобы приложения на нём выглядели более предсказуемо для пользователя. Уже внесено много нововведение. Ничего больше в нем менять не надо, так как теряется стабильность. По ходу проекта мы ещё преобразовали репозиторий, разделили ядро, потеряв ядра для OpenBSD и FreeBSD, это надо исправлять. Плиточный интерфейс тоже надо дорабатывать. Уже слишком много и так изменено, что приводит к нестабильности. Не надо больше нововведений. Все нововведения требуют доработки. Да я бы хотел, чтобы было больше разных бэкендов для компилятора, отвязка от Gtk2 и версия для Мака тоже, но это после 2.0.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Иван Денисов писал(а):
Везде, где в Блэкбоксе явно определено направление, я поставлю соответствующий токен

этого делать не пришлось, пример CheckSandBox и без специальных модификаций работает, так что обычные "Code", "Sym", "Mod" везде.
Направления предлагаю осмысливать кому интересно потом, и у меня какой-то опыт появится. Пока двинем дальше.


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

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


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

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


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

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