SeekEof in Free PascalSun Sep 6 10:35:27 2020 UTC Пытаюсь убедить фрипаскальцев пофиксить, наконец, 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'е до чёрта изменений, будет сложно среди них вычленить те, которые этот альтернативно профессиональный товарищ внёс. 
|
пояснениеВы находитесь на официальном сайте Андрея Викторовича Столярова, автора учебных пособий по программированию и информационным технологиям. Если вы искали сайт замечательного писателя-фантаста Андрея Михайловича Столярова, то вам, к сожалению, не сюда. Андрей Михайлович Столяров в библиотеке Мошкова |
☞ From Anonymous (unverified) Sun Sep 19 21:53:00 2021 UTC
SetTextAutoFlush / GetTextAutoFlush
Не знаю, видели ли Вы (т.к. багтрекер FPC переехал на GitLab), но по Вашему второму отчёту об ошибке два месяца назад в RTL добавили функции SetTextAutoFlush() и GetTextAutoFlush().
https://gitlab.com/freepascal.org/fpc/source/-/issues/37833#note_644891342
http://94.130.77.24/fpcbin/docu/rtl/system/gettextautoflush.html
http://94.130.77.24/fpcbin/docu/rtl/system/settextautoflush.html
ответить
Ссылка на
Ссылка на гитлаб у меня не открывается — точнее, открывается, показывает панели оформления, а самого текста не показывает.
Вообще с переходом от собственной инфраструктуры к этому мерзотному чучелу Free Pascal можно было бы окончательно закапывать, если бы в мире были другие живые реализации. Проблема в том, что их нет. Ну а добавление двух нафнг не нужных функций вместо исправления откровенного косяка — это вполне в духе тех, кто там остался "в лавке".
ответить
Вот ссылка на
Вот ссылка на коммит на зеркале с GitHub, может откроется:
https://github.com/fpc/FPCSource/commit/9f6651fdb7fc4e9b37a7f3ac1d417e6de95f1f34
ответить
Да эта-то
Да эта-то открылась, но что там эти функции делают, было и так понятно. Мне интересно было бы посмотреть, как там развивалась дискуссия на открытом мной тикете, но нет так нет.
Особенно, конечно, прямо вот замечателен это пассаж про совместимость с TP/BP. Идиоты клинические.
ответить
Предпоследний
Предпоследний комментарий там датируется январём сего года (задолго до переезда на GitLab, так что вплоть до него Вы всё уже читали, думаю. А последний я выше привёл, Вы его уже запостили.
ответить
и вот последний
и вот последний комментарий из 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.
ответить
☞ From Сергей
Fri Oct 30 18:58:00 2020
UTC 
опечатка?
Уважаемый Андрей Викторович!
Дико извиняюсь, что отрываю от дел. Читаю Ваш первый том и компилирую по-тихонечку примеры.
Так вот программа olympcount.pas корректно работает (в моем понимании корректно - когда мы подаем содержимое текстового файла в качестве стандартного ввода) если мы поменяем строчку
while not eof do
на
while not SeekEof do
ответить
Странно
По идее, должна и так нормально работать, там ведь readln. А как выглядит некорректность?
ответить
Очень стыдно
Очень стыдно признаваться, но я - болван)
Программа ругается "Illegal school id:" когда текстовый файл заканчивается пустой строкой. В случае, когда файл заканчивается после цифр - всё считается верно.
ответить
☞ From OS80 (unverified) Sat Oct 24 20:09:00 2020 UTC
Андрей
Андрей Викторович, раз уж Вы готовите второе издание книги, у меня к Вам такой интересный вопрос: а может, Вы решитесь всё же переделать ассемблерную часть книги под синтаксис стандартного линуксового as?
ответить
Нет, сорри.
Нет, сорри. Во-первых, это выпуск книги отложит минимум на полгода. Во-вторых, лично мне -- представьте себе -- синтаксис AT&T вот просто-таки тупо не нравится.
ответить
☞ From Sergei (unverified) Mon Sep 28 10:19:00 2020 UTC
Судя по
Судя по состоянию тикета, успех таки достигнут?
ответить
Да даже и не знаю (tm)
Честно говоря, непонятно -- надо будет вытянуть снапшот и посмотреть. Я очень надеюсь, что этот Tomas Hajny всё-таки не понял, что происходит при открытии текстового потока и в итоге не смог сделать то, что хотел -- отрубить буферизацию для всего, что не файл. Если же ему это удалось, то "у победы какой-то странный вкус" -- SeekEof нам вроде пофиксили, но в целом стало ещё хуже, чем раньше.
Честно говоря, я не ожидал столкнуться с таким уровнем воинствующего невежества.
UPD: Посмотрел. Таки да. Я даже не знаю, что хуже — то, что было до этого "фикса" или то, что стало после. Без корректного SeekEof обходиться довольно сложно, но можно — например, читать всё посимвольно и числа ручками переводить. А вот когда буферизация выключена на вывод, включить её изнутри программы нельзя, никаких средств для этого не предусмотрено. Чёрт знает что.
ответить
Re: Да даже и не знаю (tm)
Я нашел ваш пост через указание на linux.org.ru в комментах. Почитал. Перевел ваш пост с Ру на En и запостил в Free Pascal mailing list.
вторая половина моего перевода: == In the comments of that post:
Q (reader): Judging by the state of the ticket, has success been achieved? A (Stolyarov): To be honest, it's not clear - you'll have to pull out a snapshot and see. I really hope that this Tomas Hajny didn't understand what happens when you open a text stream and ended up not being able to do what he wanted to do -- cut off buffering for anything that isn't a file. If he succeeded, then "the victory has some strange taste" - SeekEof seems to have been fixed to us, but in general it has become even worse than before. To be honest, I didn't expect to encounter such a level of militant ignorance. UPD: I looked. So yes. I don't even know what's worse - what happened before this "fix" or what happened after. It is quite difficult to do without the correct SeekEof, but you can - for example, read everything character by character and translate numbers with pens. But when buffering is turned off for output, it is impossible to turn it on from inside the program, no means are provided for this. The devil knows what. ==
На что разработчик FPC, Tomas Hajny, ответил там же. == "This Tomas Hajny" still believes that a user having a different opinion on a certain thing doesn't automatically prove that his different view is wrong. "This Tomas Hajny" tried to provide reasoning on his position - among others, "this Tomas Hajny" still values consistency among supported platforms and consideration of various use cases more than opinions of people only interested in their particular use case on one particular platform. "This Tomas Hajny" also sees that FPC RTL already provides variety of possibilities for achieving what the user having a different opinion intends to achieve. "This Tomas Hajny" understands that different people may differ in priorities of various arguments which is why he consulted the topic among the FPC core team. On top of that, "this Tomas Hajny" has by no means exclusive access to changing FPC RTL, i.e. any other member of the FPC core team may have decided to change the implementation according to preferences of the user having a different opinion.
Tomas ==
Суда по ответу Томаса, он не признает что это была ошибка и кивает на количество платформ которые надо поддержать одним и тем же кодом. Томас также пишет что другой девелопер FPC вправе переиначить его правку.
ответить
Re: Да даже и не знаю (tm)
У меня сразу вопрос возникает, вы на даты смотрели? Странно, что там вообще кто-то вспомнил, о чём речь идёт, прошло ведь три года.
Что касается этих аргументов про "платформы", этот чувак и тогда, три года назад, напирал на то же самое. К сожалению, не могу дать ссылку на тикет, поскольку эти дебилы отказались от собственной инфраструктуры в пользу, если не ошибаюсь, GitLab, а нормальными браузерами этот ублюдочный сайт не открывается (хотя вроде старые тикеты туда перенесли).
Так вот, тупой никогда не поймёт, что он тупой. Потому что он тупой. А "других" там, похоже, просто нет.
ответить
Re: Re: Да даже и не знаю (tm)
Вы просто оскорбляете товарищей. Какой конструктивный ответ вы хотите тогда? никакой. никакой не хотите.
ответить
Re: Да даже и не знаю (tm)
Я? Я от этой толпы долбанутых агрессивных ламеров уже три года как ничего не хочу. Какого конструктива можно ожидать от команды, взявшейся поддерживать единственную в мире живую реализацию Паскаля, при том что, похоже, ни один из них не понимал (до моего тикета) зачем нужна SeekEof, и я не уверен, что хоть кто-то что-то понял и после тикета, просто вынуждены были в итоге отреагировать, когда я ткнул их ихними ламерскими харями в документацию и исходники Турбо Паскаля тридцатилетней давности, спасибо что таковые у меня нашлись (ибо в шкафу стояла коробка с Borland Pascal 7.0; не думаю, что найдётся много людей, у которых такая коробка стоит в шкафу). А конкретно этот мудак, на общение с которым в "дискуссии" на том тикете я потратил (увы мне) намного больше времени, чем мог себе позволить, ещё и не понимал (и не понимает до сих пор), зачем нужна буферизация стандартных потоков ввода-вывода.
А вот зачем автор коммента выше, представившийся как Alexey Torgashin, решил перевести мой русскоязычный коммент трёхлетней давности на английский (кстати, перевод получился отвратительный, искажающий смысл в нескольких местах) и пойти с этим переводом наперевес снова ворошить это ламерское болото — ну, это мне неведомо. И вопрос, понятно, не ко мне. Лично я всё, что хотел этим дебилам сказать, уже сказал три года назад.
И да, мне эти жопорукие безмозглые ламеры не товарищи. Есличо, они не авторы FreePascal, они его просто "поддерживают", а лучше бы не трогали; до авторов, похоже, нынче не добраться, да и вряд ли им, авторам, FreePascal всё ещё интересен, иначе не пустили бы это всё на самотёк. Так что благодарить мне всю эту шушеру не за что. А презирать, очевидно, есть за что. Что и делаю.
ответить
☞ From frzq (unverified) Mon Sep 7 05:44:00 2020 UTC
Конечно в
Конечно в багтрекер. Вы же пытаетесь ребятам работу подкинуть (несмотря на предоставленный фикс).
ответить