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

F>Но из всего, на что можно было бы ответить, ты почему-то выбрал самое неважное.

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

Все что я смог вынести из твоего пространного сообщения — тебе не нравится наличие дополнительной ДЛЛ. Чем она помешала так и осталось за кадром.

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

F> В основном Nemerle.dll меня ничуть не парит, но есть некоторые минималистичные "проекты" которые не должны иметь внешних зависимостей кроме как от фреймворка.

Так компилируй такие проекты без стандартной библиотеки, а с необходимыми исходниками из нее. Они доступны каждому. Думаю, подключить файл к проекту тебе не составит труда.

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

F>> В основном Nemerle.dll меня ничуть не парит, но есть некоторые минималистичные "проекты" которые не должны иметь внешних зависимостей кроме как от фреймворка.
VD>Так компилируй такие проекты без стандартной библиотеки, а с необходимыми исходниками из нее. Они доступны каждому. Думаю, подключить файл к проекту тебе не составит труда.
Тогда после этого я немогу подключить такую сборку к другому проекту на Nemerle — он начинает сыпать кучу ворнингов и вместо того что бы референсить Nemerle.dll — референсит мою сборку (первую референсит). Т.е. это тоже получается не очень решением.
Хотя возможно если подправить компилятор, то вполне реально его заставить искать все эти типы в другом нэймспейсе.

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

F> Тогда после этого я немогу подключить такую сборку к другому проекту на Nemerle — он начинает сыпать кучу ворнингов и вместо того что бы референсить Nemerle.dll — референсит мою сборку (первую референсит). Т.е. это тоже получается не очень решением.

Ты уж как-нибудь определись. Или тебе нудно делать минимальные проекты без зависиостей, или ты хочешь сборки плодить. Если немеровых сборок в проекте больше одной, то имеет смысл использовать Nemerle.dll и не заниматься ерундой. Одна мелка сборка ни на что не влияет.

F> Хотя возможно если подправить компилятор, то вполне реально его заставить искать все эти типы в другом нэймспейсе.

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

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

Я то определился. Задача сделать сборку без зависимостей, ничего кроме mscorlib/System ей не нужно. Это требование, можешь с ним не соглашаться, но оно от этого никуда не денется.

В этой ситуации немерл ничем не может помочь, исключительно потому что так реализован. Если не использовать каких-то особых фишек — то и зависимость не появляется.

Но без лямбд — жить тяжело, а шарп справляется с любыми лямбдами, — потому что это просто возможность генерировать тело метода на основе известного типа делегата.
В N всё тоже самое, только насильно притянут свой Function, который разумеется шире в возможностях. Тем не менее при вызове метода, например, Where передавая туда инлайн лямбду — толку от этого Function никакого нет, ни одна из его возможностей не будет задействована. Т.е. если очень захотеть — то в этом случае вполне можно генерировать всё тот же класс, но не наследовать его от Function, заодно кешируя в нём целевой делегат, а не просто себя.
Из-за чего собственно и происходит лишнее создание делегата, если это не Function, что как бы тоже не шибко хорошо, хотя терпимо, ибо с замыканиями его всё равно создавать.

Но опять же — шарп создаёт один класс на замыкание и лямбды. В N — их уже два. Т.е. вызов лямбды с замыканием стоит на один объект дороже, и их нужно уже не два, а три, или в случае собственного функционального типа — их всё ещё нужно два, но мог бы быть и один, что было бы явно покруче шарпа.

Но судя по всему это конечно же ерунда, спички и игрушки.

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

F> Я то определился. Задача сделать сборку без зависимостей, ничего кроме mscorlib/System ей не нужно. Это требование, можешь с ним не соглашаться, но оно от этого никуда не денется.

Брось ты изучение немерла. Оно тебе явно не надо. У тебя задачи совершенно иные. Немерл он для тех кому нужны вариантные типы, кортежи, неизменяемые структуры данных вроде списков и словарей, макросы и т.п. Тем кому не нужно зависимостей от всего этого нужно использовать шарп. А еще лучше ассемблер. Там вообще полный контроль будет. Зачем над собой издеваться то?

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

<skip/>

