OberonCore

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

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




Начать новую тему Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.  [ Сообщений: 28 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: #033: Предложение: дополнение Log
СообщениеДобавлено: Воскресенье, 03 Май, 2020 12:24 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Товарищи, в серверную сборку хочется перестать тащить StdLog (коллеги, не таскают, а у меня таскается).

Но этому мешает то, что часто в отладочной печати нужно выводить LONGINT и View-ы.

По View-ам есть предложение ввести процедуру Log.View(v: ANYPTR), которая работает только в случае подключенной реализации (при необходимости можно будет и в серверном режиме часть вьюшек обработать), а по-умолчанию ничего не делает.

Ну а по LONGINT давно назрело.
Думаю, что всё равно перекомпиляция необходима на новой версии - поэтому просто поменять у Int параметр на LONGINT, как это сделано в StdLog.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Воскресенье, 03 Май, 2020 13:09 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
У меня у универсального модуля заглушка реализована вот так:

Код:
   PROCEDURE View* (v: ANYPTR);
   BEGIN
      IF impl.View = NIL THEN
         String("<View>")
      ELSE
         impl.View(v)
      END
   END View;

   PROCEDURE ViewForm* (v: ANYPTR; w, h: INTEGER);
   BEGIN
      IF impl.ViewForm = NIL THEN
         String("<View>")
      ELSE
         impl.ViewForm(v, w, h)
      END
   END ViewForm;


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Воскресенье, 03 Май, 2020 13:16 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
А стандартная реализация устроена так, с перспективой на обработку не только Views.View, а расширяемого набора объектов:

Код:
MODULE L1Log_Std;
   IMPORT Views, StdLog,
      Log := L1Log;

   PROCEDURE View (v: ANYPTR);
   BEGIN
      WITH v: Views.View DO
         StdLog.View(v)
      ELSE
         Log.String(" <not Views.View> ")
      END
   END View;

   PROCEDURE ViewForm (v: ANYPTR; w, h: INTEGER);
   BEGIN
      WITH v: Views.View DO
         StdLog.ViewForm(v, w, h)
      ELSE
         Log.String(" <not Views.View> ")
      END
   END ViewForm;

BEGIN
   Log.impl.View := View;
   Log.impl.ViewForm := ViewForm
END L1Log_Std.



Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Воскресенье, 03 Май, 2020 13:47 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
LONGINT, видимо, был просто забыт.

Про вьюшки лично я Вам доверяю ))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Воскресенье, 03 Май, 2020 14:16 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Views уже сделаны. Про LONGINT согласен, что можно заменить. Могут быть какие-то побочные эффекты, кроме нарушения бинарной совместимости?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Воскресенье, 03 Май, 2020 19:09 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Я у себя, в принципе, и SetDefaultRuler, Open и Clear из StdLog воспроизвёл.
Совершенно естественно представить код какой-нибудь прикладной, который и линейку устанавливает в гуёвом режиме, и на сервере запускается тоже в кластере каком-нибудь.
Унифицировать.

А что, может, замахнёмся на Уильяма нашего... и StringLn добавим - как сокращение громоздкости для 50% случаев вызова String? ))
Не знаю, как кто, а я постоянно дописываю забытый Log.Ln, запустив что-нибудь первый раз и увидев слепленный вывод.

======
Щас криминал скажу... Добавить Str как псевдоним. Ну и StrLn (а не StringLn). Ну мусор это явный, визуальный и печатный, для постоянно используемых процедур вывода. Использование удачных, однозначных сокращений в Оберон-традиции сплошь и рядом (вместо километровых строк Ada или Java).
Т.е., например, между StringToInt и StrToInt выбор ну просто ну точно в пользу последнего.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Понедельник, 04 Май, 2020 01:43 
Администратор

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

Вот этого уже не надо.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Понедельник, 04 Май, 2020 01:46 
Администратор

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Понедельник, 04 Май, 2020 15:20 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Борис Рюмшин писал(а):
С моей точки зрения, LONGINT поставить надо давно. Мне не понятно, зачем нужно View для логирования. В особенности непонятно, зачем это нужно на сервере. Журнал это служебное средство всё-таки, а не консоль для вывода красивостей.


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

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

Единство окружения, напиши один раз - запускай всюду и т.п. :)

Мы же и так получаем сплошной профит, когда код запускается без изменений кроссплатформенно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Понедельник, 04 Май, 2020 15:24 
Модератор
Аватара пользователя

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

Вот этого уже не надо.


Ну, может быть, я один заколебался добавлять (и убирать, как при отладочных печатях) этот мусор Log.String.... ; Log.Ln;
:)

