Wydano Mono 2.4 oraz MonoDevelop 2.0
- Dodano: 1 kwietnia 2009
- Wprowadził: mith
- Komentarze: 41
Projekt Mono, którego celem jest opracowanie otwartej wieloplatformowej implementacji, stworzonego przez Microsoft, frameworka .Net, doczekał się wersji 2.4. Równocześnie wydane zostało MonoDevelop 2.0.
Główny programista, Miguel de Icaza, informuje na swoim blogu, że najważniejsze zmiany dotyczą przyspieszenia Mono. Poprawiono wsparcie dla instrukcji SIMD oraz działanie aplikacji wielowątkowych. Ulepszono również działanie kontrolki DataGridView.
Częścią składową projektu jest środowisko programistyczne MonoDevelop, wspierające tworzenie aplikacji z wykorzystaniem GTK#. W wydanej właśnie wersji drugiej, zyskało ono znakomitego debuggera. Pojawił się również plugin oferujący wstępną obsługę języka Vala, którego składnia przypomina C#. Zaletą Vali jest fakt, iż napisany w nim kod, jest kompilowany do C, co umożliwia łatwe linkowanie go z całym mnóstwem bibliotek napisanych w tym języku i późniejszą kompilację do postaci binarnej (w odróżnieniu od bytecodu, który wymaga interpretera, co zwykle wiąże się z pewną utratą wydajności).
Kolejną nowością w MonoDevelop jest tryb edycji w stylu Vi. Dodano obsługę schematów kolorów. Ulepszono podpowiadanie składni, które teraz wspiera C# 3.0. Poprawiło się również wsparcie znaczników XML.
Projekt Mono w ciągu kilku lat rozwinął się bardzo i dziś jest już w pełni funkcjonalnym frameworkiem. Stworzono w nim kilka popularnych i lubianych aplikacji, w tym odtwarzacz Banshee oraz GNOME Do. Pełna informacja o wydaniu jest dostępna tutaj.
Tym razem informacja zupełnie serio 
Więcej informacji: http://arstechnica.com/open-source/news/...leased.ars
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
41 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
zdjęcie się nie powieksza po klinięciu nie wiem czy tak być powinno.
News dwaplusdobry
. Samo mono niby zgodne z .net, ale nie zawsze odpali program napisany w .net
Novell dostarcza program do testowania, czy dany program jest zgodny z Mono. Zależy to od wielu czynników. Wkurzające jest też, że bardzo łatwo (wystarczy korzystać z biblioteki gnome w Mono) napisać program pod Mono, który nie działa na .NET (i nawet na Mono w wersji Windowsowej), to tyle jeśli chodzi o przenośność.
Vala w MonoDevelop będzie kompilowana za pomocą valac, czyli nie jako .NET. Przez to pojawia się ciekawe IDE dla Vali.
Wiesz, tego, że program napisany w Mono nie kompiluje się dobrze w .Net, to ja się nie spodziewałem i naprawdę nie uważam, żeby to było aż TAK STRASZNIE ważne. To zupełnie tak samo, jak programy napisane w Lazarusie nie ruszą od ręki (przynajmniej mnie, gdy się jeszcze do Pascala dotykałem, tfu!) pod zwykłym Delphi. Ale tak, jak Lazarus, jest po prostu Mono dla Windowsa, więc zainteresowani programiści raczej bez większych problemów mogą sobie stworzyć podobne, prawie identyczne środowisko pracy na obu systemach. Zresztą, czy program pisany pod Visual Studio bez żadnych kombinacji skompiluje się w Borlandzie? Śmiem wątpić. Dla tych, którzy nic naprawdę nie chcą zmieniać w kodzie, jest Java i Qt (i to nie zawsze).
Chyba nie wiesz co to jest .NET. .NET to jest odpowiednik Javy, więc powinien być przenośny jak Java. Tymczasem piszesz program dla Mono pod linuksem. Dostajesz plik exe. Działa pod Mono na Linuksie bez problemów. Odpalasz go pod Mono na Windows. I nie działa, bo nie przeportowali wszystkich bibliotek (przykładowa biblioteka libgnome, czy jak się tam zwie). TO NIE JEST PRZENOŚNOŚĆ.
PS. Jak możesz porównać Mono do Visual Studio albo Borlanda? To był żart prima aprilisowy czy coś? Może porównasz jeszcze Windowsa do pociągu?
Możesz zarzucić jakimś kodem? Chętnie zobaczę, jak to działa.
Magnes: Nigdy nie uzywalem Mono, ale jesli dziala gorzej niz Borland Delphi (niestety mialem nieszczescie spotkac sie z nim na uczelni) to az boje sie myslec
P.S. Visual Studio uwazam ze naprawde dobre srodowisko, ale niestety nie pisze nic pod .NET
magnez ma racje, program pisany w mono powinien byc przenośny niezależnie od bibliotek graficznego intertfejsu. nieważne czy to windows/gnome/qt powinno to być niezależne.
Założeniem .net nie była przenośność (bo między czym Windowsami?). Założeniem było łatwiejsze programowanie – choćby dzięki zastosowaniu GC. Dzięki zastosowaniu JIT zyskano nawet wystarczającą dla GUI wydajność.
Różnica polega na tym, że biblioteki dla Javy pisane są głównie w Javie. .net postanowiło zaczerpnąć bardziej od języków klejowych i backend korzysta z bibliotek w c/c++, z ładną c# fasadą. To samo jest z GTK#. Biblioteka, jak i programy działają tak samo na Windows, jak i na Linuksie, jedyne co trzeba zrobić to zainstalować gtk i gtk#. Są na to jednolite instalatory. Już bardzo dawno temu udowodnił to MDK http://www.mdk.org.pl/2007/1/28/clone-wars .
"program napisany w mono nie kompiluje sie dobrze w .net" – wiesz o czym piszesz?
nie piszesz programu w "srodowisku", a w jezyku (przypadku mono/.net moze to byc c#, ale i inne jezyki)
to, czy program bedzie sie uruchamial w danym srodowisku – zalezy od tego jakich bibliotek w nim uzyjesz, tj. _czy one sa przenosne_, lub czy maja swoje odpowiedniki z kompatybilnym api w innym srodowisku.
btw. podobnie nie piszesz w "lazarusie/delphi" a w paszczalu – lazarus to tylko gui do gpc, ktory jest kompilatorem m.in. object pascala. tu tez zalezy jakich bibliotek uzyjesz – jesli "jedziesz" po bibliotece standardowej jezyka, dostepnej zarowno pod delphi, jak i pod gpc – to bez roznicy czy pod delphi, czy pod gpc pod winda, czy pod gpc pod uniksoidami – aplikacja bedzie przenosna…
Myślę, że masz wiele racji w tym co napisałeś.
Dodam jeszcze, iż zamierzeniem ludzi tworzących Mono jest, aby możliwe było uruchamianie oprogramowania stworzonego pod Windowsem na innych systemach, np. biblioteka Windows Forms, która w wersji od MS jest w spore jwiększości wrapperem dla WinAPI, w wersji dla Mono została w całości przepisana w C#.
Jeśli chodzi o przenośność, to aplikacje napisane w 100% w C# działają bez problemów na Mono na różnych systemach Ważne jest powstrzymanie się przed używaniem P/Invoke, co mam miejsce w przypadku wielu aplikacji pisanych dla (wyłącznie) platformy Windows.
"np. biblioteka Windows Forms, która w wersji od MS jest w spore jwiększości wrapperem dla WinAPI, w wersji dla Mono została w całości przepisana w C#."
Do czegoś libgdiplus jest
mby7930: jesli aplikacja napisana jest w 100% w c# i do wyswietlania okna uzywa wlasnej implementacji protokolu X, to i tak sie pod winda tak prosto nie uruchomi (tj. Xming pomoze
)
podkreslam: stosowanie konkretnego jezyka nie zapewnia przenosnosci oprogramowania. ta przenosnosc to zarowno uzywanie przenosnego srodowiska uruchomieniowego (jvm, .net/mono, parrot, czy chocby python), ale przy jednoczesnym uzywaniu _przenosnych_ interface programistycznych (odwolanie sie przez dowolne z powyzszych srodowisk do "/proc" celem wykonania jakichs operacji na procesach – calkiem naturalnie nie przejdzie pod np. winda
)
sprae: zarowno przenosnosc (miedzy winda na pc, ale i na mobailach) byla brana pod uwage. wazniejszym jednak czynnikiem bylo uruchamianie aplikacji w wirtualnym srodowisku, co pozwala na zamrozenie aplikacji wraz z srodowiskiem (np. otwartymi plikami, polaczeniami sieciowymi, itp.) po czym przeniesienie jej np. na inny serwer w klastrze, po czym wznowienie dzialania aplikacji.
Mogę się tylko zgodzić.
Na stronie projektu Mono przedstawionych jest kilka sytuacji, gdy uzyskanie przenośności wymaga zmian w pierwotnym kodzie.
http://www.mono-project.com/Guide:_Porting_Winfor…
jellonek: na "mobajle" jak i na xbox360 jest specjalna wersja .net, która nie wspiera nawet sprzętowego FPU. Dlatego nie zalecają w XNA w produktach dla xboxa zbytnich obliczeń zmiennoprzecinkowych.
To z zamrażaniem i przenoszeniem to prawda czy tylko wizja?
Co do protokołu X, to w to nie wierze. Pierwszy błąd to, że używają libgdiplus. Drugi, że te wyśnione biblioteki implementujące protokół X na Windows nie są potrzebne.
"Przez to pojawia się ciekawe IDE dla Vali."
Do Vala jest już IDE nazywa się Val(a)IDE
http://www.valaide.org/
Działa pod Windowsem i Linuksem.
Oczywiście, im więcej IDE tym lepiej.
Vala wydaje się być bardzo dobrym pomysłem.
Nie widzę tam edycji formatek i kontrolek, a to jest w MonoDevelop i działa bardzo dobrze. Mam nadzieję, że z Valą także będzie działać.
Edycje formatek i kontrolek (WIDGETOW!) masz w Glade. To specjalizowane narzędzie do tego.
"formatek" – lol
widze ze juz utrwalilo sie przeniesione z bazodanowego srodowiska (jeszcze chyba z czasów clippera, albo i wczesniejszych) okreslenie…
a nie mozna po staremu – okno nazywac oknem, a nie formatka?
Ja myślę, że to z "delfi"
i z kalki jezykowej angielskiego "form" tam uzytego? to dosc prawdopodobne…
@sprae: W delphi są "komponenty" ;p
Pozwól, że zacytuje pierwsze z brzegu [googla] forum o delphi, gdzie niejaki "SACZI" pisze:
"W jaki sposób zmniejszyć standardowe kontrolki (checkbox, combobox, radiobutton, list box, combobox itd). Zmniejszanie ich uchwytami powoduje jedynie "okrojenie". Skala pozostaje taka sama.
Druga sprawa, to jak ustawić rozmiar tekstu, np 5 lub 6. Zdaje się, że mniejszy od 8 nie można ustawić."
Powinno, nie mam tego zdjęcia w większej rozdziałce po prostu. Ono jest wycięte ze strony głównej MonoDevelop – z loga
[EDIT]: A zresztą… Podlinkowałem stronę MonoDevelop pod obrazek.
Przypomniało mi to, że mam wywalić biblioteki mono ze wszystkich systemów.
jak milo ze ktos w imie fanatyzmu pozbawia sie okreslonych funkcjonalnosci
nie tak dawno podobnie robili fanatycy gnome/kde
ludzka glupota nie zna granic…
@jellonek, ja np wywaliłem mono nie ze względu funkcjonalności, a z tego względu, że tylko tomboy z tego korzystał, a potrzebowałem miejsca na dysku ;] Wszystko ma swoje granice trzeba wyluzować
jesli nie uzywasz zadnych aplikacji – to sie nie dziwie, ale w kontekscie uzytym przz xpt – to bylo dosc… fanatyczne
sam procz do tomboya to chyba do gnome-rdp i gnome-do tylko tego uzywam, chyba ze gdzies jeszcze sie ukrywa cos, o czym nie wiem i w co nie mam zamiaru sie zaglebiac.
jesli nie wadzi – to po co wywalac? ideologia?
Nie, pragmatyka.
i jeszcze LMAO, "określonych funkcjonalności", prima aprilis był wczoraj misiu.
Bytecode niekoniecznie musi wymagać interpretera. Bytecode dalvika jest interpretowany i jest utrata wydajności, ale za to bytecode javy czy CLR (.NET, MONO) jest wyposażony w kompilator JIT, który przy uruchomieniu programu kompiluje bytecode do kodu natywnego. Aktualnie kompilatory JIT są nieco wolniejsze od najnowszych wydań GCC, ale za to są szybsze od GCC 3 i wstecz, więc nie taka ta wirtualna maszyna straszna pod względem prędkości.
bytecode wyposazony w JIT? muahaha
zabawny ten skrot myslowy
pytanie jezykowe, niezartobliwe. jesli juz zostawiamy
„framework”, to odmieniamy „frameworku” czy „frameworka”?
Jeśli analogicznie do wyrazu "worek" (tylko czy można? Wszak tutaj mamy ruchome e), to PWN podaje:
To MonoDevelop nawet przejrzyście wygląda, ale ja mimo wszystko chyba pozostanę przy Qdevelop.
Wolę Gnoma od nowego KDE, ale za mono to bym chętnie strzelił kogoś w głowę. Przecież f-spot czy banshee to muuuuuuły jakich mało. Wieloplatformowa to jest java i każdy wie, jak jest z szybkością i zasobożernością programów w niej napisanych, po co powtarzać błędy?
Czasy Pentium 200 już dawno minęły. Mimo wszystko bardziej podobało mi się działanie aplikacji gtk w ramach mono, niż Pythona na wyżej wymienionym sprzęcie.
Touché!
Większość narzekaczy na "powolność" rozwiązań Java/Mono stara się "nie pamiętać" w tym akurat momencie o tym, że Python wypada w tym porównaniu dużo gorzej.
Nie wiem co jest w pythonie, dużo tego, ale bez przesady, to nie licytacja. To, że programy pythonowe (które, bo aż tak nie mam rozeznania) są wolne, nie oznacza, żeby było to wystarczające usprawiedliwienie dla mułowatości javy/mono. Jestem zdecydowanie przeciwny równaniu w dół, zawsze równajmy do lepszych, bo do gorszych to największa łatwizna i prościzna.
Ja tam bardzo Pythona lubię, to i tak język klejowy klecący w całość różne binarne moduły. Bardzo dobrze nadaje się do pisania logiki aplikacji. Punkt widzenia zależy od punktu siedzenia i na takiej Nokii N8xx moje aplikacje w Pythonie działają o wiele lepiej niż na porównywalnym sprzęcie z rodziny x86 (w granicach 400bogo). A napisałem całkiem rozbudowane.
Najnowsza Java jest od niego wydajniejsza jakieś 400x i mimo to trzeba sobie odpowiedzieć na pytanie – Czy wydajność Pythona mi odpowiada? Jego zasobożerność w średnich aplikacjach sięga mi poniżej 20 MB. Wydajność bardzo mi odpowiada.
Przy nieźle animowanej aplikacji (wiele danych na pseudoanalogowych wskaźnikach) 15fps, na Nokia działa mi 6h (ARM 400MHz + bateria 1500 mAh).
Czy to wystarczająco kompleksowa odpowiedź.
Motto: W inżynierii dokładność, jak i wydajność wyznacza się zgodnie z zapotrzebowaniem, a nie osiągnięciem maksymalnej możliwej. Ekonomia!!!