Доработка кросс-тестера

Oleg Sychev reporter

``` Следующий символ продолжаем проверять - к чему терять полезные проверки? Теперь используем функцию string_extension() которая должна дать добавленную часть строки (вызывается на основном объекте, посмотрите preg_hints.php), а из нее - первый символ (если есть).

Кроме того, нужно взять extendedmatch->str() и проверить что она дает частичное совпадение на этом (и других? или лучше как раз на другом?) матчере (а если оно full - то полное совпадение на php_preg матчере как эталонном варианте). ```

Reported by `oasychev` on 2012-01-29 20:26:41 - Labels added: Milestone-Release2.2, Component-Preg

2012-01-29T20:26:41+00:00

Oleg Sychev reporter

``` Проверку мачтеров организуем следующим образом: заводим поля:

$fullmatchreferencematcher - этот матчер через PHP, используется при проверке генерации полного совпадения

$partialmatchreferencematcher - матчер, используемый для проверки генерации символов если в результате совпадение осталось частичным. Пока делаем его равным проверяемому матчеру. Когда оба матчера будут восстановлены, сделать еще 2 php файла где другой матчер будет использоваться как проверяющий - могу вскрыться дополнительные проблемы... ```

Reported by `oasychev` on 2012-01-29 20:46:10

2012-01-29T20:46:10+00:00

Oleg Sychev reporter

``` Еще нужно сделать проверку left. Грубо говоря (extensionstart-index_first[0])+left должно быть одинаковым в обоих объектах (основном и с подсказкой). Т.е. если мы добавили 4 символа, то left должно уменьшится на 4.

Сложная формула проверки вызвана тем что мы не знаем, удалил ли матчер несовпадающее начало при генерации подсказки... ```

Reported by `oasychev` on 2012-01-29 20:48:43

2012-01-29T20:48:43+00:00

Oleg Sychev reporter

``` Ваш extra_checker проверяет is_supporting класса? По идее он должен реагировать на PARTIAL_MATCHING - если возвращается ложь (как у php_preg_matcher), то следует передавать для проверки только полные совпадения (мало ли что вернут какие матчеры), если истина - всегда...

И я кажется просил не реализовывать новый интерфейс для узлов в matching_results - только в своем наследнике. ```

Reported by `oasychev` on 2012-02-11 16:39:50

2012-02-11T16:39:50+00:00

Valeriy Streltsov

``` Я сделал немного по-другому: каждое частичное совпадение обрабатывается всеми матчерами (при наличии сгенерированного продолжения). Для стандартного матчера исключение - он вызывается только при полном совпадении в extendedmatch.

Все эти вызовы и проверки делаются внутри кросс-тестера, новый класс даёт только имя доступного матчера. ```

Reported by `vostreltsov` on 2012-02-11 16:48:35

2012-02-11T16:48:35+00:00

Oleg Sychev reporter

``` Я бы предпочел не хардкодить предполагаемые свойства матчеров, а использовать is_supporting. Может появиться еще один матчер использующий стороннюю библиотеку (ну например с другим синтаксисом чем PCRE) например. И т.д. Эти константы - универсальный способ определения способностей матчера в вопросах... ```

Reported by `oasychev` on 2012-02-11 18:07:45

2012-02-11T18:07:45+00:00

Oleg Sychev reporter

``` Еще - я так понимаю, у вас теперь все проверки проходят всегда? Индексы проверяются даже если ложна is_match?

Я бы уж если is_match ложная, то проверял индексы по константам (или сравнивал с инвалидизированным совпадением). Чтобы не править тесты если изменится формат хранения данных о несовпадении... ```

Reported by `oasychev` on 2012-02-11 20:56:42

2012-02-11T20:56:42+00:00

Oleg Sychev reporter

``` Валерий, так мы перешли на is_supporting? И обработку ложного is_match? ```

Reported by `oasychev` on 2012-04-05 15:34:27

2012-04-05T15:34:27+00:00

Valeriy Streltsov

``` Сделано. ```

Reported by `vostreltsov` on 2012-06-08 16:06:43 - Status changed: `Fixed`

2012-06-08T16:06:43+00:00

Oleg Sychev reporter

