PHP7

Готово в смысле «космический корабль есть, а языка нет?»

12 ноября вышел 7.0.0rc7 в анонсе которого писали:

This release candidate is unplanned and ships instead of the announced RTM for the reasons of yet additional quality improvement. If no major issues appear within the usual two-week test period, the 7.0.0 general availability (GA) release will be brought out.

Так что завтра-послезавтра будет либо новый rc, либо долгожданный релиз

https://marc.info/?l=php-internals&m=144838316924497&w=2

might be applied=2C

Что значит «=2C»? Это какой-то странный сленг?

В двух словах, чем оно знаменито? И что стало с php6?

Переделали структуры данных (быстрей в 2 раза), добавили плюшек.

Ты чего тег «пыхпых» не добавил? Зачем мне это говно в трекере?

php6 написать не осилили и забросили. Помойму главной причиной была невозможность перейти на UTF

Помойму

Всеспящий Ктулху, съешь это ничтожество и обосри его останками самый высокий холм в Хартфордшире...

Помойму UTFом там и так все пользуются.

нет, сам движок не юникодный. Они попробовали переписать все внутренности движка, чтобы он работал на UTF-16, и конвертил в UTF-8 когда нужно. Можно было специфицировать utf строку префиксом, $string = u"string"; или $string = u16"string"; Сами строки становились скалярными объектами, так что можно было бы сказать $string->length() и получить корректный ответ вне зависимости от кодировки. Такие строки не просто работали бы на уровне view верхнеуровнего скрипта, а были бы частью движка. У них не получилось заимплементить саму эту фичу до конца. Там же код на си, и нужно было перефигачить с простых char* на это псевдо-ооп, а код PHP это адский ад, и короче они сами там посреди рефакторинга потерялись. Плюс не совсем понятно, как опредедлить UTF-8 или UTF-16 сейчас, если данные пришли со внешнего источника. Плюс появились огромные просадки по производительности. Они написали несколько версий (6.3 помойму была последней?), расписались в беспомощности и дропнули.

Дико проиграл с твоего рассказа

собственно, вот такое поведение было раньше:

$foo = u"string";
echo strlen($foo);

PHP Warning: strlen() expects parameter 1 to be string, MADNESS given

То есть strlen не знает, что ей передано аргументом, и не может выбрать реализацию. Чтобы не случилось MADNESS, нужно юзать что-нибудь типа mb_strlen, т.е. самостоятельно помнить, в какой строке что записано. В движке это просто char*, какое масло купишь с таким и затачивать бутер будешь.

MADNESS - это кредо PHP

Да, чтоб это использовать нужны железные нервы.

Причем фишка в том, что strlen с неправильным маслом не падает с ошибкой. А выдает платформо-специфичный результат, например strlen('ọ') без всякого экзепшена отдаст ответ «3». Не 2, не 4, не 8, а 3. Have a nice debug. А вот mb_strlen('ọ','UTF-8') отдаст «1».

Вообще, там все так работает через жопу, просто строки видны невооруженным глазом, а какие-нибудь ошибки чтения файлов надо специально подстраивать. Т.е. у тебя должен быть тестировщик, потому что программисту такой фигней заниматься некогда, а у многих ли людей есть личный тестировщик? Или даже, личный тестировщик, могущий разобраться в сишном говнокоде движка?

Вот все это говно (судя по форумам) они хотели пофиксить, но ресурсов на это нету. Похапэшники готовы жрать говно, а если чтение файла будет 1 раз из 100 падать с неизвестной ошибкой, ну и черт с ним.

Вообще, там все так работает через жопу, просто строки видны невооруженным глазом, а какие-нибудь ошибки чтения файлов надо специально подстраивать. Т.е. у тебя должен быть тестировщик

Я недавно размышлял на эту тему, когда плюхался с библиотекой Requests на питоне. Ругался на библиотеку и думал, что вот на PHP бы точно таких проблем не было. Если бы на PHP стал писать, то оно бы просто работало. В итоге оказалось, что проблема была из-за специфической настройки сервера, но библиотечка Requests тоже никаких сообщений о странных ответах не выводила. Потом я над этим задумался и понял, что дело просто в том, что на PHP я гору кода успел написать, а вот Питон использую не так давно. И просто не привык. Все грабли PHP (они, безусловно, тоже есть) просто на автомате обходишь и не замечаешь даже их. А вот к других языкам и технологиям надо привыкать.

