LINUX.ORG.RU

Mono 2.10.8

 


0

4

Вышло обновление среды Mono - альтернативы MS .NET.

Среди основных изменений можно выделить следующие:

  • Обновление Task Parallel Library.
  • Провайдер SQLLiteConnection теперь может устанавливать соединение в потоке.
  • Ускорены запуск отладчика и обновление наблюдаемых переменных
  • Добавлена начальная поддержка MSBuild 4.0
  • NuGet теперь работает и в Mono.
  • Phalanger 3.0 теперь работает в Mono.
  • Добавлена поддержка некоторых библиотек фреймворка Azure.
  • Добавлена поддержка работы профилировщика со статически линкуемыми приложениями.
  • Профилировщик теперь может вести лог в любые файлы.
  • SGen теперь имеет встроенную поддержку систем, реализующих ToggleRefs.
  • Профиль для мобильных устройств теперь содержит сборку System.IO.MemoryMappedFiles
  • Добавлен класс PerformanceCounters для ведения статистики JIT.
  • Добавлена поддежка многоядерных процессоров в Mono for Android.

Также исправлено множество ошибок.

>>> Подробности

альтернативы MS .NET

Безальтернативненько.

Loki29 ★★ ()

после моно, когда снова понадобилось на питоне писать, ощутил насколько пион убог

anonymous ()
Ответ на: комментарий от ISanych

Ну так лор ведь. Сначала высказываются закапыватели с ненужниками а потом начинается холивар на отвлеченные темы ;)

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

anonymous ()
Ответ на: комментарий от anonymous

чья бы корова мычала! я помню тебя по тредам, посвящённым андроиду ;)

Пруф или балабол.

e000xf000h ()
Ответ на: комментарий от rtvd

...создание большого файла не значит, что будет использовано место на диске). Т.ч. проблемы нет.

Чем сложнее система, тем больше в ней узлов, чем больше узлов, тем выше вероятность неисправности одного из них.
Т.ч. проблема есть.

Pronin ★★★★ ()
Ответ на: комментарий от alix

..Скорость и простота разработки? Кроссплатформенность (в плане аппаратного обеспечения)?

Полный POSIX кроссплатформенного кода. Не на Java, не на MONO, не на .Net

Скорость и простота?
Это называется «моделирование». То есть СТОЛЬКО моделек?
Нет, для программ «одноразового использования» - согласен, но ведь ЭТО стремится к фундаментальным системам...

Скорее уж «скорость вывода товара на прилавок».

Pronin ★★★★ ()
Ответ на: комментарий от Pronin

Полный POSIX кроссплатформенного кода. Не на Java, не на MONO, не на .Net

Обеспечить поддержку POSIX-compatible ОСей - мало. Обычно нужен еще оффтопик. А на маках обычно предпочтительнее использовать их велосипеды, чем общениксовые.

Deleted ()
Ответ на: комментарий от Deleted

Как это, по-твоему, должно выглядеть Ъ-способом и кто так умеет?

Касательно зависимостей: питон ВООБЩЕ не умеет делать подгрузку зависимостей программы. Питоновые модули есть один дико неудобный способ подгрузить, а сишные вообще никак. Про всякие фичи молчу, хотя они тоже очень важны.

Кто это умеет - Java юзая: Maven, Ivy, Grape, etc..

С модулями общеизвестные проблемы с абсолютным импортом в 2.X и работа с общими переменным. Умеет - Java.

Нужно ли?

Многострочных лямбд

Нужно. Очень. Это конечно не так критично, как статика, но все же.

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

алгебраических типов

Ну, сложные алг. типы может и не очень нужны. Но простые а так-же нормальный case к ним, очень даже. Хотя это уже не так важно.

uhbif19 ()
Ответ на: комментарий от Deleted

Jython и IronPython

Как я уже сказал, они не нужны.

С любом случае, альтернативные реализации на десктопе особенно не поюзаешь.

uhbif19 ()
Ответ на: комментарий от winddos

Плюсую этого джентельмена.

Как я уже заметил, подождут пока Mono станет кому-нибудь нужен, и найдут как подставить в обход этой оферты.

uhbif19 ()
Ответ на: комментарий от uhbif19

Кто это умеет - Java юзая: Maven, Ivy, Grape, etc..

Maven, Ivy, Grape - ни один из них не является частью самой жабы.

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

Зачем тебе многострочные лямбды, если ты хочешь в одну строку?

Deleted ()
Ответ на: комментарий от uhbif19

Почему не поюзаешь? Юзать их можно, сколько влезет, только во всем, помимо интерфейса с жабой и дотнетами и мультитрейдинга они сливают CPython-у.

Deleted ()
Ответ на: комментарий от Pronin

...создание большого файла не значит, что будет использовано место на диске). Т.ч. проблемы нет.

Чем сложнее система, тем больше в ней узлов, чем больше узлов, тем выше вероятность неисправности одного из них. Т.ч. проблема есть.

А где тогда ее нет?

