Пересчение автоматов

[GoogleCodeExporter]

Олег Александрович, а может, мне стоит пока 
попробовать начать работать над 
пересечением? Просто в начале семестра 
должно быть посвободней, а то я опять упущу 
удобное время. Тем более, что я хочу, чтобы 
частично пересечение автоматов вошло в 
диплом.

Original issue reported on code.google.com by eklepilkina@gmail.com on 9 Feb 2015 at 8:02

[GoogleCodeExporter]

Можно в отдельном клоне, но только если с 
остальными проблемами простой. Не 
забывайте напоминать Валере.

Нам перед релизом надо как можно чаще 
смотреть фейлы вместе. +4 фейла от обратных 
ссылок в частности, и \b которые. Я в среду 
после занятий Насте назначил, вы сможете 
подойти? Посмотрим имеющиеся фейлы, 
разберемся кто виноват...

Original comment by oasyc...@gmail.com on 9 Feb 2015 at 11:46

[GoogleCodeExporter]

Можно в отдельном клоне, но только если с 
остальными проблемами простой. Не 
забывайте напоминать Валере.

Нам перед релизом надо как можно чаще 
смотреть фейлы вместе. +4 фейла от обратных 
ссылок в частности, и \b которые. Я в среду 
после занятий Насте назначил, вы сможете 
подойти? Посмотрим имеющиеся фейлы, 
разберемся кто виноват...

Original comment by oasyc...@gmail.com on 9 Feb 2015 at 11:46

[GoogleCodeExporter]

Ну если надо, подойду.

Original comment by eklepilkina@gmail.com on 10 Feb 2015 at 8:30

[GoogleCodeExporter]

Я начала вспоминать, и у меня возникли 
вопросы:
1) у меня сейчас что-то не очень 
складывается связь между сложными 
утверждениями и пересечением автоматов. 
Само утверждение будет представляться 
отдельным автоматом? То какой смысл 
пересекать, если они идут последовательно? 
на КНПО я как бы работала в основном с 
автоматами и о регулярных выражениях 
задумывалась мало. Сейчас у меня картинка 
не складывается
2)Нужно начинать с восстановления старых 
тестов? Простейшие то работают и сейчас, а 
вот для проверки работы тегов и 
изменившейся структуры ассертов надо 
переписывать функцию считывания.
3) Написание кросс-тестов. Я так понимаю 
тоже надо, т.к. они лучше всего показывают 
все проблемы, значительно лучше простых 
юнит-тестов.
Вообщем вопрос с чего начинать?

Original comment by eklepilkina@gmail.com on 22 Feb 2015 at 2:45

[GoogleCodeExporter]

1) они идут не последовательно, автомат 
утверждения может вызываться в конкретной 
точке - где утверждение вписано в регекс. Но 
этот метод хорошо работает только при 
поиске совпадения. При генерации надо 
будет генерировать в каждом месте символы, 
удовлетворяющие и основному регексу и 
ассерту (в общем случае на один символ 
может влиять произвольное количество 
больших утверждений как вперед, так и назад 
смотрящих). В этом случае гораздо проще 
свести все это пересечением в один переход, 
чем пытаться генерировать множества и 
потом их пересекать.
2) начать да, сначала тесты - прежде всего те, 
что были на КНПО сделаны, но и добавить 
новыми как раз на пересечение с простыми 
ассертами и тегами, чтобы доказать что наш 
алгоритм нормально подготовил данные для 
пересечения.
3) кросс-тесты проверяют что в целом 
работает правильно, а юнит-тесты - 
отдельные части/функции. Нужны и те и 
другие конечно, кросс-тестов больше - они и 
пишутся легче, а юнит-тесты помогают искать 
где именно ошибка.

Начать с перевода/восстановления 
имеющихся с предмета тестов; при этом 
обычные тесты переходят в юнит, а 
функциональные - в кросс-тесты. И к 
кросс-тестам разработать несколько особо 
сложных и показательных примеров
а) пересечение с участием теговых 
эпсилонов "напротив" сложного утверждения
б) простые утверждения начала/конца строки 
"напротив" сложного утверждения
в) утверждения границы слова "напротив" 
сложного утверждения
г) несколько сложных утверждений 
(позитивных и негативных, вперед и назад 
направленных) накладываются на один "кусок" 
регекса и таким образом, чтобы был переход 
в котором каждое из них отсеивает какие-то 
символы, так что для правильной генерации 
нужно учесть все.

