Ошибки из-за ужесточения проверки UTF-8 в строках

Здесь обсуждается всё, что касается макросов.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by citRiks »

Latest post of the previous page:

buniak_a_h wrote: Wed 24 Feb, 2021 17:36 Ну вот введу я код, учитывающий эту4 "особенность", а авторы ФАРа через полгодика введут новые правила - мне всё время скрипт корректировать? Я сделал (для себя!) чтоб работало. А так-то каждый выбирает сам - кому шашечки, а кому ехать.
ну любой софт предполагает что его надо поддерживать,
Да, есть такое понятие "поддерживать код", уж вам-то должно быть известно? :)
buniak_a_h wrote: Wed 24 Feb, 2021 17:36 введут новые правила - мне всё время скрипт корректировать? Я сделал (для себя!) чтоб работало.
ну ладно, если вы решили что в макроините вам удобнее,
то ваше право конечно :) а со стороны глядя, и не зная вашу ответственность,
можно подумать что вы решли ничего никогда не чинить,
ничего никому не давать, и пожизнено сидеть на какой-то устаревшей версии ФАРа
User avatar
buniak_a_h
Posts: 4262
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 644 times
Contact:

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by buniak_a_h »

citRiks wrote: Wed 24 Feb, 2021 18:46 есть такое понятие "поддерживать код", уж вам-то должно быть известно?
А ещё есть такое понятие "совместимость с более ранними версиями" - слышали?
User avatar
John Doe
Бюрократ
Posts: 13851
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 428 times
Contact:

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by John Doe »

citRiks wrote: Wed 24 Feb, 2021 18:46 а у юзера, который скачает - вылетит. Так лучше, что ли?
Не то что бы лучше или хуже, но именно так оно и произойдёт в любом случае.
И тут уж или враппер скроет ошибку от всех, либо юзер-таки вынужден будет её заметить (журналы же он читать не станет).
https://t.me/FarManager — Telegram чат
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by citRiks »

buniak_a_h wrote: Wed 24 Feb, 2021 18:52 А ещё есть такое понятие "совместимость с более ранними версиями" - слышали?
Отвечу вопросом на вопрос сначала,
а про совместимость с будущими версиями вы слышали?
А часто бывает и такое, да :)
И совместимость с прошлыми, насколько по времени,
в годах скажем, она должна быть для вас приемлимой?
Просто интересно, да и пользователям вашим полезно будет знать
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by citRiks »

На правах рекламы.
https://github.com/dr-dba/far-lua-general-utils
Сюда мы с @Хer0X-ом складываем общеполезные функии.
включая с недавнего времени и "враппер" (с указанием авторства)
Перед тем как где-то нужно "пофиксенное" УТФ8, вызвать так:
require("Lib-Common-@Xer0X")
хоть в макроините, хоть еще где надо

ДИСКЛАЙМЕР
Никто не несет ни за что никакую ответственность
User avatar
buniak_a_h
Posts: 4262
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 644 times
Contact:

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by buniak_a_h »

citRiks wrote: Wed 24 Feb, 2021 18:59 про совместимость с будущими версиями вы слышали?
Совместимости с будущими версиями не бывает. Либо учёт перспективы развития, либо сама будущая версия должна быть написана так, чтобы "не навредить". Новая версия LuaJet, видимо, навредила. Это примерно как невозможность запускать некоторые 16-разрядные приложения на 32-разрядной винде.
LAT
Posts: 343
Joined: Thu 21 Jan, 2010 20:00
Has thanked: 22 times
Been thanked: 39 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by LAT »

citRiks wrote: Wed 24 Feb, 2021 16:59 ну по крайней мере негативных эффектов на что-либо другое не замечено,
кроме падения самого скрипта, я так понимаю
Не понял вопрос. Враппер не использую. Поэтому скрипт, требующий враппера, иногда будет непредугадываемо падать. О каких негативных эффектах на что-либо другое Вы спрашиваете?
LAT
Posts: 343
Joined: Thu 21 Jan, 2010 20:00
Has thanked: 22 times
Been thanked: 39 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by LAT »

buniak_a_h wrote: Wed 24 Feb, 2021 17:49на самом деле хотелось бы пример не вылета..., а именно отрицательных последствий такого подхода. А то все возражения ограничиваются "чистотой стиля".
Враппер не использую, поэтому реальных примеров последствий его применения у меня, естественно, нет. Если чисто теоретически. Бывают ситуации, когда лучше, если программа ляжет, чем если обработает какой-то мусор, особенно массово. Соответственно, если какой скрипт рассчитывает, что некорректные данные он обрабатывать не будет, враппер позволит обойти это ограничение, причём так, что ни сам скрипт, ни пользователь этого не заметят.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by citRiks »

LAT wrote: Wed 24 Feb, 2021 22:07 О каких негативных эффектах на что-либо другое Вы спрашиваете?
да, я был неправ, мне показалось что вы его использовали, а потом убрали.
но опять же, мне были бы интересны негативные последствия использования враппера,
поэтому я и неправильно услышал от вас то что хотел услышать.
но у вас-то кажется нежелание его использовать враппер тоже религиозное :)
пожалуйста попробуйте пасть жертвой враппера ради науки,
только сообщите нам хоть один конкретный кейс вреда применения враппера
а то пока я вижу только вред от НЕприменения
gotar
Posts: 420
Joined: Sun 06 Sep, 2009 12:34
Has thanked: 17 times
Been thanked: 3 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by gotar »

Я вообще не понимаю о чем тут спор. Любой профессиональный программист, прочитавший книжку про Unicode, понимает что работать о с многобайтными кодировками нельзя также как однобайтными, что сложность Unicoda по сравнению с однобайтными кодировками не от чьей-то прихоти, а идет от сложности предмета. Два человека поленились прочитать про Unicode и получилась тема на семь страниц.
LAT
Posts: 343
Joined: Thu 21 Jan, 2010 20:00
Has thanked: 22 times
Been thanked: 39 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by LAT »

