Re[12]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 14.08.09 20:50
Оценка:
Здравствуйте, VladD2, Вы писали:

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

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

Неразумно. В силу чего возвращаемся к первоначальном вопросу
Автор: Воронков Василий
Дата: 11.08.09
.

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

ВВ>>Возможно, этого хватит и для класс вью.
VD>А, ну-ну. Значит ты пропустим мимо ушей все что я говорил.

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

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

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

Да с фолдингом и так все ОК, смысла нету лезть глубже.

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

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

Ну т.е. ты настроен депрессивно?

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

VD>А каков уровень того же Бу?

Ну запусти #D, посмотри.

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


Слушай, я вообще затронул эту тему, потому что думал, что у тебя есть представление о возможностях ШарпДевелопа. И, честно говоря, ожидал, что ты меня пошлешь сразу
На мой взгляд ограниченная поддержка в #D лучше чем полное ее отсутствие.
Ограниченная поддержка автокомплита лучше чем отсутствие автокомплита вообще.
Ограниченная означает, к примеру, что можно делать автокомплит только для тех библиотек, который висят в референсах.

Если тебе больше нравится вариант "все или ничего", то тут я спорить не буду
Еще раз повторюсь — мне казалось, что для проекта это полезно. Проект по большому счету твой, так что тебе решать.
Re[12]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 14.08.09 20:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В общем, если ты хочешь попытать счастье, то тебе как-то нужно обойти их подсистему парсинга. Реализовать все эти IParser, IResolver и т.п., но так чтобы они были полнейшими заглушками и внутри просто использовали информацию генерируемую нормальным парсером.


Вот что такое "нормальный парсер" в данном случае и непонятно. В идеале тот же IParser должен возвращать уже типизированное дерево, причем дергаться он будет очень часто. Для того, чтобы получить полностью типизированное дерево одного парсера Немерле недостаточно, как ты мне прекрасно показал. И тут же возникают вопросы с производительностью
Re[14]: Nemerle vs. SharpDevelop
От: Воронков Василий Россия  
Дата: 14.08.09 21:35
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>Здравствуйте, Воронков Василий, Вы писали:


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


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


Отличий много.
Сворачивание комментариев — причем однострочных — единым блоком.
Сворачивание юзингов.
Одна и та же реализация работает и со скобочками и без, что для Немерле актуально.
Re[13]: Проблема с r8293
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.08.09 14:21
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


Парсер не производит типизацию.
В немерле этой задачей занимается типизатор (Typer). в идеологии #Дева это задача Resolver-а.
он должен производить типизацию локально и для текущего НЕ типизированного дерева.
Для шарпа создать подобный ресолвер не сложно. Для языка поддерживающего макросы и вывод типов — нет.
Более того #Д подразумевает, для него лочно будет делаться отдельный парсер и отдельный ресолвер.
Но для немерла — это слишком большая задача (неподемная для энтузиастов).
Посему мы используем основной компилятор.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Проблема с r8293
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.08.09 14:50
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


NemerleCodeParser — никуда не годен. Но есть парсер который можно использосвать для парсинга отдельных файлов. Но есть две проблемы: 1) он не расчитан на работу в разных потоках, 2) его мало для реализации таких вещей как комплит и подсказки.

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

ВВ>На мой взгляд ограниченная поддержка в #D лучше чем полное ее отсутствие.
ВВ>Ограниченная поддержка автокомплита лучше чем отсутствие автокомплита вообще.
ВВ>Ограниченная означает, к примеру, что можно делать автокомплит только для тех библиотек, который висят в референсах.

Ты просто не понимаешь, что не будет никакого комплита. Ни хорошего ни плохого.
Для комплита нужно понять контекст. Ачтобы его понять нужно типизиовать тело метода в котором происходит комплит и связать типы всех членов в дереветипов (кстати дерево типов еще нужно построить). Парсер всего этого не делает.

ВВ>Если тебе больше нравится вариант "все или ничего", то тут я спорить не буду

ВВ>Еще раз повторюсь — мне казалось, что для проекта это полезно. Проект по большому счету твой, так что тебе решать.

