НКА должен пройти кросс-тесты от AT&T
Originally reported on Google Code with ID 86
Перевести в формат кросс-тестов тесты
http://www2.research.att.com/~gsf/testregex/testregex.html
Главным образом basic.dat - хотя возможно и некоторые другие: nullsubexpr, repetition
и надо посмотреть forcesassoc.
Reported by oasychev
on 2012-01-01 21:51:58
Comments (49)
-
reporter -
Вот описание одного из распространенных фейлов с подмасками. Есть регекс X(.?){2}Y и строка X1Y. Рисунок автомата приложен. В состояние 3 он приходит двумя путями: захватив последовательно "" и "1", и наоборот - "1" и "" в качестве подмаски. Индексы\длины (1,1) и (2,0) соответственно. Начинает работать worse_than и по leftmost-longest правилу выбирает, конечно, первый вариант. В тестах AT&T такой же регекс (только с 8 повторениями а не с 2, я уменьшил для простоты) склоняется в пользу второго варианта, и онлайн-матчеры (и для 8, и для 2 повторений) тоже. У Вилли упоминается repeating rule, но он неприменим: подмаска на обоих путях захвачена по 2 раза. Собственно, как решать проблему? Я пока не нашёл никакого формального описания кроме этого leftmost-longest правила.
Reported by
vostreltsov
on 2013-02-02 11:06:27<hr> * Attachment: subpatt_ambiguity.png<br>
-
reporter Subexpression rule: Subexpressions also match the longest possible substrings, subject to the constraint that the leftmost-longest rule must not be violated. Subexpressions starting earlier in the regular expression take priority over ones starting later. Note that higher-level subexpressions thus take priority over their lowerlevel component subexpressions(!!!). Matching an empty string is considered longer than no match at all. Обратите внимание на место, отмеченное восклицательными знаками. Там Вилли дальше это показывает на примере совпадения (a|a*)* со строкой аа: в силу приоритета подмаски над ее альтернативами как подвыражения, берется вариант по второй альтернативе чтобы подмаска совпала за один раз с обоими буквами и ее совпадение было longest. Наибольший приоритет у всего регекса, поэтому точка не захватывает Y; но у подмаски с квантификатором (.?){2} приоритет над внутренним содержимым и поэтому совпадение строится так, чтобы она захватила побольше (в AT&T и POSIX, PCRE - другой вариант) - longest. Точно также ведет себя тест с 8 вариантами - там захватывается последний символ, а не пустота. Тот же принцип longest с подмаской. А где вы в тестах AT&T увидели по другому? Поймите что подвыражение - вообще говоря не только подмаска...
Reported by
oasychev
on 2013-02-02 17:48:13 -
reporter В результате дискуссии было обнаружено, что с большой вероятностью стандарт POSIX проверят конкуренцию состояний по захвату одной и той же подмаски, а не попаданию в один и тот же узел автомата.
Reported by
oasychev
on 2013-02-02 19:01:24 -
TRE делает как и я на данный момент. Вот коммент из tre-match-parallel.c: /* Another path has also reached this state. We choose the winner by examining the tag values for both paths. */ Плюс ко всему, память Вилли выделяет заранее нужного размера, в начале функции матчинга.
Reported by
vostreltsov
on 2013-02-03 14:04:40 -
Я все больше склоняюсь к тому, что приоритеты переходов все-таки нужны. Если посмотреть на картинку из поста #2, то вот какие шаги будут на строке "X1Y": 1. Захватили X, и сразу с помощью eps-closure попали в 2 и 3. Находимся в состояниях 1, 2 и 3. 2.1 Сразу зафейлили переход 3-Y-4 по символу "1", остались состояния 1 и 2. 2.2 Перешли 2-.-3 именно по точке, она приоритетнее (при условии что обе ветки альтернативы мы совпали) 2.3 Перешли 1-.-2 опять по точке, и также оказались в состоянии 3 по eps-closure. Оказались: в состоянии 2 по пути 0-X-1-.-2 в состоянии 3 по пути 0-X-1-.-2-eps-3 в состоянии 3 по пути 0-X-1-eps-2-.-3 (этот путь должен проиграть, т.к. предыдущий вариант захватывал более приоритетную "." при переходе 1-.-2 Итого - состояния 2 и 3 после разрешения неопределенности. 3.1 Из состояния 2 уже не будет полного матча, его не рассматриваем 3.2 Из состояния 3 получаем full match. Нужно только придумать, как в коде заметить тот нюанс с выбором из двух путей до состояния 3 по предыдущему переходу. По идее, можно нумеровать все переходы слева-направо (конкатенация) и сверху-вниз (альтернатива), и если их N штук то внутри worse_than идти от 1 до N и смотреть, если первый вариант забрал текущее i, а другой нет, то второй хуже. Прошу проверить мои размышления и вообще правильность такого алгоритма.
Reported by
vostreltsov
on 2013-02-25 10:35:19 -
reporter На первый взгляд - неплохо. Чтобы проверить этот метод, надо еще проследить тоже самое для бесконечного квантификатора, когда есть цикл. В этом случае будут многократно проходится одни и те же дуги, а не разные, как в конечном квантификаторе. Но там и проблема может оказаться упрощенной, т.к. цикл не имеет минимального предела совпадений, который надо удовлетворить.
Reported by
oasychev
on 2013-02-25 12:28:15 -
А тут такой проблемы не будет в принципе. Даже если состояние перезапишется, то от старого что-то успеет форкнуться, т.к. пройдет минимум 1 шаг волны. Таким образом "пространство вариантов" из перебора не уменьшится.
Reported by
vostreltsov
on 2013-02-25 13:45:33 -
Интересное замечание со странички AT&T. The following examples examine replicated subexpressions. :RE#07:E (.?) x (0,1)(0,1) :RE#08:E (.?){1} x (0,1)(0,1) :RE#09:E (.?)(.?) x (0,1)(0,1)(1,1) :RE#10:E (.?){2} x (0,1)(1,1) :RE#11:E (.?)* x (0,1)(0,1) [D:6227-6234] specifies that RE#07 and RE#08 are equivalent, and that RE#09 and RE#10 are equivalent, and [D:6217-6219] specifies that RE#09 and RE#11 are equivalent. [D:6227-6234] When an ERE matching a single character or an ERE enclosed in parentheses is followed by an interval expression of the format "{m}" , "{m,}" , or "{m,n}" , together with that interval expression it shall match what repeated consecutive occurrences of the ERE would match. ... In RE#09 subexpression-1 matches (0,1), leaving the null string at (1,1) for subexpression-2. In RE#10 the first iteration of subexpression-1 matches (0,1), the same as subexpression-1 in RE#09, and the second iteration of subexpression-1 matches (1,1), the same as subexpression-2 in RE#09. ... Т.е. подмаска под квантификатором ведёт себя точно так же, как будто она бы была скопирована много раз подряд (RE#09 и RE#10 эквивалентны). Возможно, в переходы рядом с простыми тегами, обозначающими номера подмасок, нужно добавить дополнительные теги - номер копии этой подмаски, и аналогично отдавать приоритет по длине меньшим номерам.
Reported by
vostreltsov
on 2013-02-26 21:16:31 -
reporter Ну для конечного квантификатора это довольно логично. Он просто сокращенная форма записи копирования. Но ведет она себя так, как будто не просто скопирована, а к ней подставлено дублирование номеров подмасок. Потому как если просто скопировать будут разные подмаски, а под квантификатором - одна и та же... Заметьте что ответы на RE#09 и RE#10 все-таки разные по количеству подмасок. Вот про эквивалентность RE#09 and RE#11 я не понял. Разве что на этом конкретном тексте из одной буквы... Потому что при более 2-х букв они не эквивалентны.
Reported by
oasychev
on 2013-02-27 14:53:13 -
Реализовал очень сырую версию в учетом повторов. Прошли тесты: X{.?}{8}Y на строке "X1234567Y" - подмаска сброшена в пустоту (ab|a|c|bcd)+(d*) на строке "ababcd" - первой захвачено "bcd" (последовательно ab, a, bcd), второй - пустота. Меня смущает такой тест (в нотации AT&T): :HA#286:E (ab|a|c|bcd){1,10}(d*) ababcd (0,6)(3,6)(6,6) Почему оно утверждает, что 1 подмаска должна захватить "bcd"? Ведь это же фигурные скобки, последовательно должно захватываться ab, ab, c и потом d вообще уйти во 2 подмаску... Забавно, что онлайн-ereg считает так же, но TRE таки проходит этот тест:) Есть идеи по поводу этого?
Reported by
vostreltsov
on 2013-02-27 21:48:35 -
Смотрите, какой кусок кода я нашёл в TRE. tre-compile.c line 798 /* Expands each iteration node that has a finite nonzero minimum or maximum iteration count to a catenated sequence of copies of the node. */ static reg_errcode_t tre_expand_ast(tre_mem_t mem, tre_stack_t *stack, tre_ast_node_t *ast, int *position, tre_tag_direction_t *tag_directions, int *max_depth) ... /* Remove tags from all but the last copy. */ Что можно получить путем удаления тегов отовсюду, кроме последнего повторения?
Reported by
vostreltsov
on 2013-03-01 16:38:25 -
Записываю сюда ещё один полезный коммент, найденный там же. /* If we find a previous transition from `p1->position' to `p2->position', it is overwritten. This can happen only if there are nested loops in the regexp, like in "((a)*)*". In POSIX.2 repetition using the outer loop is always preferred over using the inner loop. Therefore the transition for the inner loop is useless and can be thrown away. */
Reported by
vostreltsov
on 2013-03-01 16:47:35 -
Вообще, тот пример из диссера Вилли с деревом подсказывает, что теги нужно создавать для вообще всех поддеревьев, а не только для подмасок. А для помасок дополнительно указывать что это именно подмаска. На константную модель памяти это натягивается, единственное что тегов будет слишком много.
Reported by
vostreltsov
on 2013-03-01 18:03:25 -
reporter >Что можно получить путем удаления тегов отовсюду, кроме последнего повторения? Захват только последнего повторения, я полагаю. Нам такой вариант не подходит, поскольку Вилли интересуют только полные совпадения, а нас - и частичные, а они могут прерываться посреди какого-то не последнего повторения. >Вообще, тот пример из диссера Вилли с деревом подсказывает, что теги нужно создавать >для вообще всех поддеревьев... Я думаю все же не для всех. Можно сформулировать условия, при которых они необходимы, чтобы их было все же не "слишком" много. Не так уж часто это и бывает нужно...
Reported by
oasychev
on 2013-03-02 18:14:51 -
У нас какая-то магия с ассоциативностью конкатенации. Приложены деревья для abc и (a)(b)(c)
Reported by
vostreltsov
on 2013-03-03 08:04:10<hr> * Attachment: assoc1.png<br>
* Attachment: assoc2.png<br>
-
Эту ситуацию я пофиксил, сделав преобразование всего дерева после парсинга. Может быть, имеет смысл сделать конкатенации и альтернативы n-арными? Это значительно уменьшит количество поддеревьев\тегов.
Reported by
vostreltsov
on 2013-03-03 11:38:50 -
reporter А как это отразится на приоритетах? Я за уменьшение тегов путем вывода условий, при которых они имеют смысл. Изложение такого вывода - неплохой раздел диплома, можно сразу текстом записывать...
Reported by
oasychev
on 2013-03-03 15:57:58 -
На приоритетах никак не отразится, если продолжать нумеровать от левого операнда к правому.
Reported by
vostreltsov
on 2013-03-03 16:19:26 -
Немного полезных ссылок: http://www2.research.att.com/~gsf/testregex/re-interpretation.html http://www.open-std.org/JTC1/SC22/WG15/docs/rr/9945-2/9945-2-135.html http://www.open-std.org/JTC1/SC22/WG15/docs/rr/9945-2/9945-2-43.html tre фейлит несколько тестов: http://xmlfy.sourceforge.net/testresults/t_xmlfy_tre.html
Reported by
vostreltsov
on 2013-03-03 16:31:33 -
Вот что я узнал после детального изучения at&t статьи. Во-первых, важно заключение статьи: That key sentence is a precise and consistent definition for the term subpattern. By noting the relationship between subpatterns and subexpressions, the proposed definition is shown to be the only one that can be consistent with all parts of the standard. Далее, определения что такое subexpression и что такое subpattern. A subexpression corresponds to the Back_open_paren RE_expression Back_close_paren form of the nondupl_RE BRE grammar production or the '(' extended_reg_exp ')' form of the ERE_expression ERE grammar production. Subexpression i begins at the ith matched open parenthesis (Back_open_paren for BREs and '(' for EREs), starting from the left and counting from 1. Subexpression 0 is the entire RE. A subpattern corresponds to the simple_RE nonterminal in the BRE grammar or the ERE_expression nonterminal in the ERE grammar. И, наконец, грамматика ERE. %token ORD_CHAR QUOTED_CHAR DUP_COUNT %start extended_reg_exp %% /* -------------------------------------------- Extended Regular Expression -------------------------------------------- */ extended_reg_exp : ERE_branch | extended_reg_exp '|' ERE_branch ; ERE_branch : ERE_expression | ERE_branch ERE_expression ; ERE_expression : one_character_ERE | '^' | '$' | '(' extended_reg_exp ')' | ERE_expression ERE_dupl_symbol ; one_character_ERE : ORD_CHAR | QUOTED_CHAR | '.' | bracket_expression ; ERE_dupl_symbol : '*' | '+' | '?' | '{' DUP_COUNT '}' | '{' DUP_COUNT ',' '}' | '{' DUP_COUNT ',' DUP_COUNT '}' ; Поэтому под subpattern может пониматься: "a", "(a)", "(a)*" или "(a){m,n}". А под subexpression только и только "(a)". И примеры, иллюстрирующие это. RE#19, RE#20 and RE#21 examine the relationship between subexpression and subpattern: :RE#19:E a?((ab)?)(b?) ab (0,2)(1,1)(?,?)(1,2) :RE#20:E (a?)((ab)?)b? ab (0,2)(0,1)(1,1)(?,?) :RE#21:E a?((ab)?)b? ab (0,2)(1,1)(?,?) These are all variations of RE#04. Other than subexpression renumbering, the match for the subexpression ((ab)?) must be the same in RE#04, RE#19, RE#20 and RE#21. a? is a subpattern in RE#19 and RE#21, of equal matching importance to (a?) in RE#04, and b? is a subpattern in RE#20 and RE#21, of equal matching importance to (b?) in RE#04.
Reported by
vostreltsov
on 2013-03-03 19:00:31 -
По поводу квантификаторов. Извиняюсь за большую копипасту, но чтобы тесты были под рукой. RE#23 through RE#27 expose implementations that sometimes do first match for alternation within subexpressions. Some implementations erroneously match the first iteration of subexpression-1 in RE#24 through RE#27 to (0,1). RE#27 is equivalent to RE#26; the match requires two iterations, the first matching (0,2) and the last matching (2,3). :RE#23:E (ab?)(b?a) aba (0,3)(0,2)(2,3) :RE#24:E (a|ab)(ba|a) aba (0,3)(0,2)(2,3) :RE#25:E (a|ab|ba) aba (0,2)(0,2) :RE#26:E (a|ab|ba)(a|ab|ba) aba (0,3)(0,2)(2,3) :RE#27:E (a|ab|ba)* aba (0,3)(2,3) RE#28 through RE#33 expose implementations that report short matches for some repeated subexpressions. Some implementations report incorrect matches for subexpression-1 in RE#30 and RE#33. :RE#28:E (aba|a*b) ababa (0,3)(0,3) :RE#29:E (aba|a*b)(aba|a*b) ababa (0,5)(0,2)(2,5) :RE#30:E (aba|a*b)* ababa (0,5)(2,5) :RE#31:E (aba|ab|a) ababa (0,3)(0,3) :RE#32:E (aba|ab|a)(aba|ab|a) ababa (0,5)(0,2)(2,5) :RE#33:E (aba|ab|a)* ababa (0,5)(2,5) RE#34 through RE#36 expose implementations that report subexpression matches for earlier iterations of the subexpression. Some implementations report a match for subexpression-2 in RE#36 while reporting the (2,3) match for subexpression-1: clearly a bug. :RE#34:E (a(b)?) aba (0,2)(0,2)(1,2) :RE#35:E (a(b)?)(a(b)?) aba (0,3)(0,2)(1,2)(2,3)(?,?) :RE#36:E (a(b)?)+ aba (0,3)(2,3)(?,?) RE#39 through RE#41 expose implementations that treat explicit vs. implicit subexpression repetition differently. This is a theme common to many of the previous examples. Again, the subexpression in RE#41 requires two iterations to match, and the second iteration matches (5,7), as illustrated by RE#40. :RE#39:E (a.*z|b.*y) azbazby (0,5)(0,5) :RE#40:E (a.*z|b.*y)(a.*z|b.*y) azbazby (0,7)(0,5)(5,7) :RE#41:E (a.*z|b.*y)* azbazby (0,7)(5,7) 26,27,34,35,36,40,41 явно показывает приоритет первых итераций над последующими.
Reported by
vostreltsov
on 2013-03-04 16:37:08 - Status changed:InProgress
-
Рад сообщить, что тесты от AT&T, не содержащие обратных ссылок, пройдены. Из всего набора пропущены 5 тестов с обратными ссылками и 4 с ленивыми квантификаторами. Я планирую сделать теперь другой метод поиска, но уже без таких оптимизаций. Как было написано в коде Вилли: "This can be rather slow, but I console myself with the thought that people who use \<digit> deserve very slow execution." :)
Reported by
vostreltsov
on 2013-03-05 16:31:57 -
reporter "Я планирую сделать теперь другой метод поиска, но уже без таких оптимизаций." - расшифруйте пожалуйста. Другой метод чего и он насколько он будет дополнять или заменять существующий... И в каком смысле "пропущены" - в смысле не пройдены или обратные ссылки теперь аццептинг откидывает?
Reported by
oasychev
on 2013-03-07 10:09:10 -
Метод поиска, очевидно. Без константной памяти. Пропущены - откинуты аксептингом. Временно закомментировал поддержку обратных ссылок.
Reported by
vostreltsov
on 2013-03-07 13:41:17 -
Текущее прохождение тестов. Два файлика: все и только AT&T тесты.
Reported by
vostreltsov
on 2013-03-08 18:33:09<hr> * Attachment: test_all * Attachment: test_att_only
-
-
reporter Не забыть решить вопрос - должны ли включаться в ответ частично совпавшие подмаски или нет... См. первый фейл в предыдущем тесте.
Reported by
oasychev
on 2013-03-08 21:28:59 -
-
Реализовал PCRE-совместимость. Посмотрите на фейл data_for_test_back_reference_in_quantifier_in_subexpression_in_quantifier Мне кажется, там ошибка, индекс должен быть 0.
Reported by
vostreltsov
on 2013-03-20 13:04:31<hr> * Attachment: test_all_3
-
Пофиксил проблему с возвратом частично совпавших подвыражений. Там есть такой тест: "(.*X|^B)" на строке "abcde\n1234Xyz". Он фейлится, но при удалении первых символов включая \n проходит. Мне кажется, там что-то за пределами НКА не так, поскольку этот внешний цикл вынесен в общий код.
Reported by
vostreltsov
on 2013-03-20 15:19:18<hr> * Attachment: test_all_4
-
Для меня также остаются непонятными некоторые фейлы из interpretation.dat, хотя я вроде бы досконально понял статью и все остальные at&t тесты сейчас проходят. Например: nfa_matcher failed on regex '(a*)*b\1*' and string 'ab' (qtype_preg_cross_tests_from_att_interpretation, data_for_test_att_interpretation_48) INDEX_FIRST: 0=>0, 1=>0, expected: INDEX_FIRST: 0=>0, 1=>1, nfa_matcher failed on regex '(a*)*b\1*' and string 'ab' (qtype_preg_cross_tests_from_att_interpretation, data_for_test_att_interpretation_48) LENGTH: 0=>2, 1=>1, expected: LENGTH: 0=>2, 1=>0, По идее, то, как матчер возвратил результат, является более корректным ответом. Приоритетнее пустоту отдать обратной ссылке, нежели и ей, и подвыражению. Такое ощущение, что при достижении \1 он делает возврат на подвыражение, делает его нулевым, и потом заново пытается сматчить \1. А если бы и так не получилось, тогда уже пропустил бы и обратную ссылку. Вы здесь видите какую-то логику действий?
Reported by
vostreltsov
on 2013-03-20 19:37:46 -
reporter Пока отвечу на комментарий 31. У нас давно тянется проблема с тестами что узлы не обрабатывают перевод строки - \n. В частности крышка и доллар. Непосредственно в вопросе всегда вводится одна строка, а вот в тестах бывает всякое. Это в узлах ассертов. Можно и доделать - по идее это не сложно.... По комменту 30 - на который из фейлов? Их там много. Копируйте уж весь фейл...
Reported by
oasychev
on 2013-03-21 15:23:55 -
31: так там ведь нет ассерта. Там есть метаточка, которая не совпадает с \n. Я только что нашел истинную проблему. Оно считает .* якорем... Строка априори неизвестна, так что предлагаю убрать .* из якорения, эта ситуация довольно редкая, но тесты будут проходить.
Reported by
vostreltsov
on 2013-03-21 15:42:26 -
reporter 31: а крышка перед B тогда что - не ассерт? В любом случае проблема есть с обработкой \n и она не сводится к якорению. Там с его "съеданием" большие проблемы возникнут, т.к. его игнорируют обычные символы в конкатенации.... Я не против развить якорение, дописав проверку на наличие \n - но вы возьметесь за проблему с его матчингом (точнее матчингом символов после него)? Если уж делать поддержку - так полностью.... Если хотите - заводите отдельное issue для поддержки переводов строки.
Reported by
oasychev
on 2013-03-21 15:46:26 -
reporter 32: там нет ошибки в конвертации? вот, что я вижу в найденном мной файле https://github.com/dslab-epfl/cloud9-uclibc/blob/master/test/regex/interpretation.dat \(a*\)b\1* ab (0,2)(0,1) Т.е. именно так, как сработал матчер...
Reported by
oasychev
on 2013-03-24 18:46:35 -
reporter А, у вас еще номера сбиты. Нас интересует тест 49 \(a*\)*b\1* ab (0,2)(1,1)
Reported by
oasychev
on 2013-03-24 19:07:25 -
reporter Вы говорите, что остальные тесты проходят. А вот разница между похожими тестами не на какие мысли не наводит? 53-й регекс проходит нормально? Он эквивалентен приведенному вами, кроме второго захвата, но квантификатор эквивалентен в интерпретации скобкам в том плане, что учитывается как подвыражение если я правильно помню... :RE#52:B \(a*\)b\(\1\)* ab (0,2)(0,1)(?,?) :RE#53:B \(a*\)*b\(\1\)* ab (0,2)(1,1)(2,2)
Reported by
oasychev
on 2013-03-24 19:53:15 -
Сделал простенькую реализацию ленивых квантификаторов, все тесты AT&T пройдены (кроме interpretation).
Reported by
vostreltsov
on 2013-03-29 06:41:49 -
Посмотрите на появившийся фейл: nfa_matcher failed on regex '(([a-c])b*?\2)*' and string 'ababbbcbc' (qtype_preg_cross_tests_from_pcre, data_for_test_character_class_in_subexpression_and_lazy_quantifier_and_back_reference_in_subexpression_in_quantifier) INDEX_FIRST: 0=>0, 1=>-1, 2=>-1, expected: INDEX_FIRST: 0=>0, 1=>3, 2=>3, nfa_matcher failed on regex '(([a-c])b*?\2)*' and string 'ababbbcbc' (qtype_preg_cross_tests_from_pcre, data_for_test_character_class_in_subexpression_and_lazy_quantifier_and_back_reference_in_subexpression_in_quantifier) LENGTH: 0=>0, 1=>-1, 2=>-1, expected: LENGTH: 0=>5, 1=>2, 2=>1, Сейчас ленивость сделана так: помимо curstates есть еще lazystates, которые заполняются в процессе полны, но начинают использоваться в самом конце при условии, что нет полного совпадения. Пример хитрый: внутренний квантификатор ленивый, а внешний - нет, поэтому должно быть захвачено именно ababb, а не aba. Фейл вызван внешним квантификатором: к моменту использования lazystates уже есть полное совпадение нулевой длины, поэтому lazystates не рассматриваются. Но текущая реализация будет работать в 99.9% случаев, я добавил несколько тестов в tests_from_preg.
Reported by
vostreltsov
on 2013-03-29 18:23:08<hr> * Attachment: test_all_5
-
reporter А почему они не рассматриваются, если потенциально могут дать совпадение большей длины? Мы же к longest должны стремиться?
Reported by
oasychev
on 2013-03-29 18:34:14 -
Если стремиться к longest, то "сверху вниз" - тогда захватятся 9 символов. Иначе я не знаю как к нему стремиться...
Reported by
vostreltsov
on 2013-03-29 18:40:37 -
Несмотря на то, что AT&T теперь пройдены полностью, появилась куча фейлов с ленивыми pcre-квантификаторами.
Reported by
vostreltsov
on 2013-04-13 17:10:52<hr> * Attachment: test_all_6
-
reporter По итогам разговора текущие проблемы средней сложности для решения в ближайшее время: а) ленивые квантификаторы по PCRE через корректную последовательность перебора "ленивых состояний" б) не считать совпавшие подмаски мертво фиксированными при генерации продолжения, если на них есть обратные ссылки - иногда можно получить меньший left перегенерировав их в) сделать наконец поддержку nullable подмасок в PCRE-режиме г) #191 (Сычев) и соответствующие изменения в кросс-тестере (Стрельцов) д) #188 Ну и проблема большей сложности, когда будет больше времени: еклмн;) мержинг \b в автомат
Reported by
oasychev
on 2013-04-13 18:42:35 -
reporter Проблема с тестами interpretation.dat 49 и аналогичными возможно решается тем, что подмаски не могут быть вложенными.
Reported by
oasychev
on 2013-05-26 20:25:12 -
Эти тесты, наконец, пройдены.
Reported by
vostreltsov
on 2013-06-27 17:57:55 - Status changed:Fixed
-
reporter Поставлю в Done когда пофиксятся регрессии в других тестах, вызванные этой правкой.
Reported by
oasychev
on 2013-07-04 13:35:40 -
Вроде бы регрессии устранены.
Reported by
vostreltsov
on 2013-07-11 08:46:39 -
Reported by
vostreltsov
on 2014-12-04 18:36:12 - Status changed:Done
- Log in to comment
``` Теперь, когда кросс-тесты добавлены, можно заняться их анализом и совершенствованием матчера.
Замечание по стиранию совпадения с подмасками при повторном прохождении через них: PCRE так себя не ведет, она сохраняет значение. Я думаю, надо будет реализовать настройку через $CFG - стирать или не стирать - а в кросс-тестере сделать "категоризацию", аналогичную правой и левой ассоциативности - т.е. будут тесты с ответами на сохранение и не сохранение.
```
Reported by `oasychev` on 2012-09-23 21:44:41