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

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

VD>>>Ну, скажем у нас есть два фрагмента в одной строке:
VD>>>

VD>>>ля ля ля <%: SomeFunc(...) %> ля <%: SomeFunc(...) %>
VD>>>

VD>>>Код в обоих фрагментах нужно ведь обернуть в некий Write(). Если они подставляют пробелы, то не ясно как они на место " ля " смогут вписать другой код.
H>>Позволю себе предположить:

S>так и есть. вот сгенерированный код:

Токмо Влад использовал "продвинутый" АСП.НЕТ 4.0 с "кодирующими" тегами <%: %> (аналог Html.Encode()).

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

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

H>А вообще вся эта хитрозамученная механика с #line и ASPX сильно похожа на провал дизайна.

Увы, в 2010 студии похоже механизьм осталась тот же. По крайнем мере глава Contained Languages перекочевала в Visual Studio 2010 SDK без видимых изменений. Хотя я очень надеялся, что в 2010 студии можно будет реализовать полноценную подержку интеллисенса в aspx файлах без такого гемора.

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

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

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

H>>А вообще вся эта хитрозамученная механика с #line и ASPX сильно похожа на провал дизайна.

S>Увы, в 2010 студии похоже механизьм осталась тот же. По крайнем мере глава Contained Languages перекочевала в Visual Studio 2010 SDK без видимых изменений. Хотя я очень надеялся, что в 2010 студии можно будет реализовать полноценную подержку интеллисенса в aspx файлах без такого гемора.


Хм видно что асп_компилер фактически делает то, что делают макросы когда раскрывают код — сохраняют локацию експрешынов.

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


H>Хм видно что асп_компилер фактически делает то, что делают макросы когда раскрывают код — сохраняют локацию експрешынов.

Кстати, а нельзя вместо line пихать какойнибудь макрос, который будет производить релокацию внутренних экспрешынов?
А саму директиву выкинуть за ненадобностью.

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

H>Кстати, а нельзя вместо line пихать какойнибудь макрос, который будет производить релокацию внутренних экспрешынов?
H>А саму директиву выкинуть за ненадобностью.

Макросом нельзя, из за ограничения на парные скобки. В aspx частенько используются конструкции наподобие:

<% if(condition) { %>
    <div>html code</div>
<% } %>

вот это — "if(condition) {" по моему запихать в макрос не получится.

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

S>вот это — "if(condition) {" по моему запихать в макрос не получится.

Да, вот это действительно засада.

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

H>Кстати, а нельзя вместо line пихать какойнибудь макрос, который будет производить релокацию внутренних экспрешынов?

Релоцировать экспершены по line нельзя. Причина неправильно работы интелисенса в aspx файлах заключается в том, что текущая компиляция Немерле производит релокацию по директивам line. Инфа из директив line должна сохраняться отдельно от локейшенов выражений и использоваться только для генерации pdb и сообщений об ошибках компиляции.

Дизайнер aspx сам производит трансформацию координат, поэтому в итоге получается двойная трансформация и интелисенс накрывается. Еще один пример неработоспособности интелисенса, вызванный релокацией, я привел в первом сообщении топика.

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

H>А вообще вся эта хитрозамученная механика с #line и ASPX сильно похожа на провал дизайна.