если чтение файла будет 1 раз из 100 падать с неизвестной ошибкой

Не припомню такого, чтобы какие-то неожиданные случайные ошибки были. Странно слышать.

Вместо GA вышел ещё один RC. Если всё будет хорошо, то 3-го декабря должны зарелизить.

ну мы это на лоре в /web-dev раскопали, короче какая-то из версий php5 ведет себя так: когда оно читает файл, то сначала вычитывает его в буфер (целиком, карл!), чистит файл, модифицирует буфер (добавляет то что хочешь записать), записывает буфер в файл. Когда происходит ошибка write в файл (например, у жесткого диска перегрузка, или свободное место закончилось), он внутри падает с ошибкой в момент записи и забывает вернуть назад предыдущее содержимое файла. То есть ты попробовал записать в файл, и файл ВНЕЗАПНО обнулился. Причем там MADNESS лапша из IF'ов написана, десятки, и такое уебищное поведение случается только при особом сочетании входных параметров, особом сочетании флагов ошибок итп. Т.е. человек который это писал тупо запутался в ифах и проворонил этот случай. То есть чтобы получить эту ошибку тестировщик должен капитально потрахаться с тем, чтобы получить одновременное сочетание допустим десяти разных параметров. Просто так его фиг достигнешь, а на перегруженном сервере оно проявляется неоднократно. Такие дела.

Вот тебе платформы, на которых будет гораздо спокойней: Java, C#, Erlang.

Он специально использует это вместо запятой? Пхп головного мозга.

когда оно читает файл, то сначала вычитывает его в буфер (целиком, карл!), чистит файл

Так оно читает файл или пишет в него? Ты уж определись.

Ты инициируешь запись в файл (с режимом append). Вместо того, чтобы вызвать нормальный аппенд, оно вначале вычитывает весь файл в буфер, и стирает его содержимое. И дальше по тексту, где-то в середине процедуры буфер просирается, и мы получаем пустой файл. Пользователь в мрачном офигении, потому что он хотел заапендить к файлу строку, а получил файл нулевой длины. Так понятней? :)

Чтобы ты страдал, болезный

and ships

друл был прав про корабли!

Да. Жесть :)

А что если файл весит over9000М ?

THIS IS SPARTA MADNESS!

Но этот бред возникает только на очень специфической комбинации, походу автор просто запутался в if'ах, и буферизация подключилась там где не надо

Время офигительных историй. Когда я ушел из админов, была возможность устроиться на первую нормальную работу: либо на Java, либо на PHP.

Вначале пошел на PHP, ибо вакансий больше. Дали тестовое, и короче там надо было вычитать данные из экселевского CSV файла и распарсить. И к удивлению и ужасу, ни один из парсеров CSV на пыхе не мог в инкрементальный парсинг, все читали в память и убивались об лимиты. В конце концов я расчехлил Си и сам написал этот парсер, выложил все на гитхаб и пошел на собеседование получать респекты. На собесе меня выебли за то, что я не воспользовался готовым парсером, а на объяснения почему так сделано получил ответ - правильный способ грузить все в память и не выеживаться, данных больше ста килобайт на сайты все равно никто не грузит (с)(тм), поэтому авторы стандартных парсеров все сделали правильно. Пришлось униженно поджать хвост и пойти устраиваться джавистом.

Так что запомни подаван, файлов больше 100Кб не бывает, и твой пример надуман =)

И чем же там requests тебе не угодила?

какие нафиг библиотеки для csv и загрузка целиком в память? о чём речь вообще?

Так что запомни подаван, файлов больше 100Кб не бывает, и твой пример надуман

учитывая потребление памяти php, даже эти 100Кб могут нехило занять места в памяти. Вообще сам сейчас не пошел на PHP вакансию, потому что собеседующие какую-то дичь несли, но уже про js и jQuery (там надо вообще какой-то невероятный мистический опыт отладки иметь, чтобы к их дибильным выводам о работе jQuery прийти ).