``` Есть функция array_fill, зачем писать отдельную функцию/цикл заполнения?! ```

Reported by `oasychev` on 2012-06-09 12:52:52

2012-06-09T12:52:52+00:00

Valeriy Streltsov

``` Исправил ```

Reported by `vostreltsov` on 2012-06-09 13:09:40

2012-06-09T13:09:40+00:00

Oleg Sychev reporter

``` Давайте уж не заводить нового раз это не закрыли.

Текущие доделки: 1) определение параметров матчинга - по идее ИМХО наилучший вариант будет сделать специальный вид данных, в которых при вариантах ответа(совпадения) указываются теги. Можно использовать их как ключи. Такие тесты будут двух видов: одни определять возможности матчера и активировать соответствующий тег. А другие - использовать тег чтобы выбрать, какой именно вариант ответа должен совпадать при соответствующем теге. Это несложно сделать и это надежнее, т.к. не сломается даже если мы перепишем абстрактный матчер на другие свойства 2) если есть исключения (несматченный сканером ввод) или ошибки сканинга/парсинга, они должны выводится с указанием того, к какому тесту относятся; лучше всего выводить ошибки тем же манером, что и на форму при редактировании вопроса...

```

Reported by `oasychev` on 2012-07-19 15:38:48 - Status changed: `InProgress`

2012-07-19T15:38:48+00:00

Oleg Sychev reporter

``` К регулярному выражению следует добавить поле notation. Если не указано - использовать native - чтобы не мучить существующие тесты...

Чтобы упростить всю эту работу, следует использовать функцию get_matcher из объекта вопроса - можно создать пустой вопрос. Она уже все это учитывать умеет и сократит код кросс-тестера... Посмотрите на нее... ```

Reported by `oasychev` on 2012-07-20 17:45:29

2012-07-20T17:45:29+00:00

Oleg Sychev reporter

``` Только если не изнутри вопроса - $answerid делать null. По нему кэш идет, а в тестах слишком много регексов для кеширования.... ```

Reported by `oasychev` on 2012-07-20 17:53:41

2012-07-20T17:53:41+00:00

Oleg Sychev reporter

``` Доделать: 3)left и next не задавать вообще если совпадение полное 4)теги могут быть у регексов, а могут у строк. дублировать одинаковые для каждой строки не надо.

```

Reported by `oasychev` on 2012-07-23 09:12:02

2012-07-23T09:12:02+00:00

Valeriy Streltsov

``` 2, 3, 4 и get_matcher с нотациями сделал, у меня 2 вопроса:

а) нельзя ли в get_matcher передавать $modifiers, а не $usecase? Я предлагаю сделать вообще маленький класс модификаторов, в котором будет не только регистрочувствительность. Его объекты также агрегировать и в узлы для локальных модификаторов.

б) по поводу 1) - я не совсем понял вашу идею, но есть еще мое предложение: в кросс-тестере сделать функцию, определяющую какие теги какой матчер поддерживает, типа как is_supporting, но в кросс-тестере... Таких тегов по идее не особо много (2 ассоциативности, ленивость квантификатора, больше пока не знаю), функция будет не очень большой. ```

Reported by `vostreltsov` on 2012-07-26 09:42:47

2012-07-26T09:42:47+00:00

Oleg Sychev reporter

``` а) код работы с модификаторами должен лежать внутри get_matcher чтобы определение, какие модификаторы нужны при каких параметрах вопроса не дублировалось по всем местам, где оно вызывается. Как раз роль get_matcher - перейти от терминов вопроса к терминам матчера, централизовать этот код. В принципе я не вижу проблем с тем чтобы сделать класс для модификаторов и не меняя параметров get_matcher. Правда необходимости особой, честно говоря, тоже - есть проблемы поважнее.

б) я имел ввиду определять теги так, как это делает AT&T - через запуск определенных тестов и анализ результатов. Это удобнее, чем прописывать их в матчере напрямую - будет меньше расхождений теории с практикой. У них же можно часть тегов и взять... ```

Reported by `oasychev` on 2012-07-27 07:55:03

2012-07-27T07:55:03+00:00

Oleg Sychev reporter

