unicuum, я смотрю, ты упорно игнорируешь текст моих сообщений.
 

Видишь, что тут написано? Тут написано Mac OS. Я же неспроста это написал. И уж если я пишу, что Mono нервно курить в сторонке, то не просто же так.


Я пытался прикрутить его на Mac OS, чтоб отображать 3D сценку в определённой области окна... Это...  Это просто невозможно! 


Ты хочешь, чтобы я перечислил всё, что создано для Java и для Qt?


Спасибо, поржал. Mono - только Linux и только с рабочим столом GNOME. И желательно SuSE. Ибо на Solaris доступна только версия 1.2 (да и то полуофициальная), на Mac OS многое не работает, да и просто делать там нечего с GTK-виджетами, на Windows просто смысла не вижу писать на Mono - сразу на .NET.

Нет не хочу, я знаю, что для них написано.


Смейся дальше, нет необходимости писать на Mono или что ты под этим подразумеваешь. Надо писать для .NET Framework и по мере написания кода анализировать идёт ли поддержка используемого функционала или нет. В конце выйдет приложение, которое будет запускаться без перекомпиляции по крайне мере на GNU/Linux и Windows, проверял сам лично и не только на openSUSE.  

Причём под виндой я его запускал как с помощью .NET Framework, так и с помощью Mono, и компиляторы были майкрософтские, никаких настроек в Visual Studio не менял. А Mac OS X и Solaris вроде как обещали поддержку, но честно говоря мне до лампочки, если ты пробовал, тебе виднее.


Ничего по этому поводу тоже сказать не могу, поддержка должна быть полной. На винде прикручивается с лёгкостью. Для линукса 3д не пробовал, но не думаю, что будут проблемы. А Mac OS X испытать нет возможности, потому что для этого надо иметь ихний макинтош, так как если программировать не на нём, то бесполезно даже пытаться. На моей виртуальной машине виртуальная видеокарта не поддерживает 3D.   Установка на обычный компьютер хакинтош тоже думаю того не стоит с точки зрения программирования.

Добавлено через 7 минут и 42 секунды

Да, кстати, раз уже речь зашла о макинтошах. Посмотри хотя бы вот эти приложения у себя на фирменном эпловском железе с полными драйверами. Потом отпишись, как это всё работает (или не работает) на Mac OS X, только Mono последней версии ставь. Оценим так сказать перспективы для макинтошей непосредственно.  

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



Mono 2.2_5
Запускаем MonoDevelop 2.0 Alpha 2. Что видим?

• Котролы ненативные. Незачод раз!
• Главное меню должно быть всегда в верхней панели. Ибо воистину! Незачод два.
• А где у нас GTK# Application Template? Опа! Нету такого. Если интересно почему - разработчики Mono ну никак не могут написать работающий дизайнер форм для Mac. Если сами разработчики не могут сделать такую (относительную) мелочь, то мне то на что расчитывать?

Большая часть приложений очень сильно привязана к нативным GNOME'овским либам. Ты сам то на Windows запустишь Banshee, Beagle, ... ? 
Всё очень плохо на Mac OS и с реализацией Windows Forms. Пробуем, например, запустить NClass:


Вот такие пироги.

unicuum, я бы сам с удовольствием писал на Mono. Но я руководствуюсь простым принципом: инструмент должен быть адыкватен поставленной задаче. При написании кросс-платформенных GUI приложений по сумме балов Qt вне конкуренции. 

Это сообщение отредактировал(а) kemiisto - 13.2.2009, 01:49

да дерьмо все это ваше программирование... 

Добавлено через 1 минуту и 30 секунд

не совсем согласен, есть-же еще Java

Добавлено через 4 минуты и 39 секунд

а ты уверен, что WinForms под мак вообще писали и что он официально поддерживается?


есть порт banshee под win32

Lazin, это уже по опыту. Я не говорю, что Java не существует, но по сумме баллов...


Да, только действительно рабочую версию обещают не раньше Mono 2.6, запланироанной на June 2009. И что, будем ждать?


Это частности, а в общем и цело очень сильная привязка к GNOME библиотекам.

kemiisto, я смотрю, ты упорно игнорируешь текст моих сообщений.  





Давай разберёмся, что у нас есть:
1. .NET Framework x.x
2. Mono x.x