На мой взгляд лучше иметь одну добротную IDE нежели две неполноценные. Посему я продолжу работу над Интеграцией с VS.

Если ты всеже хочешь повозиться с #д, то советую выбрать стратегию обхода их стратегии.

Для начала нужно научиться перехватывать события отрытия/закрытия проекта, добавления/удаления файлов и тп.
Цель — получить список файлов проекта. Тогда можно будет скормить их нашему движку. Подсветка пусть остается на фиксированном списке. Комплит перехватишь всоздав заглушку для резолвера. Ну а интерфейсы вроде IParse пусть будут просто пустышками.

Кстати. Проект открытый (#Д). Думаю не будет проблемой сделать нужные методы #Д виртуальными. Это решит все проблемы.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Проблема с r8293
От: Воронков Василий Россия  
Дата: 15.08.09 15:11
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>NemerleCodeParser — никуда не годен. Но есть парсер который можно использосвать для парсинга отдельных файлов.


Вот тут хотелось бы поподбробнее.

VD>Но есть две проблемы: 1) он не расчитан на работу в разных потоках,


А в чем там проблема? Мне казалось, он сам по себе просто однопоточный. NemerleCodeParser ведь это просто обвертка над настоящим парсером? Или нет? Он по крайней мере нормально работает если подсовываеть его #D вместо парсера

VD>2) его мало для реализации таких вещей как комплит и подсказки.


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

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

ВВ>>На мой взгляд ограниченная поддержка в #D лучше чем полное ее отсутствие.
ВВ>>Ограниченная поддержка автокомплита лучше чем отсутствие автокомплита вообще.
ВВ>>Ограниченная означает, к примеру, что можно делать автокомплит только для тех библиотек, который висят в референсах.

VD>Ты просто не понимаешь, что не будет никакого комплита. Ни хорошего ни плохого.

VD>Для комплита нужно понять контекст. Ачтобы его понять нужно типизиовать тело метода в котором происходит комплит и связать типы всех членов в дереветипов (кстати дерево типов еще нужно построить). Парсер всего этого не делает.

А вот этот самый типизатор, о которым ты говоришь, доступен в виде какого-то внешнего АПИ? Просто если ставить задачу менее глобально, то типизировать весь проект на каждый чих не придется.

ВВ>>Если тебе больше нравится вариант "все или ничего", то тут я спорить не буду

ВВ>>Еще раз повторюсь — мне казалось, что для проекта это полезно. Проект по большому счету твой, так что тебе решать.
VD>На мой взгляд лучше иметь одну добротную IDE нежели две неполноценные. Посему я продолжу работу над Интеграцией с VS.

Тут не спорю. Но лучше одну полноценную и одну... дополнительную

VD>Если ты всеже хочешь повозиться с #д, то советую выбрать стратегию обхода их стратегии.

VD>Для начала нужно научиться перехватывать события отрытия/закрытия проекта, добавления/удаления файлов и тп.
VD>Цель — получить список файлов проекта. Тогда можно будет скормить их нашему движку. Подсветка пусть остается на фиксированном списке. Комплит перехватишь всоздав заглушку для резолвера. Ну а интерфейсы вроде IParse пусть будут просто пустышками.
VD>Кстати. Проект открытый (#Д). Думаю не будет проблемой сделать нужные методы #Д виртуальными. Это решит все проблемы.

Надо попробовать. Но Nemerle.Compiler.Utils без доков как-то с наскоку не берется. Никакой документации по классам там я так понимаю нет?

ЗЫ. Что такое "Проблема с r8293"?
Re[15]: Проблема с r8293
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.08.09 19:54
Оценка: 1 (1)
Здравствуйте, Воронков Василий, Вы писали:

VD>>NemerleCodeParser — никуда не годен. Но есть парсер который можно использосвать для парсинга отдельных файлов.


ВВ>Вот тут хотелось бы поподбробнее.


Очень подробно...
1. Создаешь экземпляр класса Engine из сборки Nemerle.Compiler.Utils.dll.
2. Реализуешь интерфейсы: IEngineCallback, ISource, IProjectSources.
3. Инициализируешь экземпляр класса Engine (в зависимости от потребностей).
4. Вызываешь метод BeginUpdateCompileUnit() и ждешь когда у возвращенного им объекта AsyncRequest значение свойства IsCompleted будет равно true (или ждешь на этом же объекте).
5. Далее берешь из свойства ISource.CompileUnit объект CompileUnit.

Собственно CompileUnit содержит всю информацию которую можно получить при парсинге.

Если скормить Engine весь список исходников, то путем вызова метода BeginBuildTypesTree() (точно так же асинхронного) можно получить полностью типизированный проект. Далее останется только залезть в свойство Project и вынуть результат. Только это лучше делать в рабочем потоке.

VD>>Но есть две проблемы: 1) он не расчитан на работу в разных потоках,


