Прикручиваю автокомплит в SharpDevelop, в связи с этим возник вопрос (по-видимому к VladD2) — что это за индекс файла такой в интерфейсе ISource, из которого Location умеет изготавливать имя файла?
Как вообще с ним работать из IDE?

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

H>Как вообще с ним работать из IDE?


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

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

H>Прикручиваю автокомплит в SharpDevelop,

Не хочется тебя разочаровывать, но это тебе вряд ли удастся. По крайней мере так чтобы качественно работало. Я твои шансы оцениваю как один против ста. Там совершенно гнилая архитектура. Она заточена на один принцип работы который для немерла не годится (в виду вывода типов и макросов). Для немерла нужно парсить весь проект и в бэкграунде типизировать тела методов. А они хотят чтобы ты по их прикажу парсил и типизировал части текста. Это рабтает для C# или Васика, но не применимо для немерле.

H>в связи с этим возник вопрос (по-видимому к VladD2) — что это за индекс файла такой в интерфейсе ISource, из которого Location умеет изготавливать имя файла?

Индекс в глобальной (статической) таблице. Подробнее см. реализацию функции GetFileIndex() в AST.n.

H>Как вообще с ним работать из IDE?

Это просто номер ассоциированный с некоторым путем к файлу. Это позволяет сравнивать имена файлов просто сравнивая их индексы. Гарантируется, что для одного и того же пути индексы в рамках одного сеанса (одного процесса) будут идентичны.

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

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

H>>Прикручиваю автокомплит в SharpDevelop,

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

Ну, IEngine завелся, парсит проект
По Ctrl+Space оно выдает список, надо только его по-человечески отобразить.

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

H>Ну, IEngine завелся, парсит проект

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

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

У этих же друзей я не нашел даже такой возможности как получить оповещение об изменении части файла.

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

VD>Индекс в глобальной (статической) таблице. Подробнее см. реализацию функции GetFileIndex() в AST.n.

А если не секрет, почему так было сделано? Почему бы не хранить имя файла напрямую, строка ведь все равно должна быть интернирована.

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

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

H>>Ну, IEngine завелся, парсит проект

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

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

VD>У этих же друзей я не нашел даже такой возможности как получить оповещение об изменении части файла.

Я вызываю BeginUpdateCompileUnit для текущего документа при его изменении.

Еще не понял такого кода в NemerleSource в обработчике OnChangeLineText:

if (projectInfo.IsProjectAvailable)
{
    TextLineChange changes = lineChange[0];

    RelocationQueue.AddRelocationRequest(RelocationRequestsQueue,
    FileIndex, CurrentVersion,
    changes.iNewEndLine + 1, changes.iNewEndIndex + 1,
    changes.iOldEndLine + 1, changes.iOldEndIndex + 1,
    changes.iStartLine + 1, changes.iStartIndex + 1);
}

Если честно, то практически ничего в исходниках, кроме описаний интерфейсов, не читал.

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

ВВ>А если не секрет, почему так было сделано? Почему бы не хранить имя файла напрямую, строка ведь все равно должна быть интернирована.

Дык ровно один раз. А далее сравниваются целые числа. Сравнений локейшонов производится миллионы раз. А инициализация их из строки почти никогда.

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


H>Еще не понял такого кода в NemerleSource в обработчике OnChangeLineText:
H>

H>if (projectInfo.IsProjectAvailable)
H>{
H>    TextLineChange changes = lineChange[0];

H>    RelocationQueue.AddRelocationRequest(RelocationRequestsQueue,
H>    FileIndex, CurrentVersion,
H>    changes.iNewEndLine + 1, changes.iNewEndIndex + 1,
H>    changes.iOldEndLine + 1, changes.iOldEndIndex + 1,
H>    changes.iStartLine + 1, changes.iStartIndex + 1);
H>}
H>

А в этом коде вся суть. Так как мы отслеживаем изменения внутри методов, то остальное АСТ нужно приводить в корректное состояние после внесения изменения. Все локешоны ниже точки изменения нужно пересчитать.

OnChangeLineText вызывается при изменении участка исходника. Информация об изменении помещается в RelocationQueue и потом, в рабочем потоке, применяется к имеющемуся АСТ. Это приводит к пересчету все локешонов. Кроме того при этом отслеживаются изменение внутри методов и методы ставятся в очередь на перекомпиляцию.

А вот BeginUpdateCompileUnit вызывать явно не нужно. Надо вообще выкинуть BeginUpdateCompileUnit из публичного интерфейса.

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

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

Т.е. для оптимизации сравнения?
А так было бы медленнее?

struct Location
{
  int Col;
  int Line;
  FileInfo File;
}

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