Примеры а...в нам еще и на защите в любом 
случае понадобятся очень.

Original comment by oasyc...@gmail.com on 22 Feb 2015 at 4:43

[GoogleCodeExporter]

Там старые тесты почти все рабочие, 
менялись же только ассерты, вот с ними да не 
работает, и теги тоже. Тогда надо начать с 
того, наверное, что переписать функцию 
считывания автомата. Я думаю, с лексером 
надо написать, по нормальному.

Original comment by eklepilkina@gmail.com on 22 Feb 2015 at 6:13

[GoogleCodeExporter]

И вот те четыре теста, о которых я говорил 
а)--г) как кросс-тесты составить - к встрече 
через неделю...  Там первые три как раз 
помогут нам начать готовить сам 
доклад/пояснительную записку к диплому...

Original comment by oasyc...@gmail.com on 22 Feb 2015 at 6:41

[GoogleCodeExporter]

Я начала писать кросс-тесты на пункты a)-в) 
пока все только на вперед смотрящие 
позитивные. Вы можете посмотреть хотя бы по 
одному тесту? Я правильно поняла?
Вытолкнула в клон 
https://code.google.com/r/eklepilkina-complex-assertions/.

Original comment by eklepilkina@gmail.com on 27 Feb 2015 at 4:41

[GoogleCodeExporter]

Тесты несколько примитивны, там 
попробовать подлиннее (чтобы не следующий 
же символ прям, а на расстоянии), с 
развилками (отдельно в ассерте, отдельно в 
регексе).

Original comment by oasyc...@gmail.com on 28 Feb 2015 at 8:38

[GoogleCodeExporter]

У меня в unit-тестах, есть тесты с 
несмерженными переходами. Я внутри 
вызывала мержинг. Теперь он в другом месте. 
Я, наверное, тогда переделаю эти тесты так, 
как будто там уже все смержено.

Original comment by eklepilkina@gmail.com on 29 Mar 2015 at 2:21

[GoogleCodeExporter]

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

Добавочные кросс-тесты можно построить на 
основе тех же регексов, что использовались 
в функциональных тестах на НКПО, но сделать 
много строк с проверкой чтобы на каждом 
пересеченном шаге проходили нужные 
символы и только они. В этом смысле 
сравнение автоматов все же требует куда 
меньше проверок, чем сравнение 
кросс-тестами с детальной проверкой, 
совпадает с какими надо строками или где-то 
ошибки. Но для начала надо в аццептинге 
разблокировать эти виды утверждений (если 
включен мержинг простых конечно) и 
проверить имеющиеся юнит-тесты от PCRE с ними 
- пройдут или что-нибудь накроется? 
Частичные совпадения конечно будут 
различаться, т.к. PCRE ошибку сообщает в месте 
ассерта; эти можно и отредактировать. Но 
полные должны совпасть.

Original comment by oasyc...@gmail.com on 29 Mar 2015 at 9:06

[GoogleCodeExporter]

Еще такой вопрос. А имеет ли смысл 
выставлять consumeschars в false для остаточных 
переходов из утверждения, если там все 
решается тегами?

Original comment by eklepilkina@gmail.com on 2 Apr 2015 at 6:39

[GoogleCodeExporter]

Ну по большому счету не имеет. Но вот с 
точки зрения тестирования (проверочка типа 
"за пределами 0 тегов consumeschars = false, внутри - 
наоборот) - может иметь, подумайте...

Original comment by oasyc...@gmail.com on 2 Apr 2015 at 7:16

[GoogleCodeExporter]

(a|)*(?=(b[cd]+)|)(?<=(a*b[cl])|$). Попробовала такое 
регулярное выражение в стандартном 
матчере. Ругается на * в назад смотрящем "* 
Lookbehinds need to be zero-width, thus quantifiers are not allowed". У нас 
так же должно работать?

