Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, _NN_, Вы писали:
_NN>>А можно узнать, что конкретно вам мешает ?
I>Предлагаешь начать второй круг ?
А где написано что мешает ?
Кроме жалоб на размер лямбд я так и не понял что конкретно мешает
_NN>Подружить Resharper (другой инструмент) с Nemerle конечно не получится без содействия с jetBrains (другим инструментом), хотя думаю это и так понятно.
В случае с Resharper вполне может получиться. У Resharper достаточно открытая архитектура, можно подцепить свой языковой плагин и как минимум навигация, всякие find usages и другие простые штуки заведутся. В SDK и в паблике есть несколько примеров языков с навигацией, и первые шаги с Nemerle идут довольно легко. У меня были экспериментальные попытки на эту тему. Но до стадии "можно что-то показать" не дошло — вылезает куча пустой работы из-за того что внутренний фреймворк решарпера заточен на выхлоп их генератора парсеров.
Re[37]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
Здравствуйте, _NN_, Вы писали:
I>>Предлагаешь начать второй круг ? _NN>А где написано что мешает ? _NN>Кроме жалоб на размер лямбд я так и не понял что конкретно мешает
Неконтролируемые зависимости, непрозрачный выхлоп компилятора, размер сборок, функциональные типы идентичные стандартным дотнетовским, отсутствие поддержки полной версии языка, который могут выдавать всякие недо-,полу-, Üбер-визарды и прочие генераторы, т.к. переписать такой код нет никакой возможности.
Re[38]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
I>Неконтролируемые зависимости, непрозрачный выхлоп компилятора, размер сборок, функциональные типы идентичные стандартным дотнетовским, отсутствие поддержки полной версии языка, который могут выдавать всякие недо-,полу-, Üбер-визарды и прочие генераторы, т.к. переписать такой код нет никакой возможности.
Ээээ... это были мои единоразовые хотелки, когда основная масса возможностей N — не требуется. Т.е. эдакий C# в синтаксисе N.
В остальном у меня положительный опыт с N. Улучшать там есть чего и много, но и то, что уже есть — можно успешно использовать.
Re[39]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
Здравствуйте, fddima, Вы писали:
I>>Неконтролируемые зависимости, непрозрачный выхлоп компилятора, размер сборок, функциональные типы идентичные стандартным дотнетовским, отсутствие поддержки полной версии языка, который могут выдавать всякие недо-,полу-, Üбер-визарды и прочие генераторы, т.к. переписать такой код нет никакой возможности. F>Ээээ... это были мои единоразовые хотелки, когда основная масса возможностей N — не требуется. Т.е. эдакий C# в синтаксисе N.
У меня ровно то же, только это все обязательно в моем случае
Re[40]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, fddima, Вы писали:
I>>>Неконтролируемые зависимости, непрозрачный выхлоп компилятора, размер сборок, функциональные типы идентичные стандартным дотнетовским, отсутствие поддержки полной версии языка, который могут выдавать всякие недо-,полу-, Üбер-визарды и прочие генераторы, т.к. переписать такой код нет никакой возможности. F>>Ээээ... это были мои единоразовые хотелки, когда основная масса возможностей N — не требуется. Т.е. эдакий C# в синтаксисе N.
I>У меня ровно то же, только это все обязательно в моем случае
Теперь все ясно.
Использовать System.Func вместо Function мне кажется вполне возможным вариантом. Если бы кто-то это сделал..
Насчет контроля зависимостей, тут я даже не знаю что и придумать.
Nemerle.dll это как любая Utility.dll , которая всегда нужна.
Скажем в .NET 3.5 нет System.Threading.dll, а таски использовать хочется, получается лишняя зависимость , и как решить этот случай ?
Можно подумать как базовые типы выразить в терминах фреймворка, а все остальное вынести в отдельную библиотеку Nemerle.Lib.dll.
Тут бы хорошо подошли макротипы
Можно попробовать ILMerge-м объединить в одну сборку.
Есть идеи лучше ?
В любом случае кто-то должен будет это сделать, а если некому, то это не случится.
Здравствуйте, _NN_, Вы писали:
_NN>Использовать System.Func вместо Function мне кажется вполне возможным вариантом. Если бы кто-то это сделал..
Не надо. Даже в MS-ном F# функциональные типы делаются на их FastFunc вместо делегатов.
Re[42]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, _NN_, Вы писали:
_NN>>Использовать System.Func вместо Function мне кажется вполне возможным вариантом. Если бы кто-то это сделал.. A>Не надо. Даже в MS-ном F# функциональные типы делаются на их FastFunc вместо делегатов.
Здравствуйте, IT, Вы писали:
VD>>В итоге, NN демонстрирует, что дело (как я и предполагал) в лмбдах, но ты даже не удосуживаешься понять смысла сказанных слов и снова лепишь facepalm.
IT>А ты сам-то проверял или в этой ветке чьё-то мнение прочитал.
Я не однократно видел код ПМ и уверен, что ты ошибешься по его поводу. Что касается замыканий, лямбд и делегатов, то это вполне вероятно, так как я знаю как оно там реализовано и какие проблемы эта реализация может породить. НН озвучил результаты вполне очевидного эксперимента. Не вижу оснований не доверять его результатам.
IT>Давно уже следовало бы отобрать у тебя модерилку, чтобы лишить тебя возможности демонстрировать твою неадекватность в модерировании
А что тут не адекватного? Человек пришел на технический форум явно с целью устроить флэйм, а не разбираться с техническими вопросами. Если бы сам в него не влез давно бы забанил.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
Здравствуйте, IT, Вы писали:
VD>>Если бы его реально интересовала судьба проекта, то он попытался бы помочь ему и исправить недостатки, а не злорадствовал по чем зря.
IT>Вы же всё позакрывали и всех послали. Как тут можно помочь?
Что по закрывали? Кого послали? Чем помочь?
Человек выдергивает фразы из контекста, перевирает их и предъявляет претензии к другим собеседникам (в виде фэйспалмом). При это в теме он вообще ничего не соображает и ждет только флэйма.
Ты, кстати, тут уже тоже давно не делом заниматься, а выяснением отношений. И все из-за того, что с тобой не согласились по поводу причин увеличения размеров сборок.
Если тебя волнует эта проблема, то лучше бы помог выявить ее реальные причины, а то и помочь их устранить. НН вот сделал полезное дело и подтвердил мои предположения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, artelk, Вы писали:
A>>Здравствуйте, _NN_, Вы писали:
_NN>>>Использовать System.Func вместо Function мне кажется вполне возможным вариантом. Если бы кто-то это сделал.. A>>Не надо. Даже в MS-ном F# функциональные типы делаются на их FastFunc вместо делегатов. _NN>А какая причина ? _NN>Скорость ?
Да. Вызов виртуального метода (который может еще и инлайниться JITом, если фактический тип известен) заметно быстрее вызова делегата.
Если есть основания, что в последнем фреймворке это уже не так, просьба показать.
Re[44]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, _NN_, Вы писали:
_NN>>Здравствуйте, artelk, Вы писали:
A>>>Здравствуйте, _NN_, Вы писали:
_NN>>>>Использовать System.Func вместо Function мне кажется вполне возможным вариантом. Если бы кто-то это сделал.. A>>>Не надо. Даже в MS-ном F# функциональные типы делаются на их FastFunc вместо делегатов. _NN>>А какая причина ? _NN>>Скорость ?
A>Да. Вызов виртуального метода (который может еще и инлайниться JITом, если фактический тип известен) заметно быстрее вызова делегата. A>Если есть основания, что в последнем фреймворке это уже не так, просьба показать.
Я так понимаю это называется теперь FSharpFunc.
В F# есть карринг, без него конечно будет сложно , получится что-то вроде Func[int, Func[string, double]] вместо Func[int, string, double].
Но в Nemerle то карринга нет.
Здравствуйте, Ikemefula, Вы писали:
I>Спасибо, капитан. Многие вещи не хранятся в LOH и тем не менее влияют на фрагментацию этого LOH.
Это чушь. На фрагментацию влияет количество перезоемов больших объектов и паттерн распределения памяти. А для загрузки длл отводится соврешенно другая область памяти, которая никак не влияет на область памяти выделяемой под LOH.
I>Это ты сильно заблуждаешься. Если сборки отличаются в разы, то и выхлоп после джыта так же будет отличаться в разы и это будет не пару мег.
Я то знаю о чем говорю. Компилируются только метода. После компиляции метаданные методам нужны только для рефлексии, которая не так уж часто применяется.
Хочешь поспорить — объясни почему в 32х процессе для дотнета доступно только 1гб +- 200мб. Куда девается 1 гиг ?
Я тебе уже говорил, что реальная цифра около 1.6 гига. И определеяется она объемом виртуальной памяти доступной процессу под 32-битной Виндовс. Остальное резервируется под нужды рантайма. Ты же занимавшийся выдумками.
В любом случае на фоне гига даже мегабайтная сборка — это 0.1%. Она рояли не играет. Чтобы создать мегабайтную сборку нужно не один мег исходников наколбасить. А ты намеренно пытаешься сделать из мухи слона.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
Здравствуйте, VladD2, Вы писали:
I>>Спасибо, капитан. Многие вещи не хранятся в LOH и тем не менее влияют на фрагментацию этого LOH.
VD>Это чушь. На фрагментацию влияет количество перезоемов больших объектов и паттерн распределения памяти.
Это факты.
>А для загрузки длл отводится соврешенно другая область памяти, которая никак не влияет на область памяти выделяемой под LOH.
Чудеса, да и только. Какая область памяти отводится, дело десятое. Главное что сборки жрут именно ту часть АП, которая может использоваться GC.
Проверить просто — берешь консольное приложение безо всяких зависимостей и выделяешь память. Выходит около 1.6-1.9 гб в завимости от размера блока. 1.9 будет если выделять кусками по 16мб
Дальше просто — вгружаешь сборки и, внезапно, когда количество и разным сборок сравнимо с количеством в реальном приложении, память почемуто начинается заканчиваться на планке 1гб+200мб. Все зависит естественно от способа расходования памяти.
I>>Это ты сильно заблуждаешься. Если сборки отличаются в разы, то и выхлоп после джыта так же будет отличаться в разы и это будет не пару мег.
VD>Я то знаю о чем говорю. Компилируются только метода. После компиляции метаданные методам нужны только для рефлексии, которая не так уж часто применяется. VD>Хочешь поспорить — объясни почему в 32х процессе для дотнета доступно только 1гб +- 200мб. Куда девается 1 гиг ? VD>Я тебе уже говорил, что реальная цифра около 1.6 гига. И определеяется она объемом виртуальной памяти доступной процессу под 32-битной Виндовс. Остальное резервируется под нужды рантайма. Ты же занимавшийся выдумками.
Это цифра для консольного приложения без каких либо сборок, только самый минимум. В реальном приложении будет 1гб +-200мб.
VD>В любом случае на фоне гига даже мегабайтная сборка — это 0.1%. Она рояли не играет. Чтобы создать мегабайтную сборку нужно не один мег исходников наколбасить. А ты намеренно пытаешься сделать из мухи слона.
У меня >50мб исходного кода. Ты хорошо понимаешь, что это значит ?
Re[45]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
Здравствуйте, fddima, Вы писали:
F>Delegate — Direct: -2055
Ну давай, успокой общественность, найди в тесте ошибку.
У меня примерно те же числа при нескольких запусках.
Re[47]: Nemerle vs. C#. До сих пор привыкнуть не могу :)
Делегат может быть быстрее.
Но затраты на его создание, афаик, довольно большие. В любом случае на таком микротесте понятно не будет. + разбор процессоров по всей видимости дают разные результаты.