Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 12.08.09 13:44
Оценка: 87 (4)
Решил все-таки немного покопаться.

Вот что получилось.

Установленный Немерле на диске не требуется. Он уже включен в пакет. Саму интерграцию тоже устанавливать не надо — просто скопировать в папочку Addins\BackendBindings (туда где остальные языки). После чего должен появиться Немерле и тип проектов Console. Ну само собой должен быть ШарпДевелоп .

Что есть сейчас:
— подсветка синтаксиса из ХМЛ-ника. ХМЛ брал из SVN на nemerle.org
— компиляция идет через через билд-таргеты и билд-таск (Ncc) которые были вместе с CTP, соответственно список ошибок и ворнингов выводится
— дебаг вроде работает
нет автокомплита

Вот.
Если кто поможет разобраться с парсером, буду очень рад.
Re: Nemerle vs. SharpDevelop
От: Denom Украина  
Дата: 13.08.09 06:29
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вот что получилось.


Какая версия SharpDevelop поддерживается?
... << RSDN@Home 1.2.0 alpha 4 rev. 1181>>
Re[2]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 13.08.09 08:45
Оценка: 2 (1)
Здравствуйте, Denom, Вы писали:

ВВ>>Вот что получилось.

D>Какая версия SharpDevelop поддерживается?

3.0+
Re: Nemerle vs. SharpDevelop
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.09 12:22
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Что есть сейчас:

ВВ>- подсветка синтаксиса из ХМЛ-ника. ХМЛ брал из SVN на nemerle.org

Немерле использует динамические ключевые слова которые влючаются путем открытия пространств имен.
Так что подсветка на базе заранее заданного списка — это минимальное решение.
В проекте Nemerle.Compiler.Utils.nproj есть лексе который умеет подсвечивать код полноценно.

ВВ>- компиляция идет через через билд-таргеты и билд-таск (Ncc) которые были вместе с CTP, соответственно список ошибок и ворнингов выводится

ВВ>- дебаг вроде работает
ВВ>- нет автокомплита

Еще нет хинтов, навигции... в общем ничего кроме сборки.

ВВ>Вот.

ВВ>Если кто поможет разобраться с парсером, буду очень рад.

С парсером разбираться не надо. Это ровным счетом ничего не даст. Надо разобраться с проектом Nemerle.Compiler.Utils.nproj. В нем реализовано все что нужно для работы IDE. Я, правда, его сейчас усиленно рефакторю и переделываю, но тем не менее использовать его можно и я могу помочь с ним.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 14.08.09 12:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Немерле использует динамические ключевые слова которые влючаются путем открытия пространств имен.

VD>Так что подсветка на базе заранее заданного списка — это минимальное решение.
VD>В проекте Nemerle.Compiler.Utils.nproj есть лексе который умеет подсвечивать код полноценно.

Это я это понимаю.
Проблема в том, что подсветка в ШарпДевелопе строится на ХМЛ-нике. Там правда есть некий AdvancedHighlightingService — надо с ним поразбираться, возможно, тогда получится раскрашивать макросы.
Автокомплит в моем понимании более приоритетен

ВВ>>- компиляция идет через через билд-таргеты и билд-таск (Ncc) которые были вместе с CTP, соответственно список ошибок и ворнингов выводится

ВВ>>- дебаг вроде работает
ВВ>>- нет автокомплита
VD>Еще нет хинтов, навигции... в общем ничего кроме сборки.

Ага, и еще иконок нет
Я и не говорю, что это конец.

ВВ>>Вот.

ВВ>>Если кто поможет разобраться с парсером, буду очень рад.

VD>С парсером разбираться не надо. Это ровным счетом ничего не даст. Надо разобраться с проектом Nemerle.Compiler.Utils.nproj. В нем реализовано все что нужно для работы IDE. Я, правда, его сейчас усиленно рефакторю и переделываю, но тем не менее использовать его можно и я могу помочь с ним.


С парсером, не парсером — дело не в названии.
Этот проект я покопал и написал тебе на почту. Я правда смотрел CTP — может, что улучшилось серьезно в последних версиях?

Сейчас задача номер 1 прикрутить парсер Немерле в #D. Фактически нужно вернуть AST во внутреннем формате #D. С одной стороны имеющийся NemerleCodeParser подходит, с другой — там вроде как не сохраняется название о местоположении фрагмента в коде. А она нужна. Более того нужно даже такое:

AdvancedLinePragma : LinePragma
{
  int EndLine;
  int StartColumn;
  int EndColumn;
}


Задача номер 2 — сделать резолвер. Для этого нужно иметь по текущему положению курсора определять выражение, внутри которого мы находимся и возвращаться информацию о нем — к примеру, о предыдущем, до курсора, токене.
Я посмотрел имеющиеся интеграции — там эти задачи решаются врукопашную. Мне показалось, что в во всяких Nemerle.Utils может быть что-то полезное, но увы не нашел. В принципе резолвинг можно сделать по "мотивам" того, что используется для Шарпа.
Re[3]: Nemerle vs. SharpDevelop
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.09 13:35
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Проблема в том, что подсветка в ШарпДевелопе строится на ХМЛ-нике.


