OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 54 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 18 Февраль, 2020 19:20 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Сейчас параметры каждым модулем читаются напрямую: HostFiles, HostFiles64, HostPackedFiles (Linux), HostMenus, у меня есть еще другие.

Идея в том, чтобы реализацию механизма доступа к параметром закрыть ББ-м интерфейсом, что упростит Host-модули и позволит при необходимости подменять механизм чтения параметров, внеся исправления в одном месте. Но этот модуль придется линковать в пускач.

Возможный интерфейс.
Код:
HostConf C S         Унифицированное получение параметров от Системы   

PROCEDURE GetPar* (IN key: ARRAY OF CHAR; OUT val: ARRAY OF CHAR; OUT res: INTEGER)

Читает параметр в
- комстроке -key val или --key=val;
- переменной окружения key.

Постусловие
res = 0   влезло в val
res = 1   в val обрезанное значение
res = 2   не найден
res = 3   ошибка


Механизмы чтения параметров могут варьироваться в зависимости от системы. Например, в винде "/key".

Пока реализовал и использую эту схему без HostMenus.

Для HostMenus необходимо решить вопрос повторения ключей, когда при повторении имени они агрегируются в массив. Это можно по-разному
Например космтрока
blackbox -o file1.odc -o file2.odc
Подается в отмеченном интерфейсе как параметры o[0]=file1.odc o[1]=file2.odc.

Можно интерфейс расширить индексом
PROCEDURE GetPar* (IN key: ARRAY OF CHAR; index: INTEGER; OUT val: ARRAY OF CHAR; OUT res: INTEGER)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Февраль, 2020 21:30 
Модератор
Аватара пользователя

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

В виде костыля эта схема уже работает. Из HostFiles GetName торчит, которое используется в виндовом HostRegistry для разбора комсторки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 22 Февраль, 2020 20:50 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Логичное место для такого "ББ-го интерфейса" - не в HostFiles; HostFiles вообще не объявляет интерфейсов, а реализует их.

А что если ввести модуль (System)Host, в который собрать Host-специфичные утилиты и интерфейсы? Он будет непереносимым, его интерфейс тоже непереносимым, и рассчитан на компоновку в исполняемый файл. Туда же можно переместить argc И argv из Kernel; а может быть и ConsHook из dev18/Kernel. Так можно очистить ядро от всего, что относится не к языку, а (только) к хост-системе, и в то же время предоставить общие механизмы и реализации для Host-модулей. И GetName, который "торчит" из HostFiles, туда же переместить.

Собсно это похоже на HostConf, который Евгений предлагает, только название и предназначение шире: собрать общие Host-механизмы и утилиты.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 23 Февраль, 2020 02:34 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Думаю, что механизмы Host должны быть в Host.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 23 Февраль, 2020 18:20 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Давайте сделаем модуль Env с интерфейсами и модуль HostEnv с реализацией.
Ну и что, что модули не большие... и не беда, что список для линкера вырастает

Код:
Dev2Linker1.LinkElfExe Linux blackbox := Kernel$+ Utf8 Env HostEnv Files HostFiles HostGnome StdLoader


для Windows
Код:
BlackBox.exe := Kernel$+ Utf8 Env HostEnv Files HostFiles StdLoader


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 23 Февраль, 2020 19:59 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 23 Февраль, 2020 23:10 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Я предлагал сделать только модуль HostEnv для упрощения в Host-части. Интерфейс HostEnv никого ни к чему не обязывает, потому что это Host. Его можно менять, он может быть даже разным для разных Host.
Вы предлагаете пойти дальше и обобщить до Env. Т.е. поднять все это дело сразу до прикладного уровня.

Что-то от этого уже есть в Dialog, поддерживать по-хорошему надо. Будет отчасти дублирование функциональности. Хотелось бы услышать, что остальные на этот счет думают.
Цитата:
VAR commandLinePars: String
Command line parameters that have been passed when starting BlackBox. Variable commandLinePars contains the string entered on the command line following the /PAR option. The string can be specified enclosed in either single or double quotes. Quotes may be omitted if no white space is contained in the string. If no /PAR option is present on the command line, commandLinePars contains the empty string.

Examples:
/PAR test
/PAR "parameter string"
/PAR 'A string containing a " can be entered like this'


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 23 Февраль, 2020 23:17 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 02:02 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Кмк, в ББ два уровня публичности интерфейсов: публичные, которые ОБЯЗАТЕЛЬНО поддерживать; и used internally. В ББ то, что used internally, не документировали; мне кажется, это несправедливо и тормозит развитие среды, поскольку этими интерфейсами пользуются системщики. Мне приходилось угадывать значение интерфейсов Windows, когда я в 2007 работал над AMisc. Полагаю, вполне можно документировать то, что used internally, однако напоминать везде, что used internally - subject to change without notice: типа, пользуйтесь, если надо, но еси чо тут все может поменяться в любой версии.

Так вот Env можно сделать used internally, поскольку он для системщиков.