Как-то язык не поворачивается назвать провалом простой механизм который позволяет не допиливая ни один компилятор (в немерле баг с #line) или интеграцию получить интелисенс для любого языка. Все что требуется от компилятора — уметь CodeDom и #line, от интеграции почти ничего.

В свете того, что мне предстоит писать view engine, я не представляю как это сделать проще, т.е. так, чтобы не было необходимости править интеграцию nemerle для работы в собственном DSL вместо ASPX. Есть идеи?

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

Z>В свете того, что мне предстоит писать view engine, я не представляю как это сделать проще, т.е. так, чтобы не было необходимости править интеграцию nemerle для работы в собственном DSL вместо ASPX. Есть идеи?

Смотри как StringTemplate сделан — вполне себе View Engine, в принципе аналогичен тому, что делает aspnet_compiler.

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

S>вот информация из msdn:...

Процетированное сильно отличается от того что ты описывал.

Возможно все эти IVsContainedLanguage и т.п. уже реализованы MPF-ом что приводит к описанному тобой поведению. Но похоже, что за мапинг позиций отвечает IVsTextBufferCoordinator. Причем, и прочитенного можно понять что возможен даже двусторонний мапинг (правишь файл с кодом, обновляется АСП-страница).

S>в принципе это все, что в MSDN есть на эту тему.

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

S>Я имею ввиду файл, подключенный к проекту.

То есть .n-файл (в который отображаются сплайсы (содержимое <% %>) из АСП-страницы) исходно существует и подключен к проекту?

Если это так, то пол дела сделано.

S>Как только он открывается в редакторе, для него создается NemerleSource.

Это из отладчика информация или опять же прочитанная?

S>До этого для файла, включенного в проект, существует только FileNemerleSource, который реализует ограниченный функционал, а для получения содержимого файла использует чтение с диска.

Ну, это само собой.

VD>>А при редактировании все содержимое изменяется, или только участок файла соответствующий?

S>Влад, в первой части я описываю, как студия и интеграция обрабатывают обычные *.n файлы, подключенные к проекту. Думаю, ты и сам представляешь, что там внури при этом происходит. Я про очереди релокации и т.д.

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

S>Что поддерживать?

Эти идеологию — Contained languages.

S>Чтение из буфера используется...

Не надо мне рассказывать про то, что я сам писал. Тем более, что ты не о том рассказываешь.
Нам важно как вызывается событие (метод):

void OnChangeLineText(TextLineChange[] lineChange, int last)

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

S> интеграцией Немерле наверное с самого начала. В UpdateCompileUnit текст для парсинга получается следующей функцией:
S>public TupleStringIntInt NemerleSource::GetTextCurrentVersionAndFileIndex()
S>{
S> LockWrite();
S> try { return new TupleStringIntInt(GetText(), CurrentVersion, FileIndex); }
S> finally { UnlockWrite(); }
S>}

S>где GetText() — функция, читающая содержимое _буфера_.

Это тут совершенно не причем. Это уже внутренняя механика.

S>Да, эту часть делает наша интеграция. Я описывал процесс в комплексе.

Значит все ОК.

S>Да, пока он закрыт, исходника нет.

То есть исходник все же не в проекте?

Тогда никакого интеллисенсва получить не удастся (ни при каких условиях). Если только динамически подключать (и отключать) файл к проекту.

А как же это все в итоге компилируется? Ведь в итоге должен вызваться компилятор немерла и ему должны передать путь к исходнику (сгенерированному по АСП-стрнице).

S>Это я уже реализовал по образу и подобию питона — подключаю этот NemerleSource к проекту и отключаю после закрытия.

ОК. Пол дела сделано (если конечно это реализовано корректно).

S>Нет, в дизайнтайме исходник существует только в буфере NemerleSource. Этот NemerleSource я временно подключаю к проекту (писал об этом выше). Для компиляции наличие файла необязательно.

Последнее не понял. Файл ведь должен компилироваться? Или для каждой АСП-странциы всегда динамически создается отдельная сборка?

S>>>Затем содержимое вторичного буфера парсится с помощью простейшего парсера и обнаруженные блоки #line сопоставляются с <%%> блоками. Эта информация в дальнейшем используется для трансляции локаций первичного буфера в локации вторичного и наоборот.
VD>>Этого не понял. Что за "обнаруженные блоки #line"? Зачем их обнаруживать? Они же просто в исходник помещаются (генерируемый).

S>Смотри. Студия генерит модель кода страницы (CodeDom). Генератор Немерле превращает модель в исходник. Затем наш код интеграции должен пройтись по сгенерированному исходнику, найти все блоки #line и сообщить об их расположении дизайнеру, чтобы дизайнер знал на какие участки кода маппировать блоки <%%>.

Хм. Я вижу только два варианта еще в код-доме запоминать позиции этих самых "окон", или каким-то образом размечать участки файла так чтобы их можно было потом отыскивать банальным текстовым поиском или (на худой конец) регекспами.

S> Дизайнер не может сам пройтись по исходнику, потому что CodeLinePragma на разных языках может выглядеть по разному, VB.NEТ например, вместо #line использует директиву #ExternalSource. #line — это вообще то c# специфик директива, просто в Немерле решили не придумывать свой синтаксис, а заимствовали его у шарпа.

Ну, да. Но пока мы имеем длело с КодДомом, то там то все "окна" видны отлично, так как оформлены нипетами. Возможно этим удастся воспользоваться.

S>Уже попробовал и убедился в успешной работе автокомплита.

А хинтов?

S>Схема работает, можно думать дальше )