И кстати, не забывай еще и о том, что самые простые системы не содержат кода для обработки нештатных ситуаций. Так что не всегда просто = хорошо.

rtvd ★★★★★ ()
Ответ на: комментарий от Deleted

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

Зачем тебе многострочные лямбды, если ты хочешь в одну строку?

+1

И вообще, разве за многострочные лябмды до сих пор нет уголовной ответственности?

rtvd ★★★★★ ()
Ответ на: комментарий от Pronin

Полный POSIX кроссплатформенного кода.

Не все ОС POSIX-совместимы, и не на всех железках есть полноценная ОС (мобильные телефоны, например)

Скорее уж «скорость вывода товара на прилавок».

Ну, скорость вывода на прилавок напрямую следует из скорости и простоты разработки

alix ★★★★ ()
Ответ на: комментарий от grim

Прикол в том, что приложения на том-же C# можно оптимизировать используя простые трюки

А откуда ты знаешь, что аналогичных трюков нет в java?

Я как-то переписал простой тест на скорость на одном из сайтов - так скрость выросла в 10 раз

А я как-то переписал простой запрос из Oracle в SQLServer - так прибавка к скорости оказалась +4(sic!) порядка. Разве этот факт как-то убеждает в том, что SQLServer шустрее Oracle ?

malbolge ★★ ()
Ответ на: комментарий от uhbif19

1) Самое главное - нет JIT.

а pypy?

2) Никаких серьёзных абстракций нет.

[просто любознательность] а каких, позвольте уточнить, именно не хватает?

2) ... Нет интерфейсов и приватных полей. Без этого ООП не ООП.

3) Множественное наследование под дефолту костыль. А в питоне он еще и не работает. А необходимость наследовать object, не очень мешающий, но таки дикий маразм.

Это разве правильно разделять на два пункта, 3) покрывает 2), можно аргументировать, что мн. наследование - оверхэд и интерфейсы чище.

anonymous ()
Ответ на: комментарий от malbolge

Прикол в том, что приложения на том-же C# можно оптимизировать используя простые трюки

А откуда ты знаешь, что аналогичных трюков нет в java?

Это известный факт - сложные типы в жаве живут только в куче. Дотнет моложе и при некоторые вещи там сделаны прямее (те-же дженерики для совместимости в жаве сделали совсем уж через /dev/ass).

ISanych ()

Очень хорошо, что развивают Open Source реализацию .NET. Что бы там ни говорили, технология очень продуманная и современная. Хотите писать высокоуровневый код? Пожалуйста! Нужно что-то оптимизировать? Небезопасный код с поддержкой указателей к вашим услугам.

Java более стара и во многом уже отстаёт от .NET и C#. Да и с Java тоже не всё так просто. Надеюсь, напоминать про суд между Oracle и Google по поводу последней не нужно.

VEG ()
Ответ на: комментарий от malbolge

Это известный факт

Но тогда почему java все же шустрее mono/нета? :)

Какая связь между отсутствием value-типов и результатами конкретного теста? Если перенести 1:1 жабный код в моно, жава в общем случае будет быстрее за счет лучшего jit и gc. Есть ситуации когда value-типы дадут моно преимущество.

ISanych ()

Предлагать Mono в качестве средства разработки под линукс - это все равно, что предлагать писать на С++ под MFC и запускать через Wine. Почему последнее смешно, а первое все серьезно обсуждают?

crimson_eyes ()
Ответ на: комментарий от ISanych

жава в общем случае будет быстрее

Есть ситуации когда value-типы дадут моно преимущество.

Порвал мозг.

malbolge ★★ ()
Ответ на: комментарий от crimson_eyes

Почему последнее смешно, а первое все серьезно обсуждают?

Потому что тебя забыли спросить, родной.

Вот и получилось, что разработчики fspot gbrainy и banshee c mojoportal единогласно решили стать клоунами.

malbolge ★★ ()
Ответ на: комментарий от malbolge

Вот именно!

