Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, hardcase, Вы писали:
H>>>Да. Компиляция парсера этой грамматики в которую я добавил весь этот красивый спектр операторов теперь занимает чуть больше 10 минут (дома машинка пошустрее и считает за 7 минут).
VD>>А не смотрел профайлером что занимает основное время?
H>Судя по тому, что я увидел в профайлере, все время времени компилятор проводит в OptimizeRule, а имеенно в CanInline, которая похоже имеет жуткую полиномиальную сложность.
Исправил в r8986. Теперь оно так долго не занимается прогревом процессора.
Здравствуйте, hardcase, Вы писали:
H>Судя по тому, что я увидел в профайлере, все время времени компилятор проводит в OptimizeRule, а имеенно в CanInline, которая похоже имеет жуткую полиномиальную сложность.
А попробуй как ее просто отключить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>>Исправил в r8986. Теперь оно так долго не занимается прогревом процессора.
H>От этой жары уже и соображаю плохо... Сделал лучше: r8987.
А после исправления что занимает основное время (с точки зрения профайлера)?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>>Исправил в r8986. Теперь оно так долго не занимается прогревом процессора.
H>От этой жары уже и соображаю плохо... Сделал лучше: r8987.
Кстати, проект ты в ШарпДевелопе создавал?
С ним явно что-то не так. В студии какие-то странные проблемы.
Я его (от греха) пересоздал с помощью VS.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Кстати еще смущает размер кода. Теперь сборка с парсером стремится к 400КБ. Это нормально?
Удалил строки используемые для отладки, стало ~300Кб.
Для радикального уменьшения надо менять генерацию кода для терминальных правил (тех что разбирают отдельные символы и не содержат рекурсии). Их можно превратить в ДКА или даже специализированный код. Например, для распознавания "строк" (последовательного набора символов) можно применять сравнение строк или хотя бы более оптимальный код генерировать (без откатов и доп.проверок длинны строки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Интересу ради решил попробовать в деле генератор парсеров. H>Задачу выбрал синтетическую — разбор некоего подмножества JavaScript.
Это! Может лучше займешься созданием грамматики для C#? Нам это дело намного больше нужно. Тогда и конвертер на его базе организовали бы, и даже возможность включать в немерловый проект C#-исходников.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>Интересу ради решил попробовать в деле генератор парсеров. H>>Задачу выбрал синтетическую — разбор некоего подмножества JavaScript.
VD>Это! Может лучше займешься созданием грамматики для C#? Нам это дело намного больше нужно. Тогда и конвертер на его базе организовали бы, и даже возможность включать в немерловый проект C#-исходников.
Можно попробовать в принципе попробовать. Не думаю, что сильно сложно будет, просто рутинного кода мноооого.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>>Исправил в r8986. Теперь оно так долго не занимается прогревом процессора.
H>>От этой жары уже и соображаю плохо... Сделал лучше: r8987.
VD>А после исправления что занимает основное время (с точки зрения профайлера)?
Нормально стало вроде. Других задержек пока не замечено.
Здравствуйте, hardcase, Вы писали:
VD>>Это! Может лучше займешься созданием грамматики для C#? Нам это дело намного больше нужно. Тогда и конвертер на его базе организовали бы, и даже возможность включать в немерловый проект C#-исходников.
H>Можно попробовать в принципе попробовать.
Давай! Это будет очень полезно. А я постараюсь сосредоточиться на развитии генератора парсеров.
H>Не думаю, что сильно сложно будет, просто рутинного кода мноооого.
+1
ЗЫ
Ко всему прочему это будет первым шагом к новой версии Немерла, так как это будет пример реально достаточно большого размера, чтобы проверить все что нужно проверить (производительность, сложность, проблемы, ...).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Возникли два вопроса:
H>1) Как обрабатывать ошибки?
В ревизии 9007 я залил небольшое расширение парсера. Теперь в парсер добавляется свойство MaxRollbackPos. В этом свойстве запоминается максимальная позиция в которой был произведен откат. Фактически — это позиция в которой отбламался парсер. Эту позицию можно использовать для выдачи "общего" сообщения об ошибке, например, "Недопустимый токен".
В будущем, я думаю, нужно в этих же позициях запоминать так же некий идентификатор правила на котором произошел облом. Тогда можно будет формировать более осмысленные сообщения об ошибок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В ревизии 9007 я залил небольшое расширение парсера. Теперь в парсер добавляется свойство MaxRollbackPos. В этом свойстве запоминается максимальная позиция в которой был произведен откат. Фактически — это позиция в которой отбламался парсер. Эту позицию можно использовать для выдачи "общего" сообщения об ошибке, например, "Недопустимый токен".
Кстати, как в текущем парсере дела с "точками отсечения"? Ну, теми, после отката до которых парсер вываливается с ошибками.
Здравствуйте, catbert, Вы писали:
C>Кстати, как в текущем парсере дела с "точками отсечения"? Ну, теми, после отката до которых парсер вываливается с ошибками.
Никак, но можно создать правило перехватывающее любой ввод и выдать в нем ошибку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
VD>>Это! Может лучше займешься созданием грамматики для C#? Нам это дело намного больше нужно. Тогда и конвертер на его базе организовали бы, и даже возможность включать в немерловый проект C#-исходников.
H>Можно попробовать в принципе попробовать. Не думаю, что сильно сложно будет, просто рутинного кода мноооого.
Ну, так как?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>К сожалению прошедшую неделю был крайне далек от какого-либо компьютера H>Буду фигачить на этой.
Давай. Причем не стесняйся дергать меня (можно по Скайпу, в нем у меня логин VladD2), если что-то не так будет с PegGrammar. Это важно для будущей версии компилятора.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>К сожалению прошедшую неделю был крайне далек от какого-либо компьютера H>>Буду фигачить на этой.
VD>Давай. Причем не стесняйся дергать меня (можно по Скайпу, в нем у меня логин VladD2), если что-то не так будет с PegGrammar. Это важно для будущей версии компилятора.
Сделал начальный коммит грамматики и простую систему тестирования правил.
Здравствуйте, hardcase, Вы писали:
H>Сделал начальный коммит грамматики и простую систему тестирования правил.
Парсер теперь распознает объявления (покачто без генерирования AST) всевозможных типов (в грамматике около 200 правил).
Сборка с парсером имеет размер в полтора мегабайта.
Здравствуйте, hardcase, Вы писали:
H>Сделал начальный коммит грамматики и простую систему тестирования правил.
По поводу модификаторов (public, new, static, ...).
Не стоит описывать свой список для каждого типа деклараций. Людям свойственно ошибаться. Они часто лепят идентификаторы не по месту. И при этом им нужны внятные сообщения об ошибках. Если же забить их в грамматику, то сообщение будет типа "не ожидаемый идентификатор".
Лучше сделать единый список идентификаторов и проверять их в семантическом действии (обработчике). Или после правильного списка модификаторов давать полный список и при его сопоставлении выдавать ошибку (это будет чуть медленнее).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Это нормально?