Original comment by eklepilkina@gmail.com on 7 Apr 2015 at 12:18

[GoogleCodeExporter]

И еще не пойму, почему вот этот регекс 
(?m)a(?=$)$[bc\n]^(?<=^) не дает в стандарте 
совпадения со строкой "a\n"

Original comment by eklepilkina@gmail.com on 7 Apr 2015 at 12:25

[GoogleCodeExporter]

А все последнее поняла

Original comment by eklepilkina@gmail.com on 7 Apr 2015 at 12:27

[GoogleCodeExporter]

14 - не, это недостаток PCRE

Original comment by oasyc...@gmail.com on 9 Apr 2015 at 3:24

[GoogleCodeExporter]

Текущие вопросы:
1. accept не знает о том, включен мержинг или 
нет, ему такой параметр в отличие от 
методов построения не передается.
2. Карту с состояниями для пересечения я, 
наверное, сделаю как поле автомата, чтобы 
не таскать по всем функциям еще один 
параметр. И в карту еще надо будет добавить 
направление пересечения. Плюс хранить как 
характеристику автомата карту с ассертами 
будет правильней для сложных ассертов 
внутри ассертов. Типо такого(?=a(?=b)b)ab.

Original comment by eklepilkina@gmail.com on 13 Apr 2015 at 4:10

[GoogleCodeExporter]

А ну еще карта должна быть многомерной, 
потому что у одного состояния может быть 
несколько автоматов.ab(?<=ab)(?=cd)cd

Original comment by eklepilkina@gmail.com on 13 Apr 2015 at 4:50

[GoogleCodeExporter]

Про аццептинг создать на меня (с owner мной) 
отдельное issue чтобы не забыл - сделаю как 
только дойдут руки от совсем уже срочных 
дел. Остальное согласен.

Original comment by oasyc...@gmail.com on 13 Apr 2015 at 8:48

[GoogleCodeExporter]

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

Original comment by eklepilkina@gmail.com on 14 Apr 2015 at 4:32

[GoogleCodeExporter]

И еще насчет цикла в одном автомате. Я 
начала разбираться. Посмотрите первый 
пример (t1, t2, t5)пересекается вперед, начиная 
с вершины 1. Во-первых, тут получается, что 
при пересечении опять попадаем в ветку с 
ассертом, нужно еще раз начинать 
пересекать?
Во-вторых, по моему тут тоже неправильно с 
циклом. По идеи вместо перехода 1,9 6 3 0->3,7 4 1, 
он должен вести в 1,0. И тут предложенная 
вчера логика не сработает, потому что там 
предлагалось искать вершину 1,.
Во втором примере (t3, t4, t6) вообще 
добавляется вершина, чтобы зациклить, но 
это пересечение назад. Я немного 
запуталась, но по моему, там тоже цикл 
должен идти не так.

Original comment by eklepilkina@gmail.com on 14 Apr 2015 at 6:25

Attachments:

• t1.png
• t2.png
• t5.png
• t3.png
• t4.png
• t6.png

[GoogleCodeExporter]