citRiks wrote: Thu 25 Feb, 2021 00:35пожалуйста попробуйте пасть жертвой враппера ради науки,
только сообщите нам хоть один конкретный кейс вреда применения враппера
а то пока я вижу только вред от НЕприменения
Я не знаю, на ради какую конкретно науку Вы ссылаетесь. Единственный "вред от НЕприменения" - после перехода на новую библиотеку ютф некоторые старые скрипты не обрабатывают "некорректные" строки, и их нужно подправить. Но это всё-таки не вред, а неудобство (хотя при желании и неудобство можно считать вредом). Лично у меня таких оказалось 3.
Но вместо правки проблемных скриптов Вы и buniak_a_h предлагаете юзать форк FAR-а (пусть с мелкими отличиями, но форк), аргументируя это тем, что вам с форком комфортнее, а в грабли с некорректной обработкой "некорректных" строк никто ещё с размаха не влетел. Блин, да это "из пушки по воробьям". Тем более, что время, потраченное на враппервар, можно было потратить и более эффективно, например, на исправление проблемных скриптов.
Враппер не юзаю, поэтому не знаю, существуют ли скрипты, которые при наличии враппера способны при определённых условиях иметь вредные последствия, а написать такой скрипт специально - не вижу смысла. Но суть в том, что вы своим враппером по, в общем-то, совершенно мелочному поводу раскалываете скрипты (и скриптописателей) на 2 лагеря, пользующиеся разными форками FAR-а. А это уже вред. Имхо.
Shmuel
Posts: 6834
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 41 times
Been thanked: 530 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by Shmuel »

Данный враппер делает поведение скриптов недетерминированным. Попробую пояснить:

1. Lua-паттерны %w, %a, %u, %l и т.д. в библиотеке luautf8 имеют смысл только если входной текст - валидный UTF-8.

2. В библиотеке string дело обстоит более закручено: для правильной работы этих паттернов должно быть совпадение текущей локали программы и кодовой страницы входного текста. К примеру (при прочих равных условиях), для кодовых страниц 1251 и 866 поведение будет разное.

3. Как правило, программа на основании анализа текста принимает какие-то решения. Если мы вызываем функции string.find, string.match и т.п., не имея понятия о кодировке входного текста, мы тем самым бросаем монетку и действуем дальше в зависимости от выпадения орла или решки.

4. Каждый волен у себя на системе делать что хочет. Но как общее решение "проблемы" данный враппер не годится. (Собственно я никакой проблемы и не вижу, в своё время починил отдельные места в своих скриптах, и больше никаких красных окошек не появляется уже много месяцев).
User avatar
buniak_a_h
Posts: 4262
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 644 times
Contact:

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by buniak_a_h »

Shmuel, лично меня больше всего интересует, как для не-валидных строк работала предыдущая версия luaitf8. Были в ней ошибки, которые, как меня уверяли, вовсе не ошибки, а поведение в точном соответствии с описанием (напомню, например: S:match("^.*()$") должен по определению быть равным S:len()+1; это было не так, если в S входили двухбайтовые символы). НО!!! Обработка не-валидных строк там была реализована очень правильно ! Вот если бы нос Ивана Иваныча приделать в ушам Ивана Никифоровича…
Shmuel
Posts: 6834
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 41 times
Been thanked: 530 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by Shmuel »

buniak_a_h
Насчёт S:match("^.*()$") - в предыдущей версии luautf8 (0.1.1) было так же, как и в теперешней (0.1.2).
(Хотя кажется теперешняя уже 0.1.3, но я заморозил свою версию Фар).
А вот ещё раньше, когда использовалась библиотека Selene Unicode - там смещение было в байтах, и да, это было правильно, в полном соответствии с документацией этой библиотеки. Никакой дальнейший спор по этому вопросу поддерживать не буду, извините, времени нет.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by citRiks »

LAT wrote: Thu 25 Feb, 2021 10:49 Единственный "вред от НЕприменения" - после перехода на новую библиотеку ютф некоторые старые скрипты не обрабатывают "некорректные" строки, и их нужно подправить. Но это всё-таки не вред, а неудобство (хотя при желании и неудобство можно считать вредом). Лично у меня таких оказалось 3.
Ну пожалуйста хоть секунду внемания можно? :)
я уже устал говорить что проблема не в тех скриптах,
которые будут написаны любителями нового УТФ8 в ФАРе,
а все те километры скриптoв которые были много лет назад,
и будут писаться еще долгие годы многие годы,
и теми людьми (и не в укор никому из них будет сказано),
которые не имеют ни малейшего понятия,
ни об этой весьма специфичной библиотеке для УТФ8,
и ни о том что вообще есть ФАР манагер.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Ошибки из-за ужесточения проверки UTF-8 в строках

Post by citRiks »

LAT wrote: Thu 25 Feb, 2021 10:49 Но суть в том, что вы своим враппером по, в общем-то, совершенно мелочному поводу раскалываете скрипты (и скриптописателей) на 2 лагеря, пользующиеся разными форками FAR-а. А это уже вред. Имхо.
примирения вражды произойдет когда кто-нибудь пойдет на мировую,
и через setfenv(..) сделает для задания области действие враппера.
Может быть это даже буду я.
Но мне пока интереснее кто первый моргнет ;-)
Можете украсть и меня идею setfenv(...).
Тогда вам дадут Нобелевскую Пpемию Мира наверное.
да и вообще я не самый большой специалист по setfenv(...) ..
Post Reply

Return to “Обсуждение макросов”