Nitra pretty print comments
От: pekabon  
Дата: 02.06.15 14:08
Оценка:
Привет,

Подскажите плз, что нужно сделать чтобы в выхлопе pretty print-a присутствовали комментарии?\
У нас сейчас они как в примерах описаны
    extend token IgnoreToken
    {
        | [SpanClass(Comment), ExplicitSpaces] SingleLineComment;
        | [SpanClass(Comment), ExplicitSpaces] MultiLineComment;
    }
Re: Nitra pretty print comments
От: hardcase Пират http://nemerle.org
Дата: 02.06.15 14:25
Оценка:
Здравствуйте, pekabon, Вы писали:

P>Подскажите плз, что нужно сделать чтобы в выхлопе pretty print-a присутствовали комментарии?\


К сожалению, сейчас это не поддерживается.
http://nemerle.org/Banners/?t=Developer!&g=dark /* иЗвиНите зА неРовнЫй поЧерК */
Re: Nitra pretty print comments
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.15 21:46
Оценка:
Здравствуйте, pekabon, Вы писали:

P>Подскажите плз, что нужно сделать чтобы в выхлопе pretty print-a присутствовали комментарии?


Пока никак. Постараемся придумать что-то в ближайшее время.

С какой целью нужны комментарии?
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Nitra pretty print comments
От: pekabon  
Дата: 05.06.15 07:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>С какой целью нужны комментарии?


Мы заготовку для скрипта, который будет редактировать пользователь, генерируем и добавляем туда комментарии.
На этом этапе для форматирования текста пользуемся парсером — парсим и делаем pretty print.
В принципе можем и сами обойтись — сгенерировать уже красивый скрипт.
Re[3]: Nitra pretty print comments
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.15 09:35
Оценка:
Здравствуйте, pekabon, Вы писали:

P>Мы заготовку для скрипта, который будет редактировать пользователь, генерируем и добавляем туда комментарии.

P>На этом этапе для форматирования текста пользуемся парсером — парсим и делаем pretty print.

То есть Коментарии вы хотите не из исходника брать, а собственные добавлять?
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Nitra pretty print comments
От: pekabon  
Дата: 08.06.15 14:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>То есть Коментарии вы хотите не из исходника брать, а собственные добавлять?


Из исходинка. Просто мы "рыбу" генерим в текстовом виде.
Re[2]: Nitra pretty print comments
От: pekabon  
Дата: 19.05.16 09:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Пока никак. Постараемся придумать что-то в ближайшее время.

VD>С какой целью нужны комментарии?

Нам опять понадобились комментарии в pretty print — для автоформатирования исходников в студии.
Ничего не придумалось?
Re[3]: Nitra pretty print comments
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.16 00:12
Оценка:
Здравствуйте, pekabon, Вы писали:

P>Нам опять понадобились комментарии в pretty print — для автоформатирования исходников в студии.

P>Ничего не придумалось?

По началу не верно прочел...

Тут есть следующие соображения. Можно добавить в дерево разбора ветки для S-ок (пробельных правил), но это сильно раздует дерево разбора.

Возможно лучше будет пойти одним из следующих путей:
1. Добывать информацию об s-ках (пробельных правуилах) через Walker.
2. Получать всю необходимую для форматирования информацию через Walker.

В первом случае вы так и будете использовать ParseTree, но информацию о пробельных правилах (содержащих коменты) будете получать отдельным вызовом.

Во втором можно обойтись вообще без ParseTree. Это сделает алгоритм быстрее (и возможно даже проще).

В любом случае вам нужно создать наследника класса WalkerBase и переопределить в нем нужные методы.

Посмотрите VoidRuleWalker — он делает нечто похожее на то что нужно вам. Он собирает информацию о пробельных правилах. Вам нужно будет сделать его аналог и несколько его усугубить вынимая и кишки пробельных правил.

Для понимания того как работают Walker-ы советую сделать фильтрацию по "Walker" в Solution Explorer нитровского проекта. Например, HighlightingWalker собирает информацию о ключевых словах и прочих токенах.

Возможно для форматирования вам лучше будет собрать список токенов (включая пробельные) для каждой конструкции и реализовать форматирвоание на нем.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Nitra pretty print comments
От: pekabon  
Дата: 20.05.16 10:47
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>По началу не верно прочел...


VD>Тут есть следующие соображения. Можно добавить в дерево разбора ветки для S-ок (пробельных правил), но это сильно раздует дерево разбора.


Понятно
А как вообще планируется применять встроенный Pretty printing, который печатает с учетом всяких nl, но выкидывает комментарии?
Re[5]: Nitra pretty print comments
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.16 14:54
Оценка:
Здравствуйте, pekabon, Вы писали:

P>Понятно

P>А как вообще планируется применять встроенный Pretty printing, который печатает с учетом всяких nl, но выкидывает комментарии?

Использовать прети-принт для форматирования мы не планировали никогда. Прети-принт он для других целей совсем.

Вопрос форматирования (если к нему подходить серьезно) он довольно не прост. Сейчас попробую описать все по подробнее.

Дело в том, что форматирование должно быть настраиваемым. Например, кто-то предпочитает ставить скобки так:
if (x)
{
}

а кто-то так:
if (x) {
}

Таких мест куча.

Вторая проблема заключается в том, что иногда форматирование может зависеть не от отдельной конструкции, а от контекста. Скажем при если конструкция вложена в некоторую другую, то это сочетание должно форматироваться особым образом.

По сему описывать форматирование маркерами не получится.

Была идея сделать внешнее описание форматирования в виде паттерн-матчинга.
Описываем паттерн:
if ($Expr) nl
{ inl
  $Statments nl d
}


У нас даже был прототип генератора поттерн-матчинга, но мы его выкинули, так как он не использовался, а его компиляция для рагамматики замедляла процесс компиляции в 2.5 раза.

Как временное решение можно докрутить прети-принт, чтобы он использовал содержимое пробельных (void) правил.

Можно даже сделать прети-принт Raw AST (бинарному AST-у). Для этого нужно сделать Walker в котором генерировать текст. Такое решение будет работать очень быстро и ему будет доступны все данные о дереве разбора (в том числе и внутренности пробельных правил).
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Nitra pretty print comments
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.05.16 22:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Тут есть следующие соображения. Можно добавить в дерево разбора ветки для S-ок (пробельных правил)


Нужно. Без этого про рефакторинг можно забыть.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[5]: Nitra pretty print comments
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.05.16 14:10
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Тут есть следующие соображения. Можно добавить в дерево разбора ветки для S-ок (пробельных правил)


AVK>Нужно. Без этого про рефакторинг можно забыть.


Отнюдь. Информация об s-ках есть в Raw-Parse Tree. Причем в очень детальном виде. В тории можно вообще без материализованного дерева разбора жить. И это несколько ускорит обработку. Просто это очень не просто реализовать.

В прочем, дерево разбора сейчас ленивое, так что жертвуем только дополнительными полями.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.