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

Может кто-то попрвить компилятор?

Если инсталляция производится не в дефолтный каталог, то нужно чтобы инсталлятор задавал занчение переменной среды окружения Nemerle.

Ну, и при деинсталляции нужно ее обязательно удалять!

VD>Спасибо за фитбэк.
Пожалуйста.

Кстати, если, примеры из статьи VD, которая "рассчитана на людей, не знакомых ни с чем", вставить в свежесозднанный проект — то либо так
D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(12,5):Error: parse error near keyword 'def': expecting type declaration
D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(12,9):Error: parse error near identifier 'fahrenheitToCelsius': unexpected token after class member (you forget a closing bracket?).
Build failed -- 2 errors, 0 warnings. Build took: 00:00:01.9876325.

либо так
D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(15,1):Error: parse error near keyword 'module': unexpected keyword in expression context
D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(15,8):Error: expected ';'
D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(15,8):Error: parse error near identifier 'Program': unexpected token after expression in sequence (you forget a closing bracket?).
Build failed -- 3 errors, 0 warnings. Build took: 00:00:02.0070386.

Ну, я-то знаком, и разобрался быстро. А вот не знакомые ни с чем — деинсталируют.

P.S.1. Пардон.
P.S.2. На дебилов (себя имею ввиду) не обижаются.
P.S.3. А что задело? Пейсатель? Или дон ки хот?

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

VD>>Спасибо за фитбэк.
А>Пожалуйста.

А>Кстати, если, примеры из статьи VD, которая "рассчитана на людей, не знакомых ни с чем", вставить в свежесозднанный проект — то либо так
А>D:\Projects\n\ConsoleApplication1\ConsoleApplication2\Main.n(12,5):Error: parse error near keyword 'def': expecting type declaration

А в статье что написано?

VD>А в статье что написано?
Да, что там написано? Ты — автор, ты и говори

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

VD>Может кто-то попрвить компилятор?
VD>Если инсталляция производится не в дефолтный каталог, то нужно чтобы инсталлятор задавал занчение переменной среды окружения Nemerle.
VD>Ну, и при деинсталляции нужно ее обязательно удалять!

А таргет уже содержит код, подхватывающий эту переменную?
Может не стоит плодить переменные и использовать уже имеющееся в реестре значение? Я кстати уже поправил инсталятор, теперь значение InstallDir в реестре заполняется как надо.

Если такой подход устроит, то я пробегусь по шаблонам и заменю строку
<Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
на
<Nemerle Condition=" '$(Nemerle)' == '' ">$(registry:HKCU\Software\$(var.ProductName)\InstallDir)\Nemerle</Nemerle>

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

S>Если такой подход устроит, то я пробегусь по шаблонам и заменю строку
S><Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
S>на
S><Nemerle Condition=" '$(Nemerle)' == '' ">$(registry:HKCU\Software\$(var.ProductName)\InstallDir)\Nemerle</Nemerle>

C этим тоже засада. Сейчас $(var.ProductName) равен Nemerle Beta 1, а через некоторое время сменится на Nemerle Beta 2 или Nemerle RC. Редактровать каждый раз шаблоны — это не дело. С другой стороны — а зачем мы включаем номер беты в название продукта? Две разные версии интеграции паралельно все равно не встанут, смысл давать им разные имена? Может уберем номер беты из названия продукта?

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

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

S>>Если такой подход устроит, то я пробегусь по шаблонам и заменю строку
S>><Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
S>>на
S>><Nemerle Condition=" '$(Nemerle)' == '' ">$(registry:HKCU\Software\$(var.ProductName)\InstallDir)\Nemerle</Nemerle>


Параметр Nemerle нужен для:
1) указания targets файла (и как следствие Nemerle.MSBuild)
2) указания расположения стандартных библиотек: референсы сейчас указываются явно, NoStdLib = true.
3) бутстрапа компилятора
4) я штото упустил?

На мой взгляд в пользовательских проектах этого параметра быть не должно — параметр важен только для бутстрапа.

— Указать расположение targets файла можно с помощью стандартной переменной, например так: $(MSBuildExtensionsPath)\Nemerle\1.0
В этот каталог нужно деплоить targets и Nemerle.MSBuild.
— Nemerle.MSBuild может вычислять расположение инсталляции немерла посредством ключа реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle.
— Остается вопрос с референсами. Если ставить NoStdLib = false, то Nemerle.dll не попадает в аутпут каталог как это делается сейчас. Тот же вопрос с Nemerle.Compiler.dll, но его обычно указывают явно. GAC конечно призван нас спасти, но в него сейчас дистрибутив не инсталлирует сборки.