1) там был CSV сделанная приложением Microsoft Excel, с особенным способом расставленными двойными кавычками или что-то такое, давно было это, неважно. Стандартный fgetcsv такое не читает.

2) твой стандартный fgetcsv читает в массив. В массив, Карл! А что будет, если туда загрузят файл размером 2 гигабайта? У правильного csv-парсера должен быть метод «считать следующую ячейку/координату/строку», с запоминанием на какой логической строке/ячейке/координате и по какому смещению в файле ты остановился - тогда можно будет обрабатывать хоть терабайтные данные. И вот поверх этой штуки уже можно написать функцию getcsv, которая вернет массив (вызывая «дай следующую ячейку пока не EOF/EOS»). Или если уж ОЧЕНЬ нужен сразу array, можно создать array из ленивых прокси-элементов, и потом их как-то хитро заполнять с помощью кэша при первом обращении. Но создатели PHP и тут отожгли, и написали свою быдлокодерскую фигню, возвращающую array реальных строк.

3) > учитывая потребление памяти php, даже эти 100Кб могут нехило занять места в памяти

сервер с 512 гигабайтами оперативной памяти спасет отца русской демократии - судя по всему создатели PHP именно так и думают

Сейчас пилю приложение, меньше чем на 4Гб оно даже не запускается, не говоря уж обработать какие-то данные. НО эти гигабайты тратятся на дело, а не на бред типа считывания CSV целиком в память

1) Вроде даже PHPExcel умеет chunk'ами читать файл.

2)

твой стандартный fgetcsv читает в массив. В массив, Карл! А что будет, если туда загрузят файл размером 2 гигабайта?

он построчно читает, так что ничего особенного не произойдет) только вот аллокаций постоянных в цикле могло бы быть меньше. При всех недостатках PHP проблемы «в PHP нельзя построчно считать файл, только целиком» не существует.

аааа, все, дошло. Да, был неправ. Был введен в заблуждение тем, что эта функция не возвращает итератор. Наверное, она хранит итератор прямо в ссылке на ресурс, да? И потом его можно делать rewind итп как будто это обычно чтение файла

Нууу... в любом случае, тот похапэшник об этом не знал ))))) Его объяснение было не в том, что я не понял метод работы fgetcsv, а в том что больших файлов не существует

Да, там и rewind и fseek есть.

больших файлов не существует

В Excel максимальное число записей в таблице 1кк, насколько я помню. Такой код:

$init = memory_get_usage();

$table = array(1000000);

for($j = 0; $j<1000000; $j++) {
    $row = array(10);
    for($k = 0; $k < 10; $k++) {
        $row[$k] = rand(0, 100000);
    }
    $table[$j] = $row;
}

echo "Peak memory" . (memory_get_usage() - $init);

Выдает цифру 1872457992 в байтах (1.7 Гбайт!) на PHP5.6, если использовать SplFixedArray, то где-то 900Мбайт. На седьмой версии PHP будет меньше, но массивы в PHP - это нечто, конечно)

Можно ещё штаны надеть через голову, и сделать select * from 10gb_database_table.

А в православном си можно сделать for(;;) malloc(гигабайт); - память тоже очень быстро кончится.

csv распарсить

Задание на старшего помошника младшего черпальщика при юниорском бараке. А

написал парсер сам на сях

Явный overqualification. И отношение к нему в рашке в большинстве случаев дебильно-агрессивное.

я для примера, в образовательных целях, чтобы показать оверхед PHP по памяти. Можешь в православном си даже повторить эксперимент и увидеть, что 10кк int'ов - это не так много и в память вполне умещается.

А ещё можешь собрать composer'ом какой-нибудь OroCRM и наблюдать, как он построив в своей памяти граф зависимостей проекта сожрет 1.5 Гбайта.

Бывают логи, которые пишутся процессом пыха, по 10 гигов (когда админы провтыкали и забыли настроить ротацию). А грузят, да редко когда больше пары метров. И это ограничивается максимальным размером поста в пхп.ини.

PHP тут не при чём. Почитай, что такое Quoted-printable.