Оберон против криптосинтаксиса и за ясный развёрнутый текст. Но не против элегантной краткости. У нас и встроенные функции в основном трёхбуквенные (если находится элегантное сокращение, LEN и др.), и не Module сплошь и рядом в именах сокращено до Mod.
И, в конце концов, не Log.Integer, а Log.Int!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Понедельник, 04 Май, 2020 17:03 

Зарегистрирован: Среда, 04 Июль, 2007 16:43
Сообщения: 247
Илья Ермаков писал(а):

Оберон против криптосинтаксиса и за ясный развёрнутый текст.


Вот! Даже Мокси к такому же выводу, наконец, пришел:

Many trends in modern programming language design
seem to focus on developers pressing fewer keys on the
keyboard. To me, that's a strange priority.

For large systems where the industry spends most of its
time, I think "readability" is much more important than
"writability."


и т.д. ;-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Понедельник, 04 Май, 2020 17:27 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
LONGINT Поддерживаю.
Про Log.Str - мне нейтрально, String меня вполне удовлетворяет.
Про Log.StrLn - есть же Log.Msg, он, кажется, добавляет Ln в конце.
Наличие такой процедуры будет провоцировать Log.StrLn(a$ + b$ + c$). Но я как-то раз увидел, что $ и + производят невидимые переменные в стеке активации, и не могу развидеть; с тех пор избегаю конкатенации (в выводе). Хотя все равно больше 5МБ ББ не использует.

Соображения про Log.View(x: ANYPTR).
1) мне больше нравится (v: Views.View), но я понимаю, что это тянет ряд зависимостей, которые, вероятно, не подключаются в серверной реализации. Насколько это критично для ваших серверных сборок?
Список зависимостей (в интерфейсах) получается примерно такой:
Kernel Files Dialog Fonts Ports Stores Models Views Coverters Services

2) Д.В.Дагаев как раз чтобы не импортировать Views ввел собственный журнал

3) в текстовом интерфейсе зрители (views) используются не только для "красивостей", но как универсальные контейнеры каких-нибудь данных или как разделители (Е.Темиргалеев предлагал недавно зритель-разделитель для коммандеров). Поэтому в журнал они вставляться тоже могут не для красивости, а для контейнирования - и уже дело реализации что-то с ними сделать или не сделать.
4) единство окружения - оч весомый аргумент!!

А может, сделать два разных модуля: в одном - без процедуры View, а в другом - с ней? И подключать в импорте IMPORT Log или Log := Log2 ? Это тоже даст определенный уровень независимости и единства окружения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Понедельник, 04 Май, 2020 19:12 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Да если менять исходник и перекомпилировать, то уже не независимость от окружения...

А какую проблему вы видите с ANYPTR вместо View? Что что-то не то туда отправите? ) Ну так что-то не то оно пусть игнорирует.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Вторник, 05 Май, 2020 04:13 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Сейчас так сделано:

Код:
PROCEDURE View (v: ANYPTR);
PROCEDURE ViewForm (v: ANYPTR; w, h: INTEGER);


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Среда, 06 Май, 2020 20:17 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
Илья Ермаков писал(а):
А какую проблему вы видите с ANYPTR вместо View?

Логично, чтобы процедура называласть не View, а Any.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Среда, 06 Май, 2020 21:32 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Trurl писал(а):
Илья Ермаков писал(а):
А какую проблему вы видите с ANYPTR вместо View?

Логично, чтобы процедура называласть не View, а Any.

В точку!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Среда, 06 Май, 2020 22:38 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Не, Any можно заводить с другой сигнатурой: IN par: ANYREC.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #033: Предложение: дополнение Log
СообщениеДобавлено: Пятница, 08 Май, 2020 07:14 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Заменил INTEGER на LONGINT в аргументах Int и IntForm. Обновил в репозитории dev18.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Пятница, 08 Май, 2020 18:29 
Администратор

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

Вот этого уже не надо.


Ну, может быть, я один заколебался добавлять (и убирать, как при отладочных печатях) этот мусор Log.String.... ; Log.Ln;
:)

Мы уже раз вводили, потом все замахались путаться и вывели обратно. И ты с этим согласился. Поэтому не надо по второму кругу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: дополнение Log
СообщениеДобавлено: Пятница, 08 Май, 2020 18:31 
Администратор

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

Лог это, вообще говоря, очень служебная вещь, которая должна оставаться простой.
Если тебе нужна сложная отладка -- пиши отдельный модуль с ней и выводи в отдельное окно, отдельный документ, файл. Это проблема разве?


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

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


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

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


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

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