LINUX.ORG.RU

Вышел MonoDevelop 0.13


0

0

Как то новость прошла мимо ЛОР-а, а список изменений довольно внушительный:

  • появился контроль версий (пока только Subversion)
  • значительно улучшено автодополнение кода, шаблоны в стиле Visual Studio
  • вид списка задач
  • поддержка Web-ссылок
  • различные улучшения в дизайнере Gtk# (undo/redo, интернационализация и др.)
  • поддержка решений (solutions) Visual Studio 2005 "из коробки"!!!
  • интеграция с Makefile
  • Nunit 2.2.9 теперь поставляется с MonoDevelop (и интегрирован в него)
  • исправлена 71 ошибка
  • новые настройки развертывания (deployment) позволяют использовать внешние команды, в том числе сборки RPMs и DEBs
  • ... и многое, многое другое

Release notes: http://www.monodevelop.com/Release_no...

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

Только учитывая, что большинство серверных поделок на .NET пишется с использованием MSSQL, а клиентских - на WinForms, сомневаюсь, что когда-либо будет переносимость с венды на линух для программ сложнее хелловорлда.

anonymous
()

Этот MonoDevelop ну никак до Visual Studio .NET не дотягивает.

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

поддерживать то поддерживает.. но как он это делает... не знаю как обстоят дела с ado, но половина windows.forms не поддерживается однозначно.

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

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

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

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

Ты не прав - сравни тогда количество опускателей лиспа и количество знающих его людей здесь. Мону опускают именно из за ее недостатков и понимая что эта технология всего лишь средство захавать побольше клиентов дав им мнимую кроссплатформенность.

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

> Ты не прав - сравни тогда количество опускателей лиспа и количество знающих его людей здесь. Мону опускают именно из за ее недостатков и понимая что эта технология всего лишь средство захавать побольше клиентов дав им мнимую кроссплатформенность.

Парадигма компонентного программирования сама по себе реализованная как и в Java дает уникальные преимущества при написании приложении несколькими (минимум) людьми. О том что эта среда по максимальному быстродействию может кого-то не устраивать, я не спорю. Но часто ли кому-либо приходится писать приложения высокой доступности в жестких условиях? Или давайте всех кто на асме не программирует называть "быдлокодерами".. Хотя большинство из всех кто здесь постит не знаком даже с особенностями архитектуры x86. Да, это решение более медленное, но не забывайте, что CLR дает возможность работать над одной задачей нескольким людям одновременно. Менеджер памяти проследит за тем, чтобы вам меньше времени пришлось тратить на организацию хранения и освобождения данных. Мультиплатформенность для ваших приложений - это здорово, при учете цены за все это - 0$. не дотягивает до уровня MSVC? Платите за MSVC! А еще лучше за то количество лицензий, которое нужно для открытия своей, скажем, небольшой фирмы.

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

>Парадигма компонентного программирования сама по себе реализованная как >и в Java дает уникальные преимущества при написании приложении >несколькими (минимум) людьми.

Феерический бред. То что ты называешь компонентами - суть есть обычные библиотеки, и чем они глобально отличаются от собратьев в c++/c мне видимо не понять

>Но часто ли кому-либо приходится писать приложения высокой доступности >в жестких условиях?

Я тебе открою страшную тайну но _все_ кодеры кроме пишущих ентерпраиз поделки для внутреннего использования -пишут именно "приложения высокой доступности >в жестких условиях". Игрострой, shareware, mission-critical.. дальше продолжать?

>но не забывайте, что CLR дает возможность работать над одной задачей >нескольким людям одновременно.

снова феерический бред

>Менеджер памяти проследит за тем, чтобы вам меньше времени пришлось >тратить на организацию хранения и освобождения данных

А когда тебе надо дать максимальный fps?

>Мультиплатформенность для ваших приложений - это здорово, при учете >цены за все это - 0$.

Ты в этом так уверен? А что вот случится если сан&ко вдруг откажутся поддерживать дальше джаву? ОС будут развиваться,компиляторы тоже но вот jdk ты уже собрать не сможешь - не будет совместимости. Догадайся куда полетишь ты и твой проект на джаве в этом случае?

signal
()

