| |
| 2.2, Crazy Alex (ok), 21:02, 03/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Именно. Оставили бы одну латиницу - 256 символов как раз бы хватило на все умляуты и подобное. Всё равно дикарям с кириллицей и прочими иероглифами сложную технику давать нежелательно.
| | |
| |
| 3.3, Аноним (-), 21:31, 03/10/2016 [^] [^^] [^^^] [ответить]
| –4 +/– |
Вы или крестик снимите (хватить жопничать байты для UCS-4), или трусы оденьте (KOI8-R во все стринги и чары).
| | |
| |
| 4.4, Stax (ok), 21:43, 03/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
 А UCS-4 не текст, символы с кодом 0, однако. Вы предложите вариант, чтобы без управляющих символов в тексте.
| | |
| |
| 5.8, Аноним (-), 23:15, 03/10/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Я вообще предлагаю, разработать новую кодировку - машслово со времён 8битовых кодировок выросло в 8 раз, нет ни единой веской причины, кроме legacy, цепляться за эти волшебные 2^8. И да, память в "веские причины" не входит.
| | |
| |
| 6.13, Аноним (-), 10:21, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Нет ни единой веской причины разрабатывать кодировку с 8-байтным символом. Ошибки в некоторых продуктах при работе с символами переменной длины в "веские причины" не входят.
| | |
| |
| 7.30, Аноним (-), 17:35, 04/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Т.е. фортеля с сегментной памятью это хорошо и удобно, что аж перешли на модель плоской памяти? А уж как все были в восторге от циркового фокуса под названием PAE, когда в 32битные указатели вдруг вся эта плоская память стала не помещаться.
Я и говорю, или крестик снимите, или трусы наденьте. Эти грабли с символами переменной длины будут ещё очень долго икаться.
| | |
|
|
|
| 4.5, Аноним (-), 21:46, 03/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Помню, какая истерика была при переходе на 64-битную архитектуру, что, дескать, память жрёт, а тут все строки в 4 раза увеличить. Ну да, ну да.
| | |
| 4.10, Crazy Alex (ok), 00:50, 04/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Лично меня текущая ситуация - UTF-8 на диске и то, что удобнее в каждом конкретном случае - в памяти - полностью устраивает. Это Шигорина опечалило то, что алгоритм поменяли. А ведь - слава utf-8 - поменяли не из-за того, что поломан, а только ради оптимизации.
| | |
| |
| 5.19, Аноноим (?), 13:48, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
UTF-8 не нужно по причине непредсказуемости того, сколько символов в этой кодировке можно запихнуть в массив размером столько-то байт. Чисто для примера возьмём максимальную длину имени файла в линуксовых файловых системах, то есть 255 байт. Сколько это будет не латинских букв и цифр при UTF-8? А хз: с кириллицей один результат, с иероглифами другой, с каким-нибудь санскритом или греческим третий. Как выделить в оперативке буфер для текста размером, например, в 1024 символа? Умножай это дело на 6, поскольку в теории символ utf-8 может весить до 6 байт и выделяй, ага:) И прочее и прочее.
| | |
| |
| |
| 7.25, Аноноим (?), 14:27, 04/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
1024 - просто для примера. Ёмкость какого-нибудь буфера для сетевых/файловых операций или ещё чего типа длины строки при использовании паскалеподобных языков, у которых она задаётся заранее вместо нулевого символа в качестве признака конца строки. Вот и думай что лучше: то ли вместо одного килобайта оперативки сразу шесть выделить и не мучиться, то ли ждать грабель из серии "последний символ в отведённой памяти целиком не поместился", либо "ой, блин, файл из архива не вынимается по причине русского и слишком длинного имени".
| | |
|
| 6.22, Stax (ok), 14:18, 04/10/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
Аллокация с запасом, realloc, аллокация связанных структур и т.д. и т.п.
Зачем вы в задаче работы с кодировками опускаетесь до нюансов, как оптимизировать аллокацию? Оставьте это другим. Тем более не могу представить задачи, когда в оперативке надо выделять память под utf-8 представление всего объема неких данных, которые есть в другом представлении юникода. Бред же какой-то. Работаете поблочно...
Проблема с длиной имен, конечно, есть, но только потому, что не придумали универсального и переносимого способа хранить метаинформацию произвольного файла, кроме имени. Вы никакой длиной и кодировкой эту проблему не решите, пока не будет стандарта на метаинформацию. Как дойдет прогресс до работы везде с object storage заместо фс, так и настанет счастье. Ну, относительно...
| | |
| 6.23, iZEN (ok), 14:21, 04/10/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
 > Как выделить в оперативке буфер для текста размером, например, в 1024 символа? Умножай это дело на 6, поскольку в теории символ utf-8 может весить до 6 байт и выделяй, ага:) И прочее и прочее.