F-Spot:
Most of the times when I tried F-Spot, it just keeps crashing on me. Shotwell on a other hand feels a lot more solid and is better integrated with GNOME desktop. (http://www.techdrivein.com/2010/06/meet-shotwell-f-spot-replacement-for.html)

gbrainy: такой графический hello world все равно, на чем писать, хоть на жабаскрипте, хоть на MFC через Wine

Banshee
Banshee 2.0 crashes often: If you have a large music collection (over 10000 songs) expect Banshee to freeze. I’ve never had this problem with Rhythmbox. (http://www.bigfatostrich.com/2011/05/ubuntu-11-04-rhythmbox-vs-banshee/)

mojoportal: основная платформа - Windows, так что Mono выступает в роли Wine, о чем я и толкую

crimson_eyes ()
Ответ на: комментарий от malbolge

А откуда ты знаешь, что аналогичных трюков нет в java?

Потому что я с ней работаю с 2000

grim ★★★☆ ()
Ответ на: комментарий от crimson_eyes

Как мне кажется, многим нравится C# как язык, а альтернатив ему нет.

Кроме того Mono != Wine все таки, там идет упор на альтернативную реализацию байткода, а совсем не костыли с WinAPI как в Wine.

uhbif19 ()
Ответ на: комментарий от rtvd

Ну, да это я глупость сморозил (:

В одну ..э.. логическую строку (?). Как то так.

Но даже в однострочниках это имеет значение :

[1, 2, 3].each { print it }

И аналогично для других операторов :

[1, 2, 3].each { if ( it instanceof Integer ) { println «${it} is a number !» } }

uhbif19 ()
Ответ на: комментарий от alman

Религия не позволяет?

Про религию надо было вспоминать, когда свой фастрепорт на .Нет писали. Заточились под МС, а потом героически эту кривую заточку на кривых руках с помощью кривых поделок в линукс затащили вместо того, чтобы сразу либо дизайн выбрать правильный (сервер-генератор отчетов с платформонезависимым веб- или другим клиентом (например Qt) клиентом) либо технологию ( что-то типа JasperReport или какой-нить pyreport, который без всякой говномоны везде работать будет).

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

Задолбали дятлы :((((

Прошу прощения за мой францусский, но наболело. Куда нормальные программисты делись? Одни недоучки - какое железо не дай - все набок положат кривыми программами.

dr_dobermann ()
Ответ на: комментарий от Deleted

Maven, Ivy, Grape - ни один из них не является частью самой жабы.

И что ? Я же написал «тулзы». Питон этого никак не умеет.

uhbif19 ()
Ответ на: комментарий от grim

А примеры есть?

Да сколько угодно! Вспомните все эти оледыбы, Комы, эктивэксы и прочую шушару, вроде вижуальных бейсиков №6. Все заявы МС про бэствэй оф девелопмент практически умирают в период от 2 до 5 лет гарантированно! Что сейчас будет с тем же .Нет в Вындоус 8? Пригодятся ли накопленный знания и опыт программистов в новой ОС. Вопрос чисто риторический, поскольку ответ известен.

Никто так не прокидывал программеров, как МС. Неподдерживаемость старых кодов в новом пайтоне, по сравнению с обычной практикой МС, просто деццкие игры.

И ладно бы подыхали технологии, Бог с ними. Остается же код, который надо поддерживать. А кто его будет поддерживать, когда это уже МС-мейнстрим и леммингов учат новым совершенным технологиям? Правильно - никто. Вот и мучайся потом с ними.

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

dr_dobermann ()
Ответ на: комментарий от anonymous

а pypy?

Он конечно дико крут, на фоне CPython, но до джавы ему как до луны.

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

[просто любознательность] а каких, позвольте уточнить, именно не хватает?

Говорю-же : интерфейсы, астрактные классы, приватные поля, константы, аннотации.

Это разве правильно разделять на два пункта, 3) покрывает 2), можно аргументировать, что мн. наследование - оверхэд и интерфейсы чище.

Чесно говоря не очень понял вашу мысль (:

Множественное наследование никакого отношения к интерфейсам не имеет. Оно :

1) Не нужно. Само по себе. 2) Интерфейсов никак не заменяет. И дело ни в каком не оверхэде.

Создавая класс с «raise UndefinedMethod», вы создаете очередное устное соглашение, которое усложняет код и работу с ним.

uhbif19 ()
Ответ на: комментарий от uhbif19

Статическая типизация, хотя нафиг она питону для этого есть cyton

Она нужна. Очень.

Вы не тот язык выбрали, ежу понятно. Если вам нужна статическая типизация, ничего лучше С++ посоветовать не могу. Хотя тру говорят про Хаскел, но его на знаю.

Как было сказано выше, ограничения, которые вы привели не ограничения питона, а ваши.

dr_dobermann ()
Ответ на: комментарий от dr_dobermann

в период от 2 до 5 лет гарантированно

.Net 1.0 - 2002 год (:

Никто так не прокидывал программеров, как МС. Неподдерживаемость
старых кодов в новом пайтоне, по сравнению с обычной практикой МС,
просто деццкие игры.

Мне кажется что таких популярных как .Net средств для программирования у Microsoft пока не было.

А кто его будет поддерживать, когда это уже МС-мейнстрим и леммингов учат новым совершенным технологиям?

А в чем отличие Java тут ?

uhbif19 ()
Ответ на: комментарий от uhbif19

.Net 1.0 - 2002 год (:

Кто сейчас пишет под .Нет 1? Достаточно ли знаний .Нет 1 для написания кода под .Нет 4.5? Заработает ли код, который написан под .Нет 4.5 по .Нет 1?

Мне кажется что таких популярных как .Net средств для программирования у Microsoft пока не было.

То, что кажется, не всегда является истиной. Я вот помню, что MFC было самым популярным средством для программирования приложений под МС, причем подольше, чем .Нет.

А в чем отличие Java тут ?

Да ни в чем, то же кидалово, хотя теоретически код 1.1 должен работать под 1.6. Потому на жабе и не пишу.

dr_dobermann ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.