OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 24 Июнь, 2021 02:13

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




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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 486
Евгений Темиргалеев писал(а):
Надо по-особому отлаживать? -- слинковали спец. пускач с особой версией.


Это не подходит вот в каком сценарии:
Василий поставил ББ, потом апгрейдил какие-то пакеты Убунту, у него ББ перестал загружаться или стал падать. Он меня спрашивает: что делать? А я ему: слинкуй спец. пускач с особой версией.

Нет, лучше вот так: я ему: Василий, открой терминал, там набери bbcb и пришли мне, что он напишет тебе.

А в светлом будущем еще лучше: я ему: Василий, сейчас посмотрю! Подключаюсь к его машине и получаю его лог к себе.

А когда подтянется Яос: Денис ему: Василий, давай уже завязывай с убунту, запускай Черный Квадрат из Яос!

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


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4619
Откуда: Россия, Орёл
adimetrius писал(а):
Но это можно поправить так:
Код:
MODULE Kernel;
  VAR String-: PROCEDURE (IN str: ARRAY OF CHAR);
  PROCEDURE SetString* (p: PROCEDURE (IN str: ARRAY OF CHAR));
END Kernel.
Так с самого начала так и было. :)

adimetrius писал(а):
Я бы сказал, обобщить не для разных Host-систем, а для разных модулей в Host в одной системе.
Тогда всякие ABSTRACTы и хуки не нужны вообще.
adimetrius писал(а):
В этом смысле интерфейс на процедурных переменных для аварийного вывода надежнее, чем на производных типах....
Тем более не нужны. Живой пример.

Вот, чем не обобщение для линукса? Назвать еще Int, String, Real и вообще красота :)
Код:
MODULE Host1K18 ["libc.so.6"];

   IMPORT SYSTEM;

      TYPE
         PtrSTR* = POINTER TO ARRAY [untagged] OF SHORTCHAR;

      PROCEDURE [ccall] printf* ["printf"] (s: PtrSTR): INTEGER;
      PROCEDURE [ccall] printf_i* ["printf"] (s: PtrSTR; x: INTEGER): INTEGER;
      PROCEDURE [ccall] printf_i_i* ["printf"] (s: PtrSTR; x1, x2: INTEGER): INTEGER;
      PROCEDURE [ccall] printf_s* ["printf"] (s: PtrSTR; x: PtrSTR): INTEGER;
      PROCEDURE [ccall] printf_g* ["printf"] (s: PtrSTR; x: REAL): INTEGER;
      PROCEDURE [ccall] printf_is* ["printf"] (s: PtrSTR; x1: INTEGER; x2: PtrSTR): INTEGER;
      PROCEDURE [ccall] printf_l* ["printf"] (s: PtrSTR; x: LONGINT): INTEGER;

END Host1K18.


adimetrius писал(а):
Это не подходит вот в каком сценарии:
Василий поставил ББ, потом апгрейдил какие-то пакеты Убунту, у него ББ перестал загружаться или стал падать. Он меня спрашивает: что делать? А я ему: слинкуй спец. пускач с особой версией.

