Мы потихоньку начали пилить N2. Сейчас идет работа над парсером. Точнее даже над его прототипом — проектом ParserGenerator. В последствии он будет преобразован в парсер Н2, а далее облеплен "мясом" и станет самим Н2.
Сам парсер пилит WolfHound. Я только помогаю ему консультациями по скайпу и допиливанием компилятора (если какие-то ошибки или недоработки мешают двигаться дальше). Он с этим делом прекрасно справляется и помощь ему особо не нужна. Более того она даже вредна, так как проект, периодически, требует серьезных рефакторингов и два человека будут просто мешать друг другу.
Однако есть ряд задач которые нужно решить в ближайшее время, и которые относительно независимы от проекта парсера. Ниже я перечислю эти задачи, а детали по ним распишу в отдельных сообщениях которые будут ответом на данные сообщения.
Если кому-то захочется задать, по самому проекту N2, вопрос не связанный с описанными заданиями, то просьба делать это в отдельной теме. Данная тема относится исключительно к задачам. Для каждой из задач будет заведена отдельная подветка. Вот в них и можно будет задать вопросы по ним. Остальные ответы буду считать офопом и удалять. Прошу отнестись с пониманием. Тема не должна превратиться в хлам и флэйм.
Задачи которые требуют добровольцев
1. Создание утилиты тестирования для парсеров полученных с помощью нового генератора парсеров (аналогичная тестовой утилите применяемой для тестирования компилятора Н1).
2. Создание модуля расширения для студии, чтобы можно было тестировать парсер "на лету". Расширение должно осуществлять подсветку, навигацию по скобкам, отображение сообщений об ошибках... в дальнейшем интеллисенс и т.п., и все это на основании полученного от парсера AST.
3. Создание грамматики Н1 для нового генератора парсеров.
4. Создание грамматики C# 4+ для нового генератора парсеров.
Последние два проекта нужны для тестирования генератора парсеров на реальных задачах, а первые два как техническая реализация этого самого тестирования.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Создание утилиты тестирования для парсеров полученных с помощью нового генератора парсеров (аналогичная тестовой утилите применяемой для тестирования компилятора Н1).
Это должен быть ехе-шник с именем, предположим, test.exe.
Он должен принимать на входе командную строку, набор файлов содержащих исходный код (размеченный специальным образом) и производить разбор этих файлов указанным в командной строке парсером. Далее результат работы парсера должен сопоставляться с закодированным специальным образом эталонным результатом. В случае несовпадения выдавать сообщение об ошибке выдающее информацию позволяющую понять, что произошло не так и где следует искать ошибку.
Данная утилита будет использоваться как для тестирования самого генератора парсеров, так и для тестирования парсеров полученных с помощью нашего генератора парсеров.
Путь к сборке содержащей парсер задается аргументом командной строки перед которым не идет '/' или '-'.
Так же должны поддерживаться следующие опции командной строки:
/parser:"квалифицированное имя класса парсера который надо загрузить"
/ext:"имена расширений тестовых файлов перечисленные через ';'"
/tests_path:"относительный (от текущего каталога) путь к тестовым файлам"
/debug — выдавать assert2(false) в случае провала теста с тем чтобы можно было начать отладку теста.
Активная размета
В файлах с тестами должны присутствовать дополнительные описания которые позволят указать дополнительную информацию необходимую для проверки правильности работы парсера.
Вся активная размета должна перед передачей кода теста парсеру заменяться пробельными символами, так как парсер не обязан считать такие конструкции корректными строками языка (например, комментариями).
В начале любого тестового файла могут следовать следующие строки содержащие общие настройки:
// OPTION: настройки парсера (пока ничего)
Внутри кода, в конце строк с кодом могут встречаться конструкции:
// E: ...
// W: ...
// H: ...
Где вместо "..." может встречаться произвольный текст ожидаемого сообщения об ошибке. При этом текст интерпретируется как плоский текст (а не как регекс в тестовой утилите Н1).
Если опции описаны так:
// E:R: ...
// W:R: ...
// H:R: ...
то текст идущий вместо "..." должен интерпретироваться как регулярное выражение, с которым должно сопоставляться сообщение об ошибке выданное парсером.
Внутри кода (но не в приведенных выше конструкциях) могут встречаться конструкции:
/*{*/SomeCode/*} E: образец сообщения*/()
Опять же вместо "E:" могут использоваться "W:", "H:", а так же "E:R:" и т.п.
Кроме того хорошо бы должен поддерживаться гибридный вариант:
/*{*/SomeCode/*}*/() // E: Expected XXX
При этом в строке может быть только одна пара кавычек /*{*/ и /*}*/, которая идентифицирует реальное местоположение ошибки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Это должен быть модуль расширения (Extension) для VS 2010 (и последующих версий) который позволял бы отрывать файлы с расширением n и cs (или n2 и csn, если возникнет конфликт с интеграциями этих языков) и просматривать / редактировать его содержимое.
При этом:
1. Код должен в реальном времени подсвечиваться по информации полученной от парсера.
2. Должен работать переход по скобкам при нажатии Ctrl+}.
3. При подведении мыши к тому или иному участку кода должна отображаться всплывающая подсказка (хинт) в которой должна выводиться информация о ветках AST соответствующих участку кода расположенному под курсором мыши и правило в соответствии с которым было получено данное AST.
4. Нужно реализовать окно AST Explorer (по аналогии с Solution Explorer). Данное окно (тул) должно прилепать сбоку студии (как Solution Explorer) и отображать информацию о ветке AST находящейся под текстовым курсором. AST должно отображаться в виде дерева (графического элемента управления). Текущий элемент этого дерева должен быть подсвечен в коде изменением цвета фона, так чтобы было видно, чему соответствует элемент AST. В окне должен быть реализован поиск веток AST по имени.
Вся информация должна автоматически обновляться при изменении текста в редакторе в режиме приближенном к режиму реального времени (т.е. чем быстрее, тем лучше). Обновление дерева AST не должно тормозить отрисовку подсветки и т.п., т.е. должно происходить асинхронно.
Парсинг по началу можно делать прямо в GUI-потоке, но со временем он должен уйти в отдельный потоке (или позволять переключать режим "в отдельном потоке" / "В GUI-потоке").
Далее туда же будут подключаться и другие фичи парсера, и в последствии, самого N2. Так что из него вырастит новая интеграция для VS.
Первоочередные задачи данного проекта — интерактивное тестирование парсеров полученных новым генератором парсеров и оценка их производительности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Создание грамматики N1 для нового генератора парсеров
Цель этого проекта с эмулировать парсер N1 и его макросов, так чтобы обкатать возможности генератора парсеров, протестировать скорость, качество сообщений об ошибках и т.п.
Особенностями данного парсера будут:
1. Динамически-расширяемая грамматика (часть правил будет загружаться из внешних модулей).
2. Отсутствие ключевых слов. По возможности парсер должен использовать "контекстно-зависимые ключевые слова". Сейчас в Nemerle 1.х контекстно-зависимыми являются только ключевые слова get, set, add, remove и type.
Данный проект будет использоваться для тестирования генератора парсеров через утилиту тестирования
Цель этого проекта с эмулировать парсер N1 и его макросов, так чтобы обкатать возможности генератора парсеров, протестировать скорость, качество сообщений об ошибках и т.п.
Данный парсер нужен для тестирования парсинга "лексерных" языков, т.е. языков с предопределенным набором ключевых слов.
Кроме того будем стараться делать в нем сообщения об ошибках аналогичными тем, что выдает парсер C#.
Данный проект будет использоваться для тестирования генератора парсеров через утилиту тестирования
Здесь можно задавать общие вопросы не относящиеся к перечисленным проектам. В том числе и по самому N2.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Общие вопросы по теме в целом
От:
Аноним
Дата:
17.02.12 05:27
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здесь можно задавать общие вопросы не относящиеся к перечисленным проектам. В том числе и по самому N2.
С большим удовольствием вольюсь в проект. Меня интересует тема extension на Visual Studio 2010. Сразу оговорюсь что Nemerle начал изучать недавно, но язык великолепен, фанатею и всем рассказываю Так что если понадобится пара рук, мой адрес sunex.development@gmail.com
данный синтаксис рассчитан на то что в тестируемом парсере такие строки невозможны
иначе как их выцеплять из тетируемого файла?
как тестировать комментарии?
может быть пойти более геморным, но концептуально более целостным путём —
сделать парсер-расширение к тестируемому парсеру, который это и будет автоматом делать.
в случае противоречий — выводить ошибки в статике
или препроцессор-расширение
в принципе этот парсер-тестовое-расширение будет чаще всего универсальным для большинства (например с-подобных языков)
и одновременно тестировать функцию расширения.
Здравствуйте, sunexdev, Вы писали:
S>С большим удовольствием вольюсь в проект. Меня интересует тема extension на Visual Studio 2010. Сразу оговорюсь что Nemerle начал изучать недавно, но язык великолепен, фанатею и всем рассказываю Так что если понадобится пара рук, мой адрес sunex.development@gmail.com
Понадобится не одна пара рук. Тем более, что опыт показывает, что люди у которых есть работа физически не могут уделять проекту много времени.
Проект с интеграцией потенциально большой. Там не на одного человека работы хватит. Так что можешь браться. Если найдутся помошники, то будете вмести с ними рабоать.
Я в интеграции кое что понимаю, так то смогу помочь и направить в нужном направлении.
Через скайп есть возможность общаться?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
P>данный синтаксис рассчитан на то что в тестируемом парсере такие строки невозможны P>иначе как их выцеплять из тетируемого файла?
В первой версии этого сообщения я добавил опцию
// QUOT: /* */ //
Которая позволила бы задавать свои символьные сочетания, но в потом понял, что подобные вещи лучше уже потом, отдельной итерацией делать.
На первых порах у нас будет только два языка N и C#. В обоих это полноценный коменты. Ну, и вообще, это весьма редкие сочетания символов.
А если возникнет проблема, то всегда можно будет доработать. Так что достаточно вынести строки в отдельный модуль/класс, чтобы их потом легко было подменять.
P>как тестировать комментарии?
Не понял вопрос. Зачем тестировать комментарии?
P>может быть пойти более геморным, но концептуально более целостным путём -
P>сделать парсер-расширение к тестируемому парсеру, который это и будет автоматом делать. P>в случае противоречий — выводить ошибки в статике P>или препроцессор-расширение
Мне кажется — это лишнее. Утилита тестирования нужна уже сейчас. Так что время критично. Изыски могут затянуть разработку. Нам достаточно выцепления коментов с помощью регекспов.
Потом расширение надо специально прописывать в грамматике. А это дополнительное препятствие. Лучше уж в посделствии сделать возможность задания сиволов комментариев настраиваемым через командную строку и комент в начале файла.
Сами области под комментариями нужно просто забивать пробельными символами перед передачей текста парсеру. Тогда, даже если в парсере это не комментарии он все равно будет работать. А потенциальный конфликт можно будет устранить заданием других "коментов".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Visor2004, Вы писали:
V>Я могу взять на себя этот кусок. Создавал VS интеграцию для вот этих продуктов. Проекту смогу уделять около 16 часов в неделю.
Я тоже в интеграциях кое-что понимаю, так что буду участвовать (как минимум помогать советами).
По сему предлагаю обсудить детали через скайп. У тебя есть скайп? Мой экаунт в скайпе — VladD2.
Перво что нужно сделать для этого проекта — создать соответствующий проект с поддержкой MEF и перевести его на Немерл.
Участники проекта должны использовать компилятор и интеграцию к немерлу собранные из исходников. Иначе будут проблемы с версиями сборок и т.п. Сам проект имеет смысл поместить в проект парсера. Для начала можно просто форкнуть основной проект и когда проект интеграции начнет запускаться предложить пулреквест.
Нам нужен проект с расширением (пока что) для редактора кода. Можно воспользоваться шаблоном для шарпа EditorClassifier и потом перетащить из полученного проекта все нужное в аналогичный немерловый проект.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, sunexdev, Вы писали:
S>С большим удовольствием вольюсь в проект. Меня интересует тема extension на Visual Studio 2010. Сразу оговорюсь что Nemerle начал изучать недавно, но язык великолепен, фанатею и всем рассказываю Так что если понадобится пара рук, мой адрес sunex.development@gmail.com
Данный форк будет постоянно обновляться с оригиналом.
Все кто хочет принять участие в одном из озвученных подпроектов просьба присылать свои экануты, я включу их в состав рабочей группы. Ну, и естественно, вам надо начать с клонирования данного репозитория на свои машины.
Здравствуйте, Аноним, Вы писали:
А>Спасибо за предложение работать в проекте (это sunexdev, я наконец зарегистрировался на rsdn), мой аккаунт на guthub — mumusan.
Добавил в команду Nemerle.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mumusan, Вы писали:
M>Где можно вести план работ? ставить задачи? Есть ли примерный список задач? Или это пока что что-то абстрактное, в вакууме?
Здравствуйте, Mumusan, Вы писали:
M>Где можно вести план работ? ставить задачи? Есть ли примерный список задач? Или это пока что что-то абстрактное, в вакууме?
Вопросы можно задавать здесь (в ветках относящихся к каждой из задач) или по скайпу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