Это убогий подход. Он даже для Шарпа плохо подходит, так как и в шарпе есть что подсвечивать динамически (типы). Для немерла он совсем плох (причины я описал).
В общем, если других путей нет, то и этот пойдет.

ВВ>Там правда есть некий AdvancedHighlightingService — надо с ним поразбираться, возможно, тогда получится раскрашивать макросы.


Там не только макросы. Так что если заниматься серьезной поддержкой ШарпДевелопа, то следует разобраться с этим AdvancedHighlightingService.

ВВ>Автокомплит в моем понимании более приоритетен


Я смотрю на работу несколько по другому. Если делать только, то что более приоритетно то получится халтура. По-этому нужно все. Ты еще не упомянул такие фичи как сворачивание текста (фолдинг).

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

VD>>Еще нет хинтов, навигции... в общем ничего кроме сборки.


ВВ>Ага, и еще иконок нет

ВВ>Я и не говорю, что это конец.

Если ты собирашься заняться этим вопросом серьезно, а не ограничиться light-версией, то стучись ко мне в Skype (имя VladD2) и можно будет обсудить все более детально.

ВВ>С парсером, не парсером — дело не в названии.

ВВ>Этот проект я покопал и написал тебе на почту. Я правда смотрел CTP — может, что улучшилось серьезно в последних версиях?

В последних версиях многое изменилось. Я как раз сейчас виду работу по переводу этого проекта на внутренний теневой поток (ранее использовалась реализация от MS которая была никуда не годна).

ВВ>Сейчас задача номер 1 прикрутить парсер Немерле в #D. Фактически нужно вернуть AST во внутреннем формате #D. С одной стороны имеющийся NemerleCodeParser


NemerleCodeParser — это сырая фигня. Это раз.
А два, зачем вообще чего-то кому-то возвращать?
Комплит работает совсем по другому. Для его реализации нужно иметь построенное дерево типв и запустить специальный метод которому передать текст тела метода и координаты того места где производится попытка автодополнения. На выходе будет список описаний членов которые нужно как-то показать в комбе целевой IDE.
Но заниматься комплитом на пустом месте нельзя! Сначала нужно запустить всю подсистему теневого парсинга.

ВВ> подходит, с другой — там вроде как не сохраняется название о местоположении фрагмента в коде. А она нужна. Более того нужно даже такое:


ВВ>Задача номер 2 — сделать резолвер. Для этого нужно иметь по текущему положению курсора определять выражение, внутри которого мы находимся и возвращаться информацию о нем — к примеру, о предыдущем, до курсора, токене.


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

ВВ>Я посмотрел имеющиеся интеграции — там эти задачи решаются врукопашную. Мне показалось, что в во всяких Nemerle.Utils может быть что-то полезное, но увы не нашел. В принципе резолвинг можно сделать по "мотивам" того, что используется для Шарпа.


Не, ну, упорным и флаг в руки. Можешь заниматься любой ерудой, то тогда я тебе уже не помошник. То что ты говорить — это мягко говоря видение основанное на поверхностном понимании проблемы.

В общем, если ты желаешь получить реальный результат, то стоит прислушаться к моим словам. В ином случае я тебе гарантирую, что результат будет никуда не годный (и, естественно, я участвовать в этом не буду).
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 14.08.09 13:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это убогий подход. Она даже для Шарпа плохо подходит, так как и в шарпе есть что подсвечивать динамически (типы). Для немерла он совсем плох (причины я описал).

VD>В общем, если других путей нет, то и этот пойдет.
ВВ>>Там правда есть некий AdvancedHighlightingService — надо с ним поразбираться, возможно, тогда получится раскрашивать макросы.
VD>Там не только макросы. Так что если заниматься серьезной поддержкой ШарпДевелопа, то следует разобраться с этим AdvancedHighlightingService.

Я и не говорил, что не буду разбираться

ВВ>>Автокомплит в моем понимании более приоритетен

VD>Я смотрю на работу несколько по другому. Если делать только, то что более приоритетно то получится халтура. По-этому нужно все. Ты еще не упомянул такие фичи как сворачивание текста (фолдинг).

Под "более приоритетен" я имею в виду очередность выполнения задач, не более. Фолдинг появится by design вместе с работающим class view с навигацией как только будет LinePragma

VD>Что же до комплита, то ему все равно нужна информация о токене для которого производится автодополнение. Кроме того для автодополнение требует наличия построенного дерева типов. Так что имеет смысл делать все по порядку.


Я так и стараюсь делать. Смотри, там есть такие сервисы (упрощенно):

1. IParser
2. IExpressionFinder
3. IResolver
4. IAdvancedHighligher

Например, там нет какого-то специального IHintService или IFoldingService. Сейчас занимаюсь п. 1. Как только он заработает — заработает фолдинг и навигаций.
Как только будут сделаны IExpressionFinder и IResolver — будут хинты и авто-комплит. И так далее.

VD>>>Еще нет хинтов, навигции... в общем ничего кроме сборки.


ВВ>>Ага, и еще иконок нет