Нет, лучше вот так: я ему: Василий, открой терминал, там набери bbcb и пришли мне, что он напишет тебе.
В данном случае я говорил про отладочный вывод, но не на консоль.
А для того, чтобы Василий мог прислать вывод из консоли при использовании штатной сборки, в штатной сборке просто должен быть вывод в консоль. Против которого здесь никто не выступает. По крайней мере я не видел. Другое дело, что складывается впечатление, как будто вы упорно отстаивате позицию, что вывод без ABSTRACT и без Hook не возможен. Но это же не так. :)


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3111
Это делается не просто для того, чтобы вывод сделать. Через Libc или WinApi идет вывод, конечно из каждого модуля. Но это плохо. Когда Adimetrius выступил с этим предложением, то во первых я увидел решение для злободневной темы замены реализации через printf в единой точке, во втоторых - единая точка STDERR потока организуется, а в третьих мы получаем возможность писать этот STDERR в прикладных программах куда угодно без перекомпиляции ядра, в том числе в файл. Сплошные плюсы. Минус только в том, что вам надо пропатчить несколько ядер. Я с уважением отношусь к вашему негодованию. Но честно, это ведь не аргумент. Да, переход на новую версию всегда связан с некоторыми изменениями. А тут ещё и версия 1.8. Это мы еще не начали применять герметизацию по мотивам работы Лунь. И даже не начали применять изменения в Windows для развертывания системы Tyler. Так что тут надо понимать, что это не косметические правки, а серьезная работа с заделом на будущее, чтобы жить было всем потом легче. Блэкбокс спроектирован местами так, "чтобы запутать русских". Так что придется кое что и распутывать.


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

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


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3111
Вот так получается через процедурные переменные, если еще экспортировать Int, Msg, Hex, Adr...
Код:
VAR
      errString: PROCEDURE (IN str: ARRAY OF CHAR);
      errLn: PROCEDURE;


   PROCEDURE ErrString* (IN str: ARRAY OF CHAR);
   BEGIN IF errString # NIL THEN errString(str) END;
   END ErrString;
   
   PROCEDURE ErrLn*;
   BEGIN IF errLn # NIL THEN errLn END;
   END ErrLn;

   PROCEDURE Msg* (IN msg: ARRAY OF CHAR);
   BEGIN ErrString(msg); ErrLn
   END Msg;

   PROCEDURE IntToString (x: LONGINT; OUT a: ARRAY OF CHAR);
      CONST max = 25;
      VAR b: ARRAY max OF CHAR; i, j: INTEGER; y: LONGINT;
   BEGIN IF x < 0 THEN x := -x; a[0] := '-'; j := 1 ELSIF x > 0 THEN j := 0 ELSE j := 1; a[0] := '0' END;
      i := 0; WHILE x # 0 DO y := x MOD 10; b[i] := SHORT(CHR(y + ORD('0'))); x := x DIV 10; INC(i) END;
      DEC(i); WHILE (i >= 0) & (j < max) DO a[j] := b[i]; INC(j); DEC(i) END;
      ASSERT(j < max, 20);
      a[j] := 0X;
   END IntToString;
   
   PROCEDURE Int* (x: INTEGER);
      VAR buf: ARRAY 16 OF CHAR;
   BEGIN
      IntToString(x, buf); ErrString(buf)
   END Int;

   PROCEDURE Hex* (x: INTEGER; OUT buf: ARRAY OF CHAR);
      CONST n = 8;
      VAR i, y: INTEGER;
   BEGIN
      IF n <= LEN(buf) - 1 THEN
         i := n - 1;
         WHILE i >= 0 DO
            y := x MOD 16; x := x DIV 16;
            IF y > 9 THEN y := y + (ORD("A") - ORD("0") - 10) END;
            buf[i] := CHR(y + ORD("0")); DEC(i)
         END;
         buf[n] := 0X
      ELSE buf[0] := 0X
      END
   END Hex;
   
   PROCEDURE Adr* (x: INTEGER);
      VAR b: ARRAY 10 OF CHAR;
   BEGIN Hex(x, b); ErrString(b)
   END Adr;
   
   PROCEDURE DefErrLn;
      VAR ss: ARRAY 2 OF SHORTCHAR; res: INTEGER;
   BEGIN ss[0] := 0AX; ss[1] := 0X; res := Libc.printf(ss)
   END DefErrLn;
   
   PROCEDURE DefErrString (IN str: ARRAY OF CHAR);
      CONST max = 1024;
      VAR ss: ARRAY max + 2 OF SHORTCHAR; i, j, res, len: INTEGER;
   BEGIN len := LEN(str); ss[max + 1] := 0X;
      i := 0; j := 0; WHILE (i < len) & (str[i] # 0X) DO ss[j] := SHORT(str[i]); INC(i);
         IF j = max THEN res := Libc.printf(ss); j := 0 ELSE INC(j) END
      END;
      IF j > 0 THEN ss[j] := 0X; res := Libc.printf(ss) END
   END DefErrString;
   
   PROCEDURE SetErrString* (p: PROCEDURE(IN str: ARRAY OF CHAR));
   BEGIN
      IF p # NIL THEN errString := p END
   END SetErrString;
   
   PROCEDURE SetErrLn* (p: PROCEDURE);
   BEGIN
      IF p # NIL THEN errLn := p END
   END SetErrLn;

BEGIN
   (* set debug out *)
   errString := DefErrString;
   errLn := DefErrLn;


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 486
Евгений Темиргалеев писал(а):
... складывается впечатление, как будто вы упорно отстаивате позицию, что вывод без ABSTRACT и без Hook не возможен. Но это же не так. :)


Не, не отстаиваю ABSTRACT и Hook. Вполне можно и без них, с процедурными переменными, и я вполне доволен буду. Как я понимаю, у нас тут дискурс, и я позволяю себе высказывать свое отношение к разным вариантам решений. Любое, что мы тут обсудили - хоть на немного, но улучшает (и без того уже прекрасный) ББ. Но сердце мое мятётся жеж, пока котлы стоят асимметрично... шучу