Проблемы сишников явистов и паскалистов не колышат!
| | |
| |
| 7.26, Аноноим (?), 14:28, 04/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
>> Как выделить в оперативке буфер для текста размером, например, в 1024 символа? Умножай это дело на 6, поскольку в теории символ utf-8 может весить до 6 байт и выделяй, ага:) И прочее и прочее.
> Проблемы сишников явистов и паскалистов не колышат!
А фортеров не колышат проблемы и явистов с паскалистами:)
| | |
| 7.48, Аноним Аналитег (?), 20:23, 05/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Проблемы несколько шире, в MariaDB/MySQL на символ utf8 аллокируется 3 байта, для четырех байтовых символов есть отдельный characterset, для пяти уже нету.
| | |
|
|
| 5.27, Michael Shigorin (ok), 14:41, 04/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Это Шигорина опечалило то, что алгоритм поменяли.
Не-а. Опечалило то, что из-за кривых данных пришлось сперва обтыкивать это всё горами костылей, а потом их ещё перекладывать.
Кто помнит, сколько времени и где/как в coreutils/grep/sed делали поддержку UTF-8 -- тот поймёт.
| | |
|
|
| 3.6, Michael Shigorin (ok), 22:04, 03/10/2016 [^] [^^] [^^^] [ответить]
| –8 +/– |
> Именно. Оставили бы одну латиницу - 256 символов как раз бы хватило
> на все умляуты и подобное. Всё равно дикарям с кириллицей и
> прочими иероглифами сложную технику давать нежелательно.
Особенно мило это утверждение "дикаря" оттеняется разбором подавляющей части достижений "недикарей", сделанной "дикарями" в первом-втором поколении.
PS: подразумевал ИТ, по которым такой разбор на глаза и попадался.
| | |
| |
| 4.9, Crazy Alex (ok), 00:47, 04/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Ну дык - дикарское желание пробиться + образование/цивилизация... ;-)
P.S. Если кто-то не понял - предыдущий коммент - сарказм. Я хоть и не сторонник пихания в юникод всего, чего можно, включая клингон, но угадывать "а какая у этой хрени была кодировка" на порядок хуже.
| | |
| |
| 5.20, Michael Shigorin (ok), 14:08, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> P.S. Если кто-то не понял - предыдущий коммент - сарказм.
Эт как раз понятно, просто смотришь на достижения "цивилизации" и понимаешь, что лучше б её такой не было вовсе.
> Я хоть и не сторонник пихания в юникод всего, чего можно, включая клингон,
> но угадывать "а какая у этой хрени была кодировка" на порядок хуже.
UCS-4 выглядит разумнее всем, кроме... обратной совместимости с семибитной ASCII.
| | |
|
|
| 3.11, Vkni (ok), 01:17, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
 > Всё равно дикарям с кириллицей и прочими иероглифами сложную технику давать нежелательно.