А может быть как-то можно получить обратное отображение? Ну, информацию о том, как код из n-файла отображается на aspx-файл. Тогда можно будет просто отлавливать список сообщений об ошибках принадлежащий этим fake-исходникам и менять в сообщениях локешоны, так чтобы они указывали на aspx-файл.

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

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

S>Релоцировать экспершены по line нельзя. Причина неправильно работы интелисенса в aspx файлах заключается в том, что текущая компиляция Немерле производит релокацию по директивам line. Инфа из директив line должна сохраняться отдельно от локейшенов выражений и использоваться только для генерации pdb и сообщений об ошибках компиляции.

Боюсь, что встраивать второй локейшон будет очнь сложным занятием.

Предлагаю сделать иначе.

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

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

Z>>В свете того, что мне предстоит писать view engine, я не представляю как это сделать проще, т.е. так, чтобы не было необходимости править интеграцию nemerle для работы в собственном DSL вместо ASPX. Есть идеи?

H>Смотри как StringTemplate сделан — вполне себе View Engine, в принципе аналогичен тому, что делает aspnet_compiler.

Но для него нужен валидный nemerle синтаксис, чего хотелось бы избежать.

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

Z>Как-то язык не поворачивается назвать провалом простой механизм который позволяет не допиливая ни один компилятор или интеграцию получить интелисенс для любого языка.

+1

Решение как решение.

Z>(в немерле баг с #line)

Нет в нем никакого бага. Просто не рассчитано на такое использование. Для того же шарпа есть компилятор, и интелисенс-движок. Последний специально затачивался, в том числе, и на такое использование.

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

Z>Все что требуется от компилятора — уметь CodeDom и #line, от интеграции почти ничего.

Кстати, CodeDom тут совершенно лишний. А #line тоже иметь не требуется. Реализацию отображения можно реализовать как угодно. #line — один из вариантов. Откровенно гоовря я бы вместо #line сделал бы #location чтобы можно было задавать полное местоположение. А то приходится пробелами выкручиваться.

Z>В свете того, что мне предстоит писать view engine, я не представляю как это сделать проще, т.е. так, чтобы не было необходимости править интеграцию nemerle для работы в собственном DSL вместо ASPX. Есть идеи?

Тебе вообще не нужно делать подобие ASPX. ASPX — это внешний ДСЛ. И внешний он не потому, что это круто, а потому, что для обычных языков — это единственный выход. Ты же можешь реализовать внутренний ДСЛ. Причем, как тебе было не один раз сказано, вместо того чтобы обрабатывать плоский текст ты сможешь обрабатывать некое объектное представление ХМЛ/ХТМЛ, что даст ряд офигительных преимуществ (проверка корректности на уровне фрагментов, дополнительная метаинформация и т.п.).

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

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

H>Смотри как StringTemplate сделан — вполне себе View Engine, в принципе аналогичен тому, что делает aspnet_compiler.

Он тут его сильно критиковал .

Но я бы тоже сделал что-то иное. Что-то что позволяло бы работать не с текстом, а хотя бы с ХМЛ, а то и более строгой моделью.

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

Z>Но для него нужен валидный nemerle синтаксис, чего хотелось бы избежать.

Можно пояснить эту мысль?

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

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

H>>Смотри как StringTemplate сделан — вполне себе View Engine, в принципе аналогичен тому, что делает aspnet_compiler.

VD>Он тут его сильно критиковал .

Не покажешь где я критиковал именно ST? А не предложения переписать все на нем?

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

VD>>Он тут его сильно критиковал .

Z>Не покажешь где я критиковал именно ST?

Ну, как же? Он же ничего особенного не делает... по сравнению с $-строками.

Z>А не предложения переписать все на нем?

Я тебе не предлагал переписывать что-то на нам. Я предлагал сразу использовать его в качестве основы для генерации SQL-скриптов.

Если честно, я даже не понял, что ты это дело просто где-то стянул.

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

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

Z>>Но для него нужен валидный nemerle синтаксис, чего хотелось бы избежать.

VD>Можно пояснить эту мысль?

[NRails.Macros.View]
class MyPuperView
{
Код на моем DSL
}

Выделенное — синтаксический оверхед, особенно MyPuperView.

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

Z>>Не покажешь где я критиковал именно ST?

VD>Ну, как же? Он же ничего особенного не делает... по сравнению с $-строками.

В реализации моего драйвера, да. Впрочем трудно судить, так как ни доки ни хороших примеров на нем толком найти не удалось.

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

Я и не расчитывал, что хватит на все =) Я делаю прототип, главное сделать рабочие фичи и посмотреть как это будет в использовании. Потом уже можно пилить и оптимизировать все что угодно.

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