Иван: я бы назвал String и Ln, а не ErrString и ErrLn. Но не настаиваю. ;-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 25 Февраль, 2020 23:44 

Зарегистрирован: Пятница, 13 Март, 2015 16:40
Сообщения: 492
Евгений Темиргалеев писал(а):
А начинали с чего? С того, чтобы printf отладочные собрать в одном месте.

А под капотом там K&R... ;-) Вот кто отцы-основатели реально, а то Вирт-Вирт-Вирт...

PS: а не, по дальнейшем прочтении мир не перевернулся.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3111
Заменил ConsHook на реализацию через процедурные переменные.
В Windows версию тоже добавил для тестирования. Хотя там пока нет текстовых трапов в консоль, однако протестировать возможности вывода в STD_ERROR уже возможно:

https://blackbox.oberon.org/unstable/de ... a1.014.zip

Чтобы поток STD_ERROR писался в файл, надо вот так запускать Блэкбокс
Код:
BlackBox.exe > errors.txt 2>&1


Вложение:
recordErrors.png
recordErrors.png [ 163.64 КБ | Просмотров: 1481 ]


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4619
Откуда: Россия, Орёл
Процедуры назначать можно пачкой. SetOutProcs (str: ...; ln: ...)

А вывод так в ядре и остался...


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3111
Евгений, как я понял из нашей сегодняшней переписки ты предлагаешь еще один модуль линковать в пускач. Вот там уже Utf8 и HostEnv, а теперь будет ещё и Debug прилинкован на постоянной основе. Как выше писал Антон, временные отладочные решения нас не интересуют. Ядро всегда должно иметь возможность сообщить о проблеме, чтобы была возможность выяснить именно на рабочей конфигурации. Всё это разрастание обязательных модулей пускача, как-то не очень радует. Не меньше чем пара дополнительных процедур в ядре. Однако родилась интересная идея. Я тогда предлагаю оформить модуль под названием HostKernel и в него поместить экспортированные низкоуровневые процедуры для отладки, которые можно будет вызывать из HostFiles, HostPackedFiles и также там будет устанавливаться дефолтная реализация для вывода и в самом Kernel.
Почему это интересно. Потому, что будет правильно пойти путём обособления платформенно-зависимых частей ядра в отдельном модуле, чтобы Kernel превратился в настоящий интерфейсный модуль, соответствующий подсистеме System. Как смотрите на такое предложение?


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4619
Откуда: Россия, Орёл
Добавить Debug (название роли не играет) в пускач и не трогать интерфейс Kernel -- это плохо.
Добавить вместо Debug HostKernel с последствиями для интерфейса Kernel -- это хорошо.

Я считаю, что в специальных сборках можно пробовать по разному.
А если говорить об общеупотребимой сборке, то, я считаю, лучше искать решения без того, чтобы трогать устоявшиеся интерфейсы. Files в 1.7 уже улучшили. Kernel тоже.

Я за то, чтобы упорядочить код в Host части. Я за то, чтобы отладочный вывод был и чтобы он по возможности был более подробным.
Для реализации этого шага можно собрать процедуры отладочного вывода в один Host-модуль и либо использовать его, либо копировать нужные процедуры оттуда, чтобы во всех модулях в коде были одинаковые вызовы, например Msg, Int, Adr, Hex и т.п. Это будет упорядочивание.

Расширение интерфейса Kernel процедурами отладочного вывода или его разделение на две части выглядит как внесение хаоса на более высоком уровне ради упорядочивания на более низком уровне. Вот как я смотрю на это решение.


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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4536
Откуда: Россия, Орёл
adimetrius писал(а):
Нарушение безопасности такое:

Целенаправленно завалить систему можно разными способами.

Говорил уже много раз и повторю: Kernel - это вам не сервисный модуль, это рантайм языка. "Человеческое лицо" ядра это Meta и Services. Импортировать Kernel без дела (как и SYSTEM) никуда не нужно. Полагаться на его интерфейс также не нужно. И, более того, считаю, что поставить отдельной задачей надо снижение его импорта по ББ там, где он нафиг не нужен.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9419
Откуда: Россия, Орёл
Борис Рюмшин писал(а):
Целенаправленно завалить систему можно разными способами.


Подддерживаю. Концепция защиты компонентов, находящихся в одном адресном пространстве, от недобросовестного поведения - плохая. Если это возлагать на язык, это ведёт к такому разрастанию средств защиты... И к необходимости сложнейшим образом формально верифицировать, кто и чего может. Исключения - аппаратная поддержка аля Эльбрус - и то, по максимуму желательно разные уровни привилегий разносить на изолированные пространства памяти/объектов.