ВВ>>Я и не говорю, что это конец.
VD>Если ты собирашься заняться этим вопросом серьезно, а не ограничиться light-версией, то стучись ко мне в Skype (имя VladD2) и можно будет обсудить все более детально.

А ICQ, MSN нет?

VD>NemerleCodeParser — это сырая фигня. Это раз.


Да, плохо Хотя я подозревал...

VD>А два, зачем вообще чего-то кому-то возвращать?

VD>Комплит работает совсем по другому. Для его реализации нужно иметь построенное дерево типв и запустить специальный метод которому передать текст тела метода и координаты того места где производится попытка автодополнения. На выходе будет список описаний членов которые нужно как-то показать в комбе целевой IDE.
VD>Но заниматься комплитом на пустом месте нельзя! Сначала нужно запустить всю подсистему теневого парсинга.

Блин, я тебе и пытаюсь объяснить. ШарпДевелоп делает все сам. От тебя требует реализации конкретных интерфейсов. Чтобы вся эта фигня заработала нужно прежде всего реализовать интерфейс:

IParser
{
   ICompilationUnit Parse(string source);
}


Без этого никак. ICompilationUnit — DOM модель ШарпДевелопа, которая содержит информацию о строках и колонках.

ВВ>> подходит, с другой — там вроде как не сохраняется название о местоположении фрагмента в коде. А она нужна. Более того нужно даже такое:


ВВ>>Задача номер 2 — сделать резолвер. Для этого нужно иметь по текущему положению курсора определять выражение, внутри которого мы находимся и возвращаться информацию о нем — к примеру, о предыдущем, до курсора, токене.

VD>Не надо ничего подобного делать. Все уже сделано на более высоком уровне.

Ну реализация-то требуется именно на этом уровне.

ВВ>>Я посмотрел имеющиеся интеграции — там эти задачи решаются врукопашную. Мне показалось, что в во всяких Nemerle.Utils может быть что-то полезное, но увы не нашел. В принципе резолвинг можно сделать по "мотивам" того, что используется для Шарпа.

VD>Не, ну, упорным и флаг в руки. Можешь заниматься любой ерудой, то тогда я тебе уже не помошник. То что ты говорить — это мягко говоря видение основанное на поверхностном понимании проблемы.

Это видение, основанное на понимании того, как это сделано в ШарпДевелопе. Переписывать ШарпДевелоп, чтобы все работало "правильно", я не буду.

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


Если ты хочешь руководить процессом — что и как нужно делать — ради бога, я не против. Но тогда познакомься сначала с той моделью, с помощью которой расширяется ШарпДевелоп.
Re[5]: Nemerle vs. SharpDevelop
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.09 14:26
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Под "более приоритетен" я имею в виду очередность выполнения задач, не более. Фолдинг появится by design вместе с работающим class view с навигацией как только будет LinePragma


Дык очередность нужно выдерживать не из популистский соображений, а исходя из зависимостей. Первое что нужно сделать — это заставить IDE загрузить проект немерла в компилятор (предсавленный тем самым классом Engine) и научить эту IDE давать запросы на обновление исходника. Без этого ничего корректно работать не будет.

ВВ>Я так и стараюсь делать. Смотри, там есть такие сервисы (упрощенно):


ВВ>1. IParser

ВВ>2. IExpressionFinder
ВВ>3. IResolver

Вот эти (с вероятностью 90%) просто в лес. В прочем, конечно не плохо было бы посмотреть их описания.

ВВ>4. IAdvancedHighligher


А вот это, возможно, можно использовать для полноценной раскраски немерла. Опять же без описания сказать ничего нельзя.

ВВ>Например, там нет какого-то специального IHintService или IFoldingService. Сейчас занимаюсь п. 1. Как только он заработает — заработает фолдинг и навигаций.


Ну, не зная их устройства я не могу сказать как и что нужно сопрягать. Я тебе только точно могу скзать, что без использования движка интеграции ты ничего хорошего не получишь.

ВВ>Как только будут сделаны IExpressionFinder и IResolver — будут хинты и авто-комплит. И так далее.


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

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

VD>>Если ты собирашься заняться этим вопросом серьезно, а не ограничиться light-версией, то стучись ко мне в Skype (имя VladD2) и можно будет обсудить все более детально.


ВВ>А ICQ, MSN нет?


Можно через MSN (ник тот же), но Скайп в сто раз удобнее. МСН портит код и ограничивает буфер. Голосом общаться по нему вообще плохо. А ICQ вообще почти не использую. Беждарный сервис.

VD>>NemerleCodeParser — это сырая фигня. Это раз.


ВВ>Да, плохо Хотя я подозревал...


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

ВВ>Блин, я тебе и пытаюсь объяснить. ШарпДевелоп делает все сам.


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

ВВ>От тебя требует реализации конкретных интерфейсов. Чтобы вся эта фигня заработала нужно прежде всего реализовать интерфейс:


ВВ>
ВВ>IParser
ВВ>{
ВВ>   ICompilationUnit Parse(string source);
ВВ>}
ВВ>


Уже что-то. А где описание ICompilationUnit?

Короче, приведи описания всех интерфейсов с описаниями (что они делают) и тгда можно будет поговорит более конкретно.

