Здравствуйте, Ziaw, Вы писали:
Z>У меня честный бут, он не только билдит, но и Nemerle.dll используется от него же (должно все билдиться без установки немерла).
Остается понят зачем это нужно.
"Установка" — это очень растяжимый символ. Сложить бинарники в каталог — это вполне себе установка.
Z>Интеграцию начинает плющить сразу как только встает версия немерла отличная от бута.
Так компиляйся с текущей версий и проблем не будет.
Z>>>Влад пытается доказать, что я один такой (да и ты сейчас намекаешь), но вряд-ли кто-то будет утверждать, что невозможность сделать nuget package является мелкой проблемой. Ирония в том, что доработки nuget для поддержки немерловых проектов дают возможность подключать только либы написанные на других языках. WH>>А в чем проблема с нугетом то? WH>>Или там нет других либ которые обновляются?
Z>Если я создаю бинарную либу на nemerle — я прошиваю в ней ссылку на конкретную версию nemerle.dll. Засовывать ее в nuget смысла мало. Она будет работать только у тех, у кого стоит та же самая версия немерла.
Это проблема самого дотнета. Любая общая сборка приведет к тому же результату.
То что ты предлагаешь с огромной вероятностью приведет к ДЛЛ-хелу и невозможности понять, что же в реальности произошло.
Ты бы хоть попробовал к чему приведет твое предложение. Создай две версии библиотек с одинаковым номером версии, но разной сигнатурой и попробуй подменить их без перекомпиляции ссылающейся сборки.
Возможно я не прав и ты получишь внятную диагностику. Хотя верится в это с трудом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
Здравствуйте, Ziaw, Вы писали:
Z>На всякий случай проверил еще раз, зависимостей от файлов в этой папке в проекте не нашел. Это только тулза для билда, все зависимости идут на текущий установленный немерл. Пример некорректный.
Вообще-то "тулза" (а в реальности компилятор) собирается с помощью самой себя (бутстрапится). И это самый правильный подход.
Я уже не помню твоих проблем, напомни их еще раз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
Здравствуйте, Ziaw, Вы писали:
Z>В скомпилированной нельзя. У меня в проекте миграции на nemerle. Макросы и либа для них подключаются в скомпилированном виде. Это все должно собираться (и собирается) без установки немерла, мигратор сам компилирует миграции.
Мне кажется лучше это показать более наглядно.
Как я понял имеем зависимость:
Y.dll <- X.dll <- Nemerle.dll
При чем X.dll распространяется исключительно в бинарном виде, т.е. ему нужна определенная версия Nemerle.dll.
А значит даже указав SpecificVersion False для X.dll, мы все равно прибиваемся к конкретной версии Nemerle.dll, потому как повлиять на ссылки X.dll уже не можем.
Здравствуйте, WolfHound, Вы писали:
Z>>На всякий случай проверил еще раз, зависимостей от файлов в этой папке в проекте не нашел. Это только тулза для билда, все зависимости идут на текущий установленный немерл. Пример некорректный. WH>Это у тебя проект некорректный.
Я не пойму, ты правда не понимаешь или делаешь вид? Ты утверждал, что у тебя есть зависимости от бинарников и показывал на бустрап. От его библиотек нет зависимостей в проекте, потому и пример "у меня все работает" некорректен. Вместо аргументов ты начинаешь делать необоснованные утверждения про проект который в глаза не видел.
Еще раз — у тебя все работает пока не появились бинарные зависимости от dll собраных немерлом. Например что-то захотелось выделить в nuget package.
WH>Причем лично мне не ясно, зачем тебе вообще бут?
Бут нужен, чтобы это все билдилось даже если нет под рукой человека, который способен найти и установить нужную версию немерла для билда. Авралы "я установил немерл, а у меня ничего не билдится" мне из отпуска не нужны. Переставлять немерл на билдсервере тоже не нужно.
Re[27]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
Здравствуйте, Ziaw, Вы писали:
Z>Я не пойму, ты правда не понимаешь или делаешь вид? Ты утверждал, что у тебя есть зависимости от бинарников и показывал на бустрап. От его библиотек нет зависимостей в проекте, потому и пример "у меня все работает" некорректен. Вместо аргументов ты начинаешь делать необоснованные утверждения про проект который в глаза не видел.
Так я тебе показал, как надо делать бутстрап.
Z>Еще раз — у тебя все работает пока не появились бинарные зависимости от dll собраных немерлом. Например что-то захотелось выделить в nuget package.
Ох.
А что происходит, если обновляется любая другая бинарная библиотека?
Z>Бут нужен, чтобы это все билдилось даже если нет под рукой человека, который способен найти и установить нужную версию немерла для билда. Авралы "я установил немерл, а у меня ничего не билдится" мне из отпуска не нужны. Переставлять немерл на билдсервере тоже не нужно.
А вы что больше никакую другую внешнюю библиотеку не используете?
Если используете, то как решаете проблему обновления?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[26]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
Здравствуйте, VladD2, Вы писали:
VD>Так компиляйся с текущей версий и проблем не будет.
Опять двадцать пять. У меня есть скомпилированная dll. Я не хочу ее подключать исходниками.
Z>>Если я создаю бинарную либу на nemerle — я прошиваю в ней ссылку на конкретную версию nemerle.dll. Засовывать ее в nuget смысла мало. Она будет работать только у тех, у кого стоит та же самая версия немерла.
VD>Это проблема самого дотнета. Любая общая сборка приведет к тому же результату.
В .net работают nuget packages. Для немерловых либ — нет.
VD>То что ты предлагаешь с огромной вероятностью приведет к ДЛЛ-хелу и невозможности понять, что же в реальности произошло. VD>Ты бы хоть попробовал к чему приведет твое предложение. Создай две версии библиотек с одинаковым номером версии, но разной сигнатурой и попробуй подменить их без перекомпиляции ссылающейся сборки.
Значит нужна стабильная ветка в которой правят баги, но не трогают сигнатуры. И master, в котором делают новые фичи и мерджат в него stable.
VD>Возможно я не прав и ты получишь внятную диагностику. Хотя верится в это с трудом.
ЕМНИП диагностика будет достаточно внятной, но такого счастья и правда не нужно.
Re[24]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
Здравствуйте, _NN_, Вы писали:
_NN>Как я понял имеем зависимость: _NN>Y.dll <- X.dll <- Nemerle.dll
_NN>При чем X.dll распространяется исключительно в бинарном виде, т.е. ему нужна определенная версия Nemerle.dll. _NN>А значит даже указав SpecificVersion False для X.dll, мы все равно прибиваемся к конкретной версии Nemerle.dll, потому как повлиять на ссылки X.dll уже не можем.
особенно неудобно получается если макросборка имеет внутренние зависимости между макросами
т.е. разрабатывалась с бутстрапом
Здравствуйте, Ziaw, Вы писали:
Z>Значит нужна стабильная ветка в которой правят баги, но не трогают сигнатуры. И master, в котором делают новые фичи и мерджат в него stable.
Что значит "стабильная ветка в которой ... не трогают сигнатуры"?
Почему под такую не проходят релизы? Вот на сегодня есть 1.0 и 1.1. Юзай их. Все что берется из мастера априори не стабильно.
Гарантировать, что не будет изменений невозможно. Если сама Nemerle.dll относительно стабильна, то другие либы — нет. А с ними будет такая же проблема когда кто-то захочет из из нюгета использовать.
VD>>Возможно я не прав и ты получишь внятную диагностику. Хотя верится в это с трудом.
Z>ЕМНИП диагностика будет достаточно внятной, но такого счастья и правда не нужно.
Если мы чего-то не можем гарантировать, то должны быть уверены, что люди не начнут рвать на себе волосы. Так что ты уж раз предлагаешь, то потрудись провести эксперименты и выложи здесь отчет о них. А там уже решим. Может и правда я слишком перестраховываюсь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
Здравствуйте, VladD2, Вы писали:
Z>>Значит нужна стабильная ветка в которой правят баги, но не трогают сигнатуры. И master, в котором делают новые фичи и мерджат в него stable. VD>Что значит "стабильная ветка в которой ... не трогают сигнатуры"? VD>Почему под такую не проходят релизы? Вот на сегодня есть 1.0 и 1.1. Юзай их. Все что берется из мастера априори не стабильно. VD>Гарантировать, что не будет изменений невозможно. Если сама Nemerle.dll относительно стабильна, то другие либы — нет. А с ними будет такая же проблема когда кто-то захочет из из нюгета использовать.
Скорее всего так и есть (относительно стабильна). Необходимо сделать из относительно стабильна — полностью стабильна. Это в общем-то общий подход, для тех, у кого жизненный цикл продукта достаточно длинный.
Думаю, что всё что нужно — это необходимо обеспечить, что бы Nemerle.dll's AssemblyVersion были 1.0.0.0, 1.1.0.0, 1.2.0.0, при этом AssemblyFileVersion можно наращивать так как это делается сейчас, в конце концов для более точной информации есть AssemblyInformationalVersion в который можно ложить хоть id коммита.
Но при этом необходимо следить что бы новые сборки "вдруг" ничего не ломали, во-впервые опубликованных контрактах. Следить за этим нужно специально, а не то как бог надушу положит, как это происходит сейчас (в силу отсутствия процесса контроля). Т.е. что бы это сделать по уму — за этим просто нужно специально следить и в общем-то всё. При том уже можно договорится могут ли минорные релизы ломать обратную совместимость. Мне кажется, что могут, и скорее всего больше всего парит, что имея новую версию компилятора с исправленными багами или улучшениями — мы в нагрузку получаем новую версию nemerle.dll, даже в том случае, если на неё эти изменения никакого эффекта не оказывали. Способ использовать только оффициальные билды — способ конечно, но врядли он годится в этом случае, т.к. компилятор далеко не такого качества, как тот же C# — зато и не надо ждать по 3 года, пока корпорация добра почухается.
В общем это моё, возможно ограниченное видение, Ziaw думаю поправит и дополнит.
Хотя это всё что я описал вероятно с нюгетом может и не помочь, но я нюгет глубоко никогда не копал.
Z>>ЕМНИП диагностика будет достаточно внятной, но такого счастья и правда не нужно. VD>Если мы чего-то не можем гарантировать, то должны быть уверены, что люди не начнут рвать на себе волосы. Так что ты уж раз предлагаешь, то потрудись провести эксперименты и выложи здесь отчет о них. А там уже решим. Может и правда я слишком перестраховываюсь.
Получишь вероятнее всего TypeLoadException для некоторых типов, у кого не сошлись наименования/сигнатуры, но если выполнить вышеописанное — т.е. обеспечить обратную совместимость — то такое если и будет возникать, то крайне редко.
Re[29]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
Да, развивая тему — при этом, вероятно возможно будет создать нюгет пэкеджи Nemerle Runtime 1.0/1.1/1.2 — на которые смогут ссылаться другие Nemerle-библиотеки. При этом обновления Nemerle Runtime 1.0/1.1/1.2 — будут мэйнтэйниться Nemerle Team, — а библиотеки их авторами. Но без обратной совместимости тут никуда. Ну это на правах дурной идеи, как я уже говорил, с нюгетом плотно не знакомился.
Re[28]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
Здравствуйте, VladD2, Вы писали:
VD>Что значит "стабильная ветка в которой ... не трогают сигнатуры"?
Я даже не знаю как это объяснить, какое слово непонятно? Ветка?
VD>Почему под такую не проходят релизы? Вот на сегодня есть 1.0 и 1.1. Юзай их. Все что берется из мастера априори не стабильно.
К примеру Nemerle.Web не собирается релизом 1.1 (ICE) Чтобы ее собрать приходится ставить себе ночной билд. Поэтому, к примеру, на сервере rsdn не получается установить стабильную версию. Хорошо, что сам немерл, который там собирается не использует инсталяцию. А что делать, если мне вдруг захочется собирать nrails? Бутстрапить их?
VD>Гарантировать, что не будет изменений невозможно. Если сама Nemerle.dll относительно стабильна, то другие либы — нет. А с ними будет такая же проблема когда кто-то захочет из из нюгета использовать.
Проблема того, что все либы немерла приходится тащить вместе с компилятором. По уму они должны лежать в nuget и быть зависимы от nemerle runtime 1.0 или 1.1. Сам nemerle надо положить в chockolate (это nuget package для бинарников), а интеграцию в галерею. Тогда надобность в инсталяторе отпадет, как и отпадут зависимости от либ, идущих с компилятором.
Тут я, правда, не знаю, сможет ли компилятор собрать с рантаймом отличным от используемым собой. SRE, емнип, заставляет грузить используемые сборки в текущий домен и мы получим конфликт при загрузке двух одинаковых сборок из разных мест.
Еще появляется проблема с интеграцией. Она тоже должна билдить конкретным компилятором, а не тем которым она собрана.
Баги компилятора должны правиться в компиляторе, который может наращивать свою версию сколько угодно. Компилятору не особо нужны даже ветки. Он всегда относительно стабилен. Просто наращивает функционал и правит баги, его надо уметь обновить в любой момент. Баги в библиотеке достаточно редки, но вот ей как раз нужны ветки, ибо в нее активно добавляют новые фичи.
VD>Если мы чего-то не можем гарантировать, то должны быть уверены, что люди не начнут рвать на себе волосы. Так что ты уж раз предлагаешь, то потрудись провести эксперименты и выложи здесь отчет о них. А там уже решим. Может и правда я слишком перестраховываюсь.
Ты не зря перестраховываешься. Ситуаций с изменением сигнатур быть не должно независимо от детальности диагностики, в любом случае это рантайм ошибка.
Я думаю, что приведение в порядок N1 уже не стоит затраченных усилий. На это уйдет не меньше пары месяцев нестабильности и наверняка доставит кому-то геморой даже в законченном виде. Я только хочу, чтобы в N2 не повторилась та же ошибка. В JB должны быть нормальные релиз-инженеры, просто не проморгайте эту сторону проекта, за этим должен проследить ПМ, но я не знаю насколько ваш ПМ в курсе текущей ситуации.
Re[28]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
Здравствуйте, WolfHound, Вы писали:
Z>>Я не пойму, ты правда не понимаешь или делаешь вид? Ты утверждал, что у тебя есть зависимости от бинарников и показывал на бустрап. От его библиотек нет зависимостей в проекте, потому и пример "у меня все работает" некорректен. Вместо аргументов ты начинаешь делать необоснованные утверждения про проект который в глаза не видел. WH>Так я тебе показал, как надо делать бутстрап.
Так я умею делать бустрап. Проблема не в бутстрапе, а в зависимости от nemerle.dll через другую либу.
Z>>Еще раз — у тебя все работает пока не появились бинарные зависимости от dll собраных немерлом. Например что-то захотелось выделить в nuget package. WH>Ох. WH>А что происходит, если обновляется любая другая бинарная библиотека?
Любая другая библиотека общего назначения, например log4net, старается держаться одной версии как можно дольше. И уж точно не меняет версию на багфикс релизах. Зависимость от нее не очень опасна.
В принципе, это проблема платформы вообще. Поддержка библиотеки имеющей в зависимости от себя другую, часто меняющуюся библиотеку, приносит немалый геморой. В Java проблема давно обсосана, созданы всякие maven'ы для автоматизации этого бардака.
Z>>Бут нужен, чтобы это все билдилось даже если нет под рукой человека, который способен найти и установить нужную версию немерла для билда. Авралы "я установил немерл, а у меня ничего не билдится" мне из отпуска не нужны. Переставлять немерл на билдсервере тоже не нужно. WH>А вы что больше никакую другую внешнюю библиотеку не используете? WH>Если используете, то как решаете проблему обновления?
Какую проблему обновления?
Re[15]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
Здравствуйте, fddima, Вы писали:
_NN>>В каком виде нужен unsafe ? F> Поддержка указателей. Использую C#, т.к. других вариантов нет. unsafe — это не только интероп, но крайне полезен при реализации методов критичных по скорости.
, хотя этого еще не просили.
Да я в курсе, но это крайне далеко от того что поддерживает шарп (по крайней мере на момент публикации). В принципе меня это уже никоим образом не парит — код с указателями плавно переплывает в совсем автогенерированный — хоть на IntPtr-ах можно извращаться.
Re[17]: В реальности я надеюсь, что команда Н2 закончит проект и ее уволят...
, хотя этого еще не просили. F> Да я в курсе, но это крайне далеко от того что поддерживает шарп (по крайней мере на момент публикации). В принципе меня это уже никоим образом не парит — код с указателями плавно переплывает в совсем автогенерированный — хоть на IntPtr-ах можно извращаться.
Учитывая проделанное, приделать то что нужно не выглядит большой проблемой.
Хотя конечно смотря что нужно.
Здравствуйте, fddima, Вы писали:
F> Да я в курсе, но это крайне далеко от того что поддерживает шарп (по крайней мере на момент публикации). В принципе меня это уже никоим образом не парит — код с указателями плавно переплывает в совсем автогенерированный — хоть на IntPtr-ах можно извращаться.
Я ансэйф и готу как раз для генерации более быстрого кода и сделал. Писать это руками я бы не стал. А генерированный код с ними терпеть можно, так как он по модели генерируется и отладки каждой строчки не требует.
В прочем, пока мы используем только готу.
Но в целом — согласен! Генерация кода решает много проблем. В том числе и эту.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