Так и скажи, что тебе нужны лямбды не завязанные на класс Function.
Расскажи как это сделать и предлагай реализацию этого дела при этом не поломав старый код конечно.
Также стоит объяснить какие преимущества это дает для тех кто не в теме.

Pull-request в github-е или патч в форум и можно будет протолкнуть в компилятор.

Дело за малым

P.S.
Если только жаловаться без предложений, то смысла действительно в этом нет.
В том же C# есть недоработки, но на них ты не жалуешься, а все потому что никто их не починит!
А вот в Nemerle можно и пожаловаться и самим же исправить.

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

VD>Брось ты изучение немерла. Оно тебе явно не надо. У тебя задачи совершенно иные. Немерл он для тех кому нужны вариантные типы, кортежи, неизменяемые структуры данных вроде списков и словарей, макросы и т.п. Тем кому не нужно зависимостей от всего этого нужно использовать шарп. А еще лучше ассемблер. Там вообще полный контроль будет. Зачем над собой издеваться то?
Зачем всё так утрировать и обобщать? Ну есть единичная потребность и всё. На шарпе и писано, но изначально хотел на N.
Да и сейчас хочется иметь минималистичный язык, в большей степени с макросами, нежели с встроенным list и option. Короче без stdlib. Это вполне возможно.
Ну и сказал бы что текущий компилятор под это не заточен, и заточен не будет, а ключик nostdlib годится только для сборки stdlib. Ну и нет так нет.

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

F> Ну и сказал бы что текущий компилятор под это не заточен, и заточен не будет, а ключик nostdlib годится только для сборки stdlib. Ну и нет так нет.

На это не заточен ни один в мире компилятор. Просто у МС есть возможность сложить се необходимое во фрэймворк.

Немерл не мыслим без таких вещей как list[T], option[T], кортежей и т.п. Если ты все это не используешь, то ты пишешь на C#. Ну, и пиши на нем. У МС очень быстрый компилятор и качественная IDE + ReSharper.

Так что идея отказаться от Nemerle.dll совершенно не реалистична. К тому же в этом нет никакого смысла.

Я, кстати, так и не услышал зачем нужно отказываться от Nemerle.dll.

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

F>

F>.method private hidebysig static 
F>    void Main () cil managed 
F>{
F>    // Method begins at RVA 0x2064
F>    // Code size 13 (0xd)
F>    .maxstack 1
F>    .entrypoint
F>    .locals init (
F>        [0] class [Nemerle]Nemerle.Builtins.Function`2<int32, int32>
F>    )

F>    IL_0000: ldsfld class Program/_N__N_lambda__3327__3341 Program/_N__N_lambda__3327__3341::Instance
F>    IL_0005: stloc.0
F>    IL_0006: ldloc.0
F>    IL_0007: call void Program::Method(class [Nemerle]Nemerle.Builtins.Function`2<int32, int32>)
F>    IL_000c: ret
F>} // end of method Program::Main
F>

F>Зато теперь глаз режет использование слота (т.е. лишние stloc/ldloc и locals) — все уверены, что JIT это вообще будет оптимизировать, а не тупо выделит место на стеке положит туда и прочитает? Хотя к изначальному вопросу это конечно отношения не имеет, но в целом хотелось бы конечно получать код более качественный. Хотелось бы что бы в будущем этому тоже уделялось внимание.

Я, кстати, знаю причину по которой stloc/ldloc-и появляются в генерируемом коде. Кто-то не очень чисто написал патч для поддержки try/catch/finally в выражениях. Я пробовал его поправить, но какие-то тесты отказались проходить. Могу ткнуть в конкретное место компилятора, требующее "отладки методом пристального взгляда".

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

F>> Ну и сказал бы что текущий компилятор под это не заточен, и заточен не будет, а ключик nostdlib годится только для сборки stdlib. Ну и нет так нет.
VD>На это не заточен ни один в мире компилятор. Просто у МС есть возможность сложить се необходимое во фрэймворк.
Ну почему же сразу нет таких — есть, вспомни C и C++.
Сейчас в N ключ nostdlib лишь заставляет поискать типы в другом месте, при этом список этот весьма увесистый, и в не зависимости будет ли использован в итоге, например, list — компилятор сразу же требует его наличие. Поэтому это скорее god-mode ключ --compile-stdlib. Да, можно с помощью него всунуть библиотеку к себе в проект, но ещё проще ничего не выдумывать и воспользоваться ilmerge. Как я уже говорил, это не плохо и не хорошо — просто я ожидал немного другого.
По поводу сложить всё необходимое во фреймворк — то так никто ж и не мешает использовать то, что там лежит. Но там почти ничего нужного не лежит.

