| Вниманию пользователей gmail.com! В последнее время мои письма там едва ли не все оказываются в «папке для спама». Со своей стороны могу сказать точно, что почтовая система у меня настроена совершенно корректно, а с IP-адреса, с которого отправляются мои письма, никто никогда не только спама не рассылал, но и вообще этим адресом никто кроме меня никогда не пользовался. Мракобесие фашистов из Гугла, чья цель — прогнуть под себя весь Интернет, в последнее время стало зашкаливать. Так или иначе, если вы ждёте письма от меня, не забывайте поглядывать в «спам». | Вниманию пользователей яндекс-почты! Перед отправкой мне писем из их веб-интерфейса отключайте использование формата HTML! Мой почтовый клиент не поддерживает и (принципиально!) никогда не будет поддерживать HTML в письмах, а продираться сквозь html-тэги крайне неудобно. Если вы не понимаете, о чём идёт речь — то вас это касается в первую очередь. Если вы не уверены в своих силах, задайте вопрос техподдержке Яндекса. Получив письмо с тэгами, я один раз отвечаю лаконичным "отключите HTML", последующие письма с тэгами с того же адреса игнорирую. |
SeekEof in Free PascalОпубликовано admin в Сентябрь 6, 2020 - 13:35. |
Пытаюсь убедить фрипаскальцев пофиксить, наконец, SeekEof:
https://forum.lazarus.freepascal.org/index.php/topic,51353.0.html
Что характерно, я им даже фикс послал. Проверенный фикс, Карл!
Один странный человек уже набежал (Jonas Maebe). Ощущение, как при получении отписок от чиновников. Интересно, там все такие или всё-таки разумный человек найдётся? Или, может, я в неправильное место полез, надо не на форум, а сразу в багтречку?
UPD:Отрепортил в багтрекере: https://bugs.freepascal.org/view.php?id=37716 Делайте ставки, придётся мне всё-таки в новом издании книжки писать, что корректно числа из текстового потока можно прочитать исключительно посимвольно, или таки пофиксят.
UPD2:Получил от кого-то ответ в багтрекере. Сделал патч по их правилам. Отсабмитил. Запасаемся попкорном.
UPD3:Ёлки-моталки, откуда берутся такие люди и как Free Pascal вообще ещё жив с такой командой?! И, главное, что теперь делать-то? Форкать этого монстра я, извините, не потяну, проще свой компилятор Паскаля написать, но это же не на один год работы.
UPD4: https://bugs.freepascal.org/view.php?id=37833 -- теперь будем убеждать их пофиксить последствия их фикса, который "фиксит" то, что не сломано. Ей-богу, если бы не то обстоятельство, что других реализаций Паскаля просто нет, я бы давно на этих товарищей плюнул. Студентам иной раз (да что там иной раз, просто практически всегда) проще объяснить, что и как, чем этому упёртому персонажу. В этот раз несколько хуже то, что готового патча я предоставить не могу -- ну то есть, наверное, могу, но там в git'е до чёрта изменений, будет сложно среди них вычленить те, которые этот альтернативно профессиональный товарищ внёс.
SetTextAutoFlush / GetTextAutoFlush
Не знаю, видели ли Вы (т.к. багтрекер FPC переехал на GitLab), но по Вашему второму отчёту об ошибке два месяца назад в RTL добавили функции SetTextAutoFlush() и GetTextAutoFlush().
https://gitlab.com/freepascal.org/fpc/source/-/issues/37833#note_6448913...
http://94.130.77.24/fpcbin/docu/rtl/system/gettextautoflush.html
http://94.130.77.24/fpcbin/docu/rtl/system/settextautoflush.html
Ссылка на
Ссылка на гитлаб у меня не открывается — точнее, открывается, показывает панели оформления, а самого текста не показывает.
Вообще с переходом от собственной инфраструктуры к этому мерзотному чучелу Free Pascal можно было бы окончательно закапывать, если бы в мире были другие живые реализации. Проблема в том, что их нет. Ну а добавление двух нафнг не нужных функций вместо исправления откровенного косяка — это вполне в духе тех, кто там остался "в лавке".
и вот последний
и вот последний комментарий из GitLab:
A procedure SetTextAutoFlush was added to allow explicit control of output buffering for particular text files on top of the default behaviour, and a function named GetTextAutoFlush allowing to check the current state. This provides a clear solution for anybody whose needs do not match the default behaviour (which is compatible to TP/BP). Thanks to MvC and MvdV who contributed to tackling this topic.
Вот ссылка на
Вот ссылка на коммит на зеркале с GitHub, может откроется:
https://github.com/fpc/FPCSource/commit/9f6651fdb7fc4e9b37a7f3ac1d417e6d...
Да эта-то
Да эта-то открылась, но что там эти функции делают, было и так понятно. Мне интересно было бы посмотреть, как там развивалась дискуссия на открытом мной тикете, но нет так нет.
Особенно, конечно, прямо вот замечателен это пассаж про совместимость с TP/BP. Идиоты клинические.
Предпоследний
Предпоследний комментарий там датируется январём сего года (задолго до переезда на GitLab, так что вплоть до него Вы всё уже читали, думаю. А последний я выше привёл, Вы его уже запостили.
опечатка?
Уважаемый Андрей Викторович!
Дико извиняюсь, что отрываю от дел. Читаю Ваш первый том и компилирую по-тихонечку примеры.
Так вот программа olympcount.pas корректно работает (в моем понимании корректно - когда мы подаем содержимое текстового файла в качестве стандартного ввода) если мы поменяем строчку
while not eof do
на
while not SeekEof do
Странно
По идее, должна и так нормально работать, там ведь readln. А как выглядит некорректность?
Очень стыдно
Очень стыдно признаваться, но я - болван)
Программа ругается "Illegal school id:" когда текстовый файл заканчивается пустой строкой. В случае, когда файл заканчивается после цифр - всё считается верно.
Андрей
Андрей Викторович, раз уж Вы готовите второе издание книги, у меня к Вам такой интересный вопрос: а может, Вы решитесь всё же переделать ассемблерную часть книги под синтаксис стандартного линуксового as?
Нет, сорри.
Нет, сорри. Во-первых, это выпуск книги отложит минимум на полгода. Во-вторых, лично мне -- представьте себе -- синтаксис AT&T вот просто-таки тупо не нравится.
Судя по
Судя по состоянию тикета, успех таки достигнут?
Да даже и не знаю (tm)
Честно говоря, непонятно -- надо будет вытянуть снапшот и посмотреть. Я очень надеюсь, что этот Tomas Hajny всё-таки не понял, что происходит при открытии текстового потока и в итоге не смог сделать то, что хотел -- отрубить буферизацию для всего, что не файл. Если же ему это удалось, то "у победы какой-то странный вкус" -- SeekEof нам вроде пофиксили, но в целом стало ещё хуже, чем раньше.
Честно говоря, я не ожидал столкнуться с таким уровнем воинствующего невежества.
UPD: Посмотрел. Таки да. Я даже не знаю, что хуже — то, что было до этого "фикса" или то, что стало после. Без корректного SeekEof обходиться довольно сложно, но можно — например, читать всё посимвольно и числа ручками переводить. А вот когда буферизация выключена на вывод, включить её изнутри программы нельзя, никаких средств для этого не предусмотрено. Чёрт знает что.
Конечно в
Конечно в багтрекер. Вы же пытаетесь ребятам работу подкинуть (несмотря на предоставленный фикс).