ВВ>Без этого никак. ICompilationUnit — DOM модель ШарпДевелопа, которая содержит информацию о строках и колонках.


Это общие слова. Нужна конкретика.
Скажем в движке интеграции у нас тоже есть очень похожий метод:
BeginUpdateCompileUnit(source : ISource, newEndIndex : int, newEndLine : int, oldEndIndex : int, oldEndLine : int, startIndex : int, startLine : int)

он в результате приводит к формированию класса CompileUnit который в том числе предоставляет описанную тобой информацию. Но есть множество деталей.
Возможно немного подумав можно будет написать некий адаптер который позволит реализовать их и нтерфейсы.
А возможно нужно капать чуть глубже и использовать более низкоуровневые сервисы. Уверен, то они есть в шарпдевелопе.

ВВ>Ну реализация-то требуется именно на этом уровне.


От тебя требуется реализация интерфейсов, а не логики. Улавливаешь разницу?

ВВ>Это видение, основанное на понимании того, как это сделано в ШарпДевелопе. Переписывать ШарпДевелоп, чтобы все работало "правильно", я не буду.


1. Я не уверен в том, что ты полностю понимаешь как сделан ШарпДевелоп. Думаю, что там есть сервисы разных уровней. Если они не идиоты, то должны понимать, что есть языки не подпадающие под общие кальки.
2. Кроме понимания того как усроен ШарпДевелоп нужно еще понимать, то как устроен компилятор и язык интегрируемый в него.

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

ВВ>Если ты хочешь руководить процессом — что и как нужно делать — ради бога, я не против. Но тогда познакомься сначала с той моделью, с помощью которой расширяется ШарпДевелоп.


Я не хочу руководить. Но если я что-то объясняю, то нужно к этому прислушиваться. Я трачу свое время и не хочу делать это в пусту.
Я буду рад если из твоего начиания что-то выйдет (у предыдущих товарищей не выло ничего путного). И именно по этому предостерегаю от неконструктивных действий.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 14.08.09 15:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Дык очередность нужно выдерживать не из популистский соображений, а исходя из зависимостей.


Я выдерживаю, исходя из тех зависимостей, которые навязывает #D. Ну поверь мне, он не такой расширяемый как ты думаешь. Т.е. если взять конечно его, сделать свой бранч и начать полосовать исходники, то можно чего-то добавить, но используя готовую базу SharpDevelop.Base, SharpDevelop.Dom — нельзя. А это по сути и есть сердце IDE.
Т.е. то, что ты говоришь — это по сути разработка какого-то собственного RsdnDevelop.

VD>Первое что нужно сделать — это заставить IDE загрузить проект немерла в компилятор (предсавленный тем самым классом Engine) и научить эту IDE давать запросы на обновление исходника. Без этого ничего корректно работать не будет.

ВВ>>Я так и стараюсь делать. Смотри, там есть такие сервисы (упрощенно):
ВВ>>1. IParser
ВВ>>2. IExpressionFinder
ВВ>>3. IResolver
VD>Вот эти (с вероятностью 90%) просто в лес. В прочем, конечно не плохо было бы посмотреть их описания.

А у тебя есть #D?

ВВ>>4. IAdvancedHighligher

VD>А вот это, возможно, можно использовать для полноценной раскраски немерла. Опять же без описания сказать ничего нельзя.

Я в соседнем посте приводил. К сожалению, он запускается после первого прохода, используя его данные. Но тут, как я сказал, 100% уверенности нет.

ВВ>>Например, там нет какого-то специального IHintService или IFoldingService. Сейчас занимаюсь п. 1. Как только он заработает — заработает фолдинг и навигаций.

VD>Ну, не зная их устройства я не могу сказать как и что нужно сопрягать. Я тебе только точно могу скзать, что без использования движка интеграции ты ничего хорошего не получишь.
ВВ>>Как только будут сделаны IExpressionFinder и IResolver — будут хинты и авто-комплит. И так далее.
VD>Ну, может быть эти интерфейсы можно как-то реализовать через движок интеграции. Чтобы понять — это нужно видить описания интерфейсов и знать как эти интерфейсы дергаются IDE (как их применяют).

IResolver
{
ArrayList CtrlSpace(int caretLine, int caretColumn, ParseInformation parseInfo, string fileContent, ExpressionContext context);
ResolveResult Resolve(ExpressionResult expressionResult, ParseInformation parseInfo, string fileContent);
}

IExpressionFinder
{
ExpressionResult FindExpression(string text, int offset); //1
ExpressionResult FindFullExpression(string text, int offset); //2
}



IResolver работает с результатами IExpressionFinder.
Обычная логика их работы такова:
IExpressionFinder просто находит выражение примитивным разбором. Метод 1 до текущей позиции курсора, метод 2 — после. А интеллектуальный парсинг уже совершает IResolver, который работает с результатами IExpressionFinder.

VD>Самому же тебе ни в жизни не реализовать тот самый резолвинг, так как он делается на основании типизированного AST который вне рамок проекта просто нельзя получить.


Вот, именно этот самый типизированный AST я и хочу получить

