Здравствуйте, VladD2, Вы писали:
VD>Да, на уровне редактирование, подсветка, отладка. К сожалению комлита нет. А отладка кривовата. Но хоть что-то. VD>Ссылки можно найти здесь: VD>Re: Микро-аддин для VS 2005
Да не, тут как я понял движок проектов C# насилуется, а я имел ввиду свой VSIP написать по всем правилам. Благо кое-какой опыт у меня в этом уже есть да и наработки. Я ещё погляжу, но не думаю, что это будет очень уж сложно сделать.
Здравствуйте, adontz, Вы писали:
A>Да не, тут как я понял движок проектов C# насилуется,
Ага. Но насилуется грамотно, так что за исключением комплит-ворда все очень прилично.
A>а я имел ввиду свой VSIP написать по всем правилам. Благо кое-какой опыт у меня в этом уже есть да и наработки. Я ещё погляжу, но не думаю, что это будет очень уж сложно сделать.
Хм. Это пожалуй самое больное место языка. Если ты сделашь полноценную интеграцию, то тебе "памятник нерукотворный поставят на бюсте героя". Немероловцы попробовали но дальше начального этапа не подвинулись. Зато у них есть библиотека обеспечивающая саму фунициональность интелисенса. Так что делать поддержку в студии будет куда проще.
В общем, если возьмшся, я присоеденюсь с удовольствием.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>OK, думаю возьмусь VD>Прикалываешся или серьезно?
Да нет, серьёзно. Хотя идея работать вместе ещё более шокирующая, чем сам Nemerle.
Работы конечно же не на недельку (это я погорячился), но и не с нуля начинать. Чего я вообще не знаю, так это как подключать отладчик. Впрочем нет неразрешимых проблем. А такие вещи как менеджмент файлов, компиляция и диалог с настройками проекта — наживное.
A>>Как назовём проект? Давай nesinclair. VD> Кому не нравиться пусть сам выбирает
Вот, а если серьёзно то что-нибудь придумаем. Даже NEVISIN (NEmerle VIsual Studio INtegration) сойдёт, хотя и звучит как лекарство.
Здравствуйте, adontz, Вы писали:
A>Да нет, серьёзно. Хотя идея работать вместе ещё более шокирующая, чем сам Nemerle. A>Работы конечно же не на недельку (это я погорячился), но и не с нуля начинать. Чего я вообще не знаю, так это как подключать отладчик. Впрочем нет неразрешимых проблем. А такие вещи как менеджмент файлов, компиляция и диалог с настройками проекта — наживное.
Отладчик работает и так. Правда с глюками, но это проблемы генерации отладочного мсила. А вот главное что нужно — это интелисенс (комплит-ворд в основном). Остальное мы и так имеем путем хака C#-пного проекта. Студия принимает Немерлю за C# .
A>>>Как назовём проект? Давай nesinclair. VD>> A>Кому не нравиться пусть сам выбирает A>Вот, а если серьёзно то что-нибудь придумаем. Даже NEVISIN (NEmerle VIsual Studio INtegration) сойдёт, хотя и звучит как лекарство.
Название не важно. Главное чтобы работало.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Отладчик работает и так. Правда с глюками, но это проблемы генерации отладочного мсила.
Нет, я просто не очень себе представляю что надо сделать в ответ на перевод в отладочный режим. Можно подглядеть в исходниках из примеров, просто раньше не делал.
VD>А вот главное что нужно — это интелисенс (комплит-ворд в основном). Остальное мы и так имеем путем хака C#-пного проекта. Студия принимает Немерлю за C# .
Это надо регистрировать новый редактор. Лучше даже расширить стандартный. Главное я хоть представляю что тут надо сделать.
VD>Название не важно. Главное чтобы работало.
Ещё как важно! Мне надо как нибудь обозвать папку с проектом . "New Folder(7)" очень плохое название. Уж поверь.
Здравствуйте, adontz, Вы писали:
A>Да нет, серьёзно. Хотя идея работать вместе ещё более шокирующая, чем сам Nemerle. A>Работы конечно же не на недельку (это я погорячился), но и не с нуля начинать. Чего я вообще не знаю, так это как подключать отладчик. Впрочем нет неразрешимых проблем. А такие вещи как менеджмент файлов, компиляция и диалог с настройками проекта — наживное.
Если ты возьмёшься за VSIP-плагин для Nemerle и будет результат, то тебе огромный респект А то от NoiseEHC ничего не слышно (это товарищ, который раньше этим занимался). Тем более, он его писал на C#, что не выглядит очень логичным...
A>>>Как назовём проект? Давай nesinclair. VD>> A>Кому не нравиться пусть сам выбирает
Супер!
A>Вот, а если серьёзно то что-нибудь придумаем. Даже NEVISIN (NEmerle VIsual Studio INtegration) сойдёт, хотя и звучит как лекарство.
Здравствуйте, Oyster, Вы писали:
O>Тем более, он его писал на C#, что не выглядит очень логичным...
Я его тоже буду на C# писать. Это не столько любовь к C# (можно и на Си++), сколько усвоенное правило, что VSIP для языка A, надо писать на языке B, а иначе затрахаешься. Кроме того как у Nemerle (на который ты судя по всему намекал) с COM interop я не знаю и не горю желанием узнать.
O>Можно ещё Rene (Refactoring for Nemerle).
Здравствуйте, adontz, Вы писали:
A>Я его тоже буду на C# писать. Это не столько любовь к C# (можно и на Си++), сколько усвоенное правило, что VSIP для языка A, надо писать на языке B, а иначе затрахаешься.
А почему? Я просто не в курсе — никогда не писал
A>Кроме того как у Nemerle (на который ты судя по всему намекал) с COM interop я не знаю и не горю желанием узнать.
Именно на него и намекал А с COM interop у него точно так же, как и у C#, так что тут бояться нечего.
Здравствуйте, Oyster, Вы писали:
O>А почему? Я просто не в курсе — никогда не писал
Как показала практика студия очень неохотно отдаёт заблокированные файлы. Есть хорошие шансы нарваться на случай, когда после каждого запуска отлаживаемого приложения (второй копии студии) надо будет перезапускать студию (первую копию).
То есть в теории этого быть не должно и не очень понятно как получается, но на практике это есть и чрезвычайно мешает.
O>Именно на него и намекал А с COM interop у него точно так же, как и у C#, так что тут бояться нечего.
Давай я буду писать на C# потому что
Уже есть наработки на C# в этой области.
Компилятор Nemerle АФАИК не без багов пока, не хочу возиться с такими вещами.
Это не тот проект, на котором стоит учить язык. Я бы хотел сконцентироваться на трахе с особенностями интеграции, а не забытых запятых.
Пока нету VSIP писать на C# гораздо удобнее, а я себя очень люблю.
Здравствуйте, Oyster, Вы писали:
O>Если ты возьмёшься за VSIP-плагин для Nemerle и будет результат, то тебе огромный респект А то от NoiseEHC ничего не слышно (это товарищ, который раньше этим занимался).
он сейчас занялся переписыванием своего плагина в соответствии с March CTP студийного SDK, там в сэмпле вроде бы много нового добавили.
O>Тем более, он его писал на C#, что не выглядит очень логичным...
а ты сам попробуй Там не только C#, там еще и большая куча OLE automation, и какие-то COM рапперы на C++ сбоку привинчены, и вообще полная порнография VSIP для студии — это здоровенная куча кривой интеграции с унаследованным кодом, так что возня с использованием Немерле в данном случае будет только мешать.
Хотя на нем имеет смысл писать ту часть кода, которая будет отвечать собственно за логику разбора кода, подбора вариантов, навигации и т.п. Собственно, эту часть уже и вынесли в отдельную либу в составе компилятора, под названием completion engine.
Здравствуйте, Дарней, Вы писали:
Д>он сейчас занялся переписыванием своего плагина в соответствии с March CTP студийного SDK, там в сэмпле вроде бы много нового добавили.
А мне их базовые классы с самого начала не понравились. Я всё с нуля переписал ещё когда ой-ой-ой И ниче, всё пашет.
Д>а ты сам попробуй Там не только C#, там еще и большая куча OLE automation, и какие-то COM рапперы на C++ сбоку привинчены, и вообще полная порнография VSIP для студии — это здоровенная куча кривой интеграции с унаследованным кодом, так что возня с использованием Немерле в данном случае будет только мешать.
+1. Порнографии там хоть отбавляй.
Д>Хотя на нем имеет смысл писать ту часть кода, которая будет отвечать собственно за логику разбора кода, подбора вариантов, навигации и т.п. Собственно, эту часть уже и вынесли в отдельную либу в составе компилятора, под названием completion engine.
Здравствуйте, adontz, Вы писали:
A>Это надо регистрировать новый редактор. Лучше даже расширить стандартный. Главное я хоть представляю что тут надо сделать.
я пока не копал в этом направлении, но сильно подозреваю, что он полностью unmanaged. Практически на 101% в этом уверен А это значит, что с его расширением нужно будет трахаться, трахаться, и еще раз трахаться. Можно посмотреть в качестве примера на jetbrains и их новый плагин, кстати.
Может быть, проще заюзать посторонний редактор, например какой-нибудь Rsdn.Editor? Из минусов в данном случае получается необходимость частично реализовать своими силами функционал, который уже есть в студии. Из плюсов — что тяга к халяве никого еще не доводила до добра, и временами лучше поработать своими руками, чем пытаться выжать что-то полезное из изделия криворуких индусов.
Здравствуйте, Дарней, Вы писали:
Д>я пока не копал в этом направлении, но сильно подозреваю, что он полностью unmanaged. Практически на 101% в этом уверен
Он на СОМ. В конце концов я интеропа не бось и даже Managed C++ держал в руках.
Здравствуйте, adontz, Вы писали:
A>Он на СОМ. В конце концов я интеропа не бось и даже Managed C++ держал в руках.
интероп — это конечно хорошо, но всё-таки хорошо чувствовать себя пограммистом, а не непонятно кем, который делает ремонт двигателя через выхлопную трубу
а ты уже имел дело с этим самым студийным редактором?
Здравствуйте, Дарней, Вы писали:
Д>интероп — это конечно хорошо, но всё-таки хорошо чувствовать себя пограммистом, а не непонятно кем, который делает ремонт двигателя через выхлопную трубу
Д>а ты уже имел дело с этим самым студийным редактором?
Здравствуйте, adontz, Вы писали:
A>Я его тоже буду на C# писать. Это не столько любовь к C# (можно и на Си++), сколько усвоенное правило, что VSIP для языка A, надо писать на языке B, а иначе затрахаешься. Кроме того как у Nemerle (на который ты судя по всему намекал) с COM interop я не знаю и не горю желанием узнать.
КОМ-интероп идет через атрибуты. Так что в Немерле он 1-в один.
Ну, да пофигу на чем писать. Переписать на Немерлю потом будет не проблема. Там почти полноценный конвертер есть.
O>>Можно ещё Rene (Refactoring for Nemerle).
A>Вот. Так и назовём.
Можно так NeVs
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>там еще и большая куча OLE automation, и какие-то COM рапперы на C++ сбоку привинчены, и вообще полная порнография VSIP для студии — это здоровенная куча кривой интеграции с унаследованным кодом, так что возня с использованием Немерле в данном случае будет только мешать.
Я вот тоже думал, а не плюнуть ли на эту студию и не попробовать залепить свой полностью менеджед-варинат. Конкурента ШарпДеву.
Редактор есть. С проектом тоже проблем не будет, так как МСБилд имеет своей АПИ (я в статье практически читаю прокт Шарпа).
Д>Хотя на нем имеет смысл писать ту часть кода, которая будет отвечать собственно за логику разбора кода, подбора вариантов, навигации и т.п. Собственно, эту часть уже и вынесли в отдельную либу в составе компилятора, под названием completion engine.
Не в отдельную либу, а впространство имен. А библиотека вроде та же.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я вот тоже думал, а не плюнуть ли на эту студию и не попробовать залепить свой полностью менеджед-варинат. Конкурента ШарпДеву.
Это детский сад. Помимо проектов есть ещё и сложные солюшены. Database project и тому подобные фенечки. То что ты сможешь объединить несколько файлов немерле и вместе их компилировать это замечательно, но крупные проекты (мы же на них замахиваемся, не так ли?) многоязыковые. К тому же студия расширяема, макросы и всё такое. Вобщем VS рулит
Здравствуйте, adontz, Вы писали:
A>Это детский сад. Помимо проектов есть ещё и сложные солюшены. Database project и тому подобные фенечки. То что ты сможешь объединить несколько файлов немерле и вместе их компилировать это замечательно, но крупные проекты (мы же на них замахиваемся, не так ли?) многоязыковые. К тому же студия расширяема, макросы и всё такое. Вобщем VS рулит
Я бы пережил и без БД-проктов. Особенно если учесть что жалкий макрос из Немерли убивает весь их смысл. А то что можно накрутить в области ОР-мапинга вообще затмевает все приемущества.
Резон же забивания на студию прост. При этом не прийдется трахаться с КОМ-повским АПИ студии. Это сожет резко сократить время. А когда уже будет готов прототип, то можно хоть на черта лысого перенести. Причем на самом Немерле, так как уже будет в чем на нем писать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
Д>>лучше NemerleVsip (Vsip = visual studio integration package)
A>Ведь весь смысл проекта в новых топиках Nemerle Vs! Так что никаких VSIP
Здравствуйте, VladD2, Вы писали:
VD>Я вот тоже думал, а не плюнуть ли на эту студию и не попробовать залепить свой полностью менеджед-варинат. Конкурента ШарпДеву.
VD>Редактор есть. С проектом тоже проблем не будет, так как МСБилд имеет своей АПИ (я в статье практически читаю прокт Шарпа).
Тогда уж лучше взять MonoDevelop и запинать его, чтобы он на винде нормально шел, назло всем линуксоидам
А вообще, писать свою IDE — это конечно заманчиво, но очень уж большой объем работы.... боюсь, что не потянем. Вот например, jebrains свой проект Oblivion в конце концов свернул... неудивительно, проект с таким названием изначально был обречен
С другой стороны, интеграция к студии уже привернута, во всяком случае по основным направлениям. Всё, что нужно — это добить редактор и все фичи, которые к нему прилагаются.
Здравствуйте, Max.Subpixel, Вы писали:
MS>Ой, сделайте лучше VSIP. Мы вам памятник поставим. Главное, чтобы дальше разговоров дело пошло и не загнулось по дороге...
Здравствуйте, adontz, Вы писали:
A>Да не, тут как я понял движок проектов C# насилуется, а я имел ввиду свой VSIP написать по всем правилам. Благо кое-какой опыт у меня в этом уже есть да и наработки. Я ещё погляжу, но не думаю, что это будет очень уж сложно сделать.
для начала нужно решить, что от VSIP вообще требуется
я бы предложил вот такой список (в порядке уменьшения соотношения важности/простоты)
Специальный тип проекта для Немерле, создание проектов через студию, шаблоны проектов. Структура проекта (файлы, папки), управление структурой. Настройки проекта. Компиляция.
эта часть уже есть, и даже по большей части работает
без неё все остальное все равно не имеет смысла.
подсветка кода
автокомплит
1. Ключевые слова и встроенные типы
2. Классы FCL
3. Классы программы
где-то здесь еще нужно добавить создание инсталлера — без него бета-тестирование будет невозможно, ибо далеко не каждый сможет/захочет качать толстый СДК и компилировать проект самому.
Здравствуйте, Дарней, Вы писали:
Д>где-то здесь еще нужно добавить создание инсталлера — без него бета-тестирование будет невозможно, ибо далеко не каждый сможет/захочет качать толстый СДК и компилировать проект самому.
Для компиляции пакета SDK не нужен, это обычная сборка.
Здравствуйте, AndrewVK, Вы писали:
AVK>Для компиляции пакета SDK не нужен, это обычная сборка.
т.е. если положить в проект все утилитные классы из VisualStudioIntegration\Common, то никакие больше зависимости не нужны?
хотя там еще что-то из VisualStudioIntegration\Tools вроде бы нужно. Как минимум таргеты для msbuild
Здравствуйте, Дарней, Вы писали:
Д>т.е. если положить в проект все утилитные классы из VisualStudioIntegration\Common, то никакие больше зависимости не нужны?
Да.
Д>хотя там еще что-то из VisualStudioIntegration\Tools вроде бы нужно. Как минимум таргеты для msbuild
Здравствуйте, Дарней, Вы писали:
Д>интересно... то есть с дизайном там тоже все плохо?
Я видил их код. Это довольно кривой, убогий и написанный как попало код. Возможно мне попадались именно такие фрагменты, но мое впечатление о коде было очень неприятным. Правда это было уже давно (года два назад).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Не знаю, у меня никаких таргетов не используется.
VD>Значти ты не 2005-ую студию используешь. VD>В 2005-ой без них нельзя.
VD>Собственно современный хак C#-ного проекта и основан на добавлении лишнего таргет-файла заставляющего компилировать Немерловые файлы.
Здравствуйте, AndrewVK, Вы писали:
Д>>хотя там еще что-то из VisualStudioIntegration\Tools вроде бы нужно. Как минимум таргеты для msbuild
AVK>Не знаю, у меня никаких таргетов не используется.
в самом файле я не копался, но предположить нетрудно — эта штука отвечает за регистрацию плагина в студии.
Так что нужно или тащить за собой этот файл с его зависимостями, или писать хоть какой-то свой инсталлер.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, VladD2, Вы писали:
VD>>Я вот тоже думал, а не плюнуть ли на эту студию и не попробовать залепить свой полностью менеджед-варинат. Конкурента ШарпДеву.
VD>>Редактор есть. С проектом тоже проблем не будет, так как МСБилд имеет своей АПИ (я в статье практически читаю прокт Шарпа).
Д>Тогда уж лучше взять MonoDevelop и запинать его, чтобы он на винде нормально шел, назло всем линуксоидам Д>А вообще, писать свою IDE — это конечно заманчиво, но очень уж большой объем работы.... боюсь, что не потянем. Вот например, jebrains свой проект Oblivion в конце концов свернул... неудивительно, проект с таким названием изначально был обречен Д>С другой стороны, интеграция к студии уже привернута, во всяком случае по основным направлениям. Всё, что нужно — это добить редактор и все фичи, которые к нему прилагаются.
Хотя бы потому, что Bethesda Softworks такое название не очень бы понравилось
Д>в самом файле я не копался, но предположить нетрудно — эта штука отвечает за регистрацию плагина в студии. Д>Так что нужно или тащить за собой этот файл с его зависимостями, или писать хоть какой-то свой инсталлер.
Какий на фиг плагинов? Это такргет МСБилда. Он за компиляцию и за содержимое проекта отвечает.
А вот зависимости зависят от того какие Task-и использует этот файл.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Какий на фиг плагинов? Это такргет МСБилда. Он за компиляцию и за содержимое проекта отвечает. VD>А вот зависимости зависят от того какие Task-и использует этот файл.
я всего лишь показывал, что откомпилировать плагин можно только при наличии хотя бы части SDK
но это в принципе не особо важно — писать инсталлер для плагина все равно придется, и лучше сделать это раньше чем позже
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
AVK>>>Не знаю, у меня никаких таргетов не используется.
VD>>Значти ты не 2005-ую студию используешь. VD>>В 2005-ой без них нельзя.
VD>>Собственно современный хак C#-ного проекта и основан на добавлении лишнего таргет-файла заставляющего компилировать Немерловые файлы.
AVK>Речь шла о таргетах VSIP.
Ссылку можно на описание этого чуда? А то я что-то уверен, что таковых в природе не существует, а речь идет о такрогет-файлах МСБилда. А то что VSIP для 2005-ой студии их использует совершенно нормально.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ссылку можно на описание этого чуда? А то я что-то уверен, что таковых в природе не существует, а речь идет о такрогет-файлах МСБилда. А то что VSIP для 2005-ой студии их использует совершенно нормально.
АФАИК на самом низком уровне надо обрабатывать команды BuildSln, RebuildSln, DeploySln, CleanSln, BuildSel, RebuildSel, DeploySel, CleanSel, CancelBuild в методах QueryStatusCommand и ExecCommand интерфейса IVsUIHierarchy.
Здравствуйте, adontz, Вы писали:
A>АФАИК на самом низком уровне надо обрабатывать команды BuildSln, RebuildSln, DeploySln, CleanSln, BuildSel, RebuildSel, DeploySel, CleanSel, CancelBuild в методах QueryStatusCommand и ExecCommand интерфейса IVsUIHierarchy.
Что значит "Sel"?
И нельзя ли взять за основу Шарповский проект? А то ведь уже все делаетсфя?
Сформулирю более прямо и понятно:
Нельзя ли вместо того чтобы делать поддержку с нуля просто заменить поддержку интелисенс для C#-проекта?
Ведь в нем уже есть все что нужно. И сделано хорошо. Плюс мы сможем компилировать проект состоящий из C#- и Nemerle-файлов.
Нельзя ли обойтись плагином к судии, а не полноценным VSIP-пакетом? Боюсь мы просто увязнем в каше студии.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Что значит "Sel"?
Selection
VD>И нельзя ли взять за основу Шарповский проект? А то ведь уже все делаетсфя? VD>Сформулирю более прямо и понятно: VD>Нельзя ли вместо того чтобы делать поддержку с нуля просто заменить поддержку интелисенс для C#-проекта? VD>Ведь в нем уже есть все что нужно. И сделано хорошо. Плюс мы сможем компилировать проект состоящий из C#- и Nemerle-файлов. VD>Нельзя ли обойтись плагином к судии, а не полноценным VSIP-пакетом? Боюсь мы просто увязнем в каше студии.
Хммм. Тут какое дело. Лично мне как раз интересно разобраться во всей этой каше, чтобы не просто написать VSIP, а стать очень крутым спецом по VSIP И увязнуть в каше вполне входило в мои планы. А если тебе хочеться переделывать проект-пример из SDK, то на здоровье. Собственно именно новый тип проекта для этого делать не объязательно, достаточно зарегистрировать новый тип редактора для файлов с расширением n. Но с моими планами "глубоко поковыряться" это не особо коррелирует.
Тут видишь ли какое дело, мне код из SDK очень не нравиться. Не нравится не только такими мелочами как бардак в отступах, дурацкие имена переменных и проч, но и откровенно плохим дизайном. Потому что при хорошем дизайне комментариев вроде
// Do not call virtual methods after this point since the object is in a deleted state.
не встретишь. Хотелось написать своё. Не потому что в этом есть великая нужда, а из любви к красоте.
Здравствуйте, VladD2, Вы писали:
AVK>>Речь шла о таргетах VSIP.
VD>Ссылку можно на описание этого чуда?
Это не ко мне.
VD> А то я что-то уверен, что таковых в природе не существует, а речь идет о такрогет-файлах МСБилда.
О них и идет речь. Ты внимательнее читай топик, прежде чем отвечать. Тут было замечено, что пакет не собрать без инсталляции VS2005 SDK, на что я заметил, что мой пакет собирается без него без каких либо проблем.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, adontz, Вы писали:
VD>>Что значит "Sel"?
A>Selection
А это что означает?
A>Хммм. Тут какое дело. Лично мне как раз интересно разобраться во всей этой каше, чтобы не просто написать VSIP, а стать очень крутым спецом по VSIP И увязнуть в каше вполне входило в мои планы. А если тебе хочеться переделывать проект-пример из SDK, то на здоровье. Собственно именно новый тип проекта для этого делать не объязательно, достаточно зарегистрировать новый тип редактора для файлов с расширением n.
А что нужно сделать чтобы зарегистрировать свой редактор? И можно ли при этом пользоваться редактором VS?
A>Но с моими планами "глубоко поковыряться" это не особо коррелирует.
Я понимаю твое желание покапаться в студии. Но лично я хотел бы по быстрее получить полноценную поддержку Немерла в студии.
В общем-то ясно, что для совсем полноценной поддержки нужно разрабатывать свой пакет, но это не мешает на первое время сделать хоть какую то поддержку.
A>Тут видишь ли какое дело, мне код из SDK очень не нравиться. Не нравится не только такими мелочами как бардак в отступах, дурацкие имена переменных и проч, но и откровенно плохим дизайном.
Я тоже не в восторге от грязи, но хотелось бы поглядеть на код самому, а не верить на слово.
A>Потому что при хорошем дизайне комментариев вроде A>
A>// Do not call virtual methods after this point since the object is in a deleted state.
A>
A>не встретишь. Хотелось написать своё. Не потому что в этом есть великая нужда, а из любви к красоте.
Это может быть вызвано проблемами интеграции с СОМ-ом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>Ссылку можно на описание этого чуда?
AVK>Это не ко мне.
Хм. Ты же сказал "А".
VD>> А то я что-то уверен, что таковых в природе не существует, а речь идет о такрогет-файлах МСБилда.
AVK>О них и идет речь.
Если о них, то неясно в чем проблема.
AVK> Ты внимательнее читай топик, прежде чем отвечать. Тут было замечено, что пакет не собрать без инсталляции VS2005 SDK, на что я заметил, что мой пакет собирается без него без каких либо проблем.
Не вижу связи между пакетами с регистрацией и таргетами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А что нужно сделать чтобы зарегистрировать свой редактор? И можно ли при этом пользоваться редактором VS?
Реализовать свой Package и в методе SetSite получить сервис SVsRegisterEditors и передать ему IVsEditorFactory
Как пользовать редактор студии я не знаю. Но дело это ИМХО беспонтовое, потому что без поддержки со стороны проекта твой редактор ничего о структуре проекта и всех осталных файлах знать не будет (или будет получать эту информацию через жопу) и особо дальше подсветки/завершения служебных слов ты не уедешь.
VD>Я понимаю твое желание покапаться в студии. Но лично я хотел бы по быстрее получить полноценную поддержку Немерла в студии.
АФАИК только редактором не обойтись, нужен весь комплекс.
VD>В общем-то ясно, что для совсем полноценной поддержки нужно разрабатывать свой пакет, но это не мешает на первое время сделать хоть какую то поддержку.
Хоть какая-то у тебя и так есть.
VD>Я тоже не в восторге от грязи, но хотелось бы поглядеть на код самому, а не верить на слово.
Скачай SDK, там примеры в исходниках.
VD>Это может быть вызвано проблемами интеграции с СОМ-ом.
К сожалению это проблемы неправильного назначения владельцев ресурсов.
Здравствуйте, adontz, Вы писали:
A>Реализовать свой Package и в методе SetSite получить сервис SVsRegisterEditors и передать ему IVsEditorFactory
Хм. Опять свой покет. А без этого никак? Ну, через плагин?...
A>Как пользовать редактор студии я не знаю. Но дело это ИМХО беспонтовое, потому что без поддержки со стороны проекта твой редактор ничего о структуре проекта и всех осталных файлах знать не будет (или будет получать эту информацию через жопу) и особо дальше подсветки/завершения служебных слов ты не уедешь.
Насколько мне известно получить ProjectItem не очень большая проблема. Ну, а там получить список файлов проекта уже становится делом техники. С C#-проектами я копался...
VD>>Я понимаю твое желание покапаться в студии. Но лично я хотел бы по быстрее получить полноценную поддержку Немерла в студии.
A>АФАИК только редактором не обойтись, нужен весь комплекс.
Боюсь это будет слишком большой объем работ. Там одних диалогов настройки проектов дцать штук.
VD>>В общем-то ясно, что для совсем полноценной поддержки нужно разрабатывать свой пакет, но это не мешает на первое время сделать хоть какую то поддержку.
A>Хоть какая-то у тебя и так есть.
Нужно автодополнение при вводе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Реализовать свой Package и в методе SetSite получить сервис SVsRegisterEditors и передать ему IVsEditorFactory VD>Хм. Опять свой покет. А без этого никак? Ну, через плагин?...
Не волнуйся, голый пакет, который ничего не делает это ОЧЕНЬ МАЛО кода.
using Microsoft.VisualStudio.Shell;
using Microsoft.VisualStudio.Shell.Interop;
using Microsoft.VisualStudio.OLE;
using Microsoft.VisualStudio.OLE.Interop;
namespace Nemerle.VSIP
{
[ComVisible(true)]
public abstract class VsPackageBase :
IVsPackage,
IVsInstalledProduct
{
private Microsoft.VisualStudio.OLE.Interop.IServiceProvider _serviceProvider = null;
private ServiceProvider _serviceProviderHelper = null;
private IVsRegisterEditors _vsRegisterEditors = null;
public int SetSite(Microsoft.VisualStudio.OLE.Interop.IServiceProvider serviceProvider)
{
this._serviceProvider = serviceProvider;
this._serviceProviderHelper = new ServiceProvider(this._serviceProvider);
int result = ResultCom.S_OK;
try
{
this._vsRegisterEditors = _serviceProviderHelper.GetService(typeof(SVsRegisterEditors)) as IVsRegisterEditors;
// Вот ту и регистрируем
}
catch (Exception /* exception */)
{
result = ResultCom.E_FAIL;
}
return result;
}
public int QueryClose(out int result)
{
// Давайте выключатся, мы не против.
result = 1;
return ResultCom.S_OK;
}
public int Close()
{
// А вот тут надо разрегистрировать всё что мы зарегистрировалиreturn ResultCom.S_OK;
}
public int GetAutomationObject(string name, out object automationObject)
{
// Прячемся, до нас снаружи не достучатся :) Можно наверное выдавать new DispatchWrapper(this).
automationObject = null;
return ResultCom.S_OK;
}
public int CreateTool(ref System.Guid guid)
{
// А тут мы окошечко создаём.return ResultCom.S_OK;
}
public int ResetDefaults(uint flags)
{
return ResultCom.S_OK;
}
public int GetPropertyPage(ref System.Guid guid, Microsoft.VisualStudio.Shell.Interop.VSPROPSHEETPAGE[] pageList)
{
return ResultCom.S_OK;
}
public int IdBmpSplash(out uint bitmapID)
{
bitmapID = 0;
return ResultCom.S_OK;
}
public int OfficialName(out string officialName)
{
officialName = "Nemerle VSIP! Wow, we did it!";
return ResultCom.S_OK;
}
public abstract int ProductID(out string productID)
{
productID = "v1.0 unreleased";
return ResultCom.S_OK;
}
public abstract int ProductDetails(out string productDetails)
{
productDetails = "some details";
return ResultCom.S_OK;
}
public abstract int IdIcoLogoForAboutbox(out uint bitmapID)
{
bitmapID = 0;
return ResultCom.S_OK;
}
}
}
Ну и с десяток записей в реестре.
VD>Насколько мне известно получить ProjectItem не очень большая проблема. Ну, а там получить список файлов проекта уже становится делом техники. С C#-проектами я копался...
Ну вот и это и есть через ж. Потому что от ProjectItem до иерархии классов в файле, оповещений о том, что надо бы эту иерархию обновить и проч. и проч. путь не близкий и тупиковый.
VD>Боюсь это будет слишком большой объем работ. Там одних диалогов настройки проектов дцать штук.
Каких таких диалогов? Есть Project Properties, и что ещё тебе надо? Вообще-то объязательного интерфейса у VSIP нету. Можешь совсем без диалогов всё сделать.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, adontz, Вы писали:
Д>для начала нужно решить, что от VSIP вообще требуется Д>я бы предложил вот такой список (в порядке уменьшения соотношения важности/простоты)
Д>подсветка кода
+1 Д>автокомплит Д>1. Ключевые слова и встроенные типы Д>2. Классы FCL Д>3. Классы программы
А что делать с макросами? Внутремакросовское (слово красивое) не будет автокомплититься?
Я просто уточняю и понимаю что макросы парсить это тормоза системы и разработки. Д>resolve namespaces
Д>implement interface/abstract class
Вот здесь не дошло В каком смысле "implement" и какие именно "interface/abstract class"?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, adontz, Вы писали:
VD>Ну, да пофигу на чем писать. Переписать на Немерлю потом будет не проблема. Там почти полноценный конвертер есть.
А есть ли смысл конвертировать на Немерле без применения Немерлешных изысков?
O>>>Можно ещё Rene (Refactoring for Nemerle).
A>>Вот. Так и назовём.
VD>Можно так NeVs
А ещё есть такое очень красивое название: Neva. Правда расшифровку я не могу предоставить, ммм, NEmerle Visual Assistant, VisuAl studio?
Здравствуйте, Chipsеt, Вы писали:
Д>>implement interface/abstract class C>Вот здесь не дошло В каком смысле "implement" и какие именно "interface/abstract class"?
Имеешь
interface IInterface
{
int Method();
}
Пишешь
class Implementation : IInterface
{
}
Щёлкаешь правой кнопкой на IInterface, выбираешь Implement, получаешь
class Implementation : IInterface
{
public int Method()
{
throw new Exception("not implemented");
}
}
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
A>>>Реализовать свой Package и в методе SetSite получить сервис SVsRegisterEditors и передать ему IVsEditorFactory VD>>Хм. Опять свой покет. А без этого никак? Ну, через плагин?...
A>Не волнуйся, голый пакет, который ничего не делает это ОЧЕНЬ МАЛО кода.
...
Кстати, этот код ты считашь нармальным?
A>Ну вот и это и есть через ж. Потому что от ProjectItem до иерархии классов в файле, оповещений о том, что надо бы эту иерархию обновить и проч. и проч. путь не близкий и тупиковый.
Если редактор наш, то больше ничего и не надо.
VD>>Боюсь это будет слишком большой объем работ. Там одних диалогов настройки проектов дцать штук.
A>Каких таких диалогов? Есть Project Propertie\s, и что ещё тебе надо? Вообще-то объязательного интерфейса у VSIP нету. Можешь совсем без диалогов всё сделать.
Нажми провую кномку на проекте... открой свойства проекта... погляди сколько там страниц и сколько они делают. Потерять все это крайне не желательно. А делать по второму разу неразумно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Chipsеt, Вы писали:
C>>Я просто уточняю и понимаю что макросы парсить это тормоза системы и разработки.
VD>Не понял в чем проблема? У немерловцев есть даже подсистема комплита которая построена на базе компилятора.
Опасаюсь как-бы не пришлось при каждом нажатии Ctrl+Space идти заваривать кофе пока этот компилятор пропарсит все возможные изменения макросов которые могли случиться как последствия изменений в предыдущей строке.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, этот код ты считашь нармальным?
Ну я его прямо в окне редактирования сообщений переделывал, так что остались огрехи (не везде стёр abstract и т.д.). Если тебя интересует мой стиль — посмотри Nabu.
VD>Нажми провую кномку на проекте... открой свойства проекта... погляди сколько там страниц и сколько они делают. Потерять все это крайне не желательно. А делать по второму разу неразумно.
Там многие настройки один в один повторяют параметры командной строки. Да и не боюсь я делать интерфейс.
Здравствуйте, VladD2, Вы писали:
VD>А что нужно сделать чтобы зарегистрировать свой редактор?
Прописать в реестре соответствие между расширениями и редакторами для каждого типа проекта с указанием приоритета.
VD> И можно ли при этом пользоваться редактором VS?
В своем редакторе скорее всего нет. Если пользоваться студийным текстовым редактором, то там собственное специальное API.
VD>В общем-то ясно, что для совсем полноценной поддержки нужно разрабатывать свой пакет, но это не мешает на первое время сделать хоть какую то поддержку.
Пакет отличается от аддона (ты его под плагином подразумеваешь?) только способом старта. Основной трах отнюдь не со стартом.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Прописать в реестре соответствие между расширениями и редакторами для каждого типа проекта с указанием приоритета. AVK>В своем редакторе скорее всего нет. Если пользоваться студийным текстовым редактором, то там собственное специальное API.
А примеры того как это делается можно найти?
VD>>В общем-то ясно, что для совсем полноценной поддержки нужно разрабатывать свой пакет, но это не мешает на первое время сделать хоть какую то поддержку.
AVK>Пакет отличается от аддона (ты его под плагином подразумеваешь?) только способом старта. Основной трах отнюдь не со стартом.
Как я понимаю, с пакетом возникает проблма регистрации (ключа). К тому же мне кажется лучше было бы не создавать все с нуля, а хакнуть C#-пный пакет.
Оптимальным было бы сделать обртку над редактором C# и зарегистрировать ее как редактор для Немерла.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А примеры того как это делается можно найти?
Можно конечно.
AVK>>Пакет отличается от аддона (ты его под плагином подразумеваешь?) только способом старта. Основной трах отнюдь не со стартом.
VD>Как я понимаю, с пакетом возникает проблма регистрации (ключа).
Нет там никакой проблемы. Оставляешь заявку, получаешь через несколько дней ключ.
VD> К тому же мне кажется лучше было бы не создавать все с нуля, а хакнуть C#-пный пакет.
Нереально. Он на C++ написан.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Дарней wrote: > Тогда уж лучше взять MonoDevelop и запинать его, чтобы он на винде > нормально шел, назло всем линуксоидам
А ещё есть такая вещь как, не побоюсь этого слова, Eclipse под который
тоже можно писать плугины и всякие там расширения под новые языки.
> А вообще, писать свою IDE — это конечно заманчиво, но очень уж большой > объем работы.... боюсь, что не потянем.
По сути говоря, я не вижу особой функциональности которую придется
восполнить если остаться без VS2005. Дерево проектов и управление им
(проектом), разве что. Подсветку, автодополнение, рефакторинг и прочие
фишки связанные с языком придется все равно писать.
Здравствуйте, AndrewVK, Вы писали:
VD>> К тому же мне кажется лучше было бы не создавать все с нуля, а хакнуть C#-пный пакет.
AVK>Нереально. Он на C++ написан.
Да хоть на ассемблере. Это же КОМ. Значит всегда можно обертку сделать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ВНИМАНИЕ! КАЧАТЬ БЕЗ СПЕЦИАЛЬНАХ ПРОГРАММ!
Благодаря какой-то магии VSIP SDK скачивается FlashGet/ReGet битым.
Совет: Ты скачаешь 1 exe файл. При запуске от распакует своё содержимое в папку C:\Temp или ещё какую-нибудь. Сохрани это содержимое в какую-нибудь папку. Для операций типа Repair пригодится.
Да, собственно содержимое
Здравствуйте, VladD2, Вы писали:
AVK>>Нереально. Он на C++ написан. VD>Да хоть на ассемблере. Это же КОМ. Значит всегда можно обертку сделать.
Да там вообще есть Project Aggregator, но зачем это? Интересно ведь то, что внутри.
И ещё, в папке
Visual Studio 2005 SDK\2006.04\VisualStudioIntegration\Samples\IronPythonIntegration
есть пример интеграции managed языка. Ну покрайней мере они так утверждают. Правда язык не Nemerle
Здравствуйте, adontz, Вы писали:
A>Да там вообще есть Project Aggregator,
Можно по подробнее?
A>но зачем это? Интересно ведь то, что внутри.
Мне интересен результат. Бытрый и качественный.
A>И ещё, в папке A>Visual Studio 2005 SDK\2006.04\VisualStudioIntegration\Samples\IronPythonIntegration A>есть пример интеграции managed языка. Ну покрайней мере они так утверждают. Правда язык не Nemerle
А комплит-ворд для него есть?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Да там вообще есть Project Aggregator, VD>Можно по подробнее?
Нельзя. Это просто названия примера из SDK.
A>>И ещё, в папке A>>Visual Studio 2005 SDK\2006.04\VisualStudioIntegration\Samples\IronPythonIntegration A>>есть пример интеграции managed языка. Ну покрайней мере они так утверждают. Правда язык не Nemerle VD>А комплит-ворд для него есть?
Language Service фактически присутствует, но питон я не знаю и как он работает оценить не могу.
Здравствуйте, VladD2, Вы писали:
AVK>>В данном случае нельзя.
VD>И какие проблемы? Сдается мне, что ты просто не в курсе, того что можно вытворять с КОМ-ом.
Проблемака. Я уже был зарегестрирован на эту хрень, но ID и пароль уже не помню.
А мыло там уже зарегистрировано, так что по новой зарегистрироваться не удается. И главное, не ясно куда стучаться.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Language Service фактически присутствует, но питон я не знаю и как он работает оценить не могу.
Питон динамически типизированный. Так что могут быть проблемы. Но тут главное не это. Тут важно само наличие комплита. А уж чем заполнять списки мы как-нить разберемся.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>И какие проблемы? Сдается мне, что ты просто не в курсе, того что можно вытворять с КОМ-ом.
AVK>Сдается мне ты не в курсе интерфейсов VSIP.
Чтобы сабкласить КОМ-объкты знать структуру конкретных объектов не обязательно. Это общий хак.
В двух словах все просто. Все объекты создаются через фабрику классов. Подменив пару функций из DLL-и можно вернуть свою реализацию. Так же в интерфейсах можно подменять vtbl тем самым перехватывая методы.
Далее все просто... Делаем "куклу" (длл замещающую настоящую) в которой подменяем нужные методы, а остальные транслируем напрямую. Это позволяет пдсовывать свою информацию вместо той что идет из подмененной ДЛЛ-и.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Проблемака. Я уже был зарегестрирован на эту хрень, но ID и пароль уже не помню. VD>А мыло там уже зарегистрировано, так что по новой зарегистрироваться не удается. И главное, не ясно куда стучаться.
Ну хочешь я тебе куда-нибудь закачаю? Есть FTP c 200Мб свободного места?
Здравствуйте, VladD2, Вы писали:
VD>Чтобы сабкласить КОМ-объкты знать структуру конкретных объектов не обязательно. Это общий хак.
VD>В двух словах все просто. Все объекты создаются через фабрику классов.
в vsip это не так. Через COM-фабрику создается только собственно сам Package (и то там тоже определенные ньюансы есть), да еще, пожалуй, генераторы и визарды. Все остальное создается самим пакетом и им же вручную регистрируется в соответствующих сервисах студии. Теоретически конечно можно отчасти сэмулировать среду и поднять пакет внутри себя, но с учетом большого количества сервисов и необходимости подмены гуидов тех же редакторов или типов проектов трах там совершенно нереальный.
VD> Подменив пару функций из DLL-и можно вернуть свою реализацию. Так же в интерфейсах можно подменять vtbl тем самым перехватывая методы.
Влад, я не буду здесь расписывать как устроен VSIP. Поверь, там все не так просто и никакакая подмена vtbl тебя не спасет. Этот путь неверный.
Здравствуйте, AndrewVK, Вы писали:
AVK>в vsip это не так. Через COM-фабрику создается только собственно сам Package (и то там тоже определенные ньюансы есть), да еще, пожалуй, генераторы и визарды. Все остальное создается самим пакетом и им же вручную регистрируется в соответствующих сервисах студии. Теоретически конечно можно отчасти сэмулировать среду и поднять пакет внутри себя, но с учетом большого количества сервисов и необходимости подмены гуидов тех же редакторов или типов проектов трах там совершенно нереальный.
http://www.codeproject.com/macro/vs_custom_window.asp надеюсь ничего пояснять не надо.
VD>> Подменив пару функций из DLL-и можно вернуть свою реализацию. Так же в интерфейсах можно подменять vtbl тем самым перехватывая методы.
AVK>Влад, я не буду здесь расписывать как устроен VSIP.
Да, и не надо так как к воросу принципиальной возможности это отношения не имеет.
AVK> Поверь, там все не так просто и никакакая подмена vtbl тебя не спасет. Этот путь неверный.
Ну, то что принципиально то что я говорю возможно подтверждает приведенная мной ссылка. Я конечно понимаю, что все это вилами на воде писано, но реальных аргументов я от тебя пока не услышал. Меж тем если это пройдет, то можно сэкономить море времени. У меня C#-пный проект хакнутый через MSBuild-target-ы и так делает все кроме комплита. Так что возможно все же удастся влезть в управление редактором и влепить комплит.
В худшем случае можно поступить так... Создать пакет регистриующих только редактор для расширения .n. Его реализоват на базе Rsdn.Editor. Ну, а там уже все интелисенсину будет сделать не сложно. Ну, а проект так и останется C#-пным.
Альтернатива ведь только одна — писать полный пакет с нуля. Это нехилый объем работ. Собственно я не против если Адонц этим займется. Даже помогу чем смогу. Но ничего не случится если я параллельно попробую хакнуть шарповский проект.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Да не, тут как я понял движок проектов C# насилуется, а я имел ввиду свой VSIP написать по всем правилам. Благо кое-какой опыт у меня в этом уже есть да и наработки. Я ещё погляжу, но не думаю, что это будет очень уж сложно сделать.
C удовольствием присоеденюсь к проекту. Тоже хочу поднять экспы в области интеграции с VS.
The most annoying and blatantly absent feature of Visual Studio .NET 'extensibility' is the incapacity to insert a custom window into the IDE. Obviously, the Extensibility Object model was deliberately castrated in the interest of Microsoft salesmen, since the VSIP (Visual Studio Integrated Products) package is distributed and sold separately.
Вобщем человек явно не понимает что такое VSIP.
AVK>>Влад, я не буду здесь расписывать как устроен VSIP.
VD>Да, и не надо так как к воросу принципиальной возможности это отношения не имеет.
Ну если тебе времени не жалко, можешь не верить.
VD>Ну, то что принципиально то что я говорю возможно подтверждает приведенная мной ссылка.
Она подтверждает безграмотность автора, который поленился скачать VS SDK, а вместо этого нагородил море хаков.
VD> Я конечно понимаю, что все это вилами на воде писано, но реальных аргументов я от тебя пока не услышал.
Аргументов чего? Неужели ты не понимаешь, что если пакет использует полсотни сервисов, то перекрывать для него site и писать прокси версии всех этих сервисов устанешь?
VD> Меж тем если это пройдет, то можно сэкономить море времени.
Ничего ты не съэкономишь. Хотя конечно поступай как знаешь, флаг тебе в руки.
VD>Альтернатива ведь только одна — писать полный пакет с нуля. Это нехилый объем работ.
Он значительно меньше, чем написание собственной студии, как ты тут предлагал.
Здравствуйте, adontz, Вы писали:
AVK>>А ты готов писать этот проект на Nemerle?
A>А разве кто-то всерьёз собирался? Мне казалось, что C# уже принятое решение.
Боюсь тебя разочаровать, но если решение и принято, то принято оно об использовании Nemerle.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Дарней, Вы писали:
VD>>>NemerleVs не подойдет? Д>>лучше NemerleVsip (Vsip = visual studio integration package)
A>Ведь весь смысл проекта в новых топиках Nemerle Vs! Так что никаких VSIP
ТОгда уж ИМХО лучше VsNemerle притяней звучит, да и на слух чуьт по другому воспринимается ж)
Здравствуйте, V.Petrovski, Вы писали:
VP>Здравствуйте, AndrewVK, Вы писали:
AVK>>А ты готов писать этот проект на Nemerle? VP>Я не ткаой фанат как Влад, писать R# на R#
VP>И моё мнение, что лучше писать на C# 2.0 под VS2005.
Моё мнение — лучше писать, чем не писать, выбирайте Лида, c этим кажется всё ясно , и он выбирает язык и формирует команду из Волантёров.
ЗЫ я понимаю, что со стороны не очень красиво, ибо сам я только сочуствующий и жаждущий, но ребята, больше дела.
Мы в Вас верим
V.Petrovski wrote:
> C удовольствием присоеденюсь к проекту. Тоже хочу поднять экспы в > области интеграции с VS. > ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Кажется у Влада сдохла почта, а тут собрался интересующийся народ. Вобщем вот
У меня появилась несколько идей касательно VSIP.
1. Давайте сперва напишем некоторую базу. Проект который содержит файлы, позволяет их добавлять переименовывать, удалять, редактировать, показывать контекстное меню и проч. Никакой компиляции и отладки. Собственно это у меня уже почти есть Это будет та база над которой множно строить совершенно разные VSIP концентрируясь на действительно специфичных для языка вещах (компиляция и отладка). Это будет тот код, который полезен сам по себе, вне зависимости от успешности остальных частей и хоть как-то оправдает существование проекта.
2. Добавим к этому контроль версий. Причём я бы очень хотел сделать это не только через интерфейсы VS, но в обход, например для CVS/SVN и вообще сделать эту часть максимально расширяемой. Это не объязательно делать срочно, достаточно просто оставить лазейки. Такая расширенная база уже имеет весьма недвусмысленную ценность. Многие ведь мучаются с SVN, нормально ни добавить, ни тем более переименовать файл нельзя. Можно ещё сделать так, чтобы наши веб-проекты не конфликтовали с SVN (там же проблема с именами и нужен спец-билд). Можно делать вещи на которые интерфейсы VS вообще не расчитаны.
3. Язык. Я думал над возможностью проекта для языка Nemerle... и вспомнил, что уже давно люди хотели многоязыковые проекты. Не солюшены, а именно проекты. Технической проблемы в рамках .Net (да и за рамками на самом деле) нет. Есть некоторый бардак с разными настройками для разных компиляторов, Но если реализовать вещи специфичные для компиляторов в виде расширений всё будет ОК. Сделал проект на Nemerle, потребовалось что-то уровнем ниже, добавил файл на C#, Managed C++, Unmanaged C++, да хоть Free Pascal — плевать. То есть поначалу мы сделаем только Nemerle, потом C#, а потом, учитывая что никакой необходимости воевать с парсерами у нас нет можно будет расширяться и дальше в этом направлении.
4. Front End'ы. У нас есть исходный код и есть компилятор. Между ними мы вставляем некоторый преобразователь. Не суть важно что он делает, важна сама возможность. Нередко возникает необходимость генерировать код на Си++/С# из XML или ещё чего-нибудь. А тут мы можем предоставить генератору не просто этот XML, но и все настройки проекта и данные об уже скомпилированном коде. Для тех же DSL-писателей какое-то подспорье наверное.
Вот такие вот идеёки. В каком-то смысле даже план действий. Что скажете?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, adontz, Вы писали:
[skipped]
A>Вот такие вот идеёки. В каком-то смысле даже план действий. Что скажете?
На самом деле, это только начало для идей.
Если, я надеючь что да, проект начнется и будет жить, то идею будут течь рекой.
Я считаю, что надо начинать с орг.вопросов: CVS/SVN, Solution, Лицензия, Форум и т.д.
Здравствуйте, V.Petrovski, Вы писали:
VP>CVS/SVN, Форум
SVN и форум, предоставляется RSDN для проектов.
VP>Solution
В смысле?
VP>Лицензия
Хороший, даже очень хороший вопрос. Надо подумать.
Итак, я думаю никто не возражает против open-source'сности проекта Так же я думаю никто не будет возражать против того чтобы выбрать из существующих лицензий, а не придумывать новую. Выбор в таком случае велик http://www.opensource.org/licenses/
Здравствуйте, adontz, Вы писали:
VP>>CVS/SVN, Форум A>SVN и форум, предоставляется RSDN для проектов.
ОК, если это так.
VP>>Solution A>В смысле?
Под этим словом я подрозумевал:
1. Задачи который будет решать этот проект.
2. Что должно получиться в итоге.
3. Из каких частей, проектов будет состоять решение.
4. Распеделить задачи между участниками.
A>Хороший, даже очень хороший вопрос. Надо подумать. A>Итак, я думаю никто не возражает против open-source'сности проекта
Я не против.
A> Так же я думаю никто не будет возражать против того чтобы выбрать из существующих лицензий, а не придумывать новую. Выбор в таком случае велик A>http://www.opensource.org/licenses/
Надо читать.
Здравствуйте, V.Petrovski, Вы писали:
VP>1. Задачи который будет решать этот проект. VP>2. Что должно получиться в итоге. VP>3. Из каких частей, проектов будет состоять решение. VP>4. Распеделить задачи между участниками.
Здравствуйте, V.Petrovski, Вы писали:
VP>Здравствуйте, AndrewVK, Вы писали:
AVK>>А ты готов писать этот проект на Nemerle? VP>Я не ткаой фанат как Влад, писать R# на R#
Я вообще не фанат. Но только так можно увидить слабые и сильные стороны того что делашь. Немерле, кстати, тоже сам на себе делается.
VP>И моё мнение, что лучше писать на C# 2.0 под VS2005.
Как язык C# рядом с Немерлом и рядом не волялся. Но в интеграции со студией язык думаю будет не главным. К тому же было бы хоть что-то. А там переписать на более мощьном языке будет не сложно. Так что если начать можно и на C#. А там видно будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Транслирую свой ответ по почте, чтобы все были вкурсе:
> У меня появилась несколько идей касательно VSIP. > 1. Давайте сперва напишем некоторую базу. проект который содержит > файлы, позволяет их добавлять переименовывать, удалять, редактировать, > показывать контекстное меню и проч.
Начинать с чего-то надо, так что перечисленное конечно нужно делать.
> Никакой компиляции и отладки.
Немного не ясно почему? Тем более, что это уже сделано у Nemerle-овцев. Да и компиляция точно идет через msbuild, и реализовать файл проекта в этом формате не сложно (в общем-то он уже есть).
> Собственно это у > меня уже почти есть
Так закладывай в SVN.
> 2. Добавим к этому контроль версий... > 3. Язык. Я думал над возможностью проекта для языка Nemerle... и > вспомнил, что уже давно люди хотели многоязыковые проекты... > 4. Front End'ы... > ...А тут мы можем предоставить генератору не просто этот XML, но и все > настройки проекта и данные об уже скомпилированном коде. Для тех же > DSL-писателей какое-то подспорье наверное.
Я боюсь... нет я уверен, что если попытаться объять необъятное, то ничего не выйдет. Думаю, тебе самому не приятно будет делать проект вероятность доведения которого до завершения ничтожно мала. Хватит нам уже бэнчей.
Надо быть реалистом. Я сам романтик и с удовольствием мечтаю о крутых свершениях, но больше всего в жизни я не люблю проигрывать. Так что участвовать в заведомо нереальном проекте я не хочу.
Так что, если делать, то нужно выставить приоритеты так, чтобы польза от проекта была как можно раньше.
Итак, начнем по пунктам.
П.2 — контроль версий. Реально в нем нет никакой необходимости. Просто никакой. SVN прекрасно используется с любым проектом и без какой бы то нибыло интеграции. Так что ставим этому пункту наинизший приоритет.
П.3 — многоязыковые проекты. Для начала нужно сделать хотя бы поддержку одного языка. Замахиваясь на большее мы рискуем профукать все. К тому же особых проблем создать многоязыковый проект нет. Проблема в том, чтобы собрать конечный модуль из исподников на разных языках. А это уже скорее к компилятору. Единственное, что приходит в голову — это воспользоваться разными утилитами для сливания исходников, но это можно делать и сейчас. В общем опять таки этот пункт нужно отложить до лучших времен.
П.4 — фронтэнды и генераторы. Не сделав ни одной интеграции в студию делать супер обобщенные решения крайне неразумно. Так что предлагаю сначала сосредоточиться на интеграции одного Nemerle, а уже потом обобщить опыт и сделать реализацию более универсальной.
В общем, предлагаю отбросить супер-планы и настроиться на интеграцию со студией одного языка. Если мы сделаем это качественно, то потом можно будет улучшить то что получилось. Но главное... главное, то что мы и так сдеаем очень важное дело за которое нам будут благодарны очень и очень многие.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Немного не ясно почему? Тем более, что это уже сделано у Nemerle-овцев. Да и компиляция точно идет через msbuild, и реализовать файл проекта в этом формате не сложно (в общем-то он уже есть).
В смысле мы пока сделаем не проект для Nemerle, а просто проект состоящий из файлов. Нужно будет писать другие проекты — возьмёшь этот код за основу. Не то чтобы никакой компиляцуии и отладки, скорее ничего специфичного для конкретного языка.
Что касается MSBuild. Я думал об этом, но... насколько это нас устраивает проект в формате MSBuild? Можно туда запихать элементы (файлы, например) зависимости между элементами и что дальше? Насколько этот формат расширяемый? Пример из SDK использует именно этот формат, но проекты из самой VS использут свои форматы. Причём по сравнению со студией 7.1 они поменялись без обратной совместимости, так что кажется MSBuild не очень удобен для серьёзных вещей. И вообще зачем нам компилировать через MSBuild? Импорт/экспорт в этот формат ещё ясно, а зачем нам внутри через него работать? И собственно не понятно почему импорт/экспорт сделать для MSBuild и не сделать для того же NAnt? Вобщем проблемы работать напрямую (вызывать EXE файл компилятора) я не вижу никакой, а вот какие преимущества мы получим работая через MSBuild?
VD>П.2 — контроль версий. Реально в нем нет никакой необходимости. Просто никакой. SVN прекрасно используется с любым проектом и без какой бы то нибыло интеграции. Так что ставим этому пункту наинизший приоритет.
Согласен. Я так и написал "Это не объязательно делать срочно, достаточно просто оставить лазейки."
VD>П.3 — многоязыковые проекты. Для начала нужно сделать хотя бы поддержку одного языка. Замахиваясь на большее мы рискуем профукать все. К тому же особых проблем создать многоязыковый проект нет. Проблема в том, чтобы собрать конечный модуль из исподников на разных языках. А это уже скорее к компилятору. Единственное, что приходит в голову — это воспользоваться разными утилитами для сливания исходников, но это можно делать и сейчас. В общем опять таки этот пункт нужно отложить до лучших времен.
Хм... то есть например собрать CS и VB файл в один DLL файл проблематично? Если да (нет обобщённых средств), то многоязычные проекты идут лесом.
VD>П.4 — фронтэнды и генераторы. Не сделав ни одной интеграции в студию делать супер обобщенные решения крайне неразумно. Так что предлагаю сначала сосредоточиться на интеграции одного Nemerle, а уже потом обобщить опыт и сделать реализацию более универсальной.
Тут очень простая схема. Есть файл с исходником и компилятор. Мы вызываем его как
compiler.exe source.lang
Я предлагаю добавить возможность передавать содержимое source.lang некоторому внешнему модулю, а то что он вернёт и отдавать компилятору.
compiler.exe source.lang.processed
Очень обобщённая схема. Совершенно не срочная, как и контроль версий, главное оставить лазейку.
A>В смысле мы пока сделаем не проект для Nemerle, а просто проект состоящий из файлов. Нужно будет писать другие проекты — возьмёшь этот код за основу. Не то чтобы никакой компиляцуии и отладки, скорее ничего специфичного для конкретного языка.
Зачем нам "просто проект"? Сферокони нас не интересуют. В проекте должны быть именно немерел. Его файл по умолчанию. Его визарды...
A>Что касается MSBuild. Я думал об этом, но... насколько это нас устраивает проект в формате MSBuild?
На 100%.
A> Можно туда запихать элементы (файлы, например) зависимости между элементами и что дальше?
Естественно.
A>Насколько этот формат расширяемый?
На 100%.
A> Пример из SDK использует именно этот формат, но проекты из самой VS использут свои форматы.
Не правда. Все проекты кроме С++ — это МСБилд-файлы.
A> Причём по сравнению со студией 7.1 они поменялись без обратной совместимости, так что кажется MSBuild не очень удобен для серьёзных вещей.
A> И вообще зачем нам компилировать через MSBuild?
Чтобы не изобретать велосипеды.
A> Импорт/экспорт в этот формат ещё ясно, а зачем нам внутри через него работать?
См. выше. И вообще это не обсуждается. Это стндарт Студии.
A> И собственно не понятно почему импорт/экспорт сделать для MSBuild и не сделать для того же NAnt?
Думаю прокатят импорты для Шарпового проекта (которые уже есть).
A> Вобщем проблемы работать напрямую (вызывать EXE файл компилятора) я не вижу никакой, а вот какие преимущества мы получим работая через MSBuild?
Компиляция из командной строки и при отсуствии студии.
A>Согласен. Я так и написал "Это не объязательно делать срочно, достаточно просто оставить лазейки."
ОК
VD>>П.3 — многоязыковые проекты. Для начала нужно сделать хотя бы поддержку одного языка. Замахиваясь на большее мы рискуем профукать все. К тому же особых проблем создать многоязыковый проект нет. Проблема в том, чтобы собрать конечный модуль из исподников на разных языках. А это уже скорее к компилятору. Единственное, что приходит в голову — это воспользоваться разными утилитами для сливания исходников, но это можно делать и сейчас. В общем опять таки этот пункт нужно отложить до лучших времен.
A>Хм... то есть например собрать CS и VB файл в один DLL файл проблематично?
Ага.
A> Если да (нет обобщённых средств), то многоязычные проекты идут лесом.\
Вот и я о том. Самый разумный вариант который я вижу — это конвертация. Из C# в немерле конвертировать можно. А вот из ВБ...
A>Тут очень простая схема. Есть файл с исходником и компилятор. Мы вызываем его как A>compiler.exe source.lang
И что толку?
A>Я предлагаю добавить возможность передавать содержимое source.lang некоторому внешнему модулю, а то что он вернёт и отдавать компилятору.
Здравствуйте, adontz, Вы писали:
A>Повторное использование кода. Сегодня Nemerle, завтра ещё что-то...
Такое ощущение, что языки как грибы рождаются. Зная как интегрировать один язык втрой пойдет уже как по маслу. Тогда можно будет сделать и обобщенное решение. А до первого языка делать обобщенное решение неразумно. Ведь не ясно что обобщать.
Так что надо сделать Немерле. А там уже думатьэ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>Для хитрой компиляции ничего придумывать не надо. Все украдено до нас.
A>Это через файлы, что не может не сказаться на производительности. К тому же нет доступа до многих данных, которых просто не существует в файлах.
Ты статью прочти, а там поговорим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Это через файлы, что не может не сказаться на производительности. К тому же нет доступа до многих данных, которых просто не существует в файлах. VD>Ты статью прочти, а там поговорим.
Так, вот тебе реальный пример.
Есть исходник вида
#beginregion Symbol List Generation
char[] symbolList = {
<%
for (int index = 0; index < 255; ++index)
{
Response.Write("{0}, ", index);
}
%>
};
#endregion
Отдаётся это Си++ компилятору Регионы чисто для красоты, поэтому для начала выкинем их (первый FrontEnd). В целях оптимизации регионы не вырезаются, а заменяются на комметарии. Тогда не надо сдвигать то что за ними.
/*--------------------------*/
char[] symbolList = {
<%
for (int index = 0; index < 255; ++index)
{
Response.Write("{0}, ", index);
}
%>
};
/*------*/
кроме того, у нас ещё есть код для шаблона на основе ASP.Net. Обработаем и его (второй FrontEnd)
/*--------------------------*/
char[] symbolList = {
0, 1, 2, /* немного сократил, а то 255 большое число */ 253, 254, 255,
};
/*------*/
Здравствуйте, VladD2, Вы писали:
VD>Такое ощущение, что языки как грибы рождаются.
А зачем им рождаться? Они и так есть, просто не интегрированы. Может я хочу PHP тот же или Ruby Языков как раз пруд пруди, а диалектов ещё больше. Почему бы не добавить GNU C++ Compiler к студии? Тут как раз за базовый шаблон скажут в конечном итоге гораздо большее спасибо, чем за проект но для какого-то одного языка.
VD>Зная как интегрировать один язык втрой пойдет уже как по маслу. Тогда можно будет сделать и обобщенное решение. А до первого языка делать обобщенное решение неразумно. Ведь не ясно что обобщать.
Почему не ясно? Просто для некоторых вещей функциональность будет разделена на базовый класс и наследник от него. Добавляя новую функциональност ты задумаешься специфична ли эта функциональность для Nemerle? Если да, то добавляй её в наследника, если нет, то в базовый класс. Например показывать контекстное меню ты будешь в базовом классе, но выбирать какие именно пункты показать в наследнике. Очень просто, не вижу проблем.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, V.Petrovski, Вы писали:
VP>>Здравствуйте, AndrewVK, Вы писали:
VD>Я вообще не фанат. Но только так можно увидить слабые и сильные стороны того что делашь. Немерле, кстати, тоже сам на себе делается.
Вот именно, мы ведь не Nemerle разрабатяваем.
VD>Как язык C# рядом с Немерлом и рядом не волялся. Но в интеграции со студией язык думаю будет не главным. К тому же было бы хоть что-то. А там переписать на более мощьном языке будет не сложно. Так что если начать можно и на C#. А там видно будет.
ОН конечно мощнее C#, но я так понимаю что релиза еще нет?
И для разработки одного языка мало, надо еще среда. Если бы это было не так, этот бы проект не начался.
А я уже привык к ReSharper
Здравствуйте, V.Petrovski, Вы писали:
VP>ОН конечно мощнее C#, но я так понимаю что релиза еще нет? VP>И для разработки одного языка мало, надо еще среда. Если бы это было не так, этот бы проект не начался. VP>А я уже привык к ReSharper
Решарпер макросов и паттерн-матчинга не заменит.
Среда это конечно аргумент. Но он вот как раз и должен кончиться как только заработает этот проект. После этого смысла писать на C# не останетсчя вовсе.
Боюсь вообще с C# бдут проблемы и на 100% без Немрла вообще не обойтись. Дело в том, что компилятор Немерла во всю испоьзует варианты и списки. В C# они выглядят ужасно громоздко, а использовать их из C# будет крайне затруднительно (хотя и можно).
Как минимум прийдется создать еще один проект (переходник).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>А зачем им рождаться? Они и так есть, просто не интегрированы. Может я хочу PHP тот же или Ruby
Хватит IronPyton-а и Boo. Для них и так пришлось вывод типов делать. До немерли они конечно не дотягивают, но Руби с ПХП отдыхают по полной программе. Ведь для комплита нужно знать типы. В скриптовых языках их можно только попробовать вычислить, как в Немереле. Вот только Немерле проектировался в рассчете на вывод типов, а Руби и ПХП напичканы фичами усложняющими процесс. Ну, а без этого полноценный коплит невозможен. А что толку просто с подсветки синтаксиса?
A> Языков как раз пруд пруди, а диалектов ещё больше.
Для большинсва интеграция уже есть.
A> Почему бы не добавить GNU C++ Compiler к студии?
Потому что он и так без проблем может использоваться. Там толко компилятор заменить и все. А это работа на 3 дня. Создавать интеграцию чере ВСИП для этого точно не нужно. Да и смысл нулевой. VC ничем не хуже.
A> Тут как раз за базовый шаблон скажут в конечном итоге гораздо большее спасибо, чем за проект но для какого-то одного языка.
Никто тебе зе абстрактные недоделки ничего хорошего не скажет.
И вообще, делать бобщенную и универсальную реализацию не сделав ни одной конкретной просто смешно. Это 100%-ый способ завалить проект.
VD>>Зная как интегрировать один язык втрой пойдет уже как по маслу. Тогда можно будет сделать и обобщенное решение. А до первого языка делать обобщенное решение неразумно. Ведь не ясно что обобщать.
A>Почему не ясно?
Ну, вот ты, например, не знашь даже что такое МСБилд и с чем его едять. Уже навострил лыжи отказаться от него. Меж тем на лицо банальное незнание и как следствие велосипидизм.
A> Просто для некоторых вещей функциональность будет разделена на базовый класс и наследник от него.
А где ее делить то? Ты ведь ни разу задачу не решал. И в целом ее не представляешь как решать. Ты сейчас исследователь. Твоя задача познать как работает Студия. При таком расскладе ты максимум сделашь специализированное решение. А вот когда оно будет готово, то можно покумекать как его обобщить.
A> Добавляя новую функциональност ты задумаешься специфична ли эта функциональность для Nemerle? Если да, то добавляй её в наследника, если нет, то в базовый класс. Например показывать контекстное меню ты будешь в базовом классе, но выбирать какие именно пункты показать в наследнике. Очень просто, не вижу проблем.
Nemerle хотя бы на C# похож. И у него есть готовые КодДом-провайдеры, парсеры, лексеры... А для какого нить Руби этого всего не будет. И вообще там особенностей хватает. Максимум что можно придумать, то некий шаблон с универсальным реплэйсом. Но для этого нужно сначала получить хотя бы одну работающую реализацию в которой ты будешь понимать что твориться.
В общем, делать первую версию универсальной считаю неразумным. Надо получить хотя бы какой-то прототип, а уже там думать можно ли его обобщить. Иначе все затянется и так и кончитсвя ни чем.
Более того я поглядел IronPyton и прихожу к выводу, что видимо проще сделать проект для Немерла на его базе. Убрать все лишнее... Заменить по контексту... И потихоничку набить фукнционалом. Это мозволит получить рабочую версию в ближайшее время (недели две). Ну, а там видно будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Так, вот тебе реальный пример.
Хреновый пример надо признать. Изобретение кривых велосипедов. Ну, да не о том речь.
A>Теперь объясни мне как это сделать через MSbuild?
Прочти статью. А? Ну, смешно право слово. Любую задачу можно оформить в качестве Task-а и Target-ов. Собственно компиляция есть не что иное как преобразование набора исходных файлов в набор других, выполнимых, вайлов. Идеологически это ни чем не отличается от пребразования одного текстового формата в другой.
В общем, влосипеды иду в лес. Темболее что МСБилд — это стандат.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Так, вот тебе реальный пример. VD>Хреновый пример надо признать. Изобретение кривых велосипедов. Ну, да не о том речь.
Конечно хреновый, он же реальный.
VD>Любую задачу можно оформить в качестве Task-а и Target-ов.
Ну так покажи решение.
VD>Идеологически это ни чем не отличается от пребразования одного текстового формата в другой.
Проблема в том, что далеко не вся необходимая информация храниться в файлах.
VD>Тем более что МСБилд — это стандат.
Влад, ты что-то пропагандой увлёкся. Я не против MSBuild, я просто хотел узнать преимущества. Дал реальный пример и попросил показать в общих чертах решение. Ты меня начал тыкать в свою статью. Извини, но это не аргумент и вообще не способ совместной работы. Я раньше с MSbuild не работал и прошу меня чему-то научить, а ты высокомерничаешь. Зачем?
Здравствуйте, VladD2, Вы писали:
A>> Почему бы не добавить GNU C++ Compiler к студии? VD>Потому что он и так без проблем может использоваться. Там толко компилятор заменить и все. А это работа на 3 дня.
Боюсь что это несколько не так. Надо пересоздавать Си++ проект с нуля. Intel C++ Compiler интегрируется только потому что совместим на уровне параметров командной строки и кодов ошибок.
VD>Ну, вот ты, например, не знашь даже что такое МСБилд и с чем его едять. Уже навострил лыжи отказаться от него. Меж тем на лицо банальное незнание и как следствие велосипидизм.
Я навострил лыжи? Я просто спросил в чём преимущества. Ты меня носом в статью тычешь. Ну прочёл я её, а вот великого просветления что-то не настало. А помочь ты не рвёшься
VD>А где ее делить то? Ты ведь ни разу задачу не решал. И в целом ее не представляешь как решать. Ты сейчас исследователь. Твоя задача познать как работает Студия.
Как она работает я себе вполне представляю, я просто хотел разобраться в тонкостях, которые скрывают стандартные классы.
VD>Nemerle хотя бы на C# похож. И у него есть готовые КодДом-провайдеры, парсеры, лексеры... А для какого нить Руби этого всего не будет. И вообще там особенностей хватает. Максимум что можно придумать, то некий шаблон с универсальным реплэйсом. Но для этого нужно сначала получить хотя бы одну работающую реализацию в которой ты будешь понимать что твориться.
Дело в том, что всё это не Project, а LanguageService, максимум Editor и, делая проект, о синтаксисе языка думать вообще не надо. проект это набор файлов, средства компиляции и отладки. Редактирование совершенно отдельная часть.
VD>В общем, делать первую версию универсальной считаю неразумным. Надо получить хотя бы какой-то прототип, а уже там думать можно ли его обобщить. Иначе все затянется и так и кончитсвя ни чем.
Прототип есть и сейчас — это пример из SDK. Мне он не нравится архитектурой и я давно хотел его переписать по нормальному. А заодно и разобраться в мелочах. Тут как раз представился случай делать это не одному и не только для себя вот и всё. Мне в этом проекте интересен именно базовый универсальный класс и опыт в VSIP, а на Nemerle я в ближайшее время писать не собираюсь. В прочем и в далёкое тоже. И то что не надо будет тратить время на парсеры и другие специфичные для языка вещи для меня только плюс в этом плане.
VD>Более того я поглядел IronPyton и прихожу к выводу, что видимо проще сделать проект для Немерла на его базе. Убрать все лишнее... Заменить по контексту... И потихоничку набить фукнционалом. Это мозволит получить рабочую версию в ближайшее время (недели две). Ну, а там видно будет.
Да, это самый быстрый путь, но он совершенно не коррелирует с моим желанием поковыряться. Если ты хочешь VS Project за 24 часа, то переделывай примеры из SDK. Там действительно через 1-2 недели будет результат, но лично мне писать это совершенно не интересно, потому что в примерах из SDK я уже успел разочароваться и делать что-то на их основе не считаю целесообразным. В принципе тебе решать и я соскакивать не собираюсь, но в конечном итоге, после очередного костыля и заплатки ты и сам решишь написать всё с нуля. Благо на это ИМХО нужно не более месяца. А если вмногером и того меньше.
Здравствуйте, adontz, Вы писали:
A>Боюсь что это несколько не так. Надо пересоздавать Си++ проект с нуля. Intel C++ Compiler интегрируется только потому что совместим на уровне параметров командной строки и кодов ошибок.
Я не знаком с подробностями, но даже если и так, то в чем проблема создать маленький переходной ехе-шничек?
К тому же проблемы С++ как всегда в самостийности. Исользовали бы МСБилд и вообще вопросов бы не было.
A>Я навострил лыжи? Я просто спросил в чём преимущества.
Судя по тому упорству с которым ты отстаивашь велосипед, все же дело не в преимуществах.
A>Ты меня носом в статью тычешь. Ну прочёл я её, а вот великого просветления что-то не настало. А помочь ты не рвёшься
Если бы ты ее действитльно прочел до конца, то заметил бы кучу приемуеществ. От переносимости между плаформами (ведь от утилит мы не зависис), до возможности легко расширять возможности системы добавляя новые Задания и Цели.
A>Как она работает я себе вполне представляю, я просто хотел разобраться в тонкостях, которые скрывают стандартные классы.
Хм. Первый же вопрос с устройством проекта и ты уже плавашь. Вряд ли это можно назвать твердым знанием. Ну, да ладно. Давай копнем глубже. Как по твоему работает автодополнение и парсинг файлов проекта?
A>Дело в том, что всё это не Project, а LanguageService, максимум Editor и, делая проект, о синтаксисе языка думать вообще не надо. проект это набор файлов, средства компиляции и отладки. Редактирование совершенно отдельная часть.
Хм. А что там делать то тога в проекте? В том же АйронПитоне уже все есть. Меняй по контексту и вперед.
Ценность же представляет именно редактирование (комплит, подсветка, рефакторинг, снипеты).
A>Прототип есть и сейчас — это пример из SDK.
Это черный ящик с глюками. Вот когда он заработает на Немерле, то можно будет и дальше идти.
Думаю это и должно стать первым шагом.
A> Мне он не нравится архитектурой и я давно хотел его переписать по нормальному.
Я чесно говоря архитекутных проблем пока не увидел. Грязнь в коде присутсвует конично. Но она не клиническая и ее легко можно будет отрефакторить.
A> А заодно и разобраться в мелочах.
А вот для этого нужно просто интегрировать свой язык. Мелочи сами собой вылезут. А не вылезут, значит они не значительные.
A> Тут как раз представился случай делать это не одному и не только для себя вот и всё. Мне в этом проекте интересен именно базовый универсальный класс и опыт в VSIP, а на Nemerle я в ближайшее время писать не собираюсь. В прочем и в далёкое тоже. И то что не надо будет тратить время на парсеры и другие специфичные для языка вещи для меня только плюс в этом плане.
Ну, а мне нужен результат. И я вижу, что ечли упереться в излишнее обобщение, то его (результата) можно вовсе не получить.
Считай что сначала мы делаем прототип. Когда он будет закончен можешь сделать на его базе более общую реализацию.
A>Да, это самый быстрый путь, но он совершенно не коррелирует с моим желанием поковыряться.
О... Ковыряться там огого с чем можно. Мои прикидки привели к тому, что все что связано с самим языком нужно полностью выкидывать. А это очень не малый объем работ.
A> Если ты хочешь VS Project за 24 часа, то переделывай примеры из SDK. Там действительно через 1-2 недели будет результат, но лично мне писать это совершенно не интересно, потому что в примерах из SDK я уже успел разочароваться и делать что-то на их основе не считаю целесообразным.
А в чем собственно разочарование? Поделился бы. Всем было бы интересно.
A> В принципе тебе решать и я соскакивать не собираюсь, но в конечном итоге, после очередного костыля и заплатки ты и сам решишь написать всё с нуля. Благо на это ИМХО нужно не более месяца. А если вмногером и того меньше.
Незнаю, незнаю. Объем работ там не малый. Боюсь с нуля будет очень на дого. Проект (если не полноценный как в C#, а так... лишь бы работало) действительно делается за день-два. А вот сервисы связанные с языком... Там огого сколько нужно делать. И не ясно зачем, если уже многое готово. Код не смертельно крив. Рефакторингу поддается.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
VD>>Любую задачу можно оформить в качестве Task-а и Target-ов.
A>Ну так покажи решение.
Что показывать то? Как класс реализовать? Встатье есть пример.
В МСБилде ты можешь делать любое количество стадий предварительной обработки. Это не проблема.
VD>>Идеологически это ни чем не отличается от пребразования одного текстового формата в другой.
A>Проблема в том, что далеко не вся необходимая информация храниться в файлах.
Ну, это уже твои проблемы. В проекте ты можешь задать любое сочетание айтемов и свойств. Ими можно хоть черта лысого описать.
VD>>Тем более что МСБилд — это стандат.
A>Влад, ты что-то пропагандой увлёкся.
Что-то от тебя про прапаганду много слышно. Тоже плохой симптом.
A> Я не против MSBuild, я просто хотел узнать преимущества.
Ну, я тебе вроде про них сказал. Даже статью дал. Неужели мало?
Ладно повтою еще раз. МСБилд — это 100%-но расширяемый формат, позволяющий создавать переносимые решения по сборке проектов. Он же прекрасно подходит для описания проектов для VS (является его основным форматом, и для этго собственно и разработывался), хорошо документированный, стандартизованный, используется почти во всех типах проектов в VS2005. И это против идеи передавать некий инифайл неизвесной структуры в неизвесный ехе-шник.
A> Дал реальный пример и попросил показать в общих чертах решение.
В общих чертах все решения одинаковы. Созаешь Задачу (Task) — дотнет-компонент осуществляющий работу. Регистрируешь его в таргет-файле иописывашь цель которую можно взывать. Далее цель заеляшь за другую цель чтобы она вызвалась и поисывашь зависимости (входные и выходные файлы). Если входные файлы старше вызодных и запущена цель, то произойдет вызов Задачи котороая и произведет проебразовние.
Все это подробнейшим образгом описано в статье.
A> Ты меня начал тыкать в свою статью. Извини, но это не аргумент и вообще не способ совместной работы. Я раньше с MSbuild не работал и прошу меня чему-то научить, а ты высокомерничаешь. Зачем?
Не извиню. В статье есть и примеры Задачи, и примеры проектов и полный рассказ о возможностях и разначнии. Ты просто прочел ее наискосок. Попробуй еще раз и я уверен ты поймешь суть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>Такое ощущение, что языки как грибы рождаются.
A>А зачем им рождаться? Они и так есть, просто не интегрированы. Может я хочу PHP тот же или Ruby Языков как раз пруд пруди, а диалектов ещё больше. Почему бы не добавить GNU C++ Compiler к студии? Тут как раз за базовый шаблон скажут в конечном итоге гораздо большее спасибо, чем за проект но для какого-то одного языка.
Вот! Вот это мне уже гораздо больше нравится Даёшь GNU C++ Comp...эээ, базовый шаблон
VD>>Зная как интегрировать один язык втрой пойдет уже как по маслу. Тогда можно будет сделать и обобщенное решение. А до первого языка делать обобщенное решение неразумно. Ведь не ясно что обобщать.
A>Почему не ясно? Просто для некоторых вещей функциональность будет разделена на базовый класс и наследник от него. Добавляя новую функциональност ты задумаешься специфична ли эта функциональность для Nemerle? Если да, то добавляй её в наследника, если нет, то в базовый класс. Например показывать контекстное меню ты будешь в базовом классе, но выбирать какие именно пункты показать в наследнике. Очень просто, не вижу проблем.
Здравствуйте, VladD2, Вы писали:
A>>Боюсь что это несколько не так. Надо пересоздавать Си++ проект с нуля. Intel C++ Compiler интегрируется только потому что совместим на уровне параметров командной строки и кодов ошибок. VD>Я не знаком с подробностями, но даже если и так, то в чем проблема создать маленький переходной ехе-шничек?
Проблема хотя бы в том, что количество кодов ошибок и список настроек не совпадают и переходной exe-шничек не позволит использовать все возможности GCC.
A>>Я навострил лыжи? Я просто спросил в чём преимущества. VD>Судя по тому упорству с которым ты отстаивашь велосипед, все же дело не в преимуществах.
Влад, если бы не твоё желание меня поддеть я бы уже давно успел сказать, что согласен использовать MSBuild даже если по сравнению с самопальным форматом это шило на мыло.
VD>Если бы ты ее действитльно прочел до конца, то заметил бы кучу приемуеществ.
Чего ты ждёшь? Что я скажу "Влад, я тупой"? Ну прочёл и не заметил и что теперь? Вместо того чтобы объяснить своими словами, важничаешь.
VD>Давай копнем глубже. Как по твоему работает автодополнение и парсинг файлов проекта?
Как я уже говорил с LanguageService я близко не работал, но насколько мне известно в нужные моменты (какие моменты нужные решаешь сам) вызываешь IVsTextView.UpdateCompletionStatus передавая сво реализацию IVsCompletionSet.
VD>Хм. А что там делать то тога в проекте? В том же АйронПитоне уже все есть. Меняй по контексту и вперед.
Не думаю что всё так просто. Не известно насколько IronPython доделан.
A>>Прототип есть и сейчас — это пример из SDK. VD>Это черный ящик с глюками.
Так об том и речь!
A>> Мне он не нравится архитектурой и я давно хотел его переписать по нормальному. VD>Я чесно говоря архитекутных проблем пока не увидел. Грязнь в коде присутсвует конично. Но она не клиническая и ее легко можно будет отрефакторить.
Там очень сложные и неправильные отношения владения ресурсами. Я бы хотел от этого избавиться
VD>Ну, а мне нужен результат. И я вижу, что ечли упереться в излишнее обобщение, то его (результата) можно вовсе не получить.
Я обощать ничего не собираюсь, мне нужен проект из файлов. Это не добавит никакой новой функциональности, просто разделит проект на две части универсальную и специфичную для языка. От разделения универсальная часть больше не станет, это тот же объём кодирования, просто я хотел бы с самого начала её отделить. Хотя бы потому что она мне потом пригодиться.
VD>А в чем собственно разочарование? Поделился бы. Всем было бы интересно.
Вобщем проект представлен как дерево. Причем у элементов есть Parent, FirstChild и NextSibling. Стандартный способ представлять любое дерево в виде двоичного. Есть интерфейс IVsHierarchy, который вроде бы должен упралять всем этим хозяйством. Именно он возвращает FirstChildID и NextSiblingID по ItemID. Именно через этот интерфейс управляются свойства элементов такие как имя, тип, иконка, раскрытость (для папок), объект свойства котрого показываются в кокошке Properties и проч. Основная беда в том, что владение элементов в резализации из SDK поручено самому элементу. Поэтому, если например его преименовать, то он сам себя удаляет, а потом добавляет новый элемент с такими же свойствами, но другим именем (при этом обращается к удалённому самому себе). А потом оповещает обо всём этом проект в лице самого главного IVsHierarchy. О! Кстати, в реализации MS для одного и того же дерева проекта одновременно живут многие копии IVsHierarchy, одна для проекта и по одной для каждого элемента. Причём IVsHierarchy элементов практически все вызовы делегируют IVsHierarchy проекту. Сами обрабатывают только переименование, выбор элементов контекстного меню и т.п.
Это оправдано (и по-другому нельзя) когда IVsHierarchy чужой. Например Parent для проекта это внешний объект Solution (Кстати Solution это тот же Project у которого элементы другие Project) и это отдельный IVsHierarchy, но зачем надо было устраивать такой трах внутри проекта мне совершенно не ясно. Во всяком случае показать дерево мне удалось и так.
VD>Незнаю, незнаю. Объем работ там не малый. Боюсь с нуля будет очень на дого. Проект (если не полноценный как в C#, а так... лишь бы работало) действительно делается за день-два. А вот сервисы связанные с языком... Там огого сколько нужно делать. И не ясно зачем, если уже многое готово. Код не смертельно крив. Рефакторингу поддается.
Счастье в том, что LanguageService это в высокой степени отдельная штукенция которая меня не сильно интересует. Ты её можешь запроектировать как тебе будет удобно. Мне хотелось переписать только IVsHierarchy и всё что рядом.
Хотя по уму желательно конечно кешировать информацию для подсветки и автокомплита где-то в проекте. Си++ для этих целей делает ncb файл общий для всех проектов рядом с солюшеном. Учитывая, что у нас .Net можно хранить информацию Per Project и даже Per File, Например в дополнительном NTFS потоке (кстати идея пришла в голову пока я писал сообщения и мне самому очень понравилась).
Здравствуйте, Chipsеt, Вы писали:
C>Вот! Вот это мне уже гораздо больше нравится Даёшь GNU C++ Comp...эээ, базовый шаблон
Ну вот, Влад, я ты говорил базовый шаблон никому не нужен
Кроме того джля того же PHP достаточно сделать автокомплит для всех ключевых слов и стандартных функций (для функций ещё тултипы со справкой по параметрам) и 90% PHP программистов будет счастливо. А если ещё и отладку сделать, то вообще зашибись
Здравствуйте, adontz, Вы писали:
A>Проблема хотя бы в том, что количество кодов ошибок и список настроек не совпадают и переходной exe-шничек не позволит использовать все возможности GCC.
Не надо выдумывать проблемы. Ошибки просто выдаются к консоль. Все что нужно сделать — это преобразовать их в вид который распознает студия (т.е. "путь-к-файлу(строка,колонка):Сообщение". Настройки же банально перемапливаются. Те что отсуствуют в VC можно задавать через ресширение командной строки (это уже есть).
A>Влад, если бы не твоё желание меня поддеть
У меня нет желания поддеть. Просто отстаивание велосипеда настолько очевидно для меня, что даже не хочется это обсуждать.
A> я бы уже давно успел сказать, что согласен использовать MSBuild даже если по сравнению с самопальным форматом это шило на мыло.
Ну, вот и ладно. Значит вопрос исчерпан.
A>Как я уже говорил с LanguageService я близко не работал,
Вот видишь. А между тем, LanguageService пожалуй главное что нужно сделать, так как остальное уже в общем-то есть или не вызывает вопросов.
A>но насколько мне известно в нужные моменты (какие моменты нужные решаешь сам) вызываешь IVsTextView.UpdateCompletionStatus передавая сво реализацию IVsCompletionSet.
Но ведь надо реагировать на ввод пользователя.
A>>>Прототип есть и сейчас — это пример из SDK. VD>>Это черный ящик с глюками.
A>Так об том и речь!
О чем? О том, что вместо изучения вопроса надо все сделать самому наступив на море граблей?
A>Там очень сложные и неправильные отношения владения ресурсами. Я бы хотел от этого избавиться
Можно примеры? Я заметил только не всегда красивое управление временем жизни КОМ-объектов. Что не есть проблема.
A>Счастье в том, что LanguageService это в высокой степени отдельная штукенция которая меня не сильно интересует.
Возможно это действительно счастье . Но меня интересует именно это счастье, так как проект я могу испльзовать и от C#-а. Ведь когда в нем появляются .n-файлы, то, как я понимаю управление ими передается именно LanguageService. А это практически то что нужно.
A> Ты её можешь запроектировать как тебе будет удобно. Мне хотелось переписать только IVsHierarchy и всё что рядом.
А есть смысл то? Ведь ка раз работа дерева в Питоновском примере нареканий не вызывает.
A>Хотя по уму желательно конечно кешировать информацию для подсветки и автокомплита где-то в проекте.
Кэшировать информацию для подсветки? Ты точно уверен, что хоршо понимашь о чем говоришь? Что до комплита, то это вопрос очень не простой. Но уже есть движок комплита, так что прийдется считаться с ним.
Общая идея работы с комплитом мне видится так:
1. При загрузке отпарсиваем весь проект и кэшируем результат.
2. При переключении на файл мысленно разбиваем его на функции и просто группы скобок внутри функций.
3. При изменении содержимого фала определяем какая функция изменена.
4. Определяем впорядке ли иерархии скобок. Если со скобками проблемы, то даже не пытаемся парсить.
5. Если со скобками все ОК, то определяем измененную фукнкцию и перепарсиваем ее содержимое получая таким образом список локальных переменных и функций.
6. При запросе на автокомплит обращаемся к закэшированным данным хранимым в дивжке комплита и получаем список подходящих дополнений. Тут отдельно нужно обрабатывать контекст. Например, если запрашивается список комплита, а перед курсором стоит ":", то нужно выдать список типов. А если текущей позиции соотвествует некий параметр функции, то имеет смысл отфильтровать типы приводимые к типу параметра. Ну, и так далее.
A> Си++ для этих целей делает ncb файл общий для всех проектов рядом с солюшеном.
Не, С++, а VC++. И получается полная задница. Комплит врет и глючит. В дотнете такого не делают, так как для внешних сборок все получается из метаданных, а для внутнренних файлов все можно держать в памяти. Даже 300 метров меня лично не смутят. Бенефиты того стоят.
A> Учитывая, что у нас .Net можно хранить информацию Per Project и даже Per File, Например в дополнительном NTFS потоке (кстати идея пришла в голову пока я писал сообщения и мне самому очень понравилась).
Ненадо вообще ничего хранить. Движок комплита, насколько я знаю, сам вынемает все из внешних сборок и выпарсивает из передаваемых файлов. Остается тлько грамотно совместить его умения с окружением VS.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Chipsеt, Вы писали:
C>>Вот! Вот это мне уже гораздо больше нравится Даёшь GNU C++ Comp...эээ, базовый шаблон
A>Ну вот, Влад, я ты говорил базовый шаблон никому не нужен
Я не говорил этого. Я сказал, что:
1. Он не нужен для данного проекта.
2. Это обобщение, и его следует реализовывать тлько тогда, когда будет все предельно ясно с функционированием VS. То есть сначало нужно реализовать все без выпендрежа.
К тому же необходимость эта гиптетическая. Как я уже говорил, если бы вообще кому-то сильно это захотелось, то не проблема сделать перходной ехе-шник.
A>Кроме того джля того же PHP достаточно сделать автокомплит для всех ключевых слов и стандартных функций (для функций ещё тултипы со справкой по параметрам)
Для этого нужно всего ничего. Придумать нечто вроде ХМЛ-доков для ПХП, написать парсер этого дела...
A> и 90% PHP программистов будет счастливо. А если ещё и отладку сделать, то вообще зашибись
Меня не трогает счастье ПХП-програмистов. У меня есть конкретная задача которую я намереваюсь решить. И всякое отвлечение от цели грозит тем, что цель не будет достигнута.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Настройки же банально перемапливаются. Те что отсуствуют в VC можно задавать через ресширение командной строки (это уже есть).
Ну это изврат всё таки. И потом GCC далеко не самый страшный случай.
A>>но насколько мне известно в нужные моменты (какие моменты нужные решаешь сам) вызываешь IVsTextView.UpdateCompletionStatus передавая сво реализацию IVsCompletionSet. VD>Но ведь надо реагировать на ввод пользователя
Надо, а что?
VD>О чем? О том, что вместо изучения вопроса надо все сделать самому наступив на море граблей?
Ну это море я уже наполовину проплыл
A>>Там очень сложные и неправильные отношения владения ресурсами. Я бы хотел от этого избавиться VD>Можно примеры? Я заметил только не всегда красивое управление временем жизни КОМ-объектов. Что не есть проблема.
Я же уже написал про кучу IVsHierarchy.
VD>Возможно это действительно счастье . Но меня интересует именно это счастье, так как проект я могу испльзовать и от C#-а. Ведь когда в нем появляются .n-файлы, то, как я понимаю управление ими передается именно LanguageService. А это практически то что нужно.
Ну в принципе да. Если конечно исключить вариант, что Language Service для языка умеет как-то хитро, в обход студии, общатся с проектом для того же языка, чего лично я не исключаю.
VD>А есть смысл то? Ведь как раз работа дерева в Питоновском примере нареканий не вызывает
Это дерево рисует сама студия, меня больше волнует что там внутри и во сколько мне обойдёться, например, добавлять новые типы файлов.
VD>Кэшировать информацию для подсветки? Ты точно уверен, что хорошо понимашь о чем говоришь?
Конечно. Студия тебе даёт подсвечивать текст построчно. Тебе даёться номер строки и состояние с которого начинается подсветка (состояние которым закончилась подсветка предыдущей строки). Очевидно что если не поменялась сама строка и не поменялось начальное состояние, то заново её раскрашивать нет никакого смысла.
VD>1. При загрузке отпарсиваем весь проект и кэшируем результат. VD>2. При переключении на файл мысленно разбиваем его на функции и просто группы скобок внутри функций. VD>3. При изменении содержимого фала определяем какая функция изменена. VD>4. Определяем впорядке ли иерархии скобок. Если со скобками проблемы, то даже не пытаемся парсить. VD>5. Если со скобками все ОК, то определяем измененную фукнкцию и перепарсиваем ее содержимое получая таким образом список локальных переменных и функций. VD>6. При запросе на автокомплит обращаемся к закэшированным данным хранимым в дивжке комплита и получаем список подходящих дополнений. Тут отдельно нужно обрабатывать контекст. Например, если запрашивается список комплита, а перед курсором стоит ":", то нужно выдать список типов. А если текущей позиции соотвествует некий параметр функции, то имеет смысл отфильтровать типы приводимые к типу параметра. Ну, и так далее.
Хорошо бы это сделать в виде системы фильтров. То есть у нас есть список всех имён и уже набранная часть и окружающий контекст. Мы передаём эти данные фильтру, а он возвращает новый список, элементы которого подмножество изначального списка. и так через все фильтры.
VD>Ненадо вообще ничего хранить. Движок комплита, насколько я знаю, сам вынемает все из внешних сборок и выпарсивает из передаваемых файлов. Остается тлько грамотно совместить его умения с окружением VS.
А как он вынимает, через Reflection? Так это же тогда тем более надо всё кешировать, а то если на каждый комплит у будет пробежка рефлекшеном по всем зависимостям...
Здравствуйте, adontz, Вы писали:
VD>>Но ведь надо реагировать на ввод пользователя
A>Надо, а что?
То что это и есть объем работ. Причем не маленький.
A>Ну это море я уже наполовину проплыл
Ты его и на 5% не исследовал. Там объем кода огого какой.
A>Я же уже написал про кучу IVsHierarchy.
Откроевенно говоря не заметил там каких то уж особых изрващений. Но может быть просто плохо разбирался. В ближайшее время будет видно.
A>Ну в принципе да. Если конечно исключить вариант, что Language Service для языка умеет как-то хитро, в обход студии, общатся с проектом для того же языка, чего лично я не исключаю.
Дык проект C#-ый. Думаю будет не очень сложно получить список файлов из него. В конце концов тот же IVsHierarchy и ежесним доступны. В общем, надо пробовать.
A>Это дерево рисует сама студия, меня больше волнует что там внутри и во сколько мне обойдёться, например, добавлять новые типы файлов.
Я просто заменой по контексту вроде как получил все что нужно.
VD>>Кэшировать информацию для подсветки? Ты точно уверен, что хорошо понимашь о чем говоришь?
A>Конечно. Студия тебе даёт подсвечивать текст построчно. Тебе даёться номер строки и состояние с которого начинается подсветка (состояние которым закончилась подсветка предыдущей строки). Очевидно что если не поменялась сама строка и не поменялось начальное состояние, то заново её раскрашивать нет никакого смысла.
Сразу видно, что ты не владешь проблемой. Так как я сам писал редактор с подсветкой, то могут тебе с уверенностью сказать, что кроме состояния лексера ничего кэшировать не надо. А это обычно просто целое число.
Кэшироватьние чего-то еще — это неразумная трата ресурсов и усложнение реализации. Лексер работает настолько быстро, что смысла в кэшировании просто нет.
A>Хорошо бы это сделать в виде системы фильтров. То есть у нас есть список всех имён и уже набранная часть и окружающий контекст. Мы передаём эти данные фильтру, а он возвращает новый список, элементы которого подмножество изначального списка. и так через все фильтры.
Такой фильр и есть студийные интерфейсы. А их реализация уперается в особенности парсеров и т.п. Лишний же уровень абстракции тут вроде бы ни к чему.
A>А как он вынимает, через Reflection?
Естественно.
A> Так это же тогда тем более надо всё кешировать, а то если на каждый комплит у будет пробежка рефлекшеном по всем зависимостям...
Движок сам кэширует все что нужно. Вопрос тлько в грамотном обновлении кэша при изменении внешних данных.
К тому же вынимание данных не такой уж долгий процесс. Он мало чем будет отличаться от считывания из файла. По сути это тот же файл и есть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Дык проект C#-ый. Думаю будет не очень сложно получить список файлов из него. В конце концов тот же IVsHierarchy и ежесним доступны. В общем, надо пробовать.
Список файлов можно получить даже из RunningDocumentTable. Важно уметь отслеживать изменения в этих файлах, их зависимости и проч.
VD>Сразу видно, что ты не владешь проблемой. Так как я сам писал редактор с подсветкой, то могут тебе с уверенностью сказать, что кроме состояния лексера ничего кэшировать не надо. А это обычно просто целое число.
Это когда он свой, а сказать Nemerle перепарсь мне строку № 117 из состояния 143 ты сможешь? Что-то мне подсказывает, что он парсит файл целиком и никак иначе.
VD>Такой фильтр и есть студийные интерфейсы.
Нет, студии ты отдаёшь просто список строк. Никаких фильтров там нет и студии грубоко наплевать откуда эти строки взялись и что они означают.
Здравствуйте, adontz, Вы писали:
A>Это когда он свой, а сказать Nemerle перепарсь мне строку № 117 из состояния 143 ты сможешь?
Должны смочь. Если что будем рехтовать компилятор. Немероловцы помощь уже обещали. http://nemerle.org/phpBB/viewtopic.php?p=558#558
A>Нет, студии ты отдаёшь просто список строк. Никаких фильтров там нет и студии грубоко наплевать откуда эти строки взялись и что они означают.
Откровенно говоря не очень понимаю, что там фильтровать еще.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Должны смочь. Если что будем рехтовать компилятор.
Рехтовать компилятор? И ещё ты мне что-то говришь про быстры результат?
VD>Откровенно говоря не очень понимаю, что там фильтровать еще.
Вот у тебя есть все-все-все возможные слова: типы, переменные, ключевые слова. Есть некоторый контекст: месторасполодение курсора, уже набранная часть слова. Пусть уже набранная часть это "wh". Значит фильтр №1 выкидывает все строки в которых нет "wh" и перемещает строки начинающиеся на "wh" в начало. Фильтр номер два смотрит что имя типа по контексту не умесно и выкидывает все типы. Ну и так далее. То что осталось и отдаётся в конечном итоге студии.
Кстати по поводу страхов. Пример LanguageService из SDK ровно в 2 раза меньше примера Project
Здравствуйте, adontz, Вы писали:
A>Это оправдано (и по-другому нельзя) когда IVsHierarchy чужой. Например Parent для проекта это внешний объект Solution (Кстати Solution это тот же Project у которого элементы другие Project) и это отдельный IVsHierarchy, но зачем надо было устраивать такой трах внутри проекта мне совершенно не ясно. Во всяком случае показать дерево мне удалось и так.
Ты ничего не путаешь? IVsHierarchy реализуется проектом. Список проектов в солюшене получается совсем другим способом. IVsHierarchy не является элементом иерархии, это адаптер для доступа к иерархии внутри проекта.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты ничего не путаешь? IVsHierarchy реализуется проектом. Список проектов в солюшене получается совсем другим способом. IVsHierarchy не является элементом иерархии, это адаптер для доступа к иерархии внутри проекта.
Я тоде так думал, однако можешь убедиться сам что ребята из MS сделали невозможное
public abstract class HierarchyNode :
IVsUIHierarchy,
IVsPersistHierarchyItem2,
Microsoft.VisualStudio.OLE.Interop.IOleCommandTarget,
IVsHierarchyDropDataSource2,
IVsHierarchyDropDataSource,
IVsHierarchyDropDataTarget,
IVsHierarchyDeleteHandler
public class FileNode : HierarchyNode
public class FolderNode : HierarchyNode
public class NestedProjectNode : HierarchyNode, IDisposable
public abstract class ProjectNode : HierarchyNode,
IVsGetCfgProvider,
IVsProject3,
IPersistFileFormat,
IVsProjectBuildSystem,
IVsComponentUser,
IVsUIHierWinClipboardHelperEvents,
IVsDependencyProvider,
IVsSccProject2,
IBuildDependencyUpdate,
IReferenceContainerProvider
public class ReferenceContainerNode : HierarchyNode, IReferenceContainer
public abstract class ReferenceNode : HierarchyNode
Здравствуйте, AndrewVK, Вы писали:
A>>Я тоде так думал, однако можешь убедиться сам что ребята из MS сделали невозможное AVK>Странно. Я реализовывал IVsHierarchy только в самом проекте и все работало.
Вот именно что странно зачем надо было делать так собственно я тоде реализовывал IVsHierarchy только в проекте и пока что у меня тоже всё работает. Об чём и речь — архитектура у примеров из SDK дерьмоватая.
Здравствуйте, adontz, Вы писали:
AVK>>Ты ничего не путаешь? IVsHierarchy реализуется проектом. Список проектов в солюшене получается совсем другим способом. IVsHierarchy не является элементом иерархии, это адаптер для доступа к иерархии внутри проекта.
A>Я тоде так думал, однако можешь убедиться сам что ребята из MS сделали невозможное
Я вот тоже после твоих слов долго рылся в коде АйронПитона и пытался найти где там в иерархии проектов используется IVsHierarchy. Ненашел.
Теперь ты тыкашь на код где он снова не встречается и продолжашь о нем рассуждать. Может ты пояснишь о чем ты говоришь? Где ты в приведенном тобой коде увидал IVsHierarchy ?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
A>>Я тоде так думал, однако можешь убедиться сам что ребята из MS сделали невозможное
AVK>Странно. Я реализовывал IVsHierarchy только в самом проекте и все работало.
А что в его коде где-то был IVsHierarchy? Там вроде ни одного интерфейса даже унаследованного от IVsHierarchy нет. Похоже его смутили похожие названия.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А что в его коде где-то был IVsHierarchy? Там вроде ни одного интерфейса даже унаследованного от IVsHierarchy нет. Похоже его смутили похожие названия.
Блин, Влад, вот как ты любишь высокомерно обсуждать то, в чём нихрена не понимаешь
IVsUIHierarchy наследуется от IVsHierarchy
Microsoft.VisualStudio.Package.HierarchyNode наследуется от IVsUIHierarchy
Microsoft.VisualStudio.Package.FileNode наследуется от Microsoft.VisualStudio.Package.HierarchyNode
Microsoft.VisualStudio.Package.FolderNode наследуется от Microsoft.VisualStudio.Package.HierarchyNode
Microsoft.VisualStudio.Package.NestedProjectNode наследуется от Microsoft.VisualStudio.Package.HierarchyNode
Microsoft.VisualStudio.Package.ProjectNode наследуется от Microsoft.VisualStudio.Package.HierarchyNode
Microsoft.VisualStudio.Package.ReferenceContainerNode наследуется от Microsoft.VisualStudio.Package.HierarchyNode
Microsoft.VisualStudio.Package.ReferenceNode наследуется от Microsoft.VisualStudio.Package.HierarchyNode
Обсуждал я код отсюда "C:\Program Files\Visual Studio 2005 SDK\2006.04\VisualStudioIntegration\Common\Source\CSharp\Project"
Что касается IronPython "C:\Program Files\Visual Studio 2005 SDK\2006.04\VisualStudioIntegration\Samples\IronPythonIntegration\"
Если бы вмеcто провокационных заявлений в мой адрес, ты потрудился действительно разобраться то увидел бы, что там в проекты ссылки на файлы из "C:\Program Files\Visual Studio 2005 SDK\2006.04\VisualStudioIntegration\Common\Source\CSharp\Project" и кроме того
Microsoft.Samples.VisualStudio.IronPythonProject.PythonFileNode наследуется от Microsoft.VisualStudio.Package.FileNode
Microsoft.Samples.VisualStudio.IronPythonProject.PythonProjectNode наследуется от Microsoft.VisualStudio.Package.ProjectNode
Вобщем загибай пальцы обратно
Здравствуйте, adontz, Вы писали:
A>Блин, Влад, вот как ты любишь высокомерно обсуждать то, в чём нихрена не понимаешь
... A>Вобщем загибай пальцы обратно
Зничит так. Умерь пыл и соблюдай приличие. Я всего лишь задал вопрос так как искренне не понимал о чем речь.
Если хочешь что-то сделать, то прошу впредь не допускать подобных выпадов в чью бы то нибыло сторону.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Зничит так. Умерь пыл и соблюдай приличие. Я всего лишь задал вопрос так как искренне не понимал о чем речь.
Ты уж Влад извни, но ты не только ошибся, ты уже успел сделать далеко идущие выводы из своих ошибочных представлений. Так что, ИМХО, Рома прав, не стоит делать поспешных суждений не разбираясь в вопросе.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты уж Влад извни, но ты не только ошибся, ты уже успел сделать далеко идущие выводы из своих ошибочных представлений. Так что, ИМХО, Рома прав, не стоит делать поспешных суждений не разбираясь в вопросе.
Вопросы в моих сообщениях видел? Если не видел, то прочти их еще раз. Если видел, но не догадался что это вопросы, то спроси. Я поясню.
Рома просто откровенно скандалит. И это на самых начальных стадиях. Терпеть я это не намерен. О чем открыто и говорю.
Если хочется что-то сделать, то надо делать это конструктивно. Ошибаться могут все. Ечли человек ошибся нужно его поправить, а не глумиться над ошибками.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Рома просто откровенно скандалит.
Нет, Влад, ты просто постоянно пытаешься меня поддеть. И похоже уже готов вне зависимости от результат свалить провал проекта на меня.
Если ты бы действительно не понял, ты бы написал "А где этот интерфейс IVsHierarchy используется? Я не нашёл ни одного класса который бы его наследовал". Но вместо этого ты решил что я перепутал IVsHierarchy и IVsUIHierarchy ("Похоже его смутили похожие названия"). Тебе даже в голову не пришло заглянуть в документацию хотя с VSIP ты знаком пару дней, а я больше года. Наверное мысль, что я не прав грела твоё сердце слишком сильно. До этого ты так увлёкся доказательством, что я занимаюсь велосипедостроением не желая использовать формат MSBuild, что даже не заметил, что я вобщем-то согласен его использовать.
Знаешь ещё можно было бы привести пару животрепешущих фразочек из личной переписки, но я, во-первых, не собираюст опускаться до этого, а во-вторых, мне просто лень с тобой скандалить. Выяснение отношений явно не стоит потраченного времени. Судя по всему ты даже не отдаёшь себе отчёта, что ведёшь себя некрасиво. Соответсвенно и обижатся на тебя бесполезно. У меня было желание написать этот VSIP сейчас и для Nemerle. Может и не очень большое, но было. А сейчас его нет, потому что лично ты своим хамством и высокомерным отношением его отбил. Очень хорошо, что мы ничего не сделали. Когда-нибудь я может что-то и напишу, но уж точно без тебя. Чисто консультативно в пределах форума, как и по другим вопросам на которые я знаю ответы, я помогать конечно же буду. А писать с тобой вместе что-либо ни-ни. Я уже сейчас вижу, что ты не способен воспринимать новую информацию и готов обвинить всех вокруг при первых же проблемах, но только не себя.
Как назовём проект? Давай nesinclair.
VSIP для студии — это здоровенная куча кривой интеграции с унаследованным кодом, так что возня с использованием Немерле в данном случае будет только мешать. 
"Всё что не убивает нас, делает нас сильнее..."
, и он выбирает язык и формирует команду из Волантёров.
