Оставшиеся проблемы с апострофами

[Oleg Sychev]

Originally reported on Google Code with ID 159

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Reported by oasychev on 2012-10-31 08:13:15

[Oleg Sychev]

 Наличие юникодовского апострофа вызывает кучу ошибок и сбоев в форме редактирования
вопроса, попробуйте следующую лексему
madman’s

Reported by oasychev on 2012-10-31 08:14:56 - Labels added: Component-WritingCompetently

[Oleg Sychev]

Еще 'em определяется как две лексемы, а это сокращенное them.

Reported by oasychev on 2012-10-31 09:53:50

[Former user]

'em исправил, а вот с U+2019 жуткая проблема. Дело в том, что ошибка находится в коде,
сгенеренном JLexPHP. Такое ощущение, что он не видит состояния для перехода. Я пробовал
тупо забить его в код сканера - код самого JLexPHP валится на генерации сканера. Я
думаю, в это issue стоит добавить Стрельцова, возможно он что-то такое делал и как-то
решил такую проблему.

Reported by mamontov.dp on 2012-11-01 16:34:33

[Valeriy Streltsov]

Я тупо заменил стандартные строковые функции на свои. В poasquestion сейчас нормальный
jlex.php - можешь его использовать. Входной файл для jlex'а в юникоде сохранен? :)

Reported by vostreltsov on 2012-11-01 19:47:50

[Former user]

Ты там что-то в предыдущей подобной issue писал о %unicode и %full. Это может исправить
ситуацию, или такой же тупик?

Reported by mamontov.dp on 2012-11-02 11:27:46

[Valeriy Streltsov]

Я указывал %unicode в файле лекса. Объясни подробнее, какой базовый файл jlex.php ты
используешь - из poasquestion или нет? Эта директива влияет только на генерируемый
файл (там больше каких-то констант становится). А если базовый класс в том файле двигается
по буферу используя обычные строковые функции - толку не будет.

Reported by vostreltsov on 2012-11-02 13:28:37

[Former user]

Да, из  poasquestion. Тогда сейчас попробую применить его.

Reported by mamontov.dp on 2012-11-02 14:27:55

[Former user]

Не сработало. Если указать в файле юникодовый апостроф в регулярном выражении тогда
JLexPHP упадет в момент генерации ДКА. Пока буду думать над тем, как исправить его.

Reported by mamontov.dp on 2012-11-02 14:52:00

[Oleg Sychev]

Потестил pregовский сканер - он не валится на регулярном выражении, содержащем этот
юникодовый апостроф. Так что проблема с jlex'ом должна быть решаемой. poasquestion
то у вас в последнем состоянии на домашнем тестовом сайте?

Reported by oasychev on 2012-11-04 11:41:42

[Former user]

Вы не правильно поняли проблему. Дело не в том, что апостроф вылетает (это было исправлено
путем добавления директивы %unicode). Дело в том, что если апостроф  данным символом
использовать в регулярном выражении исходного файла, передаваемого в JlexPHP, cам JLexPHP
вылетает с ArrayIndexOfBoundException 1074. Я пробовал преобразовывать кодировку исходного
файла языка в UTF-16, но это он тоже на распознает.

Reported by mamontov.dp on 2012-11-04 11:44:54

[Oleg Sychev]

Мануал говорит что Jlex умеет понимать юникод-символы в синтаксисе
\udddd  The Unicode character code corresponding to the number formed by four hexidecimal
digits dddd

Вы так его добавляли?

Reported by oasychev on 2012-11-04 12:15:25

[Former user]

Увы, и просто символ, и задание его в виде \u2019 валятся с той же ошибкой.

Reported by mamontov.dp on 2012-11-04 12:20:28

[Oleg Sychev]

Ну если оно перестало вылетать - это уже весьма хорошо, ибо вылеты в принципе недопустимы.

Что касается его поддержки как апострофа. Может тупо перед сканнингом сделать предобработку
строки, заменив этот символ на ASCII апостроф? Тогда JLex этим мучить не придется...

Reported by oasychev on 2012-11-04 19:00:14

[Oleg Sychev]

Кстати, кому-нибудь не мешало бы сравнить с последними версиями JLex PHP и Lemon PHP
- например в последнем есть про фиксы некоторых багов коммиты не очень давно...
https://github.com/wez/lemon-php
https://github.com/wez/JLexPHP

Можно там же попробовать написать автору о проблемах, хотя активности нет давно. И
еще можно скачать оригинальную версию JLex и попробовать ей скормить тот же символ
- если и она поимеет проблемы (а вполне может, т.к. они не на стадии генерации кода
происходят), то можно уже писать багрепорт его поддержке, а там вроде как серьезный
ВУЗ за этим стоит, могут отреагировать...

Reported by oasychev on 2012-11-04 19:07:06

[Former user]

Я буквально позавчера скачивал оттуда последнюю версию JLexPHP, она ничем не отличается
от моей и в ней присутствует этот баг. Но предобработку сделаю сегодня.

Reported by mamontov.dp on 2012-11-05 05:39:38

[Former user]

Нашел как исправить ситуацию чисто случайно. Оказалось, что я взял директиву %full из
preg, которая в случае присутствия %unicode попросту не нужна. Если удалить эту директиву
- все работает и проходит тесты.

Reported by mamontov.dp on 2012-11-05 07:24:58

[Oleg Sychev]

А чего кавычки в тесте вокруг madman’s двойные?

Reported by oasychev on 2012-11-05 09:52:39

[Former user]

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

Reported by mamontov.dp on 2012-11-05 09:54:49

[Oleg Sychev]

fixed не забываете выставлять...

Reported by oasychev on 2012-11-09 12:08:38

[Former user]

Исправлено.

Reported by mamontov.dp on 2012-11-26 12:38:21 - Status changed: Fixed

[Oleg Sychev]

Спасибо

Reported by oasychev on 2012-11-26 12:41:17 - Status changed: Done