VD>Там даже проблема не в том, что он сыр. Проблема в том, что он просто исходно ограничен. В общем, забудь про него. Это тупиковый путь.


ОК, забыл. Но все равно нужен парсер

VD>Уже что-то. А где описание ICompilationUnit?


В ICSharpCode.SharpDevelop.Dom. Это их внутренняя ДОМ модель.

VD>От тебя требуется реализация интерфейсов, а не логики. Улавливаешь разницу?


Мы пока ходим по кругу. Для #D первый шаг для серьезного биндинга — это именно реализация интерфейса IParser, который я приводил. ParserService — статический класс в "базе", который нельзя подменить. AST должно содержать информацию о локейшинах. И именно этот интерфейс от меня и требуется.

ВВ>>Это видение, основанное на понимании того, как это сделано в ШарпДевелопе. Переписывать ШарпДевелоп, чтобы все работало "правильно", я не буду.


VD>1. Я не уверен в том, что ты полностю понимаешь как сделан ШарпДевелоп. Думаю, что там есть сервисы разных уровней. Если они не идиоты, то должны понимать, что есть языки не подпадающие под общие кальки.


ШарпДевелоп вообще делался как ИДЕ для Шарпа. Пока что я вижу, что многие вещи там интегрированы по самое не могу.

VD>2. Кроме понимания того как усроен ШарпДевелоп нужно еще понимать, то как устроен компилятор и язык интегрируемый в него.


Ну для этого ты и есть

VD>У немерла есть свои особенности которые нужно учитывать. Скажем типизация у него сильно медленее нежели у шарпа и просто на каждый чих перетипизировать весь проект или весь файл нельзя. Потом нельзя перетипизировать отдельный файл, так как есть макросы которые раскрываютя в процессе типизации. Это делается толко на урове проекта.


Мда, об этом я конечно не подумал
Плохо на самом деле. #D вообще сам решает, что и когда парсить. Парсер тут как бы камень преткновения — без него нельзя и с ним невозможно. Всем рулит статический ParserService, который в частности делает:

public static IParser GetParser(string fileName) {}

ВВ>>Если ты хочешь руководить процессом — что и как нужно делать — ради бога, я не против. Но тогда познакомься сначала с той моделью, с помощью которой расширяется ШарпДевелоп.

VD>Я не хочу руководить. Но если я что-то объясняю, то нужно к этому прислушиваться. Я трачу свое время и не хочу делать это в пусту.
VD>Я буду рад если из твоего начиания что-то выйдет (у предыдущих товарищей не выло ничего путного). И именно по этому предостерегаю от неконструктивных действий.

Мне кажется тут надо ставить вопрос так: какие возможности *вообще* можно реализовать посредством ШарпДевелопа.
Re[7]: Nemerle vs. SharpDevelop
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.09 15:59
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я выдерживаю, исходя из тех зависимостей, которые навязывает #D. Ну поверь мне, он не такой расширяемый как ты думаешь. Т.е. если взять конечно его, сделать свой бранч и начать полосовать исходники, то можно чего-то добавить, но используя готовую базу SharpDevelop.Base, SharpDevelop.Dom — нельзя. А это по сути и есть сердце IDE.


Давай начнем с двух вещей.
У него доступны исходники и какая-то дукументация к ним?

ВВ>Т.е. то, что ты говоришь — это по сути разработка какого-то собственного RsdnDevelop.


Я так не думаю.

ВВ>А у тебя есть #D?


Нет. Зачем он мне?

ВВ>Я в соседнем посте приводил. К сожалению, он запускается после первого прохода, используя его данные. Но тут, как я сказал, 100% уверенности нет.


Ну, дык давай доки и/или исходники и поглядим.

ВВ>
ВВ>IResolver
ВВ>{
ВВ>  ArrayList CtrlSpace(int caretLine, int caretColumn, ParseInformation parseInfo, string fileContent, ExpressionContext context);
ВВ>  ResolveResult Resolve(ExpressionResult expressionResult, ParseInformation parseInfo, string fileContent);
ВВ>}

ВВ>IExpressionFinder
ВВ>{
ВВ>  ExpressionResult FindExpression(string text, int offset); //1
ВВ>  ExpressionResult FindFullExpression(string text, int offset); //2
ВВ>}
ВВ>


Нужны описания ParseInformation, ExpressionResult и ExpressionContext. Если это абстрактные типы, то с большой вероятностью их можно реализовать через адапетры. Плохо, только, что они передают просто текст.

ВВ>IResolver работает с результатами IExpressionFinder.

ВВ>Обычная логика их работы такова:
ВВ>IExpressionFinder просто находит выражение примитивным разбором. Метод 1 до текущей позиции курсора, метод 2 — после. А интеллектуальный парсинг уже совершает IResolver, который работает с результатами IExpressionFinder.

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

ВВ>Вот, именно этот самый типизированный AST я и хочу получить


А для этого нужно сделать все что я описал. Да и глупо работать на таком низком уровне как типизированное АСТ. Это очень тяжело.

ВВ>ОК, забыл. Но все равно нужен парсер


Еще раж. Парсера мало. Нужен весь компилятор.

