Кстати, о трейтах.
Вот тут переводчики документации обсуждали, как правильно перевести «trait»: news.php.net/php.doc.ru/2908
Я со своей высокой башни влез и сказал, что traits они и есть трейты. Возможно, был не прав.
Если у кого-то есть обоснованные возражения на эту тему — скажите им, можно прямо в этом треде, Irker, я вижу, тут в комментах есть.
Я сужу на основе своего опыта работы с PHP6 — я довольно много phpt-тестов под него правил и чуток участвовал в разработке.
Понятное дело, нигде в продакшене я его не поднимал.
Все символы в строке? $text — даю гарантию, что все символы в строке — в строке.
>1) Почему именно должны? неужели нет ни одной альтернативы?
Потому, что там наиболее полная поддержка юникода и эта либа — стандарт де-факто.
Вы же, наверное, и на частичной поддержке не остановитесь, да?
>2) Не верю что это нельзя оптимизировать. Кэширование байткода разве не решает проблему?
Чего? Хэш-лукапов и работы со строками?
Кэширование байткода нужно только для того, чтобы не делать компиляцию кода в байткод на каждый запрос.
Но код-то еще и выполнять надо.
>3) В данном временном промежутке это не проблема (память копейки стоит),
>в тоже время вы упускаете тот факт, что всякие костыли типа регекпов для
> получения массивов символов также требую памяти и времени.
Да, костыли требуют времени тех, кому они необходимы.
А вы предлагаете всем пользователям принудительно докупить памяти.
>4) Ничего не придется переписывать, проблемы могут быть только в том, случае,
>если вы решитесь обновить древний скрипт работающий на древней версии PHP
>В нормальных скриптах разницы не будет, ибо mb_* останется и продолжить
>работать как раньше, а str* или все также будут перекрываться
>mbstring.func_overload или начнут нормально работать и без этой настройки.
>OpenSource, реализуется в первую очередь то, что хотят сами разработчики языка
>или за что им платят, поэтому данное высказывание не корректно, и, ИМХО,
>многим пишущим на PHP это нужно, другое дело, что за прошедшее время каждый
>из них уже реализовал необходимые функции (=костыли).
И судя по всему, они их устраивают, т.к. я именно про это и говорю — заинтересованных разработчиков нет (да и был один Змиевский по большому счету), а нанимать кого-то и платить за разработку никто не хочет. Вот это я и подразумеваю под «нет спроса».
>Хотя бы то, что не нужно будет задумываться о том как называется та или иная функция
Т.е. при переходе на внутренний Unicode в мануал смотреть не надо будет?
>Реальный пример — как вы сейчас получаете символ с определенной позицией из строки в UTF-8?
Естественно, я предварительно добавляю это в конфиг:
mbstring.internal_encoding=utf8
mbstring.func_overload=2
А теперь давайте подумаем что реально получается при полном переходе на юникод внутри.
1) все операции со строками должны проходить через ICU (http://icu-project.org), которая отнюдь не самая быстрай библиотека в мире, в том числе и по объективным причинам — операции со строками замедляются и довольно чувствительно.
2) все хэш-лукапы, поиски методов в списках методов классов, поиски самих классов и т.п. тоже включают в себя операции сравнения строк, поэтому и они быстрее не станут.
3) поскольку юникод по определению больше размером, то и объемы потребляемой памяти растут.
4) массу уже существующего кода придется переписать из-за того, что люди изначально закладываются на тот факт, что строка это просто данные, а не корректная строка в определённой кодировке.
5) имеем массу веселья с кодировками:
— данные от юзера — в какой кодировке?
— текст скрипта — в какой кодировке?
— файловая система — в какой кодировке?
— вывод скрипта — в какой кодировке?
— данные в базе — в какой кодировке?
и т.д. и т.п.
Всё это надо привести к внутренней кодировке ICU, для всего этого нужны какие-то INI-опции.
При этом mbstring работает нормально, а есть еще и php.net/intl для более низкоуровневой работы с Юникодом.
Вот и приходим мы к тому, что толком это никому не нужно.
Никто просто не заинтересован в инвестировании нескольких человеко-лет ради совершенно призрачного результата при таких очевидных минусах.
Нет, я согласен, ПРАВИЛЬНО было бы именно так. Но действительность говорит сама за себя — на нативную поддержку Unicode сейчас нет спроса. Был бы спрос — уже бы всё сделали.
И да, если вам надо и вы готовы — я могу вам помочь со стартом, нет проблем.
Давайте начнём упорядочивать кашу с C, на котором написан PHP.
O_CREAT — бардак! Где «E» на конце?
И надо не забыть сделать версию для camelCase-людей — oCreate, для ОО-людей — OpenAttributes::getInstance(O_CREATE), надо же учитывать эстетические вкусы всех.
что конкретно вам даст тот факт, что строки внутри будут храниться в UCS2?
увеличится скорость работы с ними? всё магически станет работать лучше?
это еще один чисто внутренний момент, который вас интересовать не должен.
Насколько я понимаю, на время суда сайт должен быть выключен, иначе он предположительно продолжает нарушать права «пострадавшей стороны». Так что, выключать сайт — это не инициатива авторов была.
Разница в этом:
-g (то же, что и -g1):
Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug.
Т.е. так прямо в мануале и написано, что -g — это если вы не планируете дебажить, это так, для бэктрэйса максимум.
-g3:
Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you -g3.
Почувствуйте разницу. Здесь точно всё-всё останется, даже макросы. Но и размер бинарника будет соотв-щий.
"-g -O2" — это универсальные дефолтовые ключи сборки, так везде.
Зачем нужен -g я только что уже сказал.
-O2 — это неэкстремальные оптимизации, как раз для сферического продакшена в вакууме.
Есть еще и -O3, см. man gcc.
>Все что необходимо — это чтобы PHP был собран с ключом "-g".
На самом деле очень желательно -g3 и еще -O0 к нему в добавок.
Ибо без них многие нужные в дебаге переменные оптимизируются и выходит вот такое: (gdb) p var
var =
В `man gcc` уровни опций -g и -O описаны довольно подробно.
>По каким-то причинам PHP 5.2.17 собрался у меня не в debug сборке с этим ключом
Понятно по каким - если он упадёт, то в корке хоть что-то должно быть читабельное, иначе не о чем будет баг-репорты писать в Дебиан.
Не понимаю почему все думают, что «сборка == установка».
У меня 5 разных версий по крону собираются каждый день, но при этом ни одной не установлено — зачем?
Для дебага или тестирования не надо ничего ставить, достаточно собрать всё в один бинарник (но не делать make install!) и его запускать.
серверу всё равно, а экстеншен собирается и работает с любой версией PHP.
«Я гарантирую это» (с), как один из людей, которые эти демоны пишет.
Вот тут переводчики документации обсуждали, как правильно перевести «trait»: news.php.net/php.doc.ru/2908
Я со своей высокой башни влез и сказал, что traits они и есть трейты. Возможно, был не прав.
Если у кого-то есть обоснованные возражения на эту тему — скажите им, можно прямо в этом треде, Irker, я вижу, тут в комментах есть.
Понятное дело, нигде в продакшене я его не поднимал.
Поменяйте параметр «длина» у функции.
>Или все символы в строке? Регекспы нам помогут?
Все символы в строке? $text — даю гарантию, что все символы в строке — в строке.
>1) Почему именно должны? неужели нет ни одной альтернативы?
Потому, что там наиболее полная поддержка юникода и эта либа — стандарт де-факто.
Вы же, наверное, и на частичной поддержке не остановитесь, да?
>2) Не верю что это нельзя оптимизировать. Кэширование байткода разве не решает проблему?
Чего? Хэш-лукапов и работы со строками?
Кэширование байткода нужно только для того, чтобы не делать компиляцию кода в байткод на каждый запрос.
Но код-то еще и выполнять надо.
>3) В данном временном промежутке это не проблема (память копейки стоит),
>в тоже время вы упускаете тот факт, что всякие костыли типа регекпов для
> получения массивов символов также требую памяти и времени.
Да, костыли требуют времени тех, кому они необходимы.
А вы предлагаете всем пользователям принудительно докупить памяти.
>4) Ничего не придется переписывать, проблемы могут быть только в том, случае,
>если вы решитесь обновить древний скрипт работающий на древней версии PHP
>В нормальных скриптах разницы не будет, ибо mb_* останется и продолжить
>работать как раньше, а str* или все также будут перекрываться
>mbstring.func_overload или начнут нормально работать и без этой настройки.
А вы попробуйте, исходники же есть: svn.php.net/viewvc/php/php-src/branches/FIRST_UNICODE_IMPLEMENTATION/
>OpenSource, реализуется в первую очередь то, что хотят сами разработчики языка
>или за что им платят, поэтому данное высказывание не корректно, и, ИМХО,
>многим пишущим на PHP это нужно, другое дело, что за прошедшее время каждый
>из них уже реализовал необходимые функции (=костыли).
И судя по всему, они их устраивают, т.к. я именно про это и говорю — заинтересованных разработчиков нет (да и был один Змиевский по большому счету), а нанимать кого-то и платить за разработку никто не хочет. Вот это я и подразумеваю под «нет спроса».
Т.е. при переходе на внутренний Unicode в мануал смотреть не надо будет?
>Реальный пример — как вы сейчас получаете символ с определенной позицией из строки в UTF-8?
$text = «тест»;
$second_utf8_symbol = substr($text, 1, 1);
Естественно, я предварительно добавляю это в конфиг:
mbstring.internal_encoding=utf8
mbstring.func_overload=2
А теперь давайте подумаем что реально получается при полном переходе на юникод внутри.
1) все операции со строками должны проходить через ICU (http://icu-project.org), которая отнюдь не самая быстрай библиотека в мире, в том числе и по объективным причинам — операции со строками замедляются и довольно чувствительно.
2) все хэш-лукапы, поиски методов в списках методов классов, поиски самих классов и т.п. тоже включают в себя операции сравнения строк, поэтому и они быстрее не станут.
3) поскольку юникод по определению больше размером, то и объемы потребляемой памяти растут.
4) массу уже существующего кода придется переписать из-за того, что люди изначально закладываются на тот факт, что строка это просто данные, а не корректная строка в определённой кодировке.
5) имеем массу веселья с кодировками:
— данные от юзера — в какой кодировке?
— текст скрипта — в какой кодировке?
— файловая система — в какой кодировке?
— вывод скрипта — в какой кодировке?
— данные в базе — в какой кодировке?
и т.д. и т.п.
Всё это надо привести к внутренней кодировке ICU, для всего этого нужны какие-то INI-опции.
При этом mbstring работает нормально, а есть еще и php.net/intl для более низкоуровневой работы с Юникодом.
Вот и приходим мы к тому, что толком это никому не нужно.
Никто просто не заинтересован в инвестировании нескольких человеко-лет ради совершенно призрачного результата при таких очевидных минусах.
Нет, я согласен, ПРАВИЛЬНО было бы именно так. Но действительность говорит сама за себя — на нативную поддержку Unicode сейчас нет спроса. Был бы спрос — уже бы всё сделали.
И да, если вам надо и вы готовы — я могу вам помочь со стартом, нет проблем.
O_CREAT — бардак! Где «E» на конце?
И надо не забыть сделать версию для camelCase-людей — oCreate, для ОО-людей — OpenAttributes::getInstance(O_CREATE), надо же учитывать эстетические вкусы всех.
увеличится скорость работы с ними? всё магически станет работать лучше?
это еще один чисто внутренний момент, который вас интересовать не должен.
pinba должна быть собрана именно с той версией MySQL и с теми ключами, с которыми собран mysqld.
-g (то же, что и -g1):
Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug.
Т.е. так прямо в мануале и написано, что -g — это если вы не планируете дебажить, это так, для бэктрэйса максимум.
-g3:
Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you -g3.
Почувствуйте разницу. Здесь точно всё-всё останется, даже макросы. Но и размер бинарника будет соотв-щий.
"-g -O2" — это универсальные дефолтовые ключи сборки, так везде.
Зачем нужен -g я только что уже сказал.
-O2 — это неэкстремальные оптимизации, как раз для сферического продакшена в вакууме.
Есть еще и -O3, см. man gcc.
На самом деле очень желательно -g3 и еще -O0 к нему в добавок.
Ибо без них многие нужные в дебаге переменные оптимизируются и выходит вот такое:
(gdb) p var
var =
В `man gcc` уровни опций -g и -O описаны довольно подробно.
>По каким-то причинам PHP 5.2.17 собрался у меня не в debug сборке с этим ключом
Понятно по каким - если он упадёт, то в корке хоть что-то должно быть читабельное, иначе не о чем будет баг-репорты писать в Дебиан.
У меня 5 разных версий по крону собираются каждый день, но при этом ни одной не установлено — зачем?
Для дебага или тестирования не надо ничего ставить, достаточно собрать всё в один бинарник (но не делать make install!) и его запускать.
Ну и не забывайте про исходники.
Поддержка ctags или cscope в редакторе так же помогает.
попробуйте перегрузить MySQL сервер, может он после этого подхватит новый кэш ld…
ldconfig -p | grep protobuf её показывает?