Microsoft даже мечтать о таком не могла. Ей даже самой не надо обеспечивать кроссплатформенность .net - дятлы сделают это за неё, и притом бесплатно!

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

я знаю ещё две полноценные реализации j2se5, это BEA Systems JRockit, и IBM. + скоро появится Hormony и HotSpot скоро полностью освободят.

http://en.wikipedia.org/wiki/List_of_Java_virtual_machines

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

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

> Феерический бред. То что ты называешь компонентами - суть есть обычные библиотеки, и чем они глобально отличаются от собратьев в c++/c мне видимо не понять

Если ты программер - одиночка то это не значит что все так софт и пишут. Заниматься совместным написанием и использовать сторонние библиотеки - совсем разные вещи. _Надеюсь_ ты это способен понять ;-)

>Я тебе открою страшную тайну но _все_ кодеры кроме пишущих ентерпраиз поделки для внутреннего использования -пишут именно "приложения высокой доступности >в жестких условиях". Игрострой, shareware, mission-critical.. дальше продолжать?

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

> CLR дает возможность работать над одной задачей >нескольким людям одновременно -- снова феерический бред Все пишем dll-ки, и радуемся скорому 2х годичному релизу.

> Менеджер памяти проследит за тем, чтобы вам меньше времени пришлось >тратить на организацию хранения и освобождения данных -- А когда тебе надо дать максимальный fps? Пока ты дебагишь свой acces violation я с удовольствием отдохну в компании друзей

> Ты в этом так уверен? А что вот случится если сан&ко вдруг откажутся поддерживать дальше джаву? ОС будут развиваться,компиляторы тоже но вот jdk ты уже собрать не сможешь - не будет совместимости. Догадайся куда полетишь ты и твой проект на джаве в этом случае?

А поувереннее ? А где цитаты из Нострадамуса ?

Ты конкретно можешь что-то предоставить? Или весь твой опыт сильно перемешан с твоими амбициями из тяжелого детства?

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

> Заниматься совместным написанием и использовать сторонние библиотеки - >совсем разные вещи.

А что совместная разработка это изобретение джавы? А мужики то не знают! (ц)

>Твоя самоцель часто далека от тех задач, которые перед тобой стоят. >Поговори с людьми, которые ставят перед тобой задачу. Уверен, ты >откроешь для себя много нового )

Разговор с этими людьми начинается только в случае не попадания в сроки, заваливания проекта. Если ты часто с подобными товарищами общаешься это значит что "в твоем королевстве не все спокойно"

>Пока ты дебагишь свой acces violation я с удовольствием отдохну в >компании друзей

Зато когда я пофиксю свой segmentation fault я с чувством выполненного долга иду в отличный дорогой ресторан а не в кабак "чиста отдохнуть"

>Ты конкретно можешь что-то предоставить?

А я что тебе что-то должен?

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

>Ты в этом так уверен? А что вот случится если сан&ко вдруг откажутся поддерживать дальше джаву? ОС будут развиваться,компиляторы тоже но вот jdk ты уже собрать не сможешь - не будет совместимости. Догадайся куда полетишь ты и твой проект на джаве в этом случае?

И что, никто не форкнет?

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

> Заниматься совместным написанием и использовать сторонние библиотеки - совсем разные вещи.

Lulz. Рассмотрите поподробнее на примере KDE, пожалуйста. Может и правда мужики-то и не знают что KDE4 надо срочно на C# переписывать, а не мучаться (видимо, поодиночке) со сторонней библиотекой Qt?

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

Только Qt по структуре, принципам разработки очень похожа на жабу:) Почти у всех классов есть общий предок, QObject, встроенное управление памятью с помощью parentов, использования шаблонов только для контейнеров и многое другое. В жабе есть один guideline на создание библиотек, как и в qt.

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

Signal - программист, который боится всего чего не понимает, а понимает он видимо в основном Turbo C или что то в этом роде, боится и не стесняется это демонстрировать публично.

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

>Только Qt по структуре, принципам разработки очень похожа на жабу:)