По вершинам - начальные и конечные вершины - 
это вершины, откуда начинается симуляция 
(выполнение) автомата и где заканчивается. 
Теги же определяют границы совпадения, 
которое нужно запомнить. Нельзя смешивать 
эти понятия. При наличии назад смотрящих 
ассертов в начале выражения начальная 
вершина может быть задолго до появления 
0-тегов. Аналогично в конце она может 
продолжаться куда позже закрывающего 
0-тега, и все эти переходы до самого конца 
должны быть выполнены (хоть в совпадение и 
не запомнятся, но если там чего не будет - 
совпадения просто не состоится....

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

Примеры посмотрю чуть позже.

Original comment by oasyc...@gmail.com on 15 Apr 2015 at 5:16

[GoogleCodeExporter]

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

Original comment by eklepilkina@gmail.com on 15 Apr 2015 at 5:48

[GoogleCodeExporter]

Начальные и конечные должны быть в любом 
автомате (в том числе скорее всего и в 
частичных, которые создаются на стеке - и в 
автоматах ассерта тоже). Их роль другая, чем 
у тегов. Они не могут определяться по тегам. 
Иначе даже \b в самом начале создаст переход 
левее открывающего 0-тега - и что, этот 
переход не будет выполняться что-ли, потому 
что 0-тег стоит после него? Это глюки будут.

Попробуйте регекс типа \babc и строки вида xabc 
- они дадут фейл? Если дадут, значит переход 
который \W, расположенный левее 0-тега 
выполнился и значит начальным считается 
состояние слева от него, а не то, которое 
перед 0-тегов.
А если не будет фейла - то это глюк, который 
надо фиксить.

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

Original comment by oasyc...@gmail.com on 15 Apr 2015 at 5:57

[GoogleCodeExporter]

Лена, что значит конкретно "определяются по 
тегам"? Каким образом? Работает вроде 
нормально, так что это явно не состояние 
непосредственно перед переходом с 0-тегом.

Original comment by oasyc...@gmail.com on 15 Apr 2015 at 6:23

[GoogleCodeExporter]

Без мержинга?
https://code.google.com/r/eklepilkina-preg-intersection/source/browse/question/t
ype/preg/fa_matcher/fa_matcher.php#1107 Вот функция, в 
которой устанавливаются начальные и 
конечные состояния.
А вот она сама 
https://code.google.com/r/eklepilkina-preg-intersection/source/browse/question/t
ype/preg/preg_fa.php#770.

Original comment by eklepilkina@gmail.com on 15 Apr 2015 at 6:34

[GoogleCodeExporter]

Начальные и конечные сделала. Все строится.

Original comment by eklepilkina@gmail.com on 21 Apr 2015 at 7:38

[GoogleCodeExporter]

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

Original comment by eklepilkina@gmail.com on 28 Apr 2015 at 8:22

Attachments:

• IMG.jpg

[GoogleCodeExporter]

И я думаю делать это последовательно, а не 
пытаться пересекать n автоматов 
параллельно.

Original comment by eklepilkina@gmail.com on 28 Apr 2015 at 8:29

[GoogleCodeExporter]

И еще, т.к. работы много, то что я должна 
сделать.
1. Адаптировать код, чтобы работал пропуск ^, 
$, eps, когда они в начале или в конце.(у меня 
пока таких тестов не было, так что ничего не 
падало на это).
2. Тестирую вперед смотрящие на более 
длинных и сложных примерах, отлаживаю их.
3. Меняю алгоритм, так чтобы можно было 
задавать не одну вершину для начала 
пересечения, а n (для поддержки \b).
4. Переделываю начальные и конечные 
состояния для подвыражений.
5. Поддержка назад смотрящих. 
6. Тестирование вперед+назад смотрящих.
7. Проверка и отладка вложенных ассертов.
8. Переписываю код для циклов, которые 
короче ассертов(то, что в комментах выше).
9. Поддержка рекурсии.

В таком порядке делаю же, чтобы простое все 
пораньше было работоспособным? а то я не 
знаю, за что хвататься.

Original comment by eklepilkina@gmail.com on 28 Apr 2015 at 8:37

[GoogleCodeExporter]

А еще ошибку для регулярных выражений, 
которые не могут совпасть из-за сложных 
утверждений, надо сделать. Ну пусть это 
между 1 и 2 будет.

Original comment by eklepilkina@gmail.com on 28 Apr 2015 at 8:45

[GoogleCodeExporter]

Пересекать n автоматов вполне удобно - 
нужно просто иметь функцию пересечения не 
двух, а n переходов. Более того, только 
пересекая n автоматов сразу можно точно 
детектировать, когда и куда именно следует 
зацикливание производить. А также когда 
можно закончить пересечения при наличии 
ассерта в коротком цикле ввиду 
повторяемости.

Кроме того, я думаю пункты 7 и 8 точно в 
приоритетах неверно стоят. Пункт 4 
желательно согласовать с Валерой - когда он 
сможет оперативно сделать свою часть; там 
работы чуть и если Валерий может сейчас - то 
тянуть с ним не стоит.

Original comment by oasyc...@gmail.com on 29 Apr 2015 at 12:06

[GoogleCodeExporter]

При последовательном пересечении будет 
точно такой же результат в принципе, он не 
будет добавлять вершины, которые уже есть. 
Но можно и параллельно.
"я думаю пункты 7 и 8 точно в приоритетах 
неверно стоят" Вы предлагаете их куда-то 
поднять? Просто проблема в том, что, если 
честно, я явно не успею сделать все из этого 
списка до сдачи диплома на проверку (10 
июня), и даже до защиты вряд ли.
Поэтому я думала, о том, чтобы говорить, что 
работают сложные утверждения, кроме 
определенных особенных случаев (типо 8 
пункта), поставив ограничение на алгоритм. 

Original comment by eklepilkina@gmail.com on 29 Apr 2015 at 5:37

[GoogleCodeExporter]

Случайно нашла следующую проблему. При 
создании вопроса, если указывать точное 
совпадение, то автоматически добавляется ^ 
и $. Причем к основному автомату сразу. И 
получается, что нельзя задавать 
утверждения, где остается хвост. Самое 
простое a(?=b) превращается в ^a(?=b)$, которое ни 
с чем совпасть не может.

Original comment by eklepilkina@gmail.com on 10 May 2015 at 4:12

[GoogleCodeExporter]

Еще проблема, никак не могу почему фейлы 
наблюдаются на вроде корректном автомате. 
Все теги вроде так. Если убрать из 
пересеченных теги, то падающие тесты 
начинают проходить, значит, проблема где-то 
там.
Результирующий, первый и второй автоматы 
на картинках.
Фейлы.
fa_matcher failed on regex 'a(?=b*)(\w?)*' and string 'ab' 
(qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_assertions_lookahead_8), merging is on:
INDEX_FIRST:     0=>0, 1=>1, 
LENGTH:          0=>2, 1=>1, 
expected:
INDEX_FIRST:     0=>0, 1=>2, 
LENGTH:          0=>2, 1=>0, 

fa_matcher failed on regex 'a(?=b*)(\w?)*' and string 'a' 
(qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_assertions_lookahead_8), merging is on:
INDEX_FIRST:     0=>0, 1=>-1, 
LENGTH:          0=>1, 1=>-1, 
expected:
INDEX_FIRST:     0=>0, 1=>1, 
LENGTH:          0=>1, 1=>0, 

Original comment by eklepilkina@gmail.com on 11 May 2015 at 3:11

Attachments:

• fa_1.svg
• fa_2.svg
• fa_3.svg

[GoogleCodeExporter]

Первый фейл ушел. Второй остался.

Original comment by eklepilkina@gmail.com on 15 May 2015 at 4:09

[GoogleCodeExporter]

Такой еще вопрос при генерации должны 
генерироваться символы из утверждения? Вот 
например тест. Тест правильный? Или 
генерация так и должна работать?
fa_matcher failed on regex '(?<=ab)cd' and string 'cd' 
(qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_assertions_lookbehind_3), merging is on:
NEXT:            cd
FULL STR:        abcd
expected:
NEXT:            a

Original comment by eklepilkina@gmail.com on 15 May 2015 at 4:17

[GoogleCodeExporter]

Генерация должна сгенерировать строку, 
которая совпадет. Включая символы в 
утверждениях. Другое дело что в 
сгенерированном объекте подмаска с 
номером 0 покажет границы истинного 
совпадения, оно там с первого символа 
начинаться не должно.

А как работает генерация для варианта типа 
\b! ? Она тоже должна сначала символ слова 
сгененрировать если не многострочный 
режим.

Original comment by oasyc...@gmail.com on 15 May 2015 at 4:45

[GoogleCodeExporter]

С \b в начале тоже с генерацией плохо.Хотя 
вот FULL STR он правильно пишет во всех случаях.

Original comment by eklepilkina@gmail.com on 15 May 2015 at 6:17

[GoogleCodeExporter]

Вообщем я не знаю, что там не так при 
генерации хвостов. FULL STR и LEFT правильно 
определяется. next character вызывается для 
незахватывающего перехода и дает 
правильный результат. Причем "!\b" работает 
нормально на "!"
NEXT:            0
LEFT:            1
FULL STR:        !0
Т.е. проблемы только с начальными хвостами.

Original comment by eklepilkina@gmail.com on 16 May 2015 at 7:31

[GoogleCodeExporter]

Еще вопрос. А частичное совпадение 
считается для незахватывающих переходов?
(?m)^(?<=a\n)d на строке ad должен дать частичное? 
или нет, потому что там 0 длина? Валера 
считает что второй вариант. но тогда как-то 
странно придется генерировать символ, 
который уже был введен заново.

Original comment by eklepilkina@gmail.com on 16 May 2015 at 8:08

[GoogleCodeExporter]

Непонятный для меня фейл. Автомат 
простейший.
fa_matcher failed on regex 'b(a|c)$(?<=b[ac])' and string 'bac' 
(qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_assertions_lookbehind_16), merging is on:
INDEX_FIRST:     0=>0, 1=>-1, 
LENGTH:          0=>1, 1=>-1, 
LEFT:            999999999
expected:
INDEX_FIRST:     0=>0, 1=>1, 
LENGTH:          0=>2, 1=>1, 
LEFT:            0

Original comment by eklepilkina@gmail.com on 17 May 2015 at 4:43

Attachments:

• fa_1.svg
• fa_2.svg
• fa_3.svg

[GoogleCodeExporter]

Еще есть вполне логичные фейлы на захват 
пустых подвыражений при частичном 
совпадении. Пустота мержится в предыдущий 
переход до ассерта, и поэтому выдает 
совпадение, когда ассерт фейлится.
Например
fa_matcher failed on regex 'a(?=b)(\w?)*' and string 'a' 
(qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_assertions_lookahead_7), merging is on:
INDEX_FIRST:     0=>0, 1=>1, 
LENGTH:          0=>1, 1=>0, 
expected:
INDEX_FIRST:     0=>0, 
LENGTH:          0=>1,

fa_matcher failed on regex 'a(?=[b-d])(|\s)(?<=[a-z])' and string 'az' 
(qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_both_assertions_2), merging is on:
INDEX_FIRST:     0=>0, 1=>1, 
LENGTH:          0=>1, 1=>0, 
expected:
INDEX_FIRST:     0=>0, 
LENGTH:          0=>1,

Original comment by eklepilkina@gmail.com on 18 May 2015 at 3:52

[GoogleCodeExporter]

Я посмотрела, что там конкретно 
генерируется в тестах с незахватывающими 
переходами в начале. Вот пример 
(?<=[a-k][a-z])(?<=[a-d][c-x])[d-y][x-z].
Фейл fa_matcher failed on regex '(?<=[a-k][a-z])(?<=[a-d][c-x])[d-y][x-z]' 
and string 'aayy' (qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_assertions_lookbehind_start), merging is on:
NEXT:            yy
FULL STR:        acyy
expected:
NEXT:            c
Выдает следующие результаты.
class qtype_preg_matching_results#13049 (9) {
  public $full =>
  bool(false)
  public $indexfirst =>
  array(1) {
    [0] =>
    int(-1)
  }
  public $length =>
  array(1) {
    [0] =>
    int(-1)
  }
  public $left =>
  int(3)
  public $extendedmatch =>
  class qtype_preg_matching_results#13069 (9) {
    public $full =>
    bool(true)
    public $indexfirst =>
    array(2) {
      [-2] =>
      int(-1)
      [0] =>
      int(2)
    }
    public $length =>
    array(2) {
      [-2] =>
      int(-1)
      [0] =>
      int(2)
    }
    public $left =>
    int(0)
    public $extendedmatch =>
    NULL
    public $extensionstart =>
    int(2)
    protected $str =>
    class qtype_poasquestion\string#13062 (2) {
      private $fstring =>
      string(4) "acyy"
      private $flength =>
      int(4)
    }
    protected $maxsubexpr =>
    int(0)
    protected $subexprmap =>
    array(0) {
    }
  }
  public $extensionstart =>
  int(-1)
  protected $str =>
  class qtype_poasquestion\string#13097 (2) {
    private $fstring =>
    string(4) "aayy"
    private $flength =>
    int(4)
  }
  protected $maxsubexpr =>
  int(0)
  protected $subexprmap =>
  array(0) {
  }
}