VD>Процетированное сильно отличается от того что ты описывал.
Процитированное — это маленькая часть всего механизма. Я же описывал его крупными мазками, на фоне которых все эти SetSpanMappings незаметны.

VD>Возможно все эти IVsContainedLanguage и т.п. уже реализованы MPF-ом что приводит к описанному тобой поведению. Но похоже, что за мапинг позиций отвечает IVsTextBufferCoordinator. Причем, и прочитенного можно понять что возможен даже двусторонний мапинг (правишь файл с кодом, обновляется АСП-страница).
S>>в принципе это все, что в MSDN есть на эту тему.
VD>Это все про низкоуровневую реализацию в самой студии. То что описывал ты — это скорее высокоуровневая реализация, скорее всего, сделанная в MPF (менеджед-обертках над студией).

IVsContainedLanguage в MPF не реализован, я содрал реализацию из питона. Студия предоставляет IVsContainedLanguage-у уже готовую реализацию координатора-а, передавая его в метод IVsContainedLanguage.SetBufferCoordinator.

Для работы координатора наша интеграция должна предоставить реализацию метода IVsContainedCode.EnumOriginalCodeBlocks(), который должен возвращать список окон. Для получения списка окон EnumOriginalCodeBlocks (наша реализация) запрашивает у координатора буфер, связанный со сгенерированным кодом и парсит его регулярными выражениями.

Кроме мапинга позиций, IVsTextBufferCoordinator предоставляет доступ к обоим буферам — к буферу, связанному с aspx файлом, и к буферу, связанному со сгенерированным кодом. Буфер — это IVsTextLines.

т.о. IVsTextBufferCoordinator реализуется студией, а IVsContainedLanguage и IVsContainedCode — реализуются нашей интеграцией. Содержимое вторичного буфера (сгенерированный код) тоже создается студией без нашего или MPF вмешательства. Поэтому чехарда с буферами и позициями — это не особенности реализации MPF или питона, а логика, навязываеая студией. Хотя наверное можно забить на нее и реализовать свою логику в обход стандартной — если возникнет острая в этом необходимость.

S>>Я имею ввиду файл, подключенный к проекту.
VD>То есть .n-файл (в который отображаются сплайсы (содержимое <% %>) из АСП-страницы) исходно существует и подключен к проекту?
VD>Если это так, то пол дела сделано.

Нет. Я имел ввиду обычный *.n файл, например в проекте типа Консольное Приложение. Это было описание работы студии с файлами, не имеющим отношение к asp.net. А теперь ты все спутал и начал обсуждать это описание применительно к aspx файлам. Ну да ладно, будем считать, что везде обсуждаем работу студии с aspx файлами.

S>>Я про очереди релокации и т.д.
VD>Нет не представляю. Лучше вдумайся в мой вопрос.
VD>Дело в том, что студия может тупо обновить весь буфер (просто залить туда новый код), а может менять только отображаемые участки. Надеюсь, что происходит второе. Тогда это будет очень похоже на ввод кода пользователем в обычном редакторе и интеллисенст будет работать инкрементально (как для обычных .n-файлов).
VD>Нам важно как вызывается событие (метод):
VD>

VD>void OnChangeLineText(TextLineChange[] lineChange, int last)
VD>

