Здравствуйте, кт, Вы писали:
кт>По теме, на мой взгляд, сюда, хотя какая «философия» может быть у вывода имен переменных? Но другие ветки еще менее подходят. кт>Посыл статьи я воспринял так: у кого нет этой удобной мелочи (вывода значений вместе с именами), как встроенной — тот лох. Точнее лохи – разработчики таких компиляторов, поскольку препроцессор легко это реализует и даже не отдельным проходом, а прямо как у автора — на лету при разборе ввода-вывода.
Мужик отстал от паровоза лет на 20, по ходу он про монаду I/O даже и не подозревает.
Re[9]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>в библиотеке выполнения известен адрес. А то, что я хотел вывести именно как X, а не как Y довольно сложно определить, поскольку имеется только содержимое указателя P. кт>А здесь никаких заморочек не надо — внутри программы автоматически запишется "X=" и дело с концом.
Прочитай статью три раза внимательно. После этого поймёшь, что возможности PL/1 по сравнению с немерле просто несравнимы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: О специализированных операторах ввода-вывода
Здравствуйте, WolfHound, Вы писали:
WH>Нет никаких нюансов.
Есть ньюанс. Представленный здесь пример на Немерле (спасибо за потраченное время) годится только для частного случая выдачи на экран.
WH>Вся статья детский сад штаны на лямке. WH>Там нет ничего что не может сделать толковый школьник на немерле за вечер. WH>И на научную статью она вообще никак не тянет. Максимум пост в бложике.
так редакция ее и не напечатала. А толковый школьник может сделать и не в Немерле, а еще как-нибудь.
WH>https://github.com/rsdn/nemerle/wiki/Macros-tutorial WH>Прочитай внимательно. Там есть код, который решает почти идентичную задачу.
почти да не совсем
WH>Это тебе в качестве домашнего задания.
Спасибо, не надо, я не работаю с Немерле, а в PL/1 уже есть готовое.
WH>Если хочешь, чтобы я с тобой дальше разговаривал тебе придётся продемонстрировать что ты хочешь узнать что-то новое, а не тупо защищаешь статью.
Я вообще-то просто обещал человеку выложить все его старые тексты (это последний), а не с кем-то разговаривать. И то лишь потому, что редакция почти по-хамски ничего ему не отвечала больше года.
Среди текстов есть и слабые, точнее мелкие вроде этого. И, не скрою, пытался защищать "честь предприятия".
А нового чего узнать в данном случае? Что можно достать имя переменной в строку? Да пожалуйста. Для этого три раза статью читать не требуется
выкладываю восьмую, последнюю статью, не попавшую в уже исчезнувший журнал RSDN Magazine.
Правда, осталась еще одна статья, но автор попросил подождать ее выкладывать: он нашел издание, куда пробует с ней толкнуться.
Так, что все свободны, всем спасибо
Даже тем, кто просматривал статьи под девизом: «Кто писал не знаю, а я, дурак, читаю» (А.Чехов «Жалобная книга»)
По обсуждениям статей, правда, удалось достичь консенсуса только по регистру SPL: нет несогласных с тем, что он на фиг не нужен
По теме, на мой взгляд, сюда, хотя какая «философия» может быть у вывода имен переменных? Но другие ветки еще менее подходят.
Посыл статьи я воспринял так: у кого нет этой удобной мелочи (вывода значений вместе с именами), как встроенной — тот лох. Точнее лохи – разработчики таких компиляторов, поскольку препроцессор легко это реализует и даже не отдельным проходом, а прямо как у автора — на лету при разборе ввода-вывода.
Здравствуйте, кт, Вы писали:
кт>По теме, на мой взгляд, сюда, хотя какая «философия» может быть у вывода имен переменных? Но другие ветки еще менее подходят. кт>Посыл статьи я воспринял так: у кого нет этой удобной мелочи (вывода значений вместе с именами), как встроенной — тот лох. Точнее лохи – разработчики таких компиляторов, поскольку препроцессор легко это реализует и даже не отдельным проходом, а прямо как у автора — на лету при разборе ввода-вывода.
Почему сразу лох? Делать специальные операторы для таких мелочей — ненужное усложнение языка. Делать препроцессор — серьёзное решение, которое потом может сильно аукнуться, у большинства современных языков препроцессоров нет.
Собственно какие языки вообще имеют такую возможность? Я вот ни одного такого языка не знаю. Только C/C++ за счёт препроцессора.
Так-то я согласен, удобно. Но можно много таких удобств придумать. Мне вот в Java не хватает захвата значений всех локальных переменных в Exception в каждом фрейме (и потом распечатывание их). Насколько проще была бы отладка.
Re[2]: О специализированных операторах ввода-вывода
Здравствуйте, vsb, Вы писали:
vsb>Собственно какие языки вообще имеют такую возможность? Я вот ни одного такого языка не знаю. Только C/C++ за счёт препроцессора.
Вот все и лохи Шучу, шучу. Просто в стародавние времена, когда не было интерактивных отладчиков и IDE с "распахиванием структур" больше внимания уделялось удобству вывода при отладке.
Ведь вывод с именами это действительно мелочь, но экономящая время. И нервные клетки.
vsb>Так-то я согласен, удобно. Но можно много таких удобств придумать. Мне вот в Java не хватает захвата значений всех локальных переменных в Exception в каждом фрейме (и потом распечатывание их). Насколько проще была бы отладка.
Да, и в Яве ведь стандартный вывод довольно развитой. Но почему-то опыт старых языков отвергли
Здравствуйте, кт, Вы писали:
кт>Сама статья, написана почти два года назад: кт>http://files.rsdn.org/122727/pl1ex19.doc
IMO в интерактивном отладчике такая фича просто не нужна.
В логах — возможно, но только временно, не в production. Потому, что в production лучше выводить не имена переменных, а их семантику.
Например "unparsed string: 234px". а не "_m_str_unpatrsed: 234px".
Потому, что имена переменных (и само их наличие) может меняться с развитием программы, и логи от старых версий станет неудобно читать.
Плюс, в C#, например, теперь есть nameof() а в JS есть JSON.stringify для объектов, то есть, частные решения уже есть и без препроцессора.
Вывод — не вижу зачем лично мне бы понадобилась описанная доработка.
Разве что быстро сляпать временный лог для разового использования... Но это такая мелочная экономия, что и заморачиватьсяне стоит.
Re[2]: О специализированных операторах ввода-вывода
Здравствуйте, vmpire, Вы писали:
V>IMO в интерактивном отладчике такая фича просто не нужна. V>В логах — возможно, но только временно, не в production. Потому, что в production лучше выводить не имена переменных, а их семантику. V>Например "unparsed string: 234px". а не "_m_str_unpatrsed: 234px".
Речь идет в основном об отладочных выводах. Если у меня массив S из 10 строк, что я должен увидеть? 10 раз "unparsed string:" или S(1)=.. S(2)=...
в первом случае толку от такого вывода мало и легко ошибиться при анализе.
V>Потому, что имена переменных (и само их наличие) может меняться с развитием программы, и логи от старых версий станет неудобно читать.
Это я вообще не понял. Если меняются даже названия переменных, зачем читать старые логи?
V>Плюс, в C#, например, теперь есть nameof() а в JS есть JSON.stringify для объектов, то есть, частные решения уже есть и без препроцессора. V>Вывод — не вижу зачем лично мне бы понадобилась описанная доработка.
Описанная доработка потребовалась автору для приведения компилятора к стандарту языка. В языке это было предусмотрено.
V>Разве что быстро сляпать временный лог для разового использования... Но это такая мелочная экономия, что и заморачиватьсяне стоит.
Вольному — воля. Описанная возможность встроена в язык и ляпать ничего уже не надо.
Здравствуйте, кт, Вы писали:
кт>Посыл статьи я воспринял так: у кого нет этой удобной мелочи (вывода значений вместе с именами), как встроенной — тот лох. Точнее лохи – разработчики таких компиляторов, поскольку препроцессор легко это реализует и даже не отдельным проходом, а прямо как у автора — на лету при разборе ввода-вывода.
На самом деле™, никто в логи просто так что попало не выводит. Нормальные логи имеют определенную структуру записи. Например: дата и время записи, ID текущего thread-а. Определенные требования могут предъявляться и к выводимым данным. Простой PUT DATA такое не потянет. Для формирования нормальной строки понадобится PUT EDIT, который, к слову, и работает намного быстрее, чем PUT DATA.
Да, я видел, что речь идет об отладке. Но это не повод нарушать единый формат логов. Тем более, что на них часто приходится натравливать всякие парсеры, которые могут упасть на непонятных записях.
Re[2]: О специализированных операторах ввода-вывода
Здравствуйте, Privalov, Вы писали:
P>Простой PUT DATA такое не потянет.
Да он, собственно, никогда и не претендовал. Всеобъемлющего оператора вывода до сих пор нет
P>Для формирования нормальной строки понадобится PUT EDIT, который, к слову, и работает намного быстрее, чем PUT DATA.
Это да, лучше бы сделали PUT EDIT DATA
P>Да, я видел, что речь идет об отладке. Но это не повод нарушать единый формат логов.
[испуганно] А где я нарушил? Кстати, что такое "единый формат логов"? ГОСТ что-ли ввели? Вот сволочи, людей им не жалко...
Re[3]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
P>>Для формирования нормальной строки понадобится PUT EDIT, который, к слову, и работает намного быстрее, чем PUT DATA. кт>Это да, лучше бы сделали PUT EDIT DATA
А еще лучше, как сейчас. Когда весь ввод-вывод вынесен в библиотеки. Я плохо представляю себе, как должен быть устроен PUT EDIT DATA.
P>>Да, я видел, что речь идет об отладке. Но это не повод нарушать единый формат логов. кт>[испуганно] А где я нарушил? Кстати, что такое "единый формат логов"? ГОСТ что-ли ввели? Вот сволочи, людей им не жалко...
ГОСТ не ввели, не надо пугаться. Но в любой нормальной программной системе логи имеют определенный формат. И нарушать его не стоит. Просто потому, что можно не найти требуемую запись. С учетом использования автоматиированных анализаторов.
Re[4]: О специализированных операторах ввода-вывода
Здравствуйте, Privalov, Вы писали:
P>А еще лучше, как сейчас. Когда весь ввод-вывод вынесен в библиотеки.
Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет.
P>Я плохо представляю себе, как должен быть устроен PUT EDIT DATA.
Да, думаю, так же как в статье. Только в списке форматов нужно через один добавлять формат "A" (надо будет автору идею кинуть )
P>ГОСТ не ввели, не надо пугаться. Но в любой нормальной программной системе логи имеют определенный формат. И нарушать его не стоит. Просто потому, что можно не найти требуемую запись. С учетом использования автоматиированных анализаторов.
Да я пошутил. Речь-то шла об отладке. Т.е. об обычно разовых выводах, которые программист посмотрел и выкинул (выкинул оператор вывода). Здесь вывод полностью определяется программистом и его понятием об удобстве и наглядности. Лог, который будут смотреть во время эксплуатации — это уже другое. Хотя и там PUT DATA пригодится. Особенно, если имена переменных хорошо продуманны.
Re[5]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет.
Это по тому что у вас языки не правильные. А в правильных языках библиотеки ещё не такое умеют. http://www.nemerle.org/
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет.
Автор статьи пишет, что иногда нужно анализировать данные на распечатке. Мне такую ситуацию пердставить сложно. В 2016 году анализировать лог на бумаге просто неудобно. Поиск по ним не сделаешь. А современные логи — штука весьма объемная. А если нужный фрагмент уже найден, то удобнее просто скопировать его, к примеру, на флэшку и посмотреть копию на каком-нибудь гаджете. Например, мой гибрид для просмотра логов подходит отлично. А если есть средства автоматизации работы с логами, тогда в печати вообще смысла нет.
А почему для записи логов используется PUT? WRITE был бы логичнее, нет? К тому же, файл можно сделать индексно-последовательным. Современные версии PL/1 такое поддерживают, правда? Сразу поиск легче станет. В качестве ключа использовать время записи.
P>>Я плохо представляю себе, как должен быть устроен PUT EDIT DATA. кт>Да, думаю, так же как в статье. Только в списке форматов нужно через один добавлять формат "A" (надо будет автору идею кинуть )
кт>Да я пошутил. Речь-то шла об отладке. Т.е. об обычно разовых выводах, которые программист посмотрел и выкинул (выкинул оператор вывода). Здесь вывод полностью определяется программистом и его понятием об удобстве и наглядности. Лог, который будут смотреть во время эксплуатации — это уже другое. Хотя и там PUT DATA пригодится. Особенно, если имена переменных хорошо продуманны.
На самом деле™ удобно, когда лог выводится в едином формате. Уровни логирования не зря придумали. Если возникает нештатная ситуация в production, просто меняется в конфиге уровень с error на debug, и все дела. Сразу, не сходя с места, получаем расширенную информацию.
Я надеюсь, для логирования используются специальные модули? А то я знаю пару любителей пихать запись в лог прямо в код. Добавит такой любитель оператор вывода в лог, а в конце убрать забудет. А с нормальными логгерами и далать ничего не надо. Только уровни расставить.
А не так много реального кода на PL/1 видел. Но везде использовался только PUT EDIT для печати.
Re[6]: О специализированных операторах ввода-вывода
Здравствуйте, WolfHound, Вы писали:
кт>>Вот как раз если ввод-вывод вынесен в библиотеки, то создание оператора типа PUT DATA затруднено:компилятор имеет адреса и свойства перечисленных для вывода объектов, а библиотека — нет. WH>Это по тому что у вас языки не правильные. А в правильных языках библиотеки ещё не такое умеют. WH>http://www.nemerle.org/
Я, кстати, оговорился. Компилятор имеет ИМЕНА и свойства.
Я же не написал создание невозможно. Я написал, что затруднено. Ведь сколько лишней информации нужно иметь и передавать туда-сюда только, чтобы вывести имя объекта в динамике. А если не нужен отладочный вывод? Все равно все иметь?
Re[3]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
V>>В логах — возможно, но только временно, не в production. Потому, что в production лучше выводить не имена переменных, а их семантику. V>>Например "unparsed string: 234px". а не "_m_str_unpatrsed: 234px". кт>Речь идет в основном об отладочных выводах. Если у меня массив S из 10 строк, что я должен увидеть? 10 раз "unparsed string:" или S(1)=.. S(2)=... кт>в первом случае толку от такого вывода мало и легко ошибиться при анализе.
"временный отладочный вывод" — это как раз то единственное применение, которое я могу представить (о чём и написал в конце поста).
А если уж говорить о массиве, то мне, например, был бы удобен более компактный вид (Например как в JSON), а уж никак не "S(1)=.. S(2)=..."
V>>Потому, что имена переменных (и само их наличие) может меняться с развитием программы, и логи от старых версий станет неудобно читать. кт>Это я вообще не понял. Если меняются даже названия переменных, зачем читать старые логи?
Ну так логика-то не меняется. Пример:
Пришло на вход сервиса XML сообщение. В лог полезно вывести информацию о нём (скажем, URI схемы, чтобы понимать, какой блок кода будет с ним работать).
Это не меняется с версиями программы.
Но, например, в первой версии это была одна переменная, в следующей — другая, а потом мы поменяли парсер и надобность в переменной отпала.
А информация по прежнему есть и её надо выводить.
В такой ситуации имена переменных будут только путать.
"зачем читать старые логи" — вопрос, видимо, риторический, так как ответ на него очевиден.
V>>Плюс, в C#, например, теперь есть nameof() а в JS есть JSON.stringify для объектов, то есть, частные решения уже есть и без препроцессора. V>>Вывод — не вижу зачем лично мне бы понадобилась описанная доработка. кт>Описанная доработка потребовалась автору для приведения компилятора к стандарту языка. В языке это было предусмотрено.
Ну тогда ок. Видимо, тогда это местные проблемы PL\1, а не общие вопросы (как можно предположить из темы).
V>>Разве что быстро сляпать временный лог для разового использования... Но это такая мелочная экономия, что и заморачиватьсяне стоит. кт>Вольному — воля. Описанная возможность встроена в язык и ляпать ничего уже не надо.
как это не надо? Язык сам догадается, какие переменные мне нужно записывать и в какой файл?
Re[6]: О специализированных операторах ввода-вывода
Здравствуйте, Privalov, Вы писали:
P>На самом деле™ удобно, когда лог выводится в едином формате. Уровни логирования не зря придумали. Если возникает нештатная ситуация в production, просто меняется в конфиге уровень с error на debug, и все дела. Сразу, не сходя с места, получаем расширенную информацию. P>Я надеюсь, для логирования используются специальные модули? А то я знаю пару любителей пихать запись в лог прямо в код. Добавит такой любитель оператор вывода в лог, а в конце убрать забудет. А с нормальными логгерами и далать ничего не надо. Только уровни расставить.
Видите ли, у Вас вся отладочная печать почему-то, исключительно что-то вроде телеметрии (недавно у Прогресса отладочная печать прервалась на 383 секунде, слышали?) или протокола работы сервера. А при создании программ отладочный вывод совершенно разный можеть быть. Какую-нибудь матрицу и вектор один раз вывести. В процессе создания может еще и логов-то и в проекте нет.
Исследовать распечатку? А почему нет. Цифирки большие. От электричества не зависит
P>А не так много реального кода на PL/1 видел. Но везде использовался только PUT EDIT для печати.
Может о PUT DATA не слышали Или это не отладочный вывод был.
Re[7]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>Я, кстати, оговорился. Компилятор имеет ИМЕНА и свойства. кт>Я же не написал создание невозможно. Я написал, что затруднено. Ведь сколько лишней информации нужно иметь и передавать туда-сюда только, чтобы вывести имя объекта в динамике. А если не нужен отладочный вывод? Все равно все иметь?
Как нужно, так и будет.
Библиотеки немерла в общем случае состоят из двух частей.
Той что выполняется во время исполнения и той что может поговорить с компилятором во время компиляции и сгенерировать, изменить или удалить код. https://github.com/rsdn/nemerle/wiki/Macros-tutorial
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: О специализированных операторах ввода-вывода
WH>Библиотеки немерла в общем случае состоят из двух частей. WH>Той что выполняется во время исполнения и той что может поговорить с компилятором во время компиляции и сгенерировать, изменить или удалить код. WH>https://github.com/rsdn/nemerle/wiki/Macros-tutorial
Ну вот пример в терминах PL/1
declare
x fixed(31) based(p),
y bit(32) based(p),
p ptr;
allocate x;
put data(x);
в библиотеке выполнения известен адрес. А то, что я хотел вывести именно как X, а не как Y довольно сложно определить, поскольку имеется только содержимое указателя P.
А здесь никаких заморочек не надо — внутри программы автоматически запишется "X=" и дело с концом.
Re[7]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>Видите ли, у Вас вся отладочная печать почему-то, исключительно что-то вроде телеметрии (недавно у Прогресса отладочная печать прервалась на 383 секунде, слышали?) или протокола работы сервера. А при создании программ отладочный вывод совершенно разный можеть быть. Какую-нибудь матрицу и вектор один раз вывести. В процессе создания может еще и логов-то и в проекте нет.
Так логи — это и есть телеметрия, нет? И в разных ситуациях нужны разные уровни детализации выводимой информации.
Вывод может быть разным по содержанию. А форма должна быть стандартизована в рамках разрабатываемой системы.
Вот так это может выглядеть:
2385/12/20 15:43:43.3440 TRACE ldomDocument::setRenderProps() - font is changed
2385/12/20 15:43:43.3440 TRACE ldomDocument::setRenderProps() - page height is changed
2385/12/20 15:43:43.3440 TRACE ldomDocument::setRenderProps() - page width is changed
2385/12/20 15:43:43.3440 INFO ldomDocument::openCacheFile() - looking for cache file
2385/12/20 15:43:43.3440 TRACE getPersistenceFlags() returned 0
2385/12/20 15:44:33.4850 TRACE Updating screen after key event
2385/12/20 15:44:33.4850 TRACE animatePageFlip( 256 -> 258 )
2385/12/20 15:44:33.4850 TRACE CRUIReadWidget::prepareScroll(1)
Лог CoolReader-а. Нормально читается. PUT DATA так не умеет.
В конфиге, вероятно, стоит уровень вывода DEBUG. Если указать INFO, то уровень детализации существенно понизится.
Ведь DEBUG может понадобиться не только при отладке, но и при тестировании. А иногда и в рабочей системе, правда, такое случается редко.
кт>Исследовать распечатку? А почему нет. Цифирки большие. От электричества не зависит
Во-первых, как я уже писал, это банально неудобно. Исследуется не одна-две строки, а десятки или сотни. Тупой поиск глазами с карандашиком лично меня напрягает.
Во-вторых, при чтении по распечатке легко ошибиться. Ну там 0 и О. Или 1 и l или I.
В-третьих, от электричества-таки зависит. Лампа какая-нибудь обязательно нужна. Наощупь в темноте у меня почему-то не очень получается.
кт>Может о PUT DATA не слышали Или это не отладочный вывод был.
Про PUT EDIT, WRITE, ISAM слышал, а про PUT DATA — нет? Я таких не встречал.
offtopic: Кстати, а ISAM поддерживается в языке?
Re[8]: О специализированных операторах ввода-вывода
P>Так логи — это и есть телеметрия, нет? И в разных ситуациях нужны разные уровни детализации выводимой информации. P>Вывод может быть разным по содержанию. А форма должна быть стандартизована в рамках разрабатываемой системы. P> PUT DATA так не умеет.
чего-то у нас диалог глухих получается. Я-то другие примеры приводил. Допустим, я перепутал порядок умножения матриц (умножение не коммутативное). У меня программа отработала 3 секунды и закрылась по концу расчета. На хрен мне все эти логи, события и времена. Мне матрицы распечатать и посмотреть не обсчитавшись член №6 в матрице 3х3. Один PUT DATA и вперед с песнями!
P>Во-первых, как я уже писал, это банально неудобно. Исследуется не одна-две строки, а десятки или сотни. Тупой поиск глазами с карандашиком лично меня напрягает. P>Во-вторых, при чтении по распечатке легко ошибиться. Ну там 0 и О. Или 1 и l или I. P>В-третьих, от электричества-таки зависит. Лампа какая-нибудь обязательно нужна. Наощупь в темноте у меня почему-то не очень получается.
В темноте спать надо. А отладочная печать не обязательно миллионы строк.
P>offtopic: Кстати, а ISAM поддерживается в языке?
Это Indexed Sequential Access Method что-ли? А зачем эта древность сейчас при живых Accessaх с SQL-лями и файлами, отображаемыми на память?
Re[9]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>чего-то у нас диалог глухих получается. Я-то другие примеры приводил. Допустим, я перепутал порядок умножения матриц (умножение не коммутативное). У меня программа отработала 3 секунды и закрылась по концу расчета. На хрен мне все эти логи, события и времена. Мне матрицы распечатать и посмотреть не обсчитавшись член №6 в матрице 3х3. Один PUT DATA и вперед с песнями!
Это частный случай. Который несложно сделать с помощью нормальных средств логирования. И потом, ЕМНИП, PUT DATA выводил данные в одну строку. Если размерность матрицы больше, чем 2x2, читать такое будет сложно. Но тут могу наврать.
кт>В темноте спать надо. А отладочная печать не обязательно миллионы строк.
А как же "от электричества не зависит"?
И про ночь я ничего не писал. Сейчас зима, темнеет раньше, чем заканчивается рабочий день.
P>>offtopic: Кстати, а ISAM поддерживается в языке? кт>Это Indexed Sequential Access Method что-ли? А зачем эта древность сейчас при живых Accessaх с SQL-лями и файлами, отображаемыми на память?
Стандарт языка не требует разве?
Вот найдется вдруг какая-нибудь ценная программа, которая 40 лет на ленте пролежала и которую срочно надо запустить. А в ней такое:
OPEN FILE(STATE_FILE) KEYED ENVIRONMENT(INDEXED);
Ну и дальше, что там требуется от индекса.
И что будет?
Как ни странно, файловые хранилища распространены достаточно широко.
Re[10]: О специализированных операторах ввода-вывода
Здравствуйте, Privalov, Вы писали:
P>Стандарт языка не требует разве? P>Вот найдется вдруг какая-нибудь ценная программа, которая 40 лет на ленте пролежала и которую срочно надо запустить. А в ней такое: P>
Здравствуйте, WolfHound, Вы писали:
WH>Прочитай статью три раза внимательно. После этого поймёшь, что возможности PL/1 по сравнению с немерле просто несравнимы.
так как в Немерле получить текст вывода "x=1280 y=1024" если x,y — целые?
У автора достаточно строки put data(x,y);
а в Немерле как будет выглядеть аналогичная строка?
Re[11]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>так как в Немерле получить текст вывода "x=1280 y=1024" если x,y — целые? кт>У автора достаточно строки put data(x,y); кт>а в Немерле как будет выглядеть аналогичная строка?
Вот прямо так и будет. Нужно только библиотеку написать.
тест
using System.Console;
using PL1.Macro;
module Program
{
Main() : void
{
def x = 1280;
def y = 1024;
put data(x, y);
put data(x, y, x + y, x.ToString() + "asd");
_ = ReadLine();
}
}
результат:
x=1280 y=1024
x=1280 y=1024 x + y=2304 x.ToString() + "asd"=1280asd
библиотека:
using Nemerle;
using Nemerle.Compiler;
using Nemerle.Compiler.Parsetree;
using System.Collections.Generic;
using System.Linq;
namespace PL1.Macro
{
public macro PutData(args)
syntax ("put", "data", args)
{
PutDataImpl.Impl(args)
}
module PutDataImpl
{
public Impl(args : PExpr) : PExpr
{
match (args)
{
| PExpr.Tuple as args =>
def code = List();
foreach (arg in args.args)
{
code.Add(<[ $(arg.ToString()) ]>);
code.Add(<[ "=" ]>);
code.Add(arg);
code.Add(<[ " " ]>);
}
code.RemoveAt(code.Count - 1);
def code = code.Aggregate((a1, a2) => <[ $a1 + $a2 ]>);
<[ System.Console.WriteLine($(code)) ]>
| _ => PExpr.Error(args.Location, "Tuple expected.")
}
}
}
}
Здравствуйте, Privalov, Вы писали:
P>Автор статьи пишет, что иногда нужно анализировать данные на распечатке. Мне такую ситуацию пердставить сложно. В 2016 году анализировать лог на бумаге просто неудобно.
Порой очень удобно. Помечать, стрелки рисовать, кружочки. ))
Любая высокоскоростная динамика отлаживается только по логам.
P>Поиск по ним не сделаешь. А современные логи — штука весьма объемная.
Фильтрацию зато сделаешь. А результат распечатаешь.
Re[7]: О специализированных операторах ввода-вывода
Здравствуйте, vdimas, Вы писали:
V>Порой очень удобно. Помечать, стрелки рисовать, кружочки. )) V>Любая высокоскоростная динамика отлаживается только по логам.
Ни разу не приходилось. Вот фрагменты исходников печатал. И в них рисовал кружочки и стрелочки. Иногда в распечатках можно заметить то, что не видно в IDE.
V>Фильтрацию зато сделаешь. А результат распечатаешь.
В прошлом проекте у нам внедрили неплохую систему работы с логами. Там все операции проводились, как с нормальной БД: фильтрция, поиск по массе критериев. Печатать не нужно было ничего.
Re[11]: О специализированных операторах ввода-вывода
Здравствуйте, pestis, Вы писали:
P>Мужик отстал от паровоза лет на 20, по ходу он про монаду I/O даже и не подозревает.
Точно! и эти, как их... ленивые вычисления не применил. А уж без привлечения монад отладочная печать с именами — все равно как пиво без водки, кино без Гоши Куценко и кучка дерьма без горки!
Re[12]: О специализированных операторах ввода-вывода
ОК. Но есть нюанс.
PUT DATA — в примере для простоты. А вообще-то это оператор вывода PUT.
Поэтому реальная форма будет чуть посложнее, например PUT FILE(F21) SKIP(2) DATA(x,y);
Т.е. может быть еще имя файла, число пропусков строк (в произвольном порядке).
Так что и библиотека будет чуть посложнее.
А так все правильно. Но ведь и в статье это названо мелочью. Кстати, а как насчет вывода не скаляров?
Т.е. а остальные примеры из статьи?
Re[12]: О специализированных операторах ввода-вывода
P>Если мы предмет обсуждения подменяем описанием его свойств, значит, он реализован?
Может я в тему не врубаюсь?
Вот пример примитивной "базы данных", допустимый в стандарте "G":
declare
1 карточка,
2(имя,
отчество,
фамилия) char(30) var,
2 возраст fixed(7),
2 дурак_ли_выпить bit,
бд file,
номер_карточки fixed(31);
open file(бд) update record direct keyed title('любители_выпить.dat');
имя ='Иван';
отчество ='Иванович';
фамилия ='Иванов';
возраст =50;
дурак_ли_выпить=нет;
Здравствуйте, кт, Вы писали:
P>>Если мы предмет обсуждения подменяем описанием его свойств, значит, он реализован? кт>Может я в тему не врубаюсь? кт>Или вопрос был не на эту тему?
Я просто спросил, реализован ли ISAM в этой версии PL/1. Вместо ISAM я мог бы написать BDAM, суть от этого не поменялась бы. Просто -есть или нет? Ответ на этот вопрос не должен вызывать затруднений. Просто — да или нет.
Re[14]: О специализированных операторах ввода-вывода
Здравствуйте, Privalov, Вы писали:
P>Я просто спросил, реализован ли ISAM в этой версии PL/1. Вместо ISAM я мог бы написать BDAM, суть от этого не поменялась бы. Просто -есть или нет? Ответ на этот вопрос не должен вызывать затруднений. Просто — да или нет.
Грибных лесов в Европе нет (с). Индексно-последовательных файлов в смысле IBM360 с их регионами и сблокированными записями в стандарте "G" нет.
Re[15]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>Грибных лесов в Европе нет (с). Индексно-последовательных файлов в смысле IBM360 с их регионами и сблокированными записями в стандарте "G" нет.
Примерно такой ответ я себе и представлял. С просто "да или нет" — проблемы.
Здравствуйте, pestis, Вы писали:
P>Мужик отстал от паровоза лет на 20, по ходу он про монаду I/O даже и не подозревает.
Отстал-то он похоже лет на 40. Но к чему монады
Re[3]: О специализированных операторах ввода-вывода
Здравствуйте, pagid, Вы писали:
P>>Мужик отстал от паровоза лет на 20, по ходу он про монаду I/O даже и не подозревает. P>Отстал-то он похоже лет на 40. Но к чему монады
Не все приняли тот факт, что еще в 80-е PL/1 был вытеснен Фортраном и Коболом.
Re[4]: О специализированных операторах ввода-вывода
Здравствуйте, Privalov, Вы писали:
P>Не все приняли тот факт, что еще в 80-е PL/1 был вытеснен Фортраном и Коболом.
Хотя в в 60-е PL/1 создавался для замены Фортрана и Кобола
Re[5]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>ОК. Но есть нюанс.
Нет никаких нюансов.
кт>А так все правильно. Но ведь и в статье это названо мелочью.
Вся статья детский сад штаны на лямке.
Там нет ничего что не может сделать толковый школьник на немерле за вечер.
И на научную статью она вообще никак не тянет. Максимум пост в бложике.
кт>Кстати, а как насчет вывода не скаляров? https://github.com/rsdn/nemerle/wiki/Macros-tutorial
Прочитай внимательно. Там есть код, который решает почти идентичную задачу.
кт>Т.е. а остальные примеры из статьи?
Это тебе в качестве домашнего задания.
Если хочешь, чтобы я с тобой дальше разговаривал тебе придётся продемонстрировать что ты хочешь узнать что-то новое, а не тупо защищаешь статью.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
) и кинь сюда ссылку, а я ее выложу как следует.
кт>Упс... А я думал, что они уже все в этой разметке. Мне их в таком виде и дали. Я их просто все себе в "файлы" и переписал.
кт>Вот все восемь ссылок http://files.rsdn.org/122727/pl1ex14.doc ,pl1ex15.doc, pl1ex19.doc-pl1ex24.doc
Автор подтвердил, что все статьи уже были размечены по этому шаблону. Так, что должны здесь нормально отображаться без дополнительных преобразований.
Re[15]: О специализированных операторах ввода-вывода
Здравствуйте, кт, Вы писали:
кт>Здравствуйте, WolfHound, Вы писали:
WH>>Нет никаких нюансов. кт>Есть ньюанс. Представленный здесь пример на Немерле (спасибо за потраченное время) годится только для частного случая выдачи на экран.
Запись в файл отличается от вывода на экран чуть менее чем никак.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[16]: О специализированных операторах ввода-вывода
Здравствуйте, hardcase, Вы писали:
H>Запись в файл отличается от вывода на экран чуть менее чем никак.
Имелось в виду, что PUT DATA(X,Y); это случай вывода в стандартный поток.
Реально операторы в программе выглядят как-то так:
PUT FILE(F) DATA(X,Y); или
PUT SKIP(2) FILE(F) DATA(X,Y); или
PUT FILE(F) SKIP DATA(X,Y); (порядок опций в операторе вывода может быть любой)
Поэтому фрагмент макро
…
public macro PutData(args)
syntax ("put", "data", args)
…
должен учитывать это и быть чуть сложнее.