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.

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

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

Ответ на: комментарий от LongLiveUbuntu

лисп пошел в расход, теперь модно писать на хаскеле

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

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

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

либо с целью догнать, либо упростить догоняние. В Mono - нет (малая часть планов и изменений относятся к технологиям M$).

Странно, я вижу это наоборот, примерно так:

Догнать:
New C# Compiler backend (can now use any custom mscorlib)
VB Compiler can now compile to both 2.0 and 4.0 profiles.
Supports ASP.NET MVC3, Razor and new WebPages.
New WebMatrix.Data database API.
F#, IronPython and IronRuby (два последних, впрочем, МСу уже не нужны)

Упростить догоняние:
New Profiler engine
Faster socket stack
Improved Parallel Framework
SGen Precise Stack Scanning and Many performance improvements.
Cecil/Light

Остальное:
Google Native Client Support
Unified MonoTouch/Monodroid runtime support
Improved OSX Mono

Я б не против, если бы NaCl существовал не только в хроме.

Не понял. Я думал, речь о моно в хроме через NaCl, нет?


to анонимус: катись отсюда

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

F#, IronPython and IronRuby (два последних, впрочем, МСу уже не нужны)

Ни один из них не является частью моно. И это нельзя считать догонянием, т.к. F# под моно пилит сам M$, а IronPython и IronRuby - их разработчики (из всего запила под моно у них только набор скриптов для установки под Linux, и пакеты).

New WebMatrix.Data database API.

New C# Compiler backend (can now use any custom mscorlib)

VB Compiler can now compile to both 2.0 and 4.0 profiles.

Где здесь догоняние?

Упростить догоняние:

New Profiler engine

Faster socket stack

Improved Parallel Framework

SGen Precise Stack Scanning and Many performance improvements.

Cecil/Light

Что из этого является, собственно, догонянием или же направлено только на догоняние?

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

Java, как язык где нету даже list comprehension, должен умереть.

Что за бред. Это всего лишь синтаксический сахарок.

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

После него убогость питона ощущается сильнее.

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

Ни один из них не является частью моно. И это нельзя считать догонянием, т.к. F# под моно пилит сам M$

Стало быть, F# делает M$ и частью моно он не является, но тем не менее изменения в F# попадают в список основных изменений в моно. И каким-то совершенно непонятным мне образом эта ситуация используется как аргумент в пользу независимости моно от M$. Мда.

Где здесь догоняние?

Ну, скажем, WebMatrix.Data - это API от M$. Или я что-то недопонял?

Что из этого является, собственно, догонянием или же направлено только на догоняние?

Ну это как улучшение сети в ReactOS - вроде как самостоятельное усовершенствование и развивается по своей внутренней логике, но никоим образом не свидетельствует о целях проекта. Я рад за моно, что у них faster socket stack, ну так и в ReactOS improved network performance.

Вопрос не в том, бывают ли в моно самостоятельные улучшения. Они и в Wine, и в Qt бывают. Вопрос вот в чем: моно - оно как Wine или как Qt?

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

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

Я могу перечислить наших конкурентов, но стоит ли лишний раз их пиарить? И насчёт присосались - Вы попали пальцем в небо. Компания начиналась с обычного shareware. Людям понравился продукт и они готовы были за него платить. Ни крутых инвесторов, ни богатых родственников, ни откатов - ничего не было. Даже интернета поначалу не было, но была фидошная нода и конференция fido7.ru.delphi.

Во-первых, про кодеров было написано в ответ на ваши высказывания «Что хрена ли думать, надо прыгать кодить»

Ай-яй-яй, как нехорошо передёргивать. Разве речь шла о думать? Наксколько я помню, речь шла о «говорить».

«Постойте, у меня все ходы записаны» (с) Ильф и Петров.

Ваш продукт я ковырял, но похоже, что он пошел из VCL-компонентов.

Смотря что называть «вышел». FastReport.VCL - это совершенно другой продукт. FastReport.Net спроектирован заново. Причём, проектировал его человек, до этого выпустивший три версии успешного генератора отчётов, т.е. не по наслышке понимающий предметную область.

Удачи в вашем проекте.

Вот за это большое человеческое спасибо!

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

Вопрос вот в чем: моно - оно как Wine или как Qt?

Как Qt. Чтобы быть как wine, слишком много отличий в API от оригинала :)

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

Вопрос вот в чем: моно - оно как Wine или как Qt?

Оно как если бы Икаса, Мигель де (© педевикия) вдруг взял и решил переписать Qt на GTK+ ;)

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

Qt на GTK+ есть (QGtkStyle), GTK+ на Qt есть (gtk-qt-engine)

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

Языки программирования это вообще синтаксический сахарок над ассемблером.

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

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

Ну 4.2 же ! Это было то-ли с прототипами Жабы, то-ли вообще с Oak-ом.

Джава много раз менялась, особенно после JIT-а.

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

???

Что за грабли с джавой и моно ?

Выше были верные утверждения, что если бы мона пошла своим путем,
а не являлась догоняющей постоянно убегающий от нее .Нет, то все
было бы лучше. Но ситуация такая как она есть, хочется вам того или > нет.

Это даже коментировать не буду. За меня это сделали.

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