В extendedmatch там indexfirst 2 для 0 тега, что 
правильно в принципе, и еще extensionstart 
какой-то тоже 2.

Original comment by eklepilkina@gmail.com on 22 May 2015 at 10:19

[GoogleCodeExporter]

Пометки для себя:
1. Незахватывающие хвосты автомата 
утверждения пересекать в другую сторону
2. Незахватывающие хвосты основного 
автомата при повторном пересечении 
пропускать
3. Перенести мержинг в класс автомата, и 
дописать мержинг и после построения 
автомата для ситуаций, когда ассертов 
много.
4. Одиночный \b развернуть.

Original comment by eklepilkina@gmail.com on 22 May 2015 at 10:56

[GoogleCodeExporter]

Original comment by eklepilkina@gmail.com on 25 May 2015 at 3:19

Attachments:

• preg_matcher.php

[GoogleCodeExporter]

Фейлов не прибавилось, вытолкнул

Original comment by vostreltsov@gmail.com on 25 May 2015 at 3:58

[GoogleCodeExporter]

У меня на данный момент очень много 
вопросов по тестам.

1. Из-за мержинга назад пустота совпадает до 
утверждения хотя должна после
Пример.
fa_matcher failed on regex 'a(?=b)(\w?)*' and string 'a' 
(qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_assertions_lookahead_7), merging is on:
INDEX_FIRST:     0=>0, 1=>1, 
LENGTH:          0=>1, 1=>0, 
expected:
INDEX_FIRST:     0=>0, 
LENGTH:          0=>1, 