Среды разработки
1. Visual Studio x.x (для Windows)
2. MonoDevelop (для GNU/Linux)

В итоге программисты могут создать программу:
1. Совместимость только с .NET Framework x.x
2. Совместимость только с Mono x.x
3. Совместимость и с .NET Framework x.x и Mono x.x

Первый и второй вариант рассматривать нет смысла, о третьем должен думать сам программист. Если он сделает что-то неправильно, совместимости не будет.


Я его в винде запустил так просто и через Моно, и через Моно он вылетает, когда делаешь диаграмму. Причём МоМА ясно говорит, что есть три ошибки, проверял для версии 2.2, 2.0 и 1.9, говорит одно и тоже.



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

Так что давай тренироваться не на учебных примерах, возьми для начала SharpChess и запусти на Mac OS X, именно Mac OS X, а не Mac OS. А потом сообщи, какие у тебя глюки или наоборот их отсутствие. Кстати, MoMA указал шесть ошибок


Но вроде это не должно вызвать глюков, хотя в документации советуют убрать вызов this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);, что думаю не сложно.

  Не запускается! Просто висьнет. Никаких Exception, просто повис. 


  Да, бывает.

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



Сделай то что красным выделено, и попробуй запустить. Если не поможет вот скомпилил файл на который MoMA начиная с версии 1.2.5 не ругается, если более старое, то матерится.  

Ну, что ж, попытка номер два, компьютер макинтош, ОС Mac OS X, запуск при помощи Mono 2.2.

unicuum, ни export не помог, ни твой exe не запустился. Симптомы теже - просто виснеть.

Требования:
Макинтош (не хакинтош)
Mac OS X Tiger (10.4) and Leopard (10.5).
Mono 2.2_5 Framework - Universal

Если после этого не пошло, значит или прога плохо написана, или Mono для ОС Х не доделана, или Mono это очередное большое надувательство от майкрософт.  

Я эту штуку запустил на Mono 1.2.5 под Мандривой 2008. Приложение запустилось и всё нарисовало, но когда жмёшь на доску, то прога по тихому вылетает. Причём MoMA говорит, что всё путём для этой версии.  На их сайте сказано, что надо включать для отладки библы моно имитирующие фреймворк, чтобы лучше узнать, что к чему.

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

unicuum, если тебе интересно, ничего не изменилось с вызодом 2.4 (MonoFramework-2.4_7.macos10.novell.universal). И MonoDevelop по-прежнему сырой и неполный. Только терь это даже на офф. сайте написано. Красным по белому:

  

Сегодня я немного познакомился с D, и еще прочитал 2 статьи о D 2.0. Впечатления такие: D 1.0 - вполне себе приятный язык, эдакий refined c++. Писать проще, обобщенное программирование намного проще и мощнее. Немного попахивает Java-й и шарпом(сборка мусора, структуры и классы - не одно и то-же, интерфейсы). Сам язык проще для разработчиков компиляторов, и прочих инструментов, его сравнительно легко парсить.
D 2.0 это вообще вынос мозга. Во первых, D 2.0, это pure functional язык программирования. Не так как haskell, а скорее наоборот, но результат тот-же.
Допустим у нас есть ф-я 

в с++, параметр можно сделать константным, но это нужно скорее программисту, чем компилятору и не гарантирует неизменяемость данных, на которые указывает var
к тому-же, компилятор не может определить, будет-ли ф-я возвращать одно и то-же значение при одних и тех-же входных параметрах
в D 2.0 можно сделать следующее: (ну ручаюсь за безошибочность синтаксиса)

если ф-я some_other_func не чистая(pure), код не скомпилируется, если переменная global_var не invariant, аналогично (причем это строго, а не так, как в с++, когда мы можем убрать const qualifier c помощью const_cast), тоесть чистота ф-ий проверяется с помощью системы типов, как в haskell, только здесь все наоборот, в haskell все по умолчанию чистое и без сайд эффектов, а в D 2.0 все по умолчанию императивное, с возможностью сказать компилятору, что та или иная ф-я(метод) чистая... но как только у нас есть что-то чистое, то смешать его с обычным, императивным кодом не получится.
Еще одно новшество касается многопоточного программирования, но я с этим еще не разобрался, там как-то с помощью системы типов форсируется thread safety...