``` 5) в AT&T есть тест с очень большим числом в квантификаторе. Он по идее должен дать ошибку слишком большого регекса. Но ее уже генерирует матчер. Куда его прописать - надо или спец. файл заводить, или в кросс-тестер добавлять возможность - ожидать такую-то ошибку....

6) я также думаю очень полезным будет возможность вставлять в описание строки или регекса флажок, говоряющий кросс-тестеру отладочно распечатать результаты матчинга для этого теста. Чтобы можно было вставлять при отладке, а то печатать по всем тестам неинтересно как-то... ```

Reported by `oasychev` on 2012-07-27 12:14:17

2012-07-27T12:14:17+00:00

Valeriy Streltsov

``` Сделал 1) - теперь можно указывать аргумент -c при запуске тестов матчеров, например: phpunit .../matcher_nfa_test.php -c Только нужно смотреть, чтобы в php.ini было включено argv и argc.

В этом случае оно запустит один тест из categorize, посмотрит совпало left или right, запустит соответствующие тесты с нужными тегами из assoc. Если не совпало left и right - скажет что ошибка и прекратит работу. ```

Reported by `vostreltsov` on 2012-08-02 08:56:40

2012-08-02T08:56:40+00:00

Oleg Sychev reporter

``` 1) Я не понял, зачем это делать именно по ключу? По идее это самая естественная вещь: вызвать спец. тест из категоризации, понять какой тег соответствует матчеру - и потом игнорировать тесты с другим тегом (т.е. если совпал left то результаты с right попросту пропускаем...)

2) Еще, может нам теперь не ассертами проверять условия, а просто условными операторами? И печатать сообщение о том на каком тесте и что не так, плюс выставлять флажок наличия ошибки. А в конце сделать assertFalse(флаг наличия ошибки) - чтобы провалить тест при наличии хоть одной. Так мы даже при ПХПЮните получим провалы многих кросс-тестов.... ```

Reported by `oasychev` on 2012-08-09 16:55:25

2012-08-09T16:55:25+00:00

Valeriy Streltsov

``` Убрал запуск с аргументов, с категоризацией всё нормально. Ассерты поменял на условия, добавил свой счетчик пассов и фейлов пар регекс-строка. В конце показывается сколько пассов и фейлов было. Ассерт в конце не делал, он сбивает с толку лишней ненужной информацией. Имхо, значений счетчиков достаточно... В опции хэндлинга добавил поле debugmode, оно также заполняется кросс-тестером. Соответствующий тег добавил. ```

Reported by `vostreltsov` on 2012-08-30 06:33:25 - Status changed: `Fixed`

2012-08-30T06:33:25+00:00

Oleg Sychev reporter

Очередной раунд (не срочно, пока записываю чтобы не забыть):
существует ряд вопросов интерпретации подмасок, в которых тесты от AT&T и PCRE расходятся.
В этом случае следует сделать категоризацию, похожую на ту, которая есть с ассоциативностью
подмасок.

Надо разобраться в том, одинаково ли реагируют библиотеки на следующие ситуации:
1)Должно ли быть совпадение со второй подмаской в следующем примере: 
выражение ((a)|b){2}
строка ab
2)Если подмаска допускает пустое совпадение и стоит под квантификатором, позволяющим
лишние совпадения, считать ли захваченным последнее непустое совпадение или брать пустой
вариант (PCRE явно следует версии пустого совпадения последним).

Reported by oasychev on 2012-11-10 18:45:38 - Status changed: InProgress

2012-11-10T18:45:38+00:00

Valeriy Streltsov

#22 пофикшено, записываю сюда задачу сделать ключи index_first_ext и length_ext для
проверки индексов, отличных от индексов основного объекта.

Reported by vostreltsov on 2013-05-19 17:58:49

2013-05-19T17:58:49+00:00

Oleg Sychev reporter

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

Reported by oasychev on 2013-06-28 14:54:08

2013-06-28T14:54:08+00:00

Oleg Sychev reporter

Если окажется, что необходимая для нашего вопроса стратегия выбора совпадения отличается
от принятой в стандартах (и их тестах), то можно поступить так.