А, как вы справедливо совершенно заметили, для прикладного уровня есть интерфейс в Dialog, который нужно поддерживать. Он кста реализован в (Win)HostMenus (а в Линукс - нет, увы, а неплохо бы), хотя к меню не имеет прямого отношения. Вот можно как раз навести порядок: убрать это из HostMenus и грамотно распределить между Dialog и Env/HostEnv.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 05:11 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Евгений Темиргалеев писал(а):
Например, как вариант, можно вполне себе поставить интерфес для прикладного чтения параметров в Dialog.
А HostFiles ничто не мешает напрямую в реализацию HostEnv обращаться.

Если прикладной уровень поставить в Dialog, то придется делать импорт HostEnv, а это запрещено.
Можно было бы сделать интерфейс для чтения параметров в ядре, но как обсуждали, не всегда в проектах используется ядро.
Так что вот приходим к необходимости модуля Env, и так как он уже используется в HostFiles активно, то он идет перед ним в списке линковки ядра.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 05:20 
Аватара пользователя

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

Вот тут есть интересное интервью Вирта, вспомнилось сейчас к теме.
https://www.youtube.com/watch?v=xCA5d87DtB0
https://www.youtube.com/watch?v=Cck53cQgFQg
https://www.youtube.com/watch?v=wrGytM2YTQY

И вот тут он говорит, что проблемы современных программистов в необходимости использовании многих существующих инструментов.
https://youtu.be/wrGytM2YTQY?t=410

Так то это и без Вирта понятно, но раз Вирт стоял у истоков Блэкбокса так или иначе, то приятно, что и он видит мир достаточно прозрачно, чтобы бы не говорили скептики и злопыхатели, паскалененавистники :)

Так что надо понемногу, не усложняя, упрощать взаимодействие с внешним миром в ББ тоже.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 16:47 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Иван Денисов писал(а):
Если прикладной уровень поставить в Dialog, то придется делать импорт HostEnv, а это запрещено.

Чтобы Dialog не импортировал Host в нем есть хуки. Но из этого не следует, что Host-модули должны работать через хук.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 16:56 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Иван Денисов писал(а):
Еще хочу сказать, что расширение возможностей общения ББ с внешним миром, — вполне продуманный шаг.
Надо не только читать параметры окружения, параметры командной строки. Но добавить в интерфейс возможность устанавливать некоторые параметры окружения.
Чтобы программы, которые запускаются через Dialog.RunExternal могли их использовать.


И что получится? Часть взаимодействия с внешним миром в Dialog, а часть в Env? Надо, на мой взгляд, как-то определятся -- либо в Dialog, либо отдельно.

Но это уже выходит за рамки предложенной мной темы. Почему бы не сделать поэтапно?

1) Сначала выделить работу с параметрами в нескольких вариантах Host. Это сейчас получается единообразно. И это уже можно сделать без заморочек о том, каков будет прикладной интерфейс.
2) Вопрос взаимодействия с внешним миром проработать отдельно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 17:45 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Да, согласен. Давайте пока сделаем HostEnv. Проверим как он применяться будет на уровне Host, а потом уже обсудим куда на прикладной уровень его вынести.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 18:43 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Не нужен никакой Env. Чтобы в каркас что-то вставлять, нужны веские основания, а не просто "а давайте вставим". Вот Host привести в приличный вид надо давно, да.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 19:45 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис, у тебя не верное впечатление. Проблема чтения параметров уже существует больше пяти лет, да вообще с момента работы на Linux версией. Мы её периодически с Александром обсуждали. Но не могли ничего сделать особо из-за заботы о ненарушении совместимости. Это очень серьезная проблема, которая мешает унифицировать Host часть каркаса.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 19:50 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
В Windows конфигурации ББ передаются как параметры командной строки. Также есть при этом и переменные окружения.
В Linux также есть аргументы командной строки. И также есть переменные окружения.

При этом для Linux/FreeBSD/OpenBSD приняли решение использовать именно переменные окружения как конфигуратор запуска.
А в Windows остается как было через параметры командной строки.

В общем это жесть, и надо как-то единообразно обращаться к переменным окружения и тем и другим через "единое окно".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 20:10 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Через командную строку.
У меня не может быть неверного представления, я всё время с приложениями работаю, которые под Linux и без всякого гуя (серверные). Так что тупо практика. Переменные окружения при запуске лично меня вымораживают.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 20:16 
Аватара пользователя

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

Когда-то тоже скептически относился к параметрам через переменные окружения, но потом понял, что так совершенно удобно через sh скрипт запускать приложения в Linux. С удивлением обнаружил, что многие программы именно так и запускаются. Даже как-то лучше стал понимать мир линукса.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 24 Февраль, 2020 21:07 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Тем не менее, через переменные окружения лучше не делать.
    1. При передаче через аргументы программа может проверить правильность имена ключей, через переменные окружения - нет
    2. С переменными окружения возможно неявное проникновение нежелательных параметров
    3. Возможно, что-то ещё

Вообще, мир GNU/Linux ужасен, хотя и во многих случаях это и лучшее, что есть по совокупности качеств.


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

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


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

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


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

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