ВВ>А в чем там проблема? Мне казалось, он сам по себе просто однопоточный. NemerleCodeParser ведь это просто обвертка над настоящим парсером? Или нет? Он по крайней мере нормально работает если подсовываеть его #D вместо парсера


Однопоточный он. Куча глобального состояния и операций которые не могут делаться параллельно.

VD>>2) его мало для реализации таких вещей как комплит и подсказки.


ВВ>Ну тут я тормознул, конечно. С другой стороны, я так понимаю, в любом языке, где есть вывод типов парсера уже недостаточно. Даже в C#.


Тут скорее даже проблема в макросах. Вывод типов он внутри методов (ну, почти). А разрешать типы можно как это делают #Дев-овцы — динамически для каждого случая. А вот макры должны отрабатывать в определенное время и в определенных условиях. Есть макры которые отрабатывают только когда есть все нетипизированное дерево типов проекта, а есть которые отрабатывают когда есть типизированное дерево.

ВВ>А вот этот самый типизатор, о которым ты говоришь, доступен в виде какого-то внешнего АПИ? Просто если ставить задачу менее глобально, то типизировать весь проект на каждый чих не придется.


Nemerle.Compiler.Utils.dll и есть обертка над компилятором в котором есть это самое АПИ. Толко использовать его на прямую не выйдет. Компилятор писался без расчета на роботу в режиме движка IDE. Nemerle.Compiler.Utils.dll дорабатывает компилятор так чтобы это было возможно. Например, в компляторе вся информация о пространствах имен и регионах теряется. Nemerle.Compiler.Utils.dll подключается к специальным событиям и достраивает эту информацию.

VD>>На мой взгляд лучше иметь одну добротную IDE нежели две неполноценные. Посему я продолжу работу над Интеграцией с VS.


ВВ>Тут не спорю. Но лучше одну полноценную и одну... дополнительную


Проблема только в том, что работы и над одной IDE выше крыши. Например, не паханным краем является отладка. Сейчас с ней есть серьезные проблемы. Например, не отобраются значения переменных попвших в замыкание. Компилятор переписывает их в обращения к полям классов-замыканий, но отладчик об этом не знает. Если у тебя есть желание помочь проекту, то лучше потратить время на это. Есть и другие задачи требующие решения...

ВВ>Надо попробовать. Но Nemerle.Compiler.Utils без доков как-то с наскоку не берется. Никакой документации по классам там я так понимаю нет?


Док конечно нет. Но я в нем неплохо разбираюсь и могу подсказать если что.

ВВ>ЗЫ. Что такое "Проблема с r8293"?


8293 — это номер ревизии в SVN-репозитории. А проблема очень простая. Я сейчас переписываю интеграцию (и в том числе Nemerle.Compiler.Utils) и в этой ревизии находится очень разобранное состояние. Сейчас там тоже не сахар, но все же уже лучше. Надеюсь, что в течении недели-двух я закончу и интеграция будет работать стабильно (даже намного стабильнее чем раньше).
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Проблема с r8293
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.08.09 11:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>4. Вызываешь метод BeginUpdateCompileUnit() и ждешь когда у возвращенного им объекта AsyncRequest значение свойства IsCompleted будет равно true (или ждешь на этом же объекте).


Небольшое уточнение. Метод BeginUpdateCompileUnit() можно вызвать на каждый чих, то есть на каждое изменение исходника. Ну, а для целей интеллисенса можно брать ту версию ISource.CompileUnit которая в данный момент доступна.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.