... и на C# ;) Сегодня, например, с удивлением обнаружил, что в .Net тоже предоставляет масштабируемый GUI по типу Qt с Layout-ами и т.п. Назовите еще преимущества Qt (хотя я ее очень люблю ;), кроме "скорости", кто нибудь сравнивал, кстати?! Как я уже говорил в одном из предыдущих тредов разработка очень схожа на C# и Qt, только огромное количество классов-компонент (где кстати больше в Qt или .Net?!) + Visual Studio ускоряют её (разработку) в разы, надеюсь и MonoDevelop теперь подтянулся немного ;)

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

Кста, нужно было помочь девушке геологу со 2-го курса МГУ, написать курсовик на C# - игру с графикой. До этого ни c#, directx в глаза не видел, юзал только opengl. Заняло у меня всего 2 дня и два вечера написание проги. Так что для меня пока c# гадость (пока?) только идеологическая.

По сравнению с жабой ( в виде swing) и .net - практически нативный вид GUI, концепция сигналов и слотов, которая проще, чем делегаты в c# ( до java пока не добрался). В qt 4.2 появились stylesheet для виджетов, что ОЧЕНЬ удобно, когда нужно поменять вид элемента, а стиль создавать накладно. В qt пока плохо одно - он нацелен на GUI, тогда как и на java, и на .net можно писать и серверное ПО.

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

>Только Qt по структуре, принципам разработки очень похожа на жабу:)

>В жабе есть один guideline на создание библиотек, как и в qt.

Если это типо юмор -ладно ,если ты на самом деле так думаешь - пей яд до упора

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

>Signal - программист, который программирует ради программирования. >Может пора взрослеть?

>Signal - программист, который боится всего чего не понимает, а понимает >он видимо в основном Turbo C или что то в этом роде, боится и не >стесняется это демонстрировать публично.

>+1 Типичный красноглазый. Должно пройти, прыщи на роже тоже проходят.

Это что хор быдлокодеров? Или у студентов сессия кончилась?

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

> То что ты называешь компонентами - суть есть обычные библиотеки, и чем они глобально отличаются от собратьев в c++/c мне видимо не понять

Отсутствием оных на C++ в принципе практически и софершенно астральной мешаниной на C?

>А когда тебе надо дать максимальный fps?

А ты видишь разницей между предсказуемостью точки освобождения ресурса и предсказуемостью времени освобождения ресурса?

>А что вот случится если сан&ко вдруг откажутся поддерживать дальше джаву?

Джаву делает очень много компаний. Сан майнстримит только под винлинарис, а есть еще другие платформы. Есть еще IBM, Bea, Apache и т.д. Короче про феерический ты сам заметил правильно:)

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

Твои закосы под ВСЛ не катят не разу, тк ВСЛ ещё и делал, и доказывал свою точку зрения. Ты хотя бы одну программу на qt писал? А на java? А с использованием boosta?

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

>Рассмотрите поподробнее на примере KDE, пожалуйста.

Рассмотри на втором примере пожалуста. Qt это тот же самы JRE для C++ где троли озаботились написанием всего что им надо самим. Найди совместимые с Qt библиотеки к Qt отношения не имеющие.

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

>А что вот случится если сан&ко вдруг откажутся поддерживать дальше джаву?

А что случится, если перестанут поддерживать твою библиотеку?

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

> Только Qt по структуре, принципам разработки очень похожа на жабу:)

