Page 16 of 16

Re: Путь приложения

Posted: Fri Dec 23, 2016 4:09 pm
by 0CodErr
:lol: Ну и как эти вот твои цитаты связаны с
CleverMouse wrote:Так это же ты предлагаешь каждой библиотеке свою кодировку.
Ммм???
CleverMouse wrote:библиотека не может "хотеть" какую-то другую.
Это был ответ для Serge
Serge wrote:А у приложения прикомпилированная или подгруженная либа, которую писал совсем другой человек. И у которого совсем другие представления о том, в какой кодировке указан путь.
И действительно, библиотека вполне может использовать какую-то конкретную кодировку. Плохо это или хорошо — это уже другой вопрос.

Re: Путь приложения

Posted: Fri Dec 23, 2016 4:30 pm
by CleverMouse
0CodErr wrote::lol: Ну и как эти вот твои цитаты связаны с
CleverMouse wrote:Так это же ты предлагаешь каждой библиотеке свою кодировку.
Ммм???
Ещё раз. Если кодировка по всей системе одна, её нельзя задавать в заголовке приложения.

Re: Путь приложения

Posted: Fri Dec 23, 2016 4:36 pm
by 0CodErr
Поэтому она и не должна быть одна.

Ответь заодно товарищу Serge
А у приложения прикомпилированная или подгруженная либа, которую писал совсем другой человек.

Re: Путь приложения

Posted: Fri Dec 23, 2016 5:37 pm
by Serge
CleverMouse wrote:Останутся старые функции, которые будут принимать UTF-8.
Я тоже за utf8. Крякозябры в кириллических именах можно пережить, тем более это решаемо.
0CodErr
Вот поэтому в заголовках и не должно быть флагов кодировки.

Re: Путь приложения

Posted: Fri Dec 23, 2016 7:34 pm
by Pathoswithin
Как-то недемократичненько... Сейчас основная кодировка ср866. Конечно, реально сделать основной UTF-8, но разве другие кодировки помешают? Собственно, идея с маркерами как раз и заключалась в том, что строки могут быть в разных кодировках, но определяются автоматически и не создают проблем. Такой подход доступен в режиме "default".

0CodErr
Зачем тогда ты сделал изменения? -> Единый стандарт. Важно.
Ладно, вот тогда пример не от меня, от постороннего человека, только там уже не гигабайты, а терабайты http://www.linux.org.ru/forum/talks/9406274
В базах данных "строка" это единица данных, а не обязательно текст. В данном случае это "10 килобайт чисел (по 8 байт на одно число)".

Не беспокойся, KolibriOS сама никуда не переедет без людей, способных поломать обратную совместимость, а точнее без основных разработчиков.

Re: Путь приложения

Posted: Fri Dec 23, 2016 7:43 pm
by 0CodErr
Serge wrote:Крякозябры в кириллических именах можно пережить
А, ну тогда зачем вообще unicode? Можно любые крякозябры пережить :mrgreen:
Serge wrote:Вот поэтому в заголовках и не должно быть флагов кодировки.
Это могут быть дополнительные сисфункции.
Serge wrote:Я тоже за utf8.
А я за универсальность. И аргументы я уже приводил. Теперь ваша очередь привести аргументы. Только, пожалуйста, не высосанные из пальца.

А с разными кодировками всё равно придётся работать, например, в ECMAScript используется UTF16, ID3 tag-и для MP3 допускают UTF-16 и UTF-8. А вы предлагаете взять и искусственно ограничить возможности системы. Причём ограничить то, что уже работает.
Pathoswithin wrote:KolibriOS сама никуда не переедет
Ну, конечно же, не сама по себе :)
Pathoswithin wrote:без людей, способных поломать обратную совместимость
А такие и даром не нужны. Пусть они и дальше у себя её ломают.
Pathoswithin wrote:точнее без основных разработчиков
Всё течёт, всё меняется. Да и по большому счёту ничего сверхъестественного и не требуется. Всего лишь оставлять работающее работающим. И всего-то! Да, GPL позволяет также использовать сторонний код :)
В базах данных "строка" это единица данных, а не обязательно текст.
не обязательно текст != обязательно не текст
Да и вообще, это лишь единичный пример. Думаешь других не может быть?
Там он дальше пишет
Ключ - строка ходов вроде «A/B/C/...», в среднем 50-100 байт, значение - матрица чисел с плавающей запятой, около 10 килобайт (для простоты можно закодировать одной строкой).

Re: Путь приложения

Posted: Fri Dec 23, 2016 8:05 pm
by Pathoswithin
Действительно, MenuetOS остаётся работающей уже больше 10 лет. И зачем они вообще Menuet64 делают? Почему-то всё течёт, всё меняется...

Правильно, матрица чисел с плавающей запятой, я процитировал его комментарий http://www.linux.org.ru/forum/talks/940 ... nt-9411049
Если хранить столько данных в текстовом виде, то надо менять не кодировку, а архитектора.

Re: Путь приложения

Posted: Fri Dec 23, 2016 8:33 pm
by 0CodErr
Pathoswithin wrote:Действительно, MenuetOS остаётся работающей уже больше 10 лет. И зачем они вообще Menuet64 делают? Почему-то всё течёт, всё меняется...
Не очень понял, к чему это. Хорошо, когда добавляется что-то новое, также хорошо, когда улучшается что-то существующее. Но плохо хотеть ограничиваться чем-то одним. В то время когда более расширенные возможности уже существуют.
Pathoswithin wrote:Если хранить столько данных в текстовом виде, то надо менять не кодировку, а архитектора.
Зачем ты так зациклился на конкретно этой задаче? Неужели думаешь, она единственная в своём роде? Можешь про BigData почитать, например.
Или вот могу я хотеть обрабатывать чего нибудь 1Mb\sec? Вполне ведь! Через 1 час это уже 3600Mb. Через 10 часов это 36000Mb и т.д. В общем, шире надо мыслить просто. Сейчас, может быть, кому-то с трудом верится, что на KolibriOS можно будет делать что-то серьёзное. Но это возможно! Просто не надо себя искусственно ограничивать. Вот и всё! :)

Re: Путь приложения

Posted: Fri Dec 23, 2016 10:14 pm
by Pathoswithin
Обработка UTF-8 это вообще не вычисления, говорить о производительности глупо. Переменная длинна в байтах это ерунда, вон в видеокодировании используется экспоненциальный код Голомба или вообще контекстно-адаптивные коды переменной длинный, а битрейт может быть и больше 1Mb\sec, но ничего, считает...

Re: Путь приложения

Posted: Fri Dec 23, 2016 11:40 pm
by Leency
Наверно, utf8_strlen() лучше сделать ядерной для упрощения разработки и уменьшения размера приложений.

Re: Путь приложения

Posted: Sat Dec 24, 2016 1:25 am
by Siemargl
CleverMouse wrote:Если всё будет в UTF-8, то большая часть, если не все, существующих программ вообще не заметит разницы.
Это настолько неудобно, что этого не будет никогда.

По крайней мере, в остальном мире выглядит именно так.