VD>из класса NemerleSource строка 113.
VD>И вызывается ли этот метод-событие вообще.
VD>Если не вызывается, то будет жопа, так как без этого нельзя добиться инкрементального изменения исходника. А без этого придется перестраивать проект на каждый чих, что по понятным причинам, никуда не годится.

Да, в текущей реализации ContainedLanguage, стыренной из Питона, этот метод вызывается при каждом редактировании aspx файла.

S>>Да, пока он закрыт, исходника нет.
VD>То есть исходник все же не в проекте?
VD>Тогда никакого интеллисенсва получить не удастся (ни при каких условиях). Если только динамически подключать (и отключать) файл к проекту.

Да, исходник подключается динамически.

VD>А как же это все в итоге компилируется? Ведь в итоге должен вызваться компилятор немерла и ему должны передать путь к исходнику (сгенерированному по АСП-стрнице).

Aspx страницы компилируются не в процессе компиляции проекта студией, а компилируются инфраструктурой asp.net в рантайме при первом к ним обращении. В рантайме генерирует уже реальный файл. Можно конечно вызвать принудительную компиляцию страниц, но все равно они скомпилируются отдельно от проекта и в отдельную сборку.

S>>Это я уже реализовал по образу и подобию питона — подключаю этот NemerleSource к проекту и отключаю после закрытия.
VD>ОК. Пол дела сделано (если конечно это реализовано корректно).

S>>Нет, в дизайнтайме исходник существует только в буфере NemerleSource. Этот NemerleSource я временно подключаю к проекту (писал об этом выше). Для компиляции наличие файла необязательно.
VD>Последнее не понял. Файл ведь должен компилироваться? Или для каждой АСП-странциы всегда динамически создается отдельная сборка?

Отдельная сборка на каждую страницу или одна на все страницы — это регулируется. Но это однозначно будет не сборка проекта.

S>>>>Затем содержимое вторичного буфера парсится с помощью простейшего парсера и обнаруженные блоки #line сопоставляются с <%%> блоками. Эта информация в дальнейшем используется для трансляции локаций первичного буфера в локации вторичного и наоборот.
VD>>>Этого не понял. Что за "обнаруженные блоки #line"? Зачем их обнаруживать? Они же просто в исходник помещаются (генерируемый).
S>>Смотри. Студия генерит модель кода страницы (CodeDom). Генератор Немерле превращает модель в исходник. Затем наш код интеграции должен пройтись по сгенерированному исходнику, найти все блоки #line и сообщить об их расположении дизайнеру, чтобы дизайнер знал на какие участки кода маппировать блоки <%%>.

VD>Хм. Я вижу только два варианта еще в код-доме запоминать позиции этих самых "окон", или каким-то образом размечать участки файла так чтобы их можно было потом отыскивать банальным текстовым поиском или (на худой конец) регекспами.

Как вариант.

S>> Дизайнер не может сам пройтись по исходнику, потому что CodeLinePragma на разных языках может выглядеть по разному, VB.NEТ например, вместо #line использует директиву #ExternalSource. #line — это вообще то c# специфик директива, просто в Немерле решили не придумывать свой синтаксис, а заимствовали его у шарпа.
VD>Ну, да. Но пока мы имеем длело с КодДомом, то там то все "окна" видны отлично, так как оформлены нипетами. Возможно этим удастся воспользоваться.

Ага, можно попробовать и такой вариант.

S>>Уже попробовал и убедился в успешной работе автокомплита.
VD>А хинтов?

С хинтами затык — текст хинта уже есть, но пока не решил, как определять координаты для отображения балона. Для обычных файлов эта информация получается от TextView, но для ContainedLanguage используется самописная реализация TextView, поэтому и методы определения координат придется писать руками или найти реализацию в апи студии.

S>>Схема работает, можно думать дальше )
VD>А может быть как-то можно получить обратное отображение? Ну, информацию о том, как код из n-файла отображается на aspx-файл. Тогда можно будет просто отлавливать список сообщений об ошибках принадлежащий этим fake-исходникам и менять в сообщениях локешоны, так чтобы они указывали на aspx-файл.

Да, обратная трансформация координат доступна. Координатор предоставляет пару методов MapPrimaryToSecondarySpan/MapSecondaryToPrimarySpan

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

Ну это на самый крайний случай )