Алекс, через 30 лет вы на первое место поставите иероглифы, а дикари у вас будут с алфавитами.
| | |
| |
| 4.16, вотак (?), 11:46, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
>> Всё равно дикарям с кириллицей и прочими иероглифами сложную технику давать нежелательно.
> Алекс, через 30 лет вы на первое место поставите иероглифы, а дикари
> у вас будут с алфавитами.
расскажите нам а почему китайцы до сих пор не захватили монголию?
| | |
| |
| 5.45, Аноним (-), 01:55, 05/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Гуглите, что такое "внутренняя монголия" и где она находится.
| | |
|
| 4.18, Клыкастый (ok), 12:14, 04/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Алекс, через 30 лет вы на первое место поставите иероглифы, а дикари у вас будут с алфавитами.
в Поднебесной уже давно так.
| | |
| |
| 5.24, iZEN (ok), 14:22, 04/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Алекс, через 30 лет вы на первое место поставите иероглифы, а дикари у вас будут с алфавитами.
> в Поднебесной уже давно так.
В Японии же.
| | |
| |
| 6.33, Crazy Alex (ok), 19:20, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Японская письменность весьма условно иероглифы - их там что-то около трёх тысяч употребляется, всё остальное добирается слоговым письмом. Примерным аналогом их иероглифов в алфавитных языках можно считать корни слов.
| | |
|
|
| 4.32, Crazy Alex (ok), 19:16, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Я (возможно, предвзято) придерживаюсь мнения, что цивилизация в её современном/будущем виде с иероглифами совместима плохо. По причинам в основном психологического толка. Пока это подтверждается - товарищи, у которых нет алфавита, всё ещё догоняют и копируют, хоть и на очень хорошем уровне. Оригинальных открытий/изобретений особо не видно.
| | |
| |
| 5.36, Michael Shigorin (ok), 19:57, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> товарищи, у которых нет алфавита
Напомню про опиумные войны -- сдаётся мне, разница ещё и в совести либо её отсутствии.
| | |
| 5.38, Vkni (ok), 21:26, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Я (возможно, предвзято) придерживаюсь мнения, что цивилизация в её современном/будущем
> виде с иероглифами совместима плохо.
Алекс, ну ты что, ну зачем учить 33 буквы, когда можно выучить 3 тысячи иероглифов!!! :-)
| | |
| |
| 6.43, fail (?), 00:04, 05/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
>> Я (возможно, предвзято) придерживаюсь мнения, что цивилизация в её современном/будущем
>> виде с иероглифами совместима плохо.
> Алекс, ну ты что, ну зачем учить 33 буквы, когда можно выучить
> 3 тысячи иероглифов!!! :-)
угу, и про четыре тональности не забыть - т.сказать развивать музыкальный слух
| | |
|
|
|
|
| 2.40, Led (ok), 23:28, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Это не однобайнтные кодировки аукаются, а однобайтные терминалы.
| | |
|
| 1.7, KonstantinB (ok), 22:25, 03/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +9 +/– |
 > Значительно увеличена скорость работы при направлении стандартного вывода в /dev/null
Web scale!
| | |
| |
| 2.15, IZh. (?), 10:36, 04/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
А ещё вечный цикл стал выполняться в два раза быстрее. ;-)
| | |
|
| 1.14, Аноним (-), 10:24, 04/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
Когда уже добавят поддержку systemd?
Жду-недождусь systemd-grepd с поддержкой multiseat!
| | |
| 1.29, XoRe (ok), 15:25, 04/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 > Значительно увеличена скорость работы при направлении стандартного вывода в /dev/null;
Просто делает вид, что работает, раз вывод не нужен?
| | |
| |
| 2.31, Анонимкин (?), 19:11, 04/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Вполне рабочий кейз:
[lexa@centos-test ~]$ cat text.txt
some text
[lexa@centos-test ~]$ grep some text.txt > /dev/null
[lexa@centos-test ~]$ echo $?
0
[lexa@centos-test ~]$ grep same text.txt > /dev/null
[lexa@centos-test ~]$ echo $?
1
| | |
|
| 1.47, curious (?), 13:31, 05/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> Значительно увеличена скорость работы при направлении стандартного вывода в /dev/null;
Мне кажется, что нефиг программе знать куда я её вывод перенаправляю (и менять своё поведение из-за этого).
| | |
| |
| 2.49, Andrey Mitrofanov (?), 09:38, 06/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Значительно увеличена скорость работы при направлении стандартного вывода в /dev/null;
> Мне кажется, что нефиг программе знать куда я её вывод перенаправляю (и
> менять своё поведение из-за этого).
А я вот уверен, что уважающая _меня_ программа должна грепать в дев-нулл быстро, как только может.
| | |
|
|