Если плюнуть на все и создать переменную окружения то вышесказанное отпадает автоматически.


Ну хм. Можно сделать частично, но не чере var.ProductName, а HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle.

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

H>- Указать расположение targets файла можно с помощью стандартной переменной, например так: $(MSBuildExtensionsPath)\Nemerle\1.0
H>В этот каталог нужно деплоить targets и Nemerle.MSBuild.
Наверное это самый правильный путь. А таргет пусть ищет компилятор через реестр.

H>- Nemerle.MSBuild может вычислять расположение инсталляции немерла посредством ключа реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle.
Я попробовал создвавать этот ключ, но поскольку он расположен не в пользовательской ветке реестра, а в глобальной (local machine), для этого нужен ALLUSERS режим работы инсталятора (http://msdn.microsoft.com/en-us/library/aa367559(VS.85).aspx). Если принудительно выбрать такой режим, то у пользователей при усановке интеграции могут возникнуть проблемы с нехваткой прав.

H>- Остается вопрос с референсами. Если ставить NoStdLib = false, то Nemerle.dll не попадает в аутпут каталог как это делается сейчас. Тот же вопрос с Nemerle.Compiler.dll, но его обычно указывают явно. GAC конечно призван нас спасти, но в него сейчас дистрибутив не инсталлирует сборки.
Устанавливать в GAC во время активной разработки и следовательно частых обновлений версий не удобно.

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

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

H>>- Указать расположение targets файла можно с помощью стандартной переменной, например так: $(MSBuildExtensionsPath)\Nemerle\1.0
H>>В этот каталог нужно деплоить targets и Nemerle.MSBuild.
S>Наверное это самый правильный путь. А таргет пусть ищет компилятор через реестр.
+1

H>>- Nemerle.MSBuild может вычислять расположение инсталляции немерла посредством ключа реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Nemerle.
S>Я попробовал создвавать этот ключ, но поскольку он расположен не в пользовательской ветке реестра, а в глобальной (local machine), для этого нужен ALLUSERS режим работы инсталятора (http://msdn.microsoft.com/en-us/library/aa367559(VS.85).aspx). Если принудительно выбрать такой режим, то у пользователей при усановке интеграции могут возникнуть проблемы с нехваткой прав.

Сдается мне для установки среды разработки (тем более в %ProgramFiles%) наличие администраторских привелегий — сущая необходимость.

H>>- Остается вопрос с референсами. Если ставить NoStdLib = false, то Nemerle.dll не попадает в аутпут каталог как это делается сейчас. Тот же вопрос с Nemerle.Compiler.dll, но его обычно указывают явно. GAC конечно призван нас спасти, но в него сейчас дистрибутив не инсталлирует сборки.
S>Устанавливать в GAC во время активной разработки и следовательно частых обновлений версий не удобно.

Получается что переменная окружения нужна будет только ради прямого указания сборок в обход GAC.

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

S>Если такой подход устроит, то я пробегусь по шаблонам и заменю строку
S><Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
S>на
S><Nemerle Condition=" '$(Nemerle)' == '' ">$(registry:HKCU\Software\$(var.ProductName)\InstallDir)\Nemerle</Nemerle>

Ну, а как вести разработку (когда ничего не инсталлируется)?

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

S>C этим тоже засада. Сейчас $(var.ProductName) равен Nemerle Beta 1, а через некоторое время сменится на Nemerle Beta 2 или Nemerle RC. Редактровать каждый раз шаблоны — это не дело. С другой стороны — а зачем мы включаем номер беты в название продукта? Две разные версии интеграции паралельно все равно не встанут, смысл давать им разные имена? Может уберем номер беты из названия продукта?

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

Только причем тут проекты? В них же указывается только ветка реестра или переменная среды окружения.

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

H>Параметр Nemerle нужен для:
H>1) указания targets файла (и как следствие Nemerle.MSBuild)
H>2) указания расположения стандартных библиотек: референсы сейчас указываются явно, NoStdLib = true.
H>3) бутстрапа компилятора
H>4) я штото упустил?

Еще для компиляции разных стадий. Но это можно отнести к третьему пункту.

H>На мой взгляд в пользовательских проектах этого параметра быть не должно — параметр важен только для бутстрапа.

Этот параметр позволяет использовать разные версии компилятора. Переменные ведь можно менять даже в бат-файлах.

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