Борис Рюмшин писал(а):
Говорил уже много раз и повторю: Kernel - это вам не сервисный модуль, это рантайм языка. "Человеческое лицо" ядра это Meta и Services. Импортировать Kernel без дела (как и SYSTEM) никуда не нужно. Полагаться на его интерфейс также не нужно. И, более того, считаю, что поставить отдельной задачей надо снижение его импорта по ББ там, где он нафиг не нужен.


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

У языков типа LISP, Smalltalk, Forth есть чёткая опора на то, как оно представлено в рантайме - и простые механизмы манипуляции в рантайме.

Для Оберона это такое же конкурентное преимущество.

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


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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4536
Откуда: Россия, Орёл
Илья Ермаков писал(а):
Концепция защиты компонентов, находящихся в одном адресном пространстве, от недобросовестного поведения - плохая.

Концепция нормальная. Только для этого нужен ряд категорических условий, как то: трансляция в промежуточное представление, никаких SYSTEM, Kernel и прочего подобного, изолированная ОС, которая всё это обеспечивает, и так далее. И всё будет работать. В ББ не будет. Ну и понимание, о какой конкретно защите (тут есть варианты) мы говорим.
Илья Ермаков писал(а):
...
С другой стороны...

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


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9419
Откуда: Россия, Орёл
Борис Рюмшин писал(а):
Концепция нормальная. Только для этого нужен ряд категорических условий, как то: трансляция в промежуточное представление, никаких SYSTEM, Kernel и прочего подобного, изолированная ОС, которая всё это обеспечивает, и так далее. И всё будет работать. В ББ не будет. Ну и понимание, о какой конкретно защите (тут есть варианты) мы говорим.


Да, но это уже должны быть интерфейсы/регуляция доступа крупно-компонентного уровня. Как раз при введении тех "компонентов в крупном смысле", вокруг которых все крутятся.

На уровне языка "модуль/процедура/тип" пытаться регулировать уровни доступа и защиты - нецелесообразно. Это будет ещё один Rust, только в котором 90% средств направлено на 10% проблем уже не управления памятью, а управления доступом.

Цитата:
Во-первых, без фанатизма надо.
Во-вторых, для этого всего тебе Kernel не нужен напрямую. Введи специальную интерфейсную обвязку, которая буде безопасной и используй. И тоже, без фанатизма (ну ты понял о чём я, да?).


Это да.

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


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

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

Ага. Ты сейчас с 32 на 64 (на ARM, ещё куда) перейдёшь... и "как она бинарно организована и во время выполнения" расползётся к хаосу. Один хрен все твои спецсредства корректировать придётся.


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

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

На уровне языка "модуль/процедура/тип" пытаться...

А я и сказал, что понимания слова "защита" могут быть разными.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9419
Откуда: Россия, Орёл
Борис Рюмшин писал(а):
Ага. Ты сейчас с 32 на 64 (на ARM, ещё куда) перейдёшь... и "как она бинарно организована и во время выполнения" расползётся к хаосу. Один хрен все твои спецсредства корректировать придётся.


Расползётся разрядно, но не структурно-бинарно, скажем так.


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 486
Коллеги, я пытался тут осмыслить все эти многорусскихбукаф, и вот условно выходит, что одна партия против экспорта из ядра (Не надо расширять интерфейс ядра!), а другая партия против импорта в ядро (Не надо лишнего в пускач и ядро!)

Утрирую.

Евгений, вы в чате предложили ввести Kernel.SetErr(двеПроцедурыВывода). Вас такое решение устроит в плане сохранности интерфейса ядра?

Иван, а вас в плане
1) дефолтный вывод в ядре все равно останется, хотя это будет printf
2) импорта в ядро не будет, а дефолтный вывод будет, поэтому в пускач можно не добавлять модулей
3) расширяемость есть, можно подключить другую реализацию (на ходу) и посылать отладочный вывод куда нужно

Евгений в чате упомянул, что это похоже на еще одну реализацию интерфейса Log.Hook, и я согласен: можно сделать (или уже есть) полноценную консольную реализацию, и две процедуры для склейки (чтобы ядро могло вызывать типосвязанные процедуры). Такое решение глубоко удовлетворит меня, поскольку будет единообразие на замену зоопарку логов. (Хотя Дмитрию Викторовичу все равно придется вести свою линию, поскольку у него нет Views в интерфейсах)


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

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 486
Илья Ермаков писал(а):
на уровне системных соглашений принять за некий инвариант существующую модель (как она бинарно организована и во время выполнения "живёт")...
Не считать её тупо внутренней кухней "аа, поменяем как хотим".


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

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

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


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

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


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

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


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

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