OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 53 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
СообщениеДобавлено: Суббота, 29 Февраль, 2020 08:29 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
adimetrius писал(а):
При этом SYSTEM.PTR участвует в сборке мусора, а untagged POINTER - нет.

Как локальные переменные они участвуют в сборке мусора абсолютно одинаково. Впрочем, как и INTEGER и даже REAL.


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
adimetrius писал(а):
Евгений, вы в чате предложили ввести Kernel.SetErr(двеПроцедурыВывода). Вас такое решение устроит в плане сохранности интерфейса ядра?

Да, меня оно устроит. Потому что если говорить о сохранности интерфейса, учитывая контекст, то надо различать два случая.

1) В интерфейсе модуля Kernel могут появиться процедуры, которые настраивают работу самого ядра. Варианты ядер могут быть разные, и это нормально. Это никак не затрагивает другие модули, которые используют существующий интерфейс Kernel.
2) В интерфейсе модуля Kernel могут появиться новые "прикладные" процедуры, которые непосредственно предназначены для использования другими модулями. И ряд модулей предлагается посадить на этот расширенный прикладной интерфейс.


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

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

Как я понял, есть опасения, что их начнут использовать для других модулей.
Но ведь можно оговорить это в документации "используйте Console.WriteErrStr".

В самом Console предлагаю переделать, чтобы был вывод раздельный в два канала.
Код:
STDOUT_FILENO* = 1;
STDERR_FILENO* = 2;


Эти два канала есть и в Windows, как я убедился уже.

Вот сейчас такой интерфейс.
Код:
   PROCEDURE (c: Console) WriteStr- (IN s: ARRAY OF CHAR), NEW, ABSTRACT;
   PROCEDURE (c: Console) WriteChar- (ch: CHAR), NEW, ABSTRACT;
   PROCEDURE (c: Console) WriteLn-, NEW, ABSTRACT;


Для общепринятого журналирования ошибок надо добавить процедуры, которые будут писать в канал STDERR
Код:
   PROCEDURE (c: Console) WriteErrStr- (IN s: ARRAY OF CHAR), NEW, ABSTRACT;
   PROCEDURE (c: Console) WriteErrChar- (ch: CHAR), NEW, ABSTRACT;
   PROCEDURE (c: Console) WriteErrLn-, NEW, ABSTRACT;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Март, 2020 13:46 
Администратор

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

И для системных целей в этом нет совершенно ничего плохого.


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Иван Денисов писал(а):
Для общепринятого журналирования ошибок надо добавить процедуры, которые будут писать в канал STDERR

А может лучше добавить еще одну консоль?

VAR
out-, err-: Console;


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

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

Код:
   PROCEDURE WriteStr* (IN text: ARRAY OF CHAR);
   BEGIN
      cons.WriteStr(text)
   END WriteStr;

   PROCEDURE WriteChar* (c: CHAR);
   BEGIN
      cons.WriteChar(c)
   END WriteChar;

   PROCEDURE WriteLn*;
   BEGIN
      cons.WriteLn
   END WriteLn;


Будет тогда так
Код:
   PROCEDURE WriteErrStr* (IN text: ARRAY OF CHAR);
   BEGIN
      cons.WriteErrStr(text)
   END WriteErrStr;

   PROCEDURE WriteErrChar* (c: CHAR);
   BEGIN
      cons.WriteErrChar(c)
   END WriteErrChar;

   PROCEDURE WriteErrLn*;
   BEGIN
      cons.WriteErrLn
   END WriteErrLn;


Или так
Код:
   PROCEDURE WriteErrStr* (IN text: ARRAY OF CHAR);
   BEGIN
      err.WriteStr(text)
   END WriteErrStr;

   PROCEDURE WriteErrChar* (c: CHAR);
   BEGIN
      err.WriteChar(c)
   END WriteErrChar;

   PROCEDURE WriteErrLn*;
   BEGIN
      err.WriteLn
   END WriteErrLn;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Март, 2020 09:05 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
Зачем все эти сложности, когда можно напрямую обращаться, типа Log.out.WriteChar( c ); Log.err.WriteChar( c );


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Sergej Durmanov писал(а):
Зачем все эти сложности, когда можно напрямую обращаться, типа Log.out.WriteChar( c ); Log.err.WriteChar( c );


Лучше стараться уходить от ООП в интерфейсах. Скрывать его в реализации, как позорную веху истории :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Март, 2020 12:09 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
Как раз с ооп есть единая точка с возможностью смены реализации без всяких правок. необоснованный отказ от ооп и создает подобные проблемы.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
adimetrius писал(а):
Илья Ермаков писал(а):
на уровне системных соглашений принять за некий инвариант существующую модель (как она бинарно организована и во время выполнения "живёт")...
Не считать её тупо внутренней кухней "аа, поменяем как хотим".


Илья, а как вы себе это "принять" представляете? Вы вот сделали документацию к ядру, я постоянно в ней справляюсь - я принял, к сведению и на вооружение.

Вы осенью справедливо упомянули о "пробеле" в этой структуре: оссуствуют метасведения о типовых процедурах. Если "цементировать", то сначала бы восполнить его. Как полагаете?

Я, кмк, еще один пробел нашел: SYSTEM.PTR и POINTER [untagged] TO Something в метасведениях про локальные переменные - неотличимы. При этом SYSTEM.PTR участвует в сборке мусора, а untagged POINTER - нет. Впрочем, это уж совсем частности.


Принять не в смысле "цементировать". Как раз пробелы дополнять.

Но понимать, что это тоже есть целостная модель, а не просто "потроха".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Март, 2020 15:47 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Отладку для Host части (и только для неё), кстати, целесообразно разместить не в Kernel, или в дополнительном модуле линкуемом, а в HostFiles. Евгений об этом, кажется, говорил.


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

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


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Организация единства точки отладочного вывода теперь возможна установкой процедур вывода через SetErr в модулях Kernel, HostFiles, HostPackedFiles. По умолчанию в этих модулях скопированы внутри платформы (Windows/Linux) реализации для вывода в консоль.


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

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


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

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


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

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