VD>Немерл не мыслим без таких вещей как list[T], option[T], кортежей и т.п. Если ты все это не используешь, то ты пишешь на C#. Ну, и пиши на нем. У МС очень быстрый компилятор и качественная IDE + ReSharper.
VD>Так что идея отказаться от Nemerle.dll совершенно не реалистична. К тому же в этом нет никакого смысла.
Тотально избавляться от Nemerle.dll я и не предлагал, — будет только хуже. Там где нахожу удобным list я использую, и АТД тоже, — они и так всегда были, только солнце закатывалось вручную. Кортежи я тоже нахожу вполне удобными.

Но N и сейчас может генерировать сборки без зависмости на Nemerle.dll. Т.е. потенциально ему ничего это не мешает делать, в ущерб возможностям конечно же. Собственно всего что мне не хватало пожалуй это ключика-гварда который бы фэйлил компиляцию, если результат начинает референсить Nemerle.dll и хочется простенькие лямбды не завязанные на функциональный тип, во вполне определённых случаях. Да, при этом код от шарпа далеко не уйдёт, но будет синтаксис N, а самому N точно от этого не станет хуже. С лямбдами не завязанными на функциональный тип я как бы и не предлагал избавлятся от Function насовсем, а наоборот при этом в итоге явно улучшить генерируемый код.


VD>Я, кстати, так и не услышал зачем нужно отказываться от Nemerle.dll.
Небольшая сборка общего назначения, которая сама по себе в 10 раз меньше Nemerle.dll. Никаких особых возможностей N она не может утилизировать, просто потому что негде там использовать АТД, list, option и даже макросы не нужны. А когда это так — и зависимость она не должна иметь.

Да шарп, в этом случае отлично подходит, — но с таким подходом действительно можно писать хоть на ilasm. Писать то ведь можно на чём угодно. Пусть не очень common case — но и не что-то совсем уж космическое. За сим предлагаю закончить эту дискуссию. Для этого случая буду продолжать просто юзать шарп, и ни кому не буду сверлить мозг.

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

H>Я, кстати, знаю причину по которой stloc/ldloc-и появляются в генерируемом коде. Кто-то не очень чисто написал патч для поддержки try/catch/finally в выражениях. Я пробовал его поправить, но какие-то тесты отказались проходить. Могу ткнуть в конкретное место компилятора, требующее "отладки методом пристального взгляда".
Ткни.

Хотя именно в этом месте помоему происходит от того, что код на самом деле был типа такого: { def _lambda = ...; method(_lambda); } — и на вот этот def всегда генерируется слот в locals, ну а затем его инициализируем (stloc), а ldloc соответственно это уже использование этой переменной. Я так подозреваю, что это необходимо делать в Debug, но в релизе/с оптимизацией это вроде как явно лишнее.

С другой стороны ещё нужно точно как-то посмотреть, чего там JIT генерит на самом деле с оптимизацией (что-то забыл как), может он такое и "хавает", оптимизация вроде как довольно простая, и её вполне можно делать именно на уровне IL. А случай довольно распространён.

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

_NN>Если только жаловаться без предложений, то смысла действительно в этом нет.

Понимаешь, тут нет решений без недостатков. Влад может сколько угодно говорить, что никого не парит зависимость от Nemerle.dll, но меня парит. Просто потому, что эта зависимость на сугубо конкретную версию Nemerle.dll. Мне надо следить, чтобы у всей команды была одна версия компилятора и обновлялась она одновременно. Если Nemerle основной язык проекта это еще допустимо, но когда столько возни из-за либы — люди перестают меня понимать.

Я бы не жаловался, но Влад-то твердит, что все нормально и никого это не парит.

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

Z>Понимаешь, тут нет решений без недостатков. Влад может сколько угодно говорить, что никого не парит зависимость от Nemerle.dll, но меня парит. Просто потому, что эта зависимость на сугубо конкретную версию Nemerle.dll.
А что в своей сборке нельзя сделать ссылку не на конкретную версию?

