 |  | ||
 главная | избранное | настройки | об ALT-форуме |
Страницы форума: ← Назад | 1 … 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 … 600 | Дальше →
3.4.0b BUG? | ||
Аноним | 08.06.09 17:00 www.parser.ru → | ответить → | | |
3.4.0b BUG? | ||
| Есть класс. В нем есть метод В этом методе по циклу вызывается метод в котором вызываеться метод) В методе явно определен $result. После определения ^throw[asd;asd;$result] выводит коректный результат. Но если сам вызов обернуть throw - ^throw[asd;asd;^getXmlContent[$sPath]] выводит кучу пустых строк | ||
| Sumo | → Аноним [1] | 08.06.09 17:03 www.parser.ru → | ответить → | | |
Выделите "проблему" в чистом виде... | ||
| ... т.е. нужен один файл в котором воспроизводится ситуация. | ||
| Аноним | → Sumo [2] | 08.06.09 17:12 www.parser.ru → | ответить → | | |
| я сам непойму... на одном сайте при разных условиях работает по разному... пока сделал в лоб - убрал result и сделал вывод прям в теле метода | ||
| Аноним | → Sumo [2] | 08.06.09 17:15 www.parser.ru → | ответить → | | |
| Багофича явно в 3.4.0(Linux) в 3.3.0(Windows) все работало | ||
| moko | → Аноним [1] | 08.06.09 17:16 / 17:17 www.parser.ru → | ответить → | | |
Проблема возможна | ||
| Да, в 3.4.0 теперь есть оптимизация, работающая в зависимости от использования $result - если $result используется, то весь остальной вывод метода игнорируется (а значит экономится процессор и память). Что будет работать некорректно: когда при одном вызове $result используется, а при другом нет. Типа @method ^if($expression){ $result[это] }{ другое-значение } То есть метод должен либо всегда использовать $result, либо всегда не использовать. Если у вас с этой точки зрения все правильно, ждем _bug.html | ||
| Аноним | → moko [5] | 08.06.09 17:27 www.parser.ru → | ответить → | | |
| Спасибо Константин! :) У меня result лежал в if`e ^if(-f $sPath){ ... $result[$sContent] }{ $result[] } так работает) | ||
| moko | → Аноним [6] | 08.06.09 17:52 www.parser.ru → | ответить → | | |
Да, конечно | ||
| Во всяком случае должно. :) Главное чтобы во всех ветках/случаях было присвоение. Например чтобы снаружи этого не стоял еще один ^if. :) Простой способ не думать об этом - $result[] в начале. | ||
| Vint | → moko [5] | 08.06.09 18:10 www.parser.ru → | ответить → | | |
Вопросцы | ||
| 1. Такое поведение актуально только при объявлении result'а в качестве локальной переменной или при наличии хотя бы одного $result в методе? Касательно новой оптимизации в парсере: 2. Имеет ли смысл объявлять локальный result в каждом методе при условии, что все медоты возвращают данные только через $result (привычка такая)? Интересуют скорость и расход памяти. 2.1 Влият ли объявление locals в методе или целом классе на объявление локального result'а, т.е. не заменяет ли locals собой result? | ||
| Hexley | → moko [7] | 08.06.09 18:20 www.parser.ru → | ответить → | | |
$tData.[$tColumns.column] | ||
$tData.[$tColumns.column] такая запись не работает в 3.4 . Чего я еще не знаю?))) | ||
| Sumo | → Hexley [9] | 08.06.09 18:21 www.parser.ru → | ответить → | | |
Работает... код полностью покажите. | ||
| moko | → Vint [8] | 08.06.09 18:43 / 18:43 www.parser.ru → | ответить → | | |
Чуть ответов | ||
| 2. Имеет ли смысл объявлять локальный result в каждом методе при условии, что все медоты возвращают данные только через $result (привычка такая)? Интересуют скорость и расход памяти. Да, конечно имеет - на этапе компиляции будет выкинут лишний whitespace. 2.1 Влият ли объявление locals в методе или целом классе на объявление локального result'а, т.е. не заменяет ли locals собой result? locals - по-моему это совсем про другое. Описанная мной оптимизация - работает во время выполнения. Грубо говоря, после первого запуска метода смотрится факт использования $result и этот факт запоминается. Выигрыш понятно единицы процентов, хотя можно придумать ситуацию, когда разница будет существенной. На тестовой странице Imprimatur I - расход памяти 8876кб - c оптимизацией, 9216кб - без нее. | ||
| moko | → Hexley [9] | 08.06.09 18:55 / 18:55 www.parser.ru → | ответить → | | |
Того, что ... | ||
| версия 3.4 сейчас в активной разработке? :) И еще вероятно с пару недель будет в таком состоянии? Так что пока 3.4 - для тех, кто хочет помочь разработчикам. Удивляться наличию ошибок в ней не стоит, а следует делать _bug.html. Примем с благодарностью, ошибка будет исправлена, код добавлен в копилку тестов. :) | ||
| Vint | → moko [11] | 08.06.09 19:02 www.parser.ru → | ответить → | | |
| locals - по-моему это совсем про другое. Ну как, locals делает все переменные локальными, получается, что и $result становится локальным (явно объявленным). Но понятно, что сам $result и объявленный result -- системные переменные, которые обрабатываются отдельно. Это я в качестве бреда подумал такое о locals:-) С остальным всё понятно. Спасибо, moko! | ||
| moko | → Vint [13] | 08.06.09 19:19 www.parser.ru → | ответить → | | |
| locals - на самом деле меняет механизм поиска переменных (упрощает процедуру). Что же касается декларирования, $result - автоматически заводится всегда. А его явная декларация - лишь указание компилятору включить режим оптимизации. | ||
| Vint | → moko [14] | 08.06.09 19:24 www.parser.ru → | ответить → | | |
Именно так и представлял, не считая "бредового" вопроса. Спасибо! | ||
| Hexley | → moko [12] | 08.06.09 20:35 www.parser.ru → | ответить → | | |
| ОК ) Буду параллельно вести версию своего проекта на parser3.4) | ||
| Misha v.3 | → Hexley [9] | 09.06.09 01:33 www.parser.ru → | ответить → | | |
когда речь идёт о head, собщайте дату/время получения вами исходников из cvs | ||
| в настоящее время там всё меняется почти каждый день и не все изменения всегда рабочие (и хотя обычно мы не коммитим то, что не проходит тесты, тесты не покрывают всего многообразия конструкций языка и соотв. иногда head версия может вести себя неадекватно в реальных условиях). | ||
| Саян | → moko [5] | 09.06.09 09:38 www.parser.ru → | ответить → | | |
А в exception подобная ситуация будет обернута? | ||
| Misha v.3 | → Саян [18] | 09.06.09 10:48 www.parser.ru → | ответить → | | |
боюсь, что это не представляется возможным | ||
| т.к. это runtime-оптимизация. для того, чтобы на этапе выполнения понять, есть ли в методе result или нет, надо выполнить все возможные ветки (а для этого, в общем случае, могут подребоваться иные данные). определение наличия явного присвоения result-у во время компиляции также полностью не решает проблему, т.к. кодер запросто может написать так: $name[result] $$name[значение] название переменной может придти извне, или кто-то может записать в result метода ($caller.result[...]). и без выполнения всех веток однозначно определить наличие в методе записи в result невозможно (соотв. и ругнуться невозможно). однако выигрыш от подобной оптимизации оказался существенным, поэтому мы решили пойти на некоторую ломку обратной совместимости, особенно учитывая тот факт, что с нашей точки зрения писать код, который иногда возвращает содержимое result, а иногда содержимое тела -- плохой стиль :) | ||
| Саян | → Misha v.3 [19] | 09.06.09 11:39 www.parser.ru → | ответить → | | |
Вариант | ||
| Если наличие $result определяется динамически после первой компиляции, то почему бы не сравнивать при следующих выполнениях факт обнаружения $result и результат, состоящий только из пробелов и табуляций (ситуация, описанная в начале топика), и при успешном сравнении создавать что-то вроде $debug_explicit_result_found[имя_оператора]? | ||
| Misha v.3 | → Саян [20] | 09.06.09 12:20 www.parser.ru → | ответить → | | |
тогда весь смысл оптимизации теряется | ||
| основная идея как раз в том, что если было обнаружено использование result, то при следующем вызове не накапливать эти пробелы, табуляции и прочий output, а просто игнорировать его, как ненужный. | ||
| Саян | → Misha v.3 [21] | 09.06.09 16:03 www.parser.ru → | ответить → | | |
Так ведь всё просто получается | ||
| 1) В какой-то момент определили наличие $result 2) Выполняем с оптимизацией 3) По окончании проверяем: result определен? Нет? Exception. | ||
| moko | → Саян [22] | 09.06.09 20:12 www.parser.ru → | ответить → | | |
Да, обсуждалось | ||
| И такое место есть см. метод result(), Проблема в том, что exception ухудшит совместимость. Сейчас в этом случае возвращается пустое значение, что сработает для всех случаев, когда $result просто забыли присвоить значение. Типа ^if($a){ $result[<$a>] } Случаи же когда умышленно делается ^if($a){ $result[<$a>] }{ <default>}- скорее исключение, поэтому и выбран вариант без exception. | ||
| Саян | → moko [23] | 11.06.09 22:41 www.parser.ru → | ответить → | | |
Эх, словит этот форум rtfm'ов... А чем @...[result] не устраивает? | ||
| Misha v.3 | → Саян [24] | 12.06.09 01:32 www.parser.ru → | ответить → | | |
rtfm :) почитайте, что делает объявление result-а локальным :) | ||
| Саян | → Misha v.3 [25] | 12.06.09 15:10 www.parser.ru → | ответить → | | |
А если оптимизацию явно определять таким же способом? @method[][optimized_result]? | ||
| Misha v.3 | → Саян [26] | 13.06.09 02:13 www.parser.ru → | ответить → | | |
рассматривали такой вариант | ||
| проблема в том, что для того, чтобы получить выигрыш в этом случае, надо открыть код и исправить кучу мест. понятно, что делать это никто не будет, т.е. оптимизации фактически нет :( | ||
| Саян | → Misha v.3 [27] | 13.06.09 08:13 www.parser.ru → | ответить → | | |
Я - исправлю | ||
| И все, кого интересует расход памяти - исправят, уверен. А кого не интересует - тому в принципе всё равно, будет оптимизация или нет. Неужели невидимая ошибка считается меньшим злом? | ||
| moko | → Саян [28] | 15.06.09 13:49 www.parser.ru → | ответить → | | |
пожалуйста. :) | ||
| >Неужели невидимая ошибка считается меньшим злом? В нашем коде мы пока даже не видели мест, где бы это привело к ошибке. Предупреждение скорее на всякий случай. Кому не нравится - может поправить исходники, например сделать #define CALL_OPTIMIZATION_DEBUG для поиска проблемных мест. :) | ||
| |||
 | |||