Да-да, живее. А этот тред - холивар Scheme vs Common Lisp vs Clojure vs какой-нибудь еще лисп. Да-да, холивар есть, просто мы его не видим :)

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

Вот кстати дико интересно это утверждение.

Особенно умиляет следующее Mono ~ .Net & .Net ~ Java.

Получается Mono ~ Java, по транзитивности.

Как это так Mono одной левой джаву по JIT-онутости догнала ? Что за тесты проводились ?

Кинте пруфов мне пожалуйста (:

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

Тот же пайтон, только сбоку.

А... еще с мета-программированием. Наверное что-бы лисперов наконец заткнуть.

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

О господи... У вас же на голове ОГРОМНЫЙ ДЛЯ-КАЖДОЙ-ЗАДАЧИ-СВОЙ-ИНСТРУМЕНТ !!1

*** Тут кеп стремительно врывается в тред ***

Но язык C++ имеет такое-же отношение к Питону, как я к двоюродной внучке Папы Римского !

Если к Питону прикрутить опциональную статику, никто от этого не умрет. В простоте и скриптовости никто не потеряет, а вот разработчикам крупных библиотек и просто хорошим людям станет ощутимо легче. Даже сам великий диктатор Guido van Rossum, который как и вы, на Хаскеле не писал и рекусию не признает, осознал необходимость статики. Правда так сволочь и не сделал.

И не смотря на всю субъективность моего восприятия ограничености Питона, разработчики не раз мною упоминаемого Groovy, каким-то чудесным образом смогли их все исправить (и далеко не только их).

P.S. Конечно «тру» могут скрипты и на хаскеле написать, в чем им безусловно помогут монады и мощная система типизации функций высшего порядка. Но я своим мирским не постигшим нирваны взором в языке вижу в первую очередь не типизацию.

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

Если к Питону прикрутить опциональную статику, никто от этого не умрет

Есть Boo - статически типизированный компилируемый питонообразный язык. Не имеющий ни одного из недостатков питона :)

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

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

Убейте меня.

Под 3-ку до сих пор почти никто не пишет. Нету половины библиотек.

Перестанте уже писать на своем древнем C !

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

Ну, даже лисперы менее занудны. Библиотеки в трешке тоже наверное не работают «by design» ? Это такой специальный аристократический питон.

В идеале вам бы помогло ознакомление с дизайном языка, с вопросами, который ставил автор(ы), когда его писал(и). Тогда сразу будут понятны ограничения by design, которые в языке заложены и те преимущества, которые язык дает по сравнению с другими языками. А вы пытаетесь впихнуть невпихуемое и при этом ругаете инструмент, а не голову.

ИКЕА by design создана, чтобы ее владелец мог стол к себе на дачу удобно завести.

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

А по существу я уже в предыдущем посте ответил.

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

Не нужно меня обижать (: Я умею пользоваться гуглом, и на SO.com не раз искал САБЖ.

Давай по порядку...

Ну Waf вообще не в тему, конечно. Он на питоне, а не для питона.

Касательно содержательной части. Собственно можно разделить подобные тулзы для Питона на два случая distutils-like и zc.buildout.

Сразу отсечем buildout. Энтерпрайзная фигня сверху, которая делает не имеющие отношения к сабжу вещи.

Так вот, distutils. Их три.

Сам distutils - по дефолту встроен в питон. Сабжа не умеет. Setuptools - дальнейшее развитие distutils. Отличается умением сабжа. Умер. Об этом кстати почти никто не знает, и все дружно жуют кактус. distribute - форк setuptools. Умеет нормальный сайт и красиво-отформатированную доку.

Так вот, поговорим о distribute.

О всяких «мелочах» говорить не буду. Из главного :

1) Он умеет только качать зависимости. То есть на самой машине клиента. Нельзя собирать прогу с зависимостями на компе разраба, в чем собственно весь смысл затеи, и что Maven делает под разными соусами (я уже молчу про упаковку, деплой и все такое).

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

3) Как я уже не раз говорил, чудо так же как и весь PyPI не различает бинарные сборки. Не лечится никак. Нужно подбирать версию у которой есть бинарная сборка, и надеется что убунта не будет жаловаться на отсуствие GCC в системе (: И надеятся, что в винде это тоже прокатит. Версии периодически с PyPI выпиливают, так что число в коде нужно периодически менять.

Единственный тру-вей это вызывать easy_install вручную (через commands.easy_install) и указывать конкретный URL для загрузки. Но тут та же проблема с выпиливанием.

4) Сам distribute не имеется у юзера в системе. И как легко можно догадатся, просто положить в папку с программой его не получится.

Нужно вызвать скрипт distribute_setup.py (его можно скачать у них с оффсайта), который содержит почти всю содержательную часть distribute, и занимется закачкой и установкой distribute в систему. Зачастую криво.

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

mono!=.net даже близко. Когда смотрел в последний раз - местами было в 10 раз тормознее (работа со строками)

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

Мой опыт старше этой статьи: http://habrahabr.ru/blogs/programming/120090/

Единственное в чем жабка лучше .net - строковые операции. В комментах там пишут, что тестирование проводилось не правильно, но что есть то есть. Субъективно (в моих приложениях) java и .net работают примерно сравнимо, а mono отставал (когда я видел в последний раз его). Сейчас я его смотреть не буду, ибо в net использую wpf.

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