VD>>Уже что-то. А где описание ICompilationUnit?


ВВ>В ICSharpCode.SharpDevelop.Dom. Это их внутренняя ДОМ модель.


Ужас. Зачем она? В приведенных тобой интерфейсах ничего подобного нет.

VD>>От тебя требуется реализация интерфейсов, а не логики. Улавливаешь разницу?


ВВ>Мы пока ходим по кругу. Для #D первый шаг для серьезного биндинга — это именно реализация интерфейса IParser, который я приводил. ParserService — статический класс в "базе", который нельзя подменить. AST должно содержать информацию о локейшинах. И именно этот интерфейс от меня и требуется.


Что ты привел? Не уже ли не ясно, что приводить интерфес без описания типов в нем используемых — это бесполезное занятие. Еще раз повторяю вопрос. Где описание ICompilationUnit? И типов в нем используемых?

ВВ>ШарпДевелоп вообще делался как ИДЕ для Шарпа. Пока что я вижу, что многие вещи там интегрированы по самое не могу.


Не надо личных впечатлений. То что я успел прочесть в гугле уже говорит о том, что начиная с 2.0 ШарпДев был перепроектирован для поддержки разных языков. А начиная с 3.0 они что-то там намудрили. Вот и надо разобраться в том, что именно и зачем.

VD>>2. Кроме понимания того как усроен ШарпДевелоп нужно еще понимать, то как устроен компилятор и язык интегрируемый в него.


ВВ>Ну для этого ты и есть


Если ты хочешь что-то сделать, то это надо понять и тебе. Хотя бы общих чертах.

ВВ>Плохо на самом деле. #D вообще сам решает, что и когда парсить.


Это действительно плохо. Уж насколько тупой, мне казалось, то как спроектирована Студия. Но чтобы вот так вот тупо... это уже перебор.
Остается надеяться, что ты все же не доконца понял их дизайн. Все что ты пока приводил довольно абстрактно.

ВВ>Парсер тут как бы камень преткновения — без него нельзя и с ним невозможно. Всем рулит статический ParserService, который в частности делает:


ВВ>public static IParser GetParser(string fileName) {}


Ну, и опять ничего особенного. Ну, мало ли просят у тебя какой-то интерфейс. Его может реализовать объект который сам будет думать, что и когда делать.

ВВ>Мне кажется тут надо ставить вопрос так: какие возможности *вообще* можно реализовать посредством ШарпДевелопа.


Для этого нужно знать его АПИ и особенности.

У него доступны исходники?
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 14.08.09 16:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Давай начнем с двух вещей.

VD>У него доступны исходники

Под GPL.
http://icsharpcode.net
ну и на сурсфордже конечно же он есть.

VD>и какая-то дукументация к ним?


С комментариями к коду хреновато
Есть материалы на сайте.
Есть в принципе изданная книга, но она относится к 1.0 и сейчас малополезная.

ВВ>>Т.е. то, что ты говоришь — это по сути разработка какого-то собственного RsdnDevelop.

VD>Я так не думаю.
ВВ>>А у тебя есть #D?

VD>Нет. Зачем он мне?


Ну чтобы посмотреть, о чем мы говорим.

ВВ>>ОК, забыл. Но все равно нужен парсер

VD>Еще раж. Парсера мало. Нужен весь компилятор.

ОК, понял.

VD>>>Уже что-то. А где описание ICompilationUnit?

ВВ>>В ICSharpCode.SharpDevelop.Dom. Это их внутренняя ДОМ модель.
VD>Ужас. Зачем она? В приведенных тобой интерфейсах ничего подобного нет.

Для фолдинга и класс вью по крайней мере. ICompilationUnit же у меня был в интерфейсах.

VD>Что ты привел? Не уже ли не ясно, что приводить интерфес без описания типов в нем используемых — это бесполезное занятие. Еще раз повторяю вопрос. Где описание ICompilationUnit? И типов в нем используемых?


Я тебе выше написал — это ICSharpCode.SharpDevelop.Dom
Ты хочешь чтобы я привел описание *всех* типов их коде-дома в рамках поста??

ВВ>>ШарпДевелоп вообще делался как ИДЕ для Шарпа. Пока что я вижу, что многие вещи там интегрированы по самое не могу.

VD>Не надо личных впечатлений. То что я успел прочесть в гугле уже говорит о том, что начиная с 2.0 ШарпДев был перепроектирован для поддержки разных языков. А начиная с 3.0 они что-то там намудрили. Вот и надо разобраться в том, что именно и зачем.

Ну я как бы в код смотрю, а не в гугл. Скачай код действительно и посмотри. А то и правда все слишком "абстрактно" получается.

ВВ>>Парсер тут как бы камень преткновения — без него нельзя и с ним невозможно. Всем рулит статический ParserService, который в частности делает:

ВВ>>public static IParser GetParser(string fileName) {}
VD>Ну, и опять ничего особенного. Ну, мало ли просят у тебя какой-то интерфейс. Его может реализовать объект который сам будет думать, что и когда делать.

