OberonCore https://forum.oberoncore.ru/ |
|
#033: Предложение: дополнение Log https://forum.oberoncore.ru/viewtopic.php?f=134&t=6608 |
Страница 1 из 2 |
Автор: | Илья Ермаков [ Воскресенье, 03 Май, 2020 12:24 ] |
Заголовок сообщения: | #033: Предложение: дополнение Log |
Товарищи, в серверную сборку хочется перестать тащить StdLog (коллеги, не таскают, а у меня таскается). Но этому мешает то, что часто в отладочной печати нужно выводить LONGINT и View-ы. По View-ам есть предложение ввести процедуру Log.View(v: ANYPTR), которая работает только в случае подключенной реализации (при необходимости можно будет и в серверном режиме часть вьюшек обработать), а по-умолчанию ничего не делает. Ну а по LONGINT давно назрело. Думаю, что всё равно перекомпиляция необходима на новой версии - поэтому просто поменять у Int параметр на LONGINT, как это сделано в StdLog. |
Автор: | Илья Ермаков [ Воскресенье, 03 Май, 2020 13:09 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
У меня у универсального модуля заглушка реализована вот так: Код: 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; |
Автор: | Илья Ермаков [ Воскресенье, 03 Май, 2020 13:16 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
А стандартная реализация устроена так, с перспективой на обработку не только 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. |
Автор: | Info21 [ Воскресенье, 03 Май, 2020 13:47 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
LONGINT, видимо, был просто забыт. Про вьюшки лично я Вам доверяю )) |
Автор: | Иван Денисов [ Воскресенье, 03 Май, 2020 14:16 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Views уже сделаны. Про LONGINT согласен, что можно заменить. Могут быть какие-то побочные эффекты, кроме нарушения бинарной совместимости? |
Автор: | Илья Ермаков [ Воскресенье, 03 Май, 2020 19:09 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Я у себя, в принципе, и SetDefaultRuler, Open и Clear из StdLog воспроизвёл. Совершенно естественно представить код какой-нибудь прикладной, который и линейку устанавливает в гуёвом режиме, и на сервере запускается тоже в кластере каком-нибудь. Унифицировать. А что, может, замахнёмся на Уильяма нашего... и StringLn добавим - как сокращение громоздкости для 50% случаев вызова String? )) Не знаю, как кто, а я постоянно дописываю забытый Log.Ln, запустив что-нибудь первый раз и увидев слепленный вывод. ====== Щас криминал скажу... Добавить Str как псевдоним. Ну и StrLn (а не StringLn). Ну мусор это явный, визуальный и печатный, для постоянно используемых процедур вывода. Использование удачных, однозначных сокращений в Оберон-традиции сплошь и рядом (вместо километровых строк Ada или Java). Т.е., например, между StringToInt и StrToInt выбор ну просто ну точно в пользу последнего. |
Автор: | Борис Рюмшин [ Понедельник, 04 Май, 2020 01:43 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Илья Ермаков писал(а): Щас криминал скажу... Добавить Str как псевдоним. Вот этого уже не надо. |
Автор: | Борис Рюмшин [ Понедельник, 04 Май, 2020 01:46 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
С моей точки зрения, LONGINT поставить надо давно. Мне не понятно, зачем нужно View для логирования. В особенности непонятно, зачем это нужно на сервере. Журнал это служебное средство всё-таки, а не консоль для вывода красивостей. |
Автор: | Илья Ермаков [ Понедельник, 04 Май, 2020 15:20 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Борис Рюмшин писал(а): С моей точки зрения, LONGINT поставить надо давно. Мне не понятно, зачем нужно View для логирования. В особенности непонятно, зачем это нужно на сервере. Журнал это служебное средство всё-таки, а не консоль для вывода красивостей. Речь о том, что может быть код, выводящий в лог расширенным образом (какая-то таблица результатов - вычислений, БД или что ещё). И используется он в основном в графическом ББ. Но нет никакой причины для невозможности без изменений вызвать его на сервере (при отладке, например) и получить вывод плоскотекстовый. Единство окружения, напиши один раз - запускай всюду и т.п. Мы же и так получаем сплошной профит, когда код запускается без изменений кроссплатформенно. |
Автор: | Илья Ермаков [ Понедельник, 04 Май, 2020 15:24 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Борис Рюмшин писал(а): Илья Ермаков писал(а): Щас криминал скажу... Добавить Str как псевдоним. Вот этого уже не надо. Ну, может быть, я один заколебался добавлять (и убирать, как при отладочных печатях) этот мусор Log.String.... ; Log.Ln; Оберон против криптосинтаксиса и за ясный развёрнутый текст. Но не против элегантной краткости. У нас и встроенные функции в основном трёхбуквенные (если находится элегантное сокращение, LEN и др.), и не Module сплошь и рядом в именах сокращено до Mod. И, в конце концов, не Log.Integer, а Log.Int! |
Автор: | QWERTYProgrammer [ Понедельник, 04 Май, 2020 17:03 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Илья Ермаков писал(а): Оберон против криптосинтаксиса и за ясный развёрнутый текст. Вот! Даже Мокси к такому же выводу, наконец, пришел: 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." и т.д. |
Автор: | adimetrius [ Понедельник, 04 Май, 2020 17:27 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
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 ? Это тоже даст определенный уровень независимости и единства окружения. |
Автор: | Илья Ермаков [ Понедельник, 04 Май, 2020 19:12 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Да если менять исходник и перекомпилировать, то уже не независимость от окружения... А какую проблему вы видите с ANYPTR вместо View? Что что-то не то туда отправите? ) Ну так что-то не то оно пусть игнорирует. |
Автор: | Иван Денисов [ Вторник, 05 Май, 2020 04:13 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Сейчас так сделано: Код: PROCEDURE View (v: ANYPTR);
PROCEDURE ViewForm (v: ANYPTR; w, h: INTEGER); |
Автор: | Trurl [ Среда, 06 Май, 2020 20:17 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Илья Ермаков писал(а): А какую проблему вы видите с ANYPTR вместо View? Логично, чтобы процедура называласть не View, а Any. |
Автор: | adimetrius [ Среда, 06 Май, 2020 21:32 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Trurl писал(а): Илья Ермаков писал(а): А какую проблему вы видите с ANYPTR вместо View? Логично, чтобы процедура называласть не View, а Any. В точку! |
Автор: | Илья Ермаков [ Среда, 06 Май, 2020 22:38 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Не, Any можно заводить с другой сигнатурой: IN par: ANYREC. |
Автор: | Иван Денисов [ Пятница, 08 Май, 2020 07:14 ] |
Заголовок сообщения: | Re: #033: Предложение: дополнение Log |
Заменил INTEGER на LONGINT в аргументах Int и IntForm. Обновил в репозитории dev18. |
Автор: | Борис Рюмшин [ Пятница, 08 Май, 2020 18:29 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Илья Ермаков писал(а): Борис Рюмшин писал(а): Илья Ермаков писал(а): Щас криминал скажу... Добавить Str как псевдоним. Вот этого уже не надо. Ну, может быть, я один заколебался добавлять (и убирать, как при отладочных печатях) этот мусор Log.String.... ; Log.Ln; Мы уже раз вводили, потом все замахались путаться и вывели обратно. И ты с этим согласился. Поэтому не надо по второму кругу. |
Автор: | Борис Рюмшин [ Пятница, 08 Май, 2020 18:31 ] |
Заголовок сообщения: | Re: Предложение: дополнение Log |
Илья Ермаков писал(а): Речь о том, что может быть код, выводящий в лог расширенным образом (какая-то таблица результатов - вычислений, БД или что ещё). И используется он в основном в графическом ББ. Лог это, вообще говоря, очень служебная вещь, которая должна оставаться простой. Если тебе нужна сложная отладка -- пиши отдельный модуль с ней и выводи в отдельное окно, отдельный документ, файл. Это проблема разве? |
Страница 1 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |