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

A>Так, вот тебе реальный пример.

Хреновый пример надо признать. Изобретение кривых велосипедов. Ну, да не о том речь.

A>Теперь объясни мне как это сделать через MSbuild?

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

В общем, влосипеды иду в лес. Темболее что МСБилд — это стандат.

Здравствуйте, 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#, а так... лишь бы работало) действительно делается за день-два. А вот сервисы связанные с языком... Там огого сколько нужно делать. И не ясно зачем, если уже многое готово. Код не смертельно крив. Рефакторингу поддается.

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

VD>>Любую задачу можно оформить в качестве Task-а и Target-ов.

A>Ну так покажи решение.

Что показывать то? Как класс реализовать? Встатье есть пример.
В МСБилде ты можешь делать любое количество стадий предварительной обработки. Это не проблема.

VD>>Идеологически это ни чем не отличается от пребразования одного текстового формата в другой.

A>Проблема в том, что далеко не вся необходимая информация храниться в файлах.

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

VD>>Тем более что МСБилд — это стандат.

A>Влад, ты что-то пропагандой увлёкся.

Что-то от тебя про прапаганду много слышно. Тоже плохой симптом.

A> Я не против MSBuild, я просто хотел узнать преимущества.

Ну, я тебе вроде про них сказал. Даже статью дал. Неужели мало?
Ладно повтою еще раз. МСБилд — это 100%-но расширяемый формат, позволяющий создавать переносимые решения по сборке проектов. Он же прекрасно подходит для описания проектов для VS (является его основным форматом, и для этго собственно и разработывался), хорошо документированный, стандартизованный, используется почти во всех типах проектов в VS2005. И это против идеи передавать некий инифайл неизвесной структуры в неизвесный ехе-шник.

A> Дал реальный пример и попросил показать в общих чертах решение.

В общих чертах все решения одинаковы. Созаешь Задачу (Task) — дотнет-компонент осуществляющий работу. Регистрируешь его в таргет-файле иописывашь цель которую можно взывать. Далее цель заеляшь за другую цель чтобы она вызвалась и поисывашь зависимости (входные и выходные файлы). Если входные файлы старше вызодных и запущена цель, то произойдет вызов Задачи котороая и произведет проебразовние.

Все это подробнейшим образгом описано в статье.

A> Ты меня начал тыкать в свою статью. Извини, но это не аргумент и вообще не способ совместной работы. Я раньше с MSbuild не работал и прошу меня чему-то научить, а ты высокомерничаешь. Зачем?

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

Здравствуйте, 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.

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

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

C>>Вот! Вот это мне уже гораздо больше нравится Даёшь GNU C++ Comp...эээ, базовый шаблон

A>Ну вот, Влад, я ты говорил базовый шаблон никому не нужен

Я не говорил этого. Я сказал, что:
1. Он не нужен для данного проекта.
2. Это обобщение, и его следует реализовывать тлько тогда, когда будет все предельно ясно с функционированием VS. То есть сначало нужно реализовать все без выпендрежа.

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

A>Кроме того джля того же PHP достаточно сделать автокомплит для всех ключевых слов и стандартных функций (для функций ещё тултипы со справкой по параметрам)

Для этого нужно всего ничего. Придумать нечто вроде ХМЛ-доков для ПХП, написать парсер этого дела...

A> и 90% PHP программистов будет счастливо. А если ещё и отладку сделать, то вообще зашибись

Меня не трогает счастье ПХП-програмистов. У меня есть конкретная задача которую я намереваюсь решить. И всякое отвлечение от цели грозит тем, что цель не будет достигнута.

Здравствуйте, 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> Так это же тогда тем более надо всё кешировать, а то если на каждый комплит у будет пробежка рефлекшеном по всем зависимостям...

Движок сам кэширует все что нужно. Вопрос тлько в грамотном обновлении кэша при изменении внешних данных.

К тому же вынимание данных не такой уж долгий процесс. Он мало чем будет отличаться от считывания из файла. По сути это тот же файл и есть.

Здравствуйте, 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>Нет, студии ты отдаёшь просто список строк. Никаких фильтров там нет и студии грубоко наплевать откуда эти строки взялись и что они означают.

Откровенно говоря не очень понимаю, что там фильтровать еще.

Здравствуйте, 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

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

A>Я тоде так думал, однако можешь убедиться сам что ребята из MS сделали невозможное

Странно. Я реализовывал IVsHierarchy только в самом проекте и все работало.

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

A>>Я тоде так думал, однако можешь убедиться сам что ребята из MS сделали невозможное
AVK>Странно. Я реализовывал IVsHierarchy только в самом проекте и все работало.

Вот именно что странно зачем надо было делать так собственно я тоде реализовывал IVsHierarchy только в проекте и пока что у меня тоже всё работает. Об чём и речь — архитектура у примеров из SDK дерьмоватая.

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

AVK>>Ты ничего не путаешь? IVsHierarchy реализуется проектом. Список проектов в солюшене получается совсем другим способом. IVsHierarchy не является элементом иерархии, это адаптер для доступа к иерархии внутри проекта.

A>Я тоде так думал, однако можешь убедиться сам что ребята из MS сделали невозможное

Я вот тоже после твоих слов долго рылся в коде АйронПитона и пытался найти где там в иерархии проектов используется IVsHierarchy. Ненашел.
Теперь ты тыкашь на код где он снова не встречается и продолжашь о нем рассуждать. Может ты пояснишь о чем ты говоришь? Где ты в приведенном тобой коде увидал IVsHierarchy ?