После релиза ввести в опции матчинга поле matchinggoal, которое может принимать значения
типа LEFTMOST_LONGEST, LONGEST и т.д. и определяет используемую стратегию матчинга;
а в кросс-тестах если тест дает разные ответы в разных стратегиях, может задаваться
массив ответов где ключами являются стратегии.

Reported by oasychev on 2013-09-05 18:13:35

2013-09-05T18:13:35+00:00

Oleg Sychev reporter

Валерий, вы посмотрели на future_tests_dfa прежде чем его удалять?
Мне кажется тамошние тесты вполне заслуживают переноса в кросс-тесты....

Reported by oasychev on 2013-11-02 23:23:52

2013-11-02T23:23:52+00:00

Oleg Sychev reporter

Текущие моменты доработки кросс-тестера
1) ввести систему контроля производительности - чтобы можно было задать параметр (через
командную строку или константой, лучше первое) - время и чтобы кросс-тестер выводил
какие тесты выполняются дольше этого времени; может быть весьма полезно при анализе
в каких ситуациях алгоритмы тормозят
2) сделать особый вывод next для случаев END_THERE и других подобных констант

И то и другое дело пустяковое, а пользы много.

Reported by oasychev on 2014-03-30 21:22:31

2014-03-30T21:22:31+00:00

Valeriy Streltsov

1) сделал
2) нужно доделывать matching results. константы не идут дальше защищенных функций матчера

Reported by vostreltsov on 2014-04-05 10:11:39

2014-04-05T10:11:39+00:00

Oleg Sychev reporter

2) получается нам нужно главным образом четко решить, что будет в $extendedmatch в случае,
если совпадение вообще сгенерировать нельзя. null - возможно, но много проверок добавлять
придется? или объект с каким-то спец. полями?

И получается что в противном случае - если next пустой, но совпадение есть - достаточно
вывести надпись что продолжать не надо? Я так понимаю тестов на регексы, с которыми
ничего совпасть не может в принципе, у нас пока нет? Если так, то сделать надпись можно
- просто условие что совпадение не полное и next - пустой (т.е. сгенерированный вариант
обрывается раньше, чем исходная строка, и совпадает с ее началом).

Reported by oasychev on 2014-04-05 16:28:45

2014-04-05T16:28:45+00:00

Oleg Sychev reporter

Нужен настроечный тег (типа at&t/pcre) с двумя значениями, так чтобы в зависимости от
него применялись разные index_first/length (если в тесте возвращается две разных).
Первый вариант тега - когда если облом совпадения на ассерте, то он считается в точке
ассерта (как в PCRE, так что можно TAG_ASSERT_FAIL_PCRE), второй - в точке куда смержился
ассерт (TAG_ASSERT_FAIL_MERGE) - это у Лены. Сделать один тест для примера Лене как
возвращать, остальные она сконвертить может.

Reported by oasychev on 2014-11-22 16:30:43

2014-11-22T16:30:43+00:00

Oleg Sychev reporter

Я не совсем понял ваше применение тегов. У вас получается, что на каждый тест где есть
разница по этому тегу надо создавать две функции. Будет дублирование кода приличное.

Я думал, что функция теста сможет возвращать по два значения length (и возможно index_first),
а кросс-тестер по установленному тегу будет выбирать какое из них юзать.

Reported by oasychev on 2014-11-22 21:58:54

2014-11-22T21:58:54+00:00

Oleg Sychev reporter

Настройку сделал, доделывайте кросс-тестер и в матчере эту настройку...

Reported by oasychev on 2014-11-22 22:24:30

2014-11-22T22:24:30+00:00

Valeriy Streltsov

Предлагаю больше не использовать в кросс-тестере get_matcher. Нотации оно больше не
конвертирует, опции полностью правильные тоже не выставляет (debug, extensionneeded
задаются через теги). Пробрасывать mergeassertions через $CFG тоже как-то странно,
когда всё можно сделать напрямую.

Кстати, поле mergeassertions в опциях булевое, а вы в get_matcher приравняли к нему
вроде как строковое значение из $CFG.

Reported by vostreltsov on 2014-11-30 14:47:27

2014-11-30T14:47:27+00:00

Comments (33)