Интерфейс то они тоже сами дергают, четко указывая, что он должен парсить. Причем заметь — парсер создается для файла.
Re[9]: Nemerle vs. SharpDevelop
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.09 19:09
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

Посмотрел исходники...

Если кратко, то я бы просто выбросил эту идею.

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

Теперь, что касается залезания на низком уровне.

В прицепи это возможно. Все сделано через наследование и фабрики, так что можно создать свой тип представления (вместо TextEditorDisplayBindingWrapper) который не подчиняется правилам парсинга используемым в ParserService. Но при этом прийдется тоже реализовать много кода, так как все что писали разработчики шарп-девелопа для этих целей идет в лес. Боюсь, что при этом будут проблемы с отладчиком. Так как на TextEditorDisplayBindingWrapper завязано много чего.


Возможно что-то можно придумать если заняться хаками. Например, фолдинг можно реализовать создав свою реализацию IFoldingStrategy и сопоставив ее с расширением .n.
В ШарпДевелопе имеются следующие стратегии:
* IFoldingStrategy
* IFormattingStrategy
* IHighlightingStrategy
* IHighlightingStrategyUsingRuleSets
* ITextBufferStrategy

При этом IHighlightingStrategy очень убогая и вряд ли позволит сделать то что нужно. Что такое IHighlightingStrategyUsingRuleSets я с наскоку не понял, но возможно с то что нужно. ITextBufferStrategy — это интерфейс к редактированию текста, но там ничего интересного нет. IFoldingStrategy пригоден для дела и полностью решает проблему фолдинга без необходимости использования их высокоуровневого АПИ.

ЗЫ

Теперь вопрос. Зачем мучатся?
Что даст наличие поддержки ШарпДевелопа?
Под виндой у нас будет NExpress который позволит получить бесплатную IDE всем желающим.
Работает ли ШарпДевелопа под Линукс?

Если, нет, то я считаю, что ломать копья не стоит. Возможно имело бы смысл попробовать рассмотреть вопрос реанимации работы над МоноДевелопом.
Если его разработчини не были так наивны как разработчики ШарпДевелопа, то возможно они оставили полноценный низкоуровневый АПИ к своей IDE и интеграцию к ней будет сделать проще.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 14.08.09 19:30
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Возможно что-то можно придумать если заняться хаками. Например, фолдинг можно реализовать создав свою реализацию IFoldingStrategy и сопоставив ее с расширением .n.


Фолдинг можно сделать и просто реализовав/использовав "простой" парсер а ля коде-дом парсер, который к примеру будет возвращать дерево классов-мемберов для текущего файла. Это будет проще, а результат вроде тот же самый.
Все что нужно — докрутить ваш NemerleCodeParser чтобы он возвращал локейшины в файле.
Возможно, этого хватит и для класс вью.

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

VD>Теперь вопрос. Зачем мучатся?

VD>Что даст наличие поддержки ШарпДевелопа?

Ну я говорил свою точку зрения на этот вопрос — ИДЕ, конечно, не идеальная, но у нее есть определенная комьюнити и если включить Nemerle в пакет SharpDevelop, то это все-таки несколько повысит привлекательность языка. 99% создадут проект, чтобы посмотреть из любопытства.
ИДЕ опенсурная, бесплатная в отличие от студии, полностью манагед. Иметь в ней поддержку опенсурного компилятора для дотнет вполне логично.

Мне казалось, что можно добавить поддержку Немерле на уровне того же Бу. Хотя ты зародил во мне сомнения

Я бы все-таки попробовал понять на каком уровне можно добавить поддержку автокомплита без переписывания ШарпДевелопа.
Re[3]: Nemerle vs. SharpDevelop
От: jenyavb  
Дата: 14.08.09 19:37
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Проблема в том, что подсветка в ШарпДевелопе строится на ХМЛ-нике. Там правда есть некий AdvancedHighlightingService — надо с ним поразбираться, возможно, тогда получится раскрашивать макросы.

ВВ>Автокомплит в моем понимании более приоритетен

Порылся немного в SD. Насчет подсветки — скорее всего нужно реализовать свой IAdvancedHighlighter. Для автокомплита — ICodeCompletionBinding. Возможно там уже есть некие базовые реализации. Нужно изучить имеющиеся биндинги для языков в /Addins/Backends, и на их примере делать биндинг для немерле.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[4]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 14.08.09 19:41
Оценка:
Здравствуйте, jenyavb, Вы писали:

J>Порылся немного в SD. Насчет подсветки — скорее всего нужно реализовать свой IAdvancedHighlighter. Для автокомплита — ICodeCompletionBinding. Возможно там уже есть некие базовые реализации. Нужно изучить имеющиеся биндинги для языков в /Addins/Backends, и на их примере делать биндинг для немерле.


Вот проблема как раз в том, что на их примере нормальный автокомплит для Немерле не получится.
Re[11]: Nemerle vs. SharpDevelop
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 14.08.09 19:47
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, VladD2, Вы писали:


VD>>Возможно что-то можно придумать если заняться хаками. Например, фолдинг можно реализовать создав свою реализацию IFoldingStrategy и сопоставив ее с расширением .n.