H>Получается что переменная окружения нужна будет только ради прямого указания сборок в обход GAC.

А зачем вы вообще изобретаете велосипеды?

Все что нужно сделать — это задавать переменную среды Nemerle в инсталляторе если установка производится в каталог отличный от дефолтного.

Зачем все эти приседания?

К тому же реестр есть тольтко под виндой. А переменные среды — везде. Разумно было бы иметь одинаковые средства настройки подо всеми поддерживаемыми ОС.

Так что бросайте возиться с реестром. Лучше доработайте инсталлятор.

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

А>А как добавить новый референс в Macro References? Правая кнопка мыши не работает.

А>Кстати просто References через ИДЕ тоже добавить не удалось... Пришлось редактировать файл проекта...

Что-то очень странное у тебя происходит. Оба пункта должны работать. Только выделять нужно именно ту ветку в которую идет добавление.

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

VD>>А в статье что написано?
А>Да, что там написано? Ты — автор, ты и говори

Там написано, что примеры нужно собирать из командной строки.

Интеграция не поддерживает сокращенного синтаксиса, как и синтаксиса основанного на отступах. Компилироваться код будет, но интеграция корректно работать не будет.

VD>Интеграция не поддерживает сокращенного синтаксиса, как и синтаксиса основанного на отступах. Компилироваться код будет, но интеграция корректно работать не будет.

Этого я в статье — не видел. Видимо не внимательный.

Ну, вы[nemerle команда] хоть работаете над этим? Или это по каким-либо причинам не возможно?

Как часто выходят билды? Стоит ли интеграцию самому собирать?

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

VD>Интеграция не поддерживает сокращенного синтаксиса, как и синтаксиса основанного на отступах. Компилироваться код будет, но интеграция корректно работать не будет.

Понятно. А я только хотел спросить почему комплит (у меня в #develop) не работал без #pragma indent при включенной опции компиляции IndentationSyntax.

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

H>>Получается что переменная окружения нужна будет только ради прямого указания сборок в обход GAC.
VD>А зачем вы вообще изобретаете велосипеды?
VD>Все что нужно сделать — это задавать переменную среды Nemerle в инсталляторе если установка производится в каталог отличный от дефолтного.
VD>Зачем все эти приседания?
Я думал, что существуют какие то непреодолимые причины, которые вынудили в свое время отказаться от переменной окружения. Ведь в инструкции по установке интеграции так и написано — удалите переменную окружения.

VD>К тому же реестр есть тольтко под виндой. А переменные среды — везде. Разумно было бы иметь одинаковые средства настройки подо всеми поддерживаемыми ОС.
Дельное замечание!

VD>Так что бросайте возиться с реестром. Лучше доработайте инсталлятор.
Значит используем такую схему: инсталятор создает переменную окружения Nemerle, и в пользовательских проектах эта переменная используется для указания путей к компилятору и сборкам Немерле.

Для этого нужно:
а) поправить инсталятор,
б) поправить шаблоны проектов, заменив путь "c:\program files\nemerle" на "$(env.Nemerle)"

если возражений нет, то займусь этим.

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

VD>>Интеграция не поддерживает сокращенного синтаксиса, как и синтаксиса основанного на отступах. Компилироваться код будет, но интеграция корректно работать не будет.

H>Понятно. А я только хотел спросить почему комплит (у меня в #develop) не работал без #pragma indent при включенной опции компиляции IndentationSyntax.

Скорее вопрос почему он работает.

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

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

Удалять ее нужно если установка идет в место предусмотренное по умолчанию. Старый инсталлятор туда полную пургу писал (в кавычки путь брал).


VD>>Так что бросайте возиться с реестром. Лучше доработайте инсталлятор.
S>Значит используем такую схему: инсталятор создает переменную окружения Nemerle, и в пользовательских проектах эта переменная используется для указания путей к компилятору и сборкам Немерле.

Инсталлятор должен проверять производится ли установка в место предусмотренное по умолчанию, если — нет, устанавливать эту переменную, если — да, удалять ее.

S>Для этого нужно:
S>а) поправить инсталятор,

Да.

S>б) поправить шаблоны проектов, заменив путь "c:\program files\nemerle" на "$(env.Nemerle)"

Нет. В проектах все ОК.

Свойств МСБилд получают значения по умолчанию из переменных среды окружения. Так что если Nemerle задана в винде, то свойство Nemerle будет установлено в проектах.