Здравствуйте, VladD2, Вы писали:
VD>Надо устранять этот недостаток .
Да не стесьняюсь я. Просто тормоз. Не могу въехать в эту полу-юинксовую полу-виндовую систему.
Половина файлов (немерловые) в одних LF'ах, другая половина CR/LF. Одни с пробелами другие с табами. Третьи вперемешку
Вавилон короче. В таких условиях лучше применять модерируемые коммиты.
Разводить флейм на тему "давайте обсудим стиль" я тем более не хочу. Точить некогда — копать нада.
Вобщем меня пока текущее положение устраивает. Вот если вам с Игорем обременительно с патчами возиться так и говорите. Буду подключаться.
Здравствуйте, VladD2, Вы писали:
VD>Все верно. Nemerle.IO.printf — это макрос который на самом деле может раскрыть намного более сложным образом. Тут нужно более сложный анализ производить. Если удастся получить хотя бы ссылу на сборку где объявлен Nemerle.IO.printf, то дальше все что нужно можно будет вытащить из метаданных.
Понял. Буду копать. QuickTip тоже нужно доработать?
Здравствуйте, Блудов Павел, Вы писали:
БП>Здравствуйте, VladD2, Вы писали:
VD>>Надо устранять этот недостаток . БП>Да не стесьняюсь я. Просто тормоз. Не могу въехать в эту полу-юинксовую полу-виндовую систему.
А можно просто MSBuild-ом пользоваться. Могу прислать улучшенные cmd-хт. Хотя что там слать. Вот сейчас и выложу:
Build.cmd (двух-проходная компиляция. Позволяет компилировать и проверять макросы в компиляторе)
Reg.cmd (копирование в инсталляционную директорию и пре-джит)
rem @echo off
IF "%Type%"=="" set Type=Debug
set NemerleBin=D:\MyProjects\Nemerle\nemerle\bin\%Type%
set GacUtil=C:\VS\VS2005\SDK\v2.0\Bin\gacutil.exe
set NemerleInstall=%ProgramFiles%\Nemerle
set NGen=%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\ngen.exe
@echo NemerleInstall=%NemerleInstall%
@echo GacUtil=%GacUtil%
@echo NGen=%GacUtil%
@echo NemerleBin=%GacUtil%
@echo GacUtil=%GacUtil%
@echo NGen=%GacUtil%
@echo NemerleBin=%GacUtil%
cd /D %NemerleInstall%
%GacUtil% /u Nemerle
%GacUtil% /u Nemerle.Compiler
%GacUtil% /u Nemerle.MSBuild.Tasks
%GacUtil% /u Nemerle.Macros
%NGen% uninstall "%NemerleInstall%\Nemerle.dll"
%NGen% uninstall "%NemerleInstall%\Nemerle.Compiler.dll"
%NGen% uninstall "%NemerleInstall%\Nemerle.Macros.dll"
%NGen% uninstall "%NemerleInstall%\Nemerle.MSBuild.Tasks.dll"
%NGen% uninstall "%NemerleInstall%\ncc.exe"
@echo errorlevel=%errorlevel%
set errorlevel=0
@echo errorlevel=%errorlevel%
copy /Y "%NemerleBin%\*.dll" "%NemerleInstall%\*.dll"
if not errorlevel 0 (
@echo errorlevel=%errorlevel%
@echo !!! ERORR: copy files !!!
pause
exit /b 1
)
copy /Y "%NemerleBin%\*.exe" "%NemerleInstall%\*.exe"
if not errorlevel 0 (
@echo !!! ERORR: copy files !!!
pause
exit /b 1
)
copy /Y "%NemerleBin%\*.pdb" "%NemerleInstall%\*.pdb"
%NGen% install "%NemerleInstall%\Nemerle.dll"
%NGen% install "%NemerleInstall%\Nemerle.Compiler.dll"
%NGen% install "%NemerleInstall%\Nemerle.Macros.dll"
%NGen% install "%NemerleInstall%\Nemerle.MSBuild.Tasks.dll"
%NGen% install "%NemerleInstall%\ncc.exe"
pause
BuildAndReg.cmd (вызывает оба файла за раз)
@echo on
IF "%Type%"=="" set Type=Debug
call Build.cmd
@echo ERRORLEVEL
IF NOT ERRORLEVEL 1 call Reg.cmd
БП>Половина файлов (немерловые) в одних LF'ах, другая половина CR/LF. Одни с пробелами другие с табами. Третьи вперемешку
На самом деле в проекте компилятора (в SVN-е) стоит опция конвертации всего к LF. А в проекте интеграции просто ничего не задано. Можно в приципе тоже что-то задать.
БП>Вавилон короче. В таких условиях лучше применять модерируемые коммиты.
Ну, тебя. На то SVN и существует, чтобы можно было работать вместе. Если что всегда можно откатить что-нибудь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>Все верно. Nemerle.IO.printf — это макрос который на самом деле может раскрыть намного более сложным образом. Тут нужно более сложный анализ производить. Если удастся получить хотя бы ссылу на сборку где объявлен Nemerle.IO.printf, то дальше все что нужно можно будет вытащить из метаданных.
БП>Понял. Буду копать. QuickTip тоже нужно доработать?
А он макросы как раз умеет раскрывать. Он их в развернутом виде показывает. То есть то что будет после их раскрытия.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А можно просто MSBuild-ом пользоваться. Могу прислать улучшенные cmd-хт. Хотя что там слать. Вот сейчас и выложу: VD>Build.cmd (двух-проходная компиляция. Позволяет компилировать и проверять макросы в компиляторе)
Может выложить его в SVN? А чтобы пути не менять, в начале коммандного файла сделать проверки, и выдавать соответствующее предупреждение?
Ты можешь просто залить, а остальные проверки я могу уже сам дописать, если у тебя времени нет
P.S. Правда у меня и самого сейчас времени нифига нет, но может на следующей неделе ситуация поменяется.
Здравствуйте, VladD2, Вы писали:
VD>А он макросы как раз умеет раскрывать. Он их в развернутом виде показывает. То есть то что будет после их раскрытия.
Угу. После раскрытия IO.Printf получается Console.Write. Соответственно переход будет к Console.Write, а не к нужному исходнику.
Здравствуйте, VladD2, Вы писали:
VD>Если есть .pdb-хи и исходники, то желательно бы позиционироваться на исходники, а не генерировать фэйк-код. Так, например, для исходников компилятора и библиотеки Немерла хотелось бы прыгать на них.
А если пользователь на этом не успокоится? Вот открылся исходник класса из ncc, а пользователь опять F12 давит.
Проблема в том, что открывшийся файл будет сам по себе, без ансамбля, т.е. без проекта. И в pdb о проекте ни слова.
Можно, как вариант, ассоциировать такие фалйы с проектом, из которого в них попадаешь.
Тогда если имеется програмка, использующая SomeAssembly, то при попадании в исходник SomeAssembly можно будет осуществлять переходы внутри SomeAssembly.
Другой вариант: для таких файлов-изгоев можно заводить виртуальный проект, у которого нет исходников вообще, но зато есть нетовая сборка и следовательно все нужные метаданные. Тогда можно будет даже осуществлять переходы на исходники сборок, на которые ссылается та сборка. До бесконечости.
Здравствуйте, Блудов Павел, Вы писали:
БП>Другой вариант: для таких файлов-изгоев можно заводить виртуальный проект, у которого нет исходников вообще, но зато есть нетовая сборка и следовательно все нужные метаданные. Тогда можно будет даже осуществлять переходы на исходники сборок, на которые ссылается та сборка. До бесконечости.
Почему же до бесконечности? VS поступает довольно-таки просто — если в текущем solution есть сборка с исходниками, то она показывает их, а иначе — только метаинформацию (обычно публичный интерфейс). Не писать же аналог рефлектора
Здравствуйте, Nuald, Вы писали:
N>Почему же до бесконечности? VS поступает довольно-таки просто — если в текущем solution есть сборка с исходниками, то она показывает их, а иначе — только метаинформацию (обычно публичный интерфейс). Не писать же аналог рефлектора
Читай ветку чуть выше. Влад предложил идею по-лучше: показывать реальный исходник если есть pdb и исходник в наличии.
Здравствуйте, Блудов Павел, Вы писали:
БП>Читай ветку чуть выше. Влад предложил идею по-лучше: показывать реальный исходник если есть pdb и исходник в наличии.
На самом деле одна идея другую не отменяет. Исходники в проекте одного солюшена надо обрабатывать особо. Нито переходы будут работать корректно только после компиляции солюшена.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Блудов Павел, Вы писали:
БП>Угу. После раскрытия IO.Printf получается Console.Write. Соответственно переход будет к Console.Write, а не к нужному исходнику.
Ну, так надо не тупо раскрывать, а смотреть что там. IT для хинтов в локальных проектах это делает и получается то что нужно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nuald, Вы писали:
N>Может выложить его в SVN? А чтобы пути не менять, в начале коммандного файла сделать проверки, и выдавать соответствующее предупреждение?
Класть в SVN что-то с фиксированными путями нельзя. Файл для компиляции конечно можно положить, но для регистрации прийдется что-то придумывать.
N>Ты можешь просто залить, а остальные проверки я могу уже сам дописать, если у тебя времени нет
Давай лучше наоборот. Правь и присылай. Я оценю и решу можно ли его заливать в таком виде.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Класть в SVN что-то с фиксированными путями нельзя.
если ты про это:
set NemerleBin=D:\MyProjects\Nemerle\nemerle\bin\%Type%
set NemerleInstall=%ProgramFiles%\Nemerle
set GacUtil=C:\VS\VS2005\SDK\v2.0\Bin\gacutil.exe
set NGen=%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\ngen.exe
То можно первый можно сделать относительным, просто положив Build.cmd в нужное место. Для остальных требовать наличия переменных окружения.
В итоге должно получиться:
set NemerleBin=%~dp0\bin\%Type%
set NemerleInstall=%ProgramFiles%\Nemerle
set GacUtil=gacutil.exe
set NGen=ngen.exe
Ниличие пути до gacutil.exe и ngen.exe можно вычислить:
%GacUtil% > nul
if errorlevel 2 echo gacutil.exe not found && exit
Здравствуйте, VladD2, Вы писали:
VD>Давай лучше наоборот. Правь и присылай. Я оценю и решу можно ли его заливать в таком виде.
Положив три файла (BuildAndReg.cmd, build.cmd, reg.cmd) в корень каталога Nemerle (у меня D:\Work\Nemerle) и подправив reg.cmd следующим образом:
set NemerleBin=%~dp0\bin\%Type%
set GacUtil="%VS80COMNTOOLS%\..\..\SDK\v2.0\Bin\gacutil.exe"
set NemerleInstall=%ProgramFiles%\Nemerle
set NGen=%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\ngen.exe
@echo NemerleInstall=%NemerleInstall%
@echo GacUtil=%GacUtil%
@echo NGen=%NGen%
@echo NemerleBin=%NemerleBin%
%GacUtil% > nul
if errorlevel 2 echo gacutil.exe not found. && pause && exit
Знаю, что завязываться на %VS80COMNTOOLS% не очень хорошо, однако ИМХО это единственное решение, не заставляющее пользователя вводить путь к .NET 2 SDK ручками.
В принципе, у меня все заработало, и завязок на какие-то абсолютные пути вроде бы не наблюдается.
Пойдет? Коммитить?
N>Знаю, что завязываться на %VS80COMNTOOLS% не очень хорошо, однако ИМХО это единственное решение, не заставляющее пользователя вводить путь к .NET 2 SDK ручками.
Согласен.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
~dp0 возвращает рабочий каталог исполняемого командного файла.
N>>Знаю, что завязываться на %VS80COMNTOOLS% не очень хорошо, однако ИМХО это единственное решение, не заставляющее пользователя вводить путь к .NET 2 SDK ручками.
VD>Согласен.
Ну еще, конечно, можно потребовать у конечного пользователя прописать Path или какую-то другую переменную окружения и ее использовать. Тогда в начале надо будет проверить путь, и предупредить пользователя. Ну либо вообще сделать что-то типа грязного хака — извлечь из реестра всю нужную информацию (например, путь к devenv.exe или считывать внутренние переменные студии) и плясать от них.
Как бы то не было, более или менее командные файлы готовы, можно коммитить. Скажешь, сделаю, либо уже ты сам. Ну а если не надо, то не надо, мое дело предложить
.
Если нам не помогут, то мы тоже никого не пощадим.