ВВ>Фолдинг можно сделать и просто реализовав/использовав "простой" парсер а ля коде-дом парсер, который к примеру будет возвращать дерево классов-мемберов для текущего файла. Это будет проще, а результат вроде тот же самый.

ВВ>Все что нужно — докрутить ваш NemerleCodeParser чтобы он возвращал локейшины в файле.
ВВ>Возможно, этого хватит и для класс вью.

А какая надобность в парсере для фолдинга Немерле? Ведь всё что нужно, это складывание по скобкам и регионам. В Виме это реализовано в две строчки регулярными выражениями:

syn region nemerleRegion start="#region" end="#endregion" transparent keepend extend fold
syn region nemerleBlock start="{" end="}" transparent fold
Ce n'est que pour vous dire ce que je vous dis.
Re[12]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 14.08.09 19:51
Оценка:
Здравствуйте, Don Reba, Вы писали:

Ну это даже по моим меркам совсем уж фигня
А если скобочки отключить?

У меня вот тоже в Programmers Notepad фолдинг для Немерле — и ничего, вроде работает. Только вот не совсем так, как в студии. И даже как в ШарпДевелопе.

К тому же уже есть парсер КодеДома — надо лишь заполнять там LinePragma. И потратить часик-другой на конвертацию Коде-Дома — и будет *полноценный* фолдинг.
Re[13]: Nemerle vs. SharpDevelop
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 14.08.09 20:01
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну это даже по моим меркам совсем уж фигня


Что-то не вижу чем это хуже. Сравнивая с C# в Студии — результат, на мой взгляд, одинаковый.

ВВ>А если скобочки отключить?


В Виме для складывания по отступам достаточно сказать ":set fdm=indent", но и вручную это реализуется в несколько строк.
Ce n'est que pour vous dire ce que je vous dis.
Re[11]: Nemerle vs. SharpDevelop
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.09 20:07
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Фолдинг можно сделать и просто реализовав/использовав "простой" парсер а ля коде-дом парсер, который к примеру будет возвращать дерево классов-мемберов для текущего файла. Это будет проще, а результат вроде тот же самый.


Несомненно можно. Вопрос только в том разумно ли писать парсер при наличии оного?

ВВ>Все что нужно — докрутить ваш NemerleCodeParser чтобы он возвращал локейшины в файле.

ВВ>Возможно, этого хватит и для класс вью.

А, ну-ну. Значит ты пропустим мимо ушей все что я говорил.

ВВ>Вообще все эта их модель с ХХХStrategy была придумана еще в 2002 и расширение на самом деле на них не строится. Т.е. с одной стороны вроде можно подменить конкретную реализацию, с другой — если ее убирать вместе с ней отваливается туева хуча кода.


Что касается фолдинга, то там все ОК. Там фабрика классов. А вот с стальным задница, так как ни стратегий, ни фабрик попросту нет.

VD>>Теперь вопрос. Зачем мучатся?

VD>>Что даст наличие поддержки ШарпДевелопа?

ВВ>Ну я говорил свою точку зрения на этот вопрос — ИДЕ, конечно, не идеальная, но у нее есть определенная комьюнити и если включить Nemerle в пакет SharpDevelop, то это все-таки несколько повысит привлекательность языка. 99% создадут проект, чтобы посмотреть из любопытства.


Боюсь, что если не обеспечить качество, то это будет последний Nemerle-проект этих самых 99%-ов.

ВВ>ИДЕ опенсурная, бесплатная в отличие от студии, полностью манагед. Иметь в ней поддержку опенсурного компилятора для дотнет вполне логично.


Мой вопрос был в том нужно ли это, а не логично или не логично.
Опенсорсность и управляемость не дают реальных приемуществ на рынке.

ВВ>Мне казалось, что можно добавить поддержку Немерле на уровне того же Бу. Хотя ты зародил во мне сомнения


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

ВВ>Я бы все-таки попробовал понять на каком уровне можно добавить поддержку автокомплита без переписывания ШарпДевелопа.


Еще раз на пальцах. Для поддержки комплита нужно собрать проект в памяти. Делать это в разных потоках и без явно выраженной стадии типизации в немерле нельзя. Первое проблема раелизации компилятора (он однопоточный), второе — иделогическая проблема. В немерле есть момент когда происходит построение дерева типов и момент когда происходит связывание типов для членов типов. В этоти моменты выполняются некоторые типы макросов. Посему должен быть один выделеный поток в котором производятся эти операции. В ШарпДевелопе это не так.

В общем, если ты хочешь попытать счастье, то тебе как-то нужно обойти их подсистему парсинга. Реализовать все эти IParser, IResolver и т.п., но так чтобы они были полнейшими заглушками и внутри просто использовали информацию генерируемую нормальным парсером.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Nemerle vs. SharpDevelop
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.08.09 20:10
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>А какая надобность в парсере для фолдинга Немерле? Ведь всё что нужно, это складывание по скобкам и регионам. В Виме это реализовано в две строчки регулярными выражениями:


DR>
syn region nemerleRegion start="#region" end="#endregion" transparent keepend extend fold
DR>syn region nemerleBlock start="{" end="}" transparent fold


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