VD>А в этом коде вся суть. Так как мы отслеживаем изменения внутри методов, то остальное АСТ нужно приводить в корректное состояние после внесения изменения. Все локешоны ниже точки изменения нужно пересчитать.
VD>OnChangeLineText вызывается при изменении участка исходника. Информация об изменении помещается в RelocationQueue и потом, в рабочем потоке, применяется к имеющемуся АСТ. Это приводит к пересчету все локешонов. Кроме того при этом отслеживаются изменение внутри методов и методы ставятся в очередь на перекомпиляцию.
VD>А вот BeginUpdateCompileUnit вызывать явно не нужно. Надо вообще выкинуть BeginUpdateCompileUnit из публичного интерфейса.

Да пусть сделает. Фишка #D не в том, что IDE такая хорошая, а в том, что все же вокруг него тусуется довольно приличный community. Если сделать минимальную поддержку Немерле — пусть даже без автокомплита, — и включить ее в дистрибуции Шарп-Девелопа, то этой пойдет на пользу проекта.

Только вот интегрироваться лучше бы с 4.0 сразу. К тому же они там серьезный redesign обещали.

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

ВВ>Т.е. для оптимизации сравнения?
ВВ>А так было бы медленнее?

ВВ>

ВВ>struct Location
ВВ>{
ВВ>  int Col;
ВВ>  int Line;
ВВ>  FileInfo File;
ВВ>}
ВВ>

Насколько позволяют мои телепатические способности — было бы медленее. Вообще, сам можешь подумать. В Location на одно поле типа int хранит информацию о файле и флагах (был ли Location сгенерирован, есть ли для него исходный код...). А ты вместо этого целую структуру данных хочешь запихнуть.

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

ВВ>Да пусть сделает.

Я что против? Просто задачу прямо не делается. Придется искать обходные маневры. И не факт, что вообще получится работоспособная версия.

ВВ>Фишка #D не в том, что IDE такая хорошая, а в том, что все же вокруг него тусуется довольно приличный community. Если сделать минимальную поддержку Немерле

Минимальная уже есть.

ВВ> — пусть даже без автокомплита, — и включить ее в дистрибуции Шарп-Девелопа, то этой пойдет на пользу проекта.

Не спорю. Но тормозящий комплит может оказаться антиреклама.

ВВ>Только вот интегрироваться лучше бы с 4.0 сразу. К тому же они там серьезный redesign обещали.

4 чего?

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

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

FileInfo — это класс, т.е. сравниваться будут указатели. Размер структуры Location на 32б будет таким же. Мне просто правда хочется понять, какие могут быть причины для создания отдельного пуля для имен файлов.

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

ВВ>>Только вот интегрироваться лучше бы с 4.0 сразу. К тому же они там серьезный redesign обещали.
VD>4 чего?

SharpDevelop 4.0, переведен на WPF, обещали и другой редизайн (к слову, многое из того, что делает hardcase может и отвалиться). Недавно стала доступна то ли бета, то ли альфа, но я не качал.

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

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

Комплит можно сделать для классов фреймворка. Class view можно сделать. Некоторую поддержку рефакторинга. Интегрировать Nemerlish. Ну и написать им, чтобы включили в следующий релиз. Вроде в таком объеме на антирекламу тянуть не должно.

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


ВВ>FileInfo — это класс, т.е. сравниваться будут указатели. Размер структуры Location на 32б будет таким же. Мне просто правда хочется понять, какие могут быть причины для создания отдельного пуля для имен файлов.

Локешонов на средний проект получается под миллионы. В каждом убдет ссылка котору ЖЦ должен будте проверить. Плюс еще где-то надо хоранить финформацию о флагах.

Внимание, вопрос — зачем?

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

ВВ>>FileInfo — это класс, т.е. сравниваться будут указатели. Размер структуры Location на 32б будет таким же. Мне просто правда хочется понять, какие могут быть причины для создания отдельного пуля для имен файлов.
VD>Локешонов на средний проект получается под миллионы. В каждом убдет ссылка котору ЖЦ должен будте проверить. Плюс еще где-то надо хоранить финформацию о флагах.
VD>Внимание, вопрос — зачем?

Я не предлагаю решение, а спрашиваю, почему было выбрано существующее. Для саморазвития, если хочешь
ОК, т.е. имя файла хранится в пуле, а не упаковывается в какой-нибудь класс (хоть FileInfo, хоть свой, "с флагами"), чтобы облегчить жизнь GC.

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

ВВ>SharpDevelop 4.0, переведен на WPF, обещали и другой редизайн (к слову, многое из того, что делает hardcase может и отвалиться). Недавно стала доступна то ли бета, то ли альфа, но я не качал.

Там и в релизе то все кривее не куда. Я бы с бэтой возиться не стал бы.

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

У Студии ведь с этим проблем нет.

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

ВВ>Комплит можно сделать для классов фреймворка.

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

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

Ну, ты уже пробовал сделать? Как оно получается?