Z>Мне надо следить, чтобы у всей команды была одна версия компилятора и обновлялась она одновременно. Если Nemerle основной язык проекта это еще допустимо, но когда столько возни из-за либы — люди перестают меня понимать.
Мы тут занимаемся хардкорным макросостроением с бутстрапингом.
И проблем с разными версиями немерла у разных разработчиков не имеем.
Что мы делаем не так?

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

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

Z>>Понимаешь, тут нет решений без недостатков. Влад может сколько угодно говорить, что никого не парит зависимость от Nemerle.dll, но меня парит. Просто потому, что эта зависимость на сугубо конкретную версию Nemerle.dll.
WH>А что в своей сборке нельзя сделать ссылку не на конкретную версию?

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

WH>Мы тут занимаемся хардкорным макросостроением с бутстрапингом.
WH>И проблем с разными версиями немерла у разных разработчиков не имеем.
WH>Что мы делаем не так?

У вас весь проект в исходниках, нет зависимостей от бинарников собранных немерлом. Соответственно таких конфликтов быть не может.

Влад пытается доказать, что я один такой (да и ты сейчас намекаешь), но вряд-ли кто-то будет утверждать, что невозможность сделать nuget package является мелкой проблемой. Ирония в том, что доработки nuget для поддержки немерловых проектов дают возможность подключать только либы написанные на других языках.

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

Z>>Я бы не жаловался, но Влад-то твердит, что все нормально и никого это не парит.
WH>Я так и не понял что у тебя за проблема.

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

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

Z>У вас весь проект в исходниках, нет зависимостей от бинарников собранных немерлом. Соответственно таких конфликтов быть не может.
А вот эта папка мне приснилась?
https://github.com/rampelstinskin/ParserGenerator/tree/master/N2/Boot/Net-4.0

Z>Влад пытается доказать, что я один такой (да и ты сейчас намекаешь), но вряд-ли кто-то будет утверждать, что невозможность сделать nuget package является мелкой проблемой. Ирония в том, что доработки nuget для поддержки немерловых проектов дают возможность подключать только либы написанные на других языках.
А в чем проблема с нугетом то?
Или там нет других либ которые обновляются?

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

Z>>У вас весь проект в исходниках, нет зависимостей от бинарников собранных немерлом. Соответственно таких конфликтов быть не может.
WH>А вот эта папка мне приснилась?
WH>https://github.com/rampelstinskin/ParserGenerator/tree/master/N2/Boot/Net-4.0

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

У меня честный бут, он не только билдит, но и Nemerle.dll используется от него же (должно все билдиться без установки немерла). Интеграцию начинает плющить сразу как только встает версия немерла отличная от бута.

Z>>Влад пытается доказать, что я один такой (да и ты сейчас намекаешь), но вряд-ли кто-то будет утверждать, что невозможность сделать nuget package является мелкой проблемой. Ирония в том, что доработки nuget для поддержки немерловых проектов дают возможность подключать только либы написанные на других языках.
WH>А в чем проблема с нугетом то?
WH>Или там нет других либ которые обновляются?

Если я создаю бинарную либу на nemerle — я прошиваю в ней ссылку на конкретную версию nemerle.dll. Засовывать ее в nuget смысла мало. Она будет работать только у тех, у кого стоит та же самая версия немерла.

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

Z>>У вас весь проект в исходниках, нет зависимостей от бинарников собранных немерлом. Соответственно таких конфликтов быть не может.
WH>А вот эта папка мне приснилась?
WH>https://github.com/rampelstinskin/ParserGenerator/tree/master/N2/Boot/Net-4.0

На всякий случай проверил еще раз, зависимостей от файлов в этой папке в проекте не нашел. Это только тулза для билда, все зависимости идут на текущий установленный немерл. Пример некорректный.

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

Z>На всякий случай проверил еще раз, зависимостей от файлов в этой папке в проекте не нашел. Это только тулза для билда, все зависимости идут на текущий установленный немерл. Пример некорректный.
Это у тебя проект некорректный.
Причем лично мне не ясно, зачем тебе вообще бут?