Хорошо, предположим что так (к моно и жабе у меня душа и знания не лежат как-то - не было ни необходимости ни желания дальше hello world'а учить). Но так и моножаба тогда, оказывается, не такая и особая и важная вещь.

И для совместной разработки нужно все-таки не CLR, а система контроля версий, guidelines и, как их подраздел, документация кто над чем работает и как это все объединяется и друг с другом взаимодействует. Что реализуемо хоть для C, хоть для C++, хоть для C#.

Но самое мне вот интересное - а где плюсы Mono тогда? Виден только четкий минус в лице лишнего слоя - виртуальной машины (лол, зачем оно само по себе нужно? чтобы народ не расслаблялся и покупал новое железо - "жабе чтобы не тормозить нужен кластер"(q)недавняя тема?) с дворником (у нас есть Qt, есть boost::shared_ptr, и, в конце-концов есть "ручной привод" Valgrind) и песочницей (у нас есть ядро, отлично знающее как запихать процесс в chroot'овую песочницу и что делать с привелегиями). Плюс не такая уж и хорошая портируемость - хорошо это или плохо, но в упор не вижу толп оффтопиковых программ, а вот Qt'шные кроссплатформенны, наверное, в большинстве случаев.

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

>Что реализуемо хоть для C, хоть для C++

Теоретически. На практике такого нет для C++/C.

>Виден только четкий минус в лице лишнего слоя - виртуальной машины

Ого. Догадайся с трех раз почему на хостингах CGI на C/++ не пускают а на жабе пускают? Вот подумай, что обеспечивает такие возможности.

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

>Отсутствием оных на C++ в принципе практически и софершенно астральной >мешаниной на C?

Ну разьясни мне тупому что такое "компонента" и чем она кардинально отличается от всего остального. Может и вправду за столько лет кодинга чего-то не догнал :)

>А ты видишь разницей между предсказуемостью точки освобождения ресурса >и предсказуемостью времени освобождения ресурса?

А при чем тут это?

>Джаву делает очень много компаний. Сан майнстримит только под >винлинарис, а есть еще другие платформы. Есть еще IBM, Bea, Apache и >т.д. Короче про феерический ты сам заметил правильно:)

Ох как достал уже этот гон про кучу разработчиков джавы.Нет у джавы других разработчиков кроме сана. То что от ibm и bea -это "другие джавы(c)", со своими заморочками и несовместимостями.Причем косяки с совместимостью вылезают такие что разработчики специально пишут для какой реализации jdk их поделие сделано.И предназначены они для работы в основном на сервере (особенно от bea). Так что если загнется релиз от сана - загнутся и остальные.

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

>Ого. Догадайся с трех раз почему на хостингах CGI на C/++ не пускают а >на жабе пускают? Вот подумай, что обеспечивает такие возможности.

Это какая же должна быть ошибка в днк чтобы пускать джаву через CGI... как говорится ноу комментс :)

Можно хоть название хостера узнать который таким занимается?

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

>другие джавы

список несовместимостей в студию, вместе с объективной оценкой стоимости портированя с HotSpot'а на "другие джавы(c)".

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

>ну по придирайся к словам. сервлеты для джавы он имел ввиду, если >имбецилу не понятно.

шел бы ты в школу детка.Нечего тебе на лоре троллить :)

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

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

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

>Только Qt по структуре, принципам разработки очень похожа на жабу:) Почти у всех классов есть общий предок, QObject,

Это ещё в Turbo Vision было.

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

>Ну разьясни мне тупому что такое "компонента" и чем она кардинально отличается от всего остального.

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

>А при чем тут это?

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

>Нет у джавы других разработчиков кроме сана.

А под разными hp, irix, aix, bsd, apple и прочей бойдой святой дух работает?

>Так что если загнется релиз от сана - загнутся и остальные.

Это приблизительно равновероятно загибанию linux.

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

>Это какая же должна быть ошибка в днк чтобы пускать джаву через CGI... как говорится ноу комментс :)

Не через CGI. Имеется ввиду что на жабе хостеры предоставляют хостинг а на си с крестами нет. Почему? Хостинг - это так близкий пример. VM он не только мусор собирать, он еще обеспечивает много интересных вещей - например безопасность исполнения кода.

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

>Я не о компонентах, а о библиотеках и общей культуре их написания.

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

>А под разными hp, irix, aix, bsd, apple и прочей бойдой святой дух >работает?

hp-ux,irix,aix -реализация джавы от sun. bsd -официально не поддерживается.Под маки есть своя реализация от Apple да.

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

>Имеется ввиду что на жабе хостеры предоставляют хостинг а на си с >крестами нет. Почему?

По той же причине по которой нет платного хостинга на лиспе или брейнфаке -спрос рождает предложение. Те кому нужен c++ на сервере (а соответственно большая скорость) не используют сторонний хостинг (в крайнем случае аренда физического сервера)

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

> Теоретически. На практике такого нет для C++/C.

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

