OberonCore

Товарищи, в серверную сборку хочется перестать тащить StdLog (коллеги, не таскают, а у меня таскается).

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

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

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

У меня у универсального модуля заглушка реализована вот так:

А стандартная реализация устроена так, с перспективой на обработку не только Views.View, а расширяемого набора объектов:

LONGINT, видимо, был просто забыт.

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

Views уже сделаны. Про LONGINT согласен, что можно заменить. Могут быть какие-то побочные эффекты, кроме нарушения бинарной совместимости?

Я у себя, в принципе, и SetDefaultRuler, Open и Clear из StdLog воспроизвёл.
Совершенно естественно представить код какой-нибудь прикладной, который и линейку устанавливает в гуёвом режиме, и на сервере запускается тоже в кластере каком-нибудь.
Унифицировать.

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

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

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

С моей точки зрения, LONGINT поставить надо давно. Мне не понятно, зачем нужно View для логирования. В особенности непонятно, зачем это нужно на сервере. Журнал это служебное средство всё-таки, а не консоль для вывода красивостей.

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

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

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

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

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


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

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

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."

и т.д.

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 ? Это тоже даст определенный уровень независимости и единства окружения.

Да если менять исходник и перекомпилировать, то уже не независимость от окружения...

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

Сейчас так сделано:

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

В точку!

Не, Any можно заводить с другой сигнатурой: IN par: ANYREC.

Заменил INTEGER на LONGINT в аргументах Int и IntForm. Обновил в репозитории dev18.

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

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