2. Проблемы с $. Вроде строятся правильные 
автоматы 16 и 17 картинка соответственно для 
16 и 17 теста, а тесты падают.
fa_matcher failed on regex 'b(a|c)$(?<=b[ac])' and string 'bac' 
(qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_assertions_lookbehind_16), merging is on:
INDEX_FIRST:     0=>0, 1=>-1, 
LENGTH:          0=>1, 1=>-1, 
LEFT:            999999999
expected:
INDEX_FIRST:     0=>0, 1=>1, 
LENGTH:          0=>2, 1=>1, 
LEFT:            0

fa_matcher failed on regex 'b(a|c$)(?<=b[ac]$)' and string 'bca' 
(qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_assertions_lookbehind_17), merging is on:
LENGTH:          0=>1, 1=>-1, 
NEXT:            a
LEFT:            1
FULL STR:        ba
expected:
LENGTH:          0=>2, 
NEXT:            -1
LEFT:            0

3. Судя по всему не находится совпадение с 
незахватывающими переходами в начале. 
Автомат картинка 20
fa_matcher failed on regex '(?m)^(?<=a\n)d' and string 'ad' 
(qtype_preg_cross_tests_from_preg_intersection, 
data_for_test_assertions_lookbehind_20), merging is on:
IS_MATCH:        FALSE
INDEX_FIRST:     0=>-1, 
LENGTH:          0=>-1, 
expected:
IS_MATCH:        TRUE
INDEX_FIRST:     0=>0, 
LENGTH:          0=>1, 

У меня остается грубо 10 дней до сдачи, и 
надо по максимуму разобраться с фейлами, но 
сама я не вижу в чем могут быть проблемы

Original comment by eklepilkina@gmail.com on 29 May 2015 at 4:20

Attachments:

• 16_1.svg
• 17.svg
• 20.svg

[GoogleCodeExporter]

Лен, то что картинки вроде правильные не 
значит что вся структура данных 
правильная. Помнишь случай с minopentag? Там 
есть еще куча полей, проверь сначала что 
все там выставляется корректно. Глянь на 
комменты к полям в классе перехода, а потом 
оцени в каких местах и как их нужно 
вычислять.

Ты можешь также раскомментировать echo в 
матчере, посмотреть что там происходит.

Остальное постараюсь глянуть 
завтра-послезавтра.

Original comment by vostreltsov@gmail.com on 29 May 2015 at 7:39