Более того, если так не сделать, и начать что-то писать группой, то вылезет куча костылей из-за различных взглядов каждого разработчика. Лично имел опыт: вдвоем быстро писали прокси-переходник между парой биллингов и одним (не буду говорить точно) быдлоmiddleware ("быдло" - потому что он, несмотря на всю свою энтерпрайзовость, жабонаписанность и "взрослый" номер версии без костылей даже логи не умел вести человеческие, а транзакции братья-индусы, писавшие этого монстра, вообще ниасилили). Подумали "а, ну его, там кода-то - мелочи, а на документацию только время потратим" - в итоге каждый со своей стороны в коде поднагородили небольших, но костылей, компенсирующих чужие взгляды и ожидания.

> Догадайся с трех раз почему на хостингах CGI на C/++ не пускают а на жабе пускают? Вот подумай, что обеспечивает такие возможности.

На "типичном" shared-хостинге - самое большое "почему" - неспособность Apache выдавать по отдельному юзеру на виртуальный хост. Поэтому даже Perl не дают, а ограничиваются похапэ (с его внутренними костылями) или жабой или еще чем такого рода. Есть один единственный mpm (peruser, что-ли) и тот не живой. Как я слышал, проблемы в архитектуре апача, который не предусмотрен для таких фокусов. Другие httpd не смотрел (все есть желание lighttpd посмотреть, говорят он хороший, но руки не доходят).

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

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

>Культура у каждого своя

В мире C++ да. В мире Java/.NET нет. В качестве примера загляни хоть бы на apache.

>hp-ux,irix,aix -реализация джавы от sun.

Да ты шо! Ссылку дашь где качать? И как получилось что под Irix жаба обогнала по возможностям (например по ограничением на объемы памяти) все прочие? И с какой радости сантехники упражняются под aix?

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

>По той же причине по которой нет платного хостинга на лиспе или брейнфаке -спрос рождает предложение.

Феерический бред. (C)... Причина тут проста - в жабе можно сделать так чтобы клиент не пакостил хостеру и остальным в C/++ он напакостит мгновенно.

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

>Собираемся, пишем документ

Пишите, Шура, пишите. Вы нам потом расскажете как вам удалось убедить коммьюнити, которое чего-то там ваяет на сорсефорже и в прочих местах следовать вашему документу.

Я говорю о том что в мире плюсов во внешней природе (как говорят мои америкосы - в буше) нету никаких стандартов, общей практики и принципов. Каждый пишет как на душу положит.

А в своей песочнице естественно вам никто не запрещает сделать все по своему стандарту. Например все самому реализовать.

>Поэтому даже Perl не дают

Перл и питон есть где попало. Ими ничего страшного не натворишь. Например не заковыряешься в шаред мемори апача или не скажешь ему застрелиться нафиг.

>Как я слышал, проблемы в архитектуре апача, который не предусмотрен для таких фокусов.

Да уж - забыли в апаче предусмотреть запрет прямого доступа в память из запускаемых програм, и способы контроля вызова всяких интересных systemов, execoв и прочих exitов.

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

>В мире C++ да. В мире Java/.NET нет.

Тебе показать пример отсутствия культуры программирования на джаве?

>Да ты шо! Ссылку дашь где качать?

Ну выразился я неверно - реализация полностью совместимого с сановской но от sgi и тд.

Но по сути это та же джава что и от санок. Нет таких отличий как между ibm-вской jdk и сановской

> И как получилось что под Irix жаба обогнала по возможностям (например по ограничением на объемы памяти) все прочие?

Я думаю по причине особой прямоты рук :)

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

>Причина тут проста - в жабе можно сделать так чтобы клиент не пакостил >хостеру и остальным в C/++ он напакостит мгновенно.

В джаве это тоже можно сделать,не волнуйся :) А причина тут только экономическая - за что платят то и строят.

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

>Я говорю о том что в мире плюсов во внешней природе (как говорят мои >америкосы - в буше) нету никаких стандартов, общей практики и >принципов. Каждый пишет как на душу положит.

Писать как бог на душу положит можно на любом языке. Проверено перлом :)

Просто эта общая практика и принципы приходят только с опытом.

>Да уж - забыли в апаче предусмотреть запрет прямого доступа в память из >запускаемых програм, и способы контроля вызова всяких интересных >systemов, execoв и прочих exitов.